Subject: RE: [mobile-ip] GPRS Tunnel Protocol (GTP)

From: [email-masked]
Date: Mon, 28 Jul 2003 12:24:42 +0100

Ed,

Thanks for your comments. Please find my response  in line.

>Unless I'm misreading this, it sounds like you are recommending that the
>issues that MIPv6 route optimization introduces to GPRS packet filtering
>(performed by gateway nodes, part of the GPRS infrastructure) should not
>be fixed on the GPRS gateway nodes, but instead should be fixed in all
>MIPv6 CNs

Maybe there are some misunderstandings.

1) The inter-working issues are not limited to  MIPv6 Route Optimisation only.
An MIPv6 CN will expererience similar problems to send packets across GPRS/UMTS
network  if HA Tunnelling is used.

2)  The I-D does not argue that  all  MIPv6 CN should be fixed  to support GPRS
packet filtering. It does NOT propose  that MIPv6 need "fixing", rather that
there are some interworking issues that need to be investigated and an optional
function proposed.

We did this because we believe that  most of us who are interested  in  or have
seen the value of MIPv6 would like to see  if there are any issues in its real
deployment, especially in one of the most important global 3G  wireless/mobile
systems.  So far, I have not heard any objections to those " problem
statements".

And I believe that  all of us would be happy to see that MIPv6 will eventually
inter-work with GPRS/UMTS without any problems.

>(i.e. all non-GPRS servers on the IPv6 Internet,
>MIPv6-capable, now forced to implement this brand new GPRS-specific
>Hop-by-Hop Options Header requirement solely to avoid needing to upgrade
> the GPRS gateway nodes).

The  I-D proposes  an optional  function for IPv6 nodes if they use MIPv6 so as
to avoid  some  interworking problems with GPRS/UMTS. This is included in the
I-D for open discussion. We believe that the expertise is in this group and the
viable solution(s) lie(s) in the hand of the group members that will help us
address this issue.

>IMO this is the wrong recommendation...

Thank you for pointing out something that may not  be appropriate. We will look
at the issue and make some changes.

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

All in all, we would like  to raise the issues to the attention to the relevant
WG and work with the WG to work out the best solution; as such we would welcome
any proposals or collaborations in this area.

Regards,

Xiaobao Chen

Orange PCS

Email: [email-masked]
Mobile: +44 (0) 7989 477 679

"Ed Remmell" <[email-masked]> on 24/07/2003 18:09:38

To:   Xiaobao CHEN/EN/HTLUK@HTLUK
      "'Ashish Sharma'" <[email-masked]>
cc:   "'Anurag Uxa'" <[email-masked]>
      "'Amir Hermelin'" <[email-masked]>
      [email-masked]
      [email-masked]
      Martin HARRIS/EN/HTLUK@HTLUK
      Nick SAMPSON/EN/HTLUK@HTLUK

Subject:  RE: [mobile-ip] GPRS Tunnel Protocol (GTP)

Xiaobao -

> 4) Mobile IPv6, however, is expected to have some impact on
> some  operations on GPRS/UMTS, especially on IPv6 (only) IMS.
> This is  because Mobile IPv6 runs on an end-to-end basis,
> i.e, an IPv6 GPRS/UMTS terminal can activate MIPv6 with its
> peers without the knowledge of the intermediate GPRS/UMTS
> systems. We have done some analysis. The details can be found
> in an I-D located at
> http://www.ietf.org/internet-drafts/draft-chen-mobileip-packet
> -fitlering-xc-01.txt
> .

>From this draft:

"4.1.2 The Case of Route Optimisation when the CN is mobile
...

   A typical example is the case when  the GSSN uses ingress
   filtering for selecting the UMTS sessions.Although the packet sent
   from the mobile CN to the MN has the  "Home Address Destination
   Option" containing its Home  address[1], a gateway node as
   an intermediate node operating standard IPv6 does not read it.
   This will have some serious implications such as the disruption of
   existing live sessions."

"5. Requirements on Inter-working Mobile IPv6 with Packet Filtering

   The following requirements are recommended for a gateway node that
   performs source address and/or destination address based packet
   filtering:

   * A gateway node running standard IPv6 should not be required to
     change to support packet filtering function.

   * The policy control functions for packet filtering such as the PCF
     should not be aware of the mobility control based on mobile IP."

"6.1.2 The Recommended Practice in case of Route Optimisation

   For a CN communicating to a MN using route optimisation
   to send packets directly to the MN, the CN should insert its IP
   address in the Hop-by-Hop Options Header. In the case where the CN
   is a mobile itself and away from its network, the CN should insert
   its Home IP address in the Options filed in the Hop-by-Hop Options
   Header."

Unless I'm misreading this, it sounds like you are recommending that the
issues that MIPv6 route optimization introduces to GPRS packet filtering
(performed by gateway nodes, part of the GPRS infrastructure) should not
be fixed on the GPRS gateway nodes, but instead should be fixed in all
MIPv6 CNs (i.e. all non-GPRS servers on the IPv6 Internet,
MIPv6-capable, now forced to implement this brand new GPRS-specific
Hop-by-Hop Options Header requirement solely to avoid needing to upgrade
the GPRS gateway nodes). IMO this is the wrong recommendation... you
should fix this problem in the GPRS gateway nodes.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003

*******************************************************************************
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: Tue, 29 Jul 2003 10:45:11 +1000

Hi Xiaobao,

[email-masked] wrote:
[much discussion cut]
> 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