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

From: [email-masked]
Date: Wed, 30 Jul 2003 10:47:47 +0100

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-masked]> on 29/07/2003 01:45:11

Please respond to [email-masked]

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

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

Hi Xiaobao,

[email-masked] 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.
*******************************************************************************

---

From: Greg Daley <[email-masked]>
Date: Thu, 31 Jul 2003 11:19:58 +1000

Hi Xiaobao,

> If it has calused any confusion, we will cosider to delete it in the revised

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.

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

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

> IPv6 may choose to use. But again this is open for discussion  and there may be

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