Re: Internet Source address filtering in 3G Networks

[email protected] Wed, 30 Jul 2003 10:47:47 +0100
Newsgroups gmane.ietf.mobileip
Message-ID <80256D73.0035204F.00@ruddick>
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.

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


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


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


>We're talking about having end-to-end communucations here,
>so the presence of intermediate machines either should be
>unobtrusive, or explicitly configured on the applicable hosts.


I assume that this could be one of the many options. Hopefully a better solution
can be found.





Regards,

Xiaobao




Greg Daley <[email protected]> on 29/07/2003 01:45:11

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:  [mobile-ip] Internet Source address filtering in 3G Networks



Hi Xiaobao,

[email protected] wrote:
[much discussion cut]
>>should fix this problem in the GPRS gateway nodes.
>
>
> Thank  you  for proposing a solution which we had  considered very carefully
> before we raised the issues to  group.This solution  would require some
> fundamental changes to the current GPRS/UMTS deployments that are already in
> operation or being rolled out. This could involve major cost and have
> significant implications for networks.
>
> Alternatively,changing GPRS/UMTS means  to change the GPRS/UMTS specs to
> restrict the use of  some or all of MIPv6 functions in GPRS/UMTS IPv6 nodes. I
> am sure very few people would like to see this practice.
>
> Even if GPRS/UMTS could be changed to support MIPv6,  do you think that these
> kind of " packet filtering" are only limited to GPRS/UMTS network ?

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.

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.

There aren't many others.

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.

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.

If there is no business case to modify the (in this case firewall)
devices, then the change will not take place.

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.

We're talking about having end-to-end communucations here,
so the presence of intermediate machines either should be
unobtrusive, or explicitly configured on the applicable hosts.

Just dropping packets isn't good enough.

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.
*******************************************************************************
att1.eml (application/octet-stream, 7 KB) - not displayed