Re: Internet Source address filtering in 3G Networks

Hi Greg,

My response to your comments in line.


Regards,

Xiaobao




Greg Daley <[email protected]> on 31/07/2003 02:19:58

Please respond to [email protected]




To:   Xiaobao CHEN/EN/HTLUK@HTLUK
cc:   Ed Remmell <[email protected]>
      [email protected]
      Martin HARRIS/EN/HTLUK@HTLUK
      Nick SAMPSON/EN/HTLUK@HTLUK


Subject:  Re: [mobile-ip] Internet Source address filtering in 3G Networks



Hi Xiaobao,

>>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.

We have also realised that  the issues are not limited to some  GPRS/UMTS
specific  functions.


>Systems which rely upon state being maintained in a
>ateway 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.

 Not sure where this requirement comes from. Could you please provide any
reference ?

>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.

 This is an interesting point. FYI, we found no problem with MIPv4 because we
can choose to use its FA-COA mode. But it is different for MIPv6.

>
>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.
>
I am not sure I would agree with you on those general requirements for modifying
some existing protocols so as to support a new protocol.   Maybe I should
iterate it again: no proposal or intention has been made in our  I-D to change
Mobile IPv6 protocol design to suit GPRS/UMTS needs; we raise the issue and
hopefully a good solution can be found.  I am sure that you know of the work
item in mip4 WG on interworking between VPN and MIPv4: problem recognised and
solutions proposed !

Although the interworking issues with MIPv6  stated in our I-D come from some
specific GPRS/UMTS functions, we think that these are similar to some more
generic functions in Firewalls/NAT and your previous comments seem to provide
some good evidence that these issues do exist.  It is too early or impractical
to state that  existing protocols should be changed to support a new protocol.
We believe that this should be studied case by case.
>
> >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.

>>
>> 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.

We are aware of the possible performance impact from  processing the hop-by-hop
option on the intermediate routers. But have you ever considered what  if extra
singalling messages need to be exchanged  across the expensive air interface to
make the "middleboxes" aware of each movement of potentially hundreds of
thousands of mobile nodes  !!!


>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?

More detailes will be appreciated.  Are you suggesting that the "middleboxes"
should look at the "Routing Header Type 2"/"Home Address Destination" options ?
Is this alway possible ?


Greg


*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************