Re: Internet Source address filtering in 3G Networks

Hi Xiaobao,

[email protected] wrote:
> Hello Greg,
> 
> Many thanks for your comments. My response is in line.
> 
> 
>>As you mentioned in your draft, current ISP source address filtering
>>is to prevent nodes on the ISP's own access network from
>>spoofing addresses on outbound packets.   This is not what
>>GPRS/UMTS networks do.
> 
> 
> You are correct. But GPRS/UMTS has a similar function called SBLP (Service-based
> Local Policy) in its IMS  to prevent ToS attacks by checking the destination
> address(s). The ingress filtering for preventing source address spoofing is
> included in the I-D for comparing it with the "packet filtering" in GPRS/UMTS.
> If it has calused any confusion, we will cosider to delete it in the revised
> version.

I think the issue is largely because the
role of source address filtering on Internet
bound packets is mandated because of the
routing topology.

This technology is far more like Firewalls or NATs.

> 
>>It's worth considering what types of devices currently undertake
>>packet classification on ingress to an access network, from the
>>Internet, based on Source addresses today.
> 
> 
>>These are essentially: Firewalls (including application level
>>proxies, and stateful L3 agents) and NAT systems.
> 
> 
> Thank you for the suggestion. We are looking at  some other more generic devices
> that perform some kind of paket filtering functions  to understand if there are
> any issues in common with those in GPRS/UMTS. Hopefully,  a generic solution can
> be found to solve the problem.
 >
> 
>>In the case of firewalls, it is part of the process that firewalls
>>inspect outbound packets (such as signalling packets for Multimedia
>>sessions) and make modifications to the filter state for this.
> 
> 
>>This is done routinely as new protocols are adopted.
> 
> 
> I am not sure if I understand your above comments.   What kind of pakcet
> inspection are you talking about ? How and when would the firewall get to know
> that it needs to change its packet inspection and/or the associated policies ?
> Does the firewall need to be aware of  MIP based mobility ?  ...
> 

Systems which rely upon state being maintained in a
gateway must be able to identify when the state changes.

This means that they have to be able to read and understand the
relevant parts of the packets involved in those protocols.

If there is a new protocol which, for example has dynamic
port assignment (like FTP), don't have ports (like ESP) or
does signalling and exchanges peer IP address&port information
(like H.323), then modified inspector methods which support
these protocols have to be defined (or modifications to the
original protocol need to be made).

Firewalling systems have been creating methods to interpret
new protocols as they are rolled out within networks.
These are programmed and supplied as part of software upgrades
to firewall systems (and the upgrade may be a manual process).

In the case of MIPv6, the Firewall is likely to require some
knowledge of Mobile IPv6 or MIPv4, but this is not (explicitly)
the requirement of the protocol designers in most cases.

Previous experiences where systems have had to make modifications
to IPSec so that it can pass through NAT systems are a case in point.
If the need is great enough, modifications can be made, but
we should probably not start bending protocol designs to
suit middleboxes.

>>It doesn't need hardware upgrades (although software upgrades
>>are required).  This has been the case for many years,
>>and such change becomes driven by the balance between user
>>and service provider or enterprise security policy.
> 
> 
> This may have been the practice for many years. But is there any problem with
> this practice when IPv6 mobility is introduced into the IPv6 nodes ?


I don't think that this is a problem, so long as it is
achievable.

>>Modifications to network protocols (especially protocols
>>which have been in standardization processes for as long
>>a time as MIPv6) take MUCH longer and have impact further
>>afield than the systems experiencing problems due to packet
>>filtering.
> 
> 
>>This can be seen with the case of NATs (which also experience
>>loss if packets arrive with different header formats
>>than those previously registered).   It is important that
>>the introduction of packet filtering or classification
>>technology in one environment doesn't force modification
>>of protocols such as IPSec, or MobileIP, simply because
>>the next header is not TCP, or because an address may
>>change.
> 
> 
> Well, there has been no suggestion in the I-D to change any  network protocol
> including MIPv6. What is proposed in the I-D is an optional function that the
> IPv6 may choose to use. But again this is open for discussion  and there may be
> well a better option.

I actually think that the practice of recommending a hop-by-hop
options header for packets traversing the Internet (as
opposed to those which travel locally across one or two hops)
is a _BAD_ idea.

Hop-by-hop options MUST be inspected by every router along the
path, while there are at most two devices (one in each UMTS network)
which are interested in this packet.

For the benefit of these two devices, the packet will not be
transferred on the forwarding fast-path (if such exists) and
will be referred to a CPU for futher processing on every hop.

This is a serious performance hit on everyone's routers
(especially the core's, if this practice becomes prevalent).

It would be better if the interested nodes just inspected
mobility options and destination options and inferred the
connection state for themselves, wouldn't it?

Greg