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

From: [email-masked]
Date: Fri, 1 Aug 2003 18:24:05 +0100

Hi,

Your comments are appreciated. My response is line line.

Regards,

Xiaobao

Orange PCS

Soliman Hesham <[email-masked]> on 31/07/2003 05:12:01

To:   Xiaobao CHEN/EN/HTLUK@HTLUK
cc:   [email-masked]
      [email-masked]
      [email-masked]
      [email-masked]
      "'Ashish Sharma'" <[email-masked]>
      "'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)

>>TFT operates separately from IMS SBLP.

>=> I realise that but I think you might end up with
similar problems in IMS.

>>So there are two obvious alternatives for solving this:
>>- Make the UE use the right address in the PDP context setup
>>for the TFT.

>Things are not that simple.  The UE (  or specifically the MT)  will only
know
>when  and how to  update the TFT when the MIPv6 function (speficially, the
>binding update process is successful) is activated. And the MIPv6 control
>messages may not be able to get through to the  UE  because the control
messages
>may get blocked by the GGSN in the first place.

>=> why would the GGSN would block that? I can't think of
a good reason.

The Binding Update will experience the same problem  with that for the data
packets; the assumption is that the mobile ip control messages will use  the
same GPRS/UMTS session for data packets.  When the Binding Update message
arrives at the GGSN, the GGSN will need to select the appropriate GPRS/UMTS
session with the right QoS. For MIPv6 Route Optimisation, as an example, the
correspodent binding update coming from a mobile CN will use its CoA as the
Source Address once it is away from its Home Network and attached to foreign
network and the similar problem happens ....

Similarly for SBLP in IMS,  a Binding Update message to HA may fail to pass the
GGSN filtering because the authorised destination address is not the HA's
address.

  And there are some other
>associated issues such as the existing standards may not allow the MT to
change
>the TFT for a 2ndary PDP Context, ....

>=> I can't parse the above. Existing standard do not
>stop you from extending the TFT for a secondary
>context. Especially if there is a clear problem like
>this. You might even want to push for it to be changed
>for previous releases on the grounds that MIPv6
>was also designed this way and people always knew
>that this will be a problem. In fact I remember coauthoring
>a contribution once on this years ago and it got no
>attention.

I remember that similar attempts were made for different reasons;  With regard
to changing TFT/2nd PDP Context for supporting MIPv6, this means that each time
mobile node moves at  either end and starts using MIPv6,  then there would be
some extra messages back and forth across the  expensive air interface and the
GGSN would have to remember the states related to MIPv6 related states as well
as those for  GPRS/UMTS session management  plus those for QoS .... a for each
UE for both uplink and downlink directions. Not sure how practical this solution
is.

Even if TFT in 2ndary PDP Context could be changed, the UE would only know  how
to change the TFT only when the Binding Update is successful. But the Binding
update messages would only be able to pass the GGSN when the TFT or SBLP
information is updated.  But without the binding update, the UE does not know
how to change the TFT ....

In addition, the SBLP authorisation information comes from the Application
Layer, changing the SBLP means that the session will need to be re-authorised by
the Application Layer (PCF/P-CSCF). Do you think that this is practical each
time Mobile IPv6 is activated by the IPv6 nodes ? Would the so-called "seamless
mobility "  be possible  by adopting this solution  ? ....

>>In the first alternative, the MT's implementation could
>>snoop the PDP context activation messages and get the
>>IPv6 prefix that is allocated to the UE and replace the
>>HoA in any messages that are sent to set the TFT with the CoA.
>>However, this will clearly not work for the CN if it
>>were also mobile because the MT could not possibly
>>know what the CN's CoA would be.

>Correct. And for this to work, the MIPv6 control messages will have to pass
>through the GPRS/UMTS network in the first place.

>=> They do pass through the network. Note the word
>"snoop". It does not have to be addressed to the GGSN.

Maybe I missed your point. But the UE will have to let the GGSN know what TFT it
selects for which session/QoS. And once it is accepted and the session is set
up, the GGSN will use this TFT to select the right sesssion to  transmit an
incoming packet.

>- Add a "MIP flag" in the message that sets up the TFT
>(PDP context)and make the GGSN parse the packet to check for
>the real addresses.

>>The second bullet above would imply making the GGSN
>>aware of IPv6 headers and parse them to see if the
>>HoA is included in the HAO (for route opt) or inside
>>the tunnel (when the packets are forwarded by the HA).

>I am just wondering if this HAO or the packet information inside the tunnel
is
>always possible to check by the GGSN. What if E2E IPSec is applied ?... Any
>clarification would be appreciated.

=> Two comments:
>- When communicating with a CN and IPsec is used
>the HAO will be visible.
>- When IPsec only covers the HA-MN path then
>there is no HAO, but the TFT includes the SPD
>and the flow label so you can filter on either
>one of those, with the src and dst addresses.

I am not sure if  I understand what you mean. As you are aware, not all three
options of TFT combinations  include SPI but the Source Address is included in
all three options.  If the Source Address does not match whichever optional
combination of TFT is used, there will be some problems as described in the I-D.

Hesham

*******************************************************************************
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: Soliman Hesham <[email-masked]>
Date: Fri, 1 Aug 2003 23:47:42 -0400

know
messages

a good reason.

>session with the right QoS. 

=> I disagree with this sequence of events. As soon as the link
is up, a MN would send the BU to its HA (after receiving
the RA). So, unless you have a "static" TFT (i.e.
the TFT is setup irrespective of the application running)
the scenario you describe should never happen. The QoS requirements
in the TFT come from apps. The BU to the HA is sent before
any apps have started so I fail to see how the BU would
not be allowed unless your default is not to allow
anything and this should not be the case.

>GGSN filtering because the authorised destination address is not the HA's

=> Well, not for the first BU. For the second BU to the HA
(refreshing) this might be the case. But the UE will need to
ensure that the secondary PDP context allows BUs to the HA.
I don't understand the problem. In short, make sure that 
if MIPv6 exists, the UE always allows traffic with the 
following filters:
- src : CoA
- dst: HA
- Proto: Mobility header

>UE for both uplink and downlink directions. Not sure how practical this
solution

=> Not sure how practical the limitation is :)
If you don't like this then always allow IP packets
as follows:
- Src: any
- dst: any
- Proto: Mobility header
This means that you will always allow MIPv6 signalling
independently of the sender or the receiver.

>how to change the TFT ....

=> See above. Once the signalling is through the UE can
update the filter. So your safest bet is to always allow
proto = mobility header to get through. This solves the
signalling part. To solve the QoS filtering for data 
then you can use one of the solutions discussed earlier.

>mobility "  be possible  by adopting this solution  ? ....

=> Well, there is no seamless IP mobility issues for a UMTS
UE! The UE will _never_ move. So I assume you are referring
to the peer's mobility. As I said in previous emails, you
can always filter on the HAO if RO is used. If packets
are delivered by the HA, then you can look inside the 
tunnel. 

>combination of TFT is used, there will be some problems as described in the
I-D.

=> But this is clearly a TFT issue that needs to be solved
on that end not in IETF. You have everything you need to
know inside the packet. If the TFT option chosen does not
include some of these parameters then that's the TFT's
problem. This is not specific to MIPv6, this will affect
any IPsec-protected traffic. 

Hesham

---

From: [email-masked]
Date: Tue, 5 Aug 2003 11:09:39 +0100

Hi,

>the RA).

I assume that you are talking about radio link, or in genera,  layer 2. Unlike
WLAN or Ethernet,  a session between the UE and the GGSN  in GPRS/UMTS needs to
be set up  before sending /receving IP packets including those packets carrying
the MIPv6  control messages. The radio link is set up as part of the session
establishment  and no packets can cross the link until the GPRS/UMTS session
terminated at the GGSN  is set up successfully.

>So, unless you have a "static" TFT (i.e.
>the scenario you describe should never happen.

Not sure what you mean by "static TFT". A UE creates a TFT when it requests to
set up a GPRS/UMTS session (with specific QoS and resource requirements) and the
TFT is associated with the session for GGSN to use to select the session for
incoming packets. Unless the UE could change the TFT dynamically, the TFT will
remain "static".

>the scenario you describe should never happen.

The scenario  I described is not about TFT but SBLP in IMS for a UE attached to
GPRS/UMTS having a authorised IMS session with a MIPv6 CN. Upon attached to the
GPRS/UMTS, UE can initiate an IMS session  which can only send packets to
authorised destinations ,i.e. to its MIPv6 CN. Unless the UE can set up a
separate session to HA for MIPv6 control messages, the binding update can not
pass  the SBLP control at the GGSN.

>The QoS requirements

TFT does not contain QoS requirements but some IP layer, Transport Layer as well
as some security information etc.  The current session management in GPRS/UMTS
is independent of Mobile IP. As long as a session  is set up, apps can or should
be able to send/receive packets irrepective of the control in Mobile IP.  This
will stop being the case if Mobile IPv6 is activated by IPv6  end nodes
including IPv6 UE's  unless something is done.

>I don't understand the problem.

This seems suggesting that the session management in GPRS/UMTS should be
combined with the MIPv6 based Mobility. And this is going to be hard because the
current  GPRS/UMTS session management is designed and used  independent of the
Mobile  IP.

> In short, make sure that

This looks like making the filtering change with the movement  of the mobile
nodes when they start using  MIPv6.  But we have foreseen some serious impact on
the resources, especially over the air interfaces,  and the peformance for
GPRS/UMTS Session Management, Mobility Management and on the GGSN.

>independently of the sender or the receiver.

This seems to be suggesting the  wildcard filtering.  But this  can't be used in
many cases.

> Well, there is no seamless IP mobility issues for a UMTS
>UE!

I don't understand what you mean.  The term "seamless IP mobility" is not used
in UMTS but low  lowtency and low/no loss in  handover/mobility is an important
objective to achieve in UMTS.

> The UE will _never_ move.

The UE will move around ,intra-PLMN, Inter-PLMN and  between WLAN and UMTS at
least.

So I assume you are referring
>are delivered by the HA, then you can look inside the

We are considering this option and need to understand if it always works.

>any IPsec-protected traffic.

I disagree. Although the examples in the I-D are given specific to GPRS/UMTS,  I
don't think  these issues will only exist in GPRS/UMTS. And there have been some
quite extensive discussions about the similar issues in Firewalls/NAT.

Regards,

Xiaobao Chen

Monitoring/Viruses

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 5 Aug 2003 06:53:27 -0400

> terminated at the GGSN  is set up successfully.

=> I understand how it works. My point is that the
MN will _not_ send the first BU until the link
is up. Now if you always allow the GGSN to pass
an packet containing a mobility header (from any
IP address to any other IP address) then there 
is no "blocking of BU" problem. This is what I mean
by static TFT. That is, a static config for all
nodes, independently of the content of their
secondary PDP context. Unless a UE specifically
removes this for its TFT (can't imagine why)
then this is the default. It's a requirement 
on GGSN, there is no magic or protocol changes here.

 > dynamically, the TFT will

=> I hope the above makes it clear.

 > The scenario  I described is not about TFT but SBLP in IMS 

=> I thought you didn't want to discuss SBLP in a previous
mail. Anyway, see below.

 > pass  the SBLP control at the GGSN.

=> It does _not_ need a separate session for MIPv6
signalling, but of course you can do that. The only reason
for having a separate session would be if you require
a different radio config for the signalling. If you don't
need special treatment over the air then you should just
allow all packets with a mobility header to pass.

 > including IPv6 UE's  unless something is done.

=> I tried to explain to you what could be done in 
previous messages. It needs to be solved in 3GPP specs.

 > combined with the MIPv6 based Mobility. 

=> Don't know how you read that. I'll summarise my 
suggestions at the end.

 > nodes when they start using  MIPv6.  

=> No, it's a context update initiated by MIPv6
(acting as an application).

  But we have foreseen 
 > some serious impact on

=> I know! This is what I said a couple of emails ago
and it's a direct consequence of having an access 
router that manages a VERY large number of users. This
is specific to the GGSN. Normally access routers don't
manage this large number of devices.

 > This seems to be suggesting the  wildcard filtering.  But 

=> Like what? do you have an example?

 > The UE will move around ,intra-PLMN, Inter-PLMN and  between 

=> Physical movement is not relevant, it's IP movement
that we care about. IP movement will only happen between
WLAN and UMTS, this will cost one BU to the HA. 

 > quite extensive discussions about the similar issues in 

=> Yes and we solved the FW problem (not sure what NAT problem
you refer to in IPv6) by having a mobility header and 
strict rules for routing header use and HAO. Basically, 
with any FW you can have the "wildcard" configuration
that I explained above and it works. This is the 
expectation from MIPv6 because it's authenticated 
end-to-end. 

So the summary:

- For signalling messages, allow all packets containing
mobility header to pass through regardless of the 
source and destination addresses. Of course this does not
preclude ingress filtering. I'm only including the src address
in the above statement to allow inbound traffic.

- For media, you will need to look inside the tunnel, 
if it comes from the HA, or look for the HAO for route
optimised packets. The decision of whether the GGSN should
inspect the packet in this special way should be based
on PDP context signalling extensions in the UE and GTP-C. 

Hesham

---

From: [email-masked]
Date: Thu, 7 Aug 2003 15:31:25 +0100

Hi,

>by static TFT.

Not sure what you mean by "mobility header". I assume that you are talking abou
the MIPv6 extension headers. If I have not missed anything from our previous
discussion, these "mobility headers" are not always readable to GGSN.

>That is, a static config for all

Do you mean that GGSN should maintain a static config. ( e.g. a PDP Context) to
allow for MIPv6 messages to pass through without filtering  ? If yes,

     1) How would the MN know when it should open  a UMTS session with reserved
resources for the MIPv6 signalling messages ?
  I am not sure if it is a good practice to keep a session open all the time in
case there are MIPv6 messages coming in or going out.

     2) Even if there is a session for MIPv6 signalling, the GGSN would have to
see if it is a legitimate MIPv6 signalling message or something else which
should not be delivered anyway ? How would the GGSN know this ?

     3) Even if the MIPv6 control messages manage to pass around between the UE
and the GGSN, the data packets would have to go through the TFT based session
selection process. To do so, the GGSN will keep what you call a MIP flag per
session per UE in downlink direction  and udpate the TFT each time the MN's
moves around from one CoA to another. If the SBLP is taken into account,  GGSN
would have to set up and maintain this per session MIP flag and maintain MIPv6
status update for the uplink direction each time the MN moves.

> allow all packets with a mobility header to pass.

If it does not use a separate session, which session is used to pass the MIPv6
signalling then ?  If it uses the session set up for the data packets, it will
experience the same problem.

>previous messages. It needs to be solved in 3GPP specs.

This has surely been considered and discussed.  But it has been realised that
this means a tremendous cost and extra complexity  to our systems unless the
3GPP specs are changed in a way to limit the use of MIPv6 partly or completely.
I am sure very few people including those who have been working hard on MIPv6
would like to see this practice.

>WLAN and UMTS, this will cost one BU to the HA.

Even though UE's  in our network may not have "IP mobility", they may well talk
to UE's that are using MIPv6 mobility or IPv6 nodes that only use MIPv6 for
mobility control.  And there will be some  problems.

>expectation from MIPv6 because it's authenticated

 Filtering based on "wildcard" will not enable the GGSN to select the individual
sessions with different QoS/resource configurations.

>in the above statement to allow inbound traffic.

So you are talking about setting up a special sesssion to pass the siganlling
message, and to do so, the GGSN will have to parse the mobility headers.  There
are some costly and very complicated implications to the 3G systems especailly
to the air interface and the GGSN as I explained before.

>on PDP context signalling extensions in the UE and GTP-C.

Surely, this is one of the solutions that we are looking at but  I am not sure
this internal packet inspection for the mobility header information is always
possible especially when end-to-end IPSec is used.  There may well be a simpler
and better solution that does not  incure too much change and little cost and
little extra complexity to the existing design and deployment practice  of 3G
systems  that have been widely going on today. And I believe that MIPv6 WG is
the right group to help  find the solution(s). In the meantime, we also believe
that it is to the benefit to the work to be aware of some pracitcal deployment
issues of MIPv6 in real life networks.

Xiaobao

Monitoring/Viruses

---

From: Soliman Hesham <[email-masked]>
Date: Thu, 7 Aug 2003 10:46:40 -0400

> Not sure what you mean by "mobility header". 

=> The Mobility Header is an extension header that
carries MIPv6 signalling as defined in the MIPv6 spec.

 > allow for MIPv6 messages to pass through without filtering  ? If yes,

=> Yes.

 > resources for the MIPv6 signalling messages ?

=> Like I said before, you only need that if you require
special air interface configuration for MIPv6 signalling.
Since MIPv6 is not used within the UMTS network, I don't
think this is necessary. If a UE has a MIPv6 implementation
it will rarely send a BU to the HA and it might send one 
every 7 minutes to a CN. Do you want a special RAB for that?
If you do it's obviously more work in 3GPP. I was trying to
give a simple and less efficient solution. If you want a more
optimal one you'll have to make more modification to 3GPP
specs.

 > case there are MIPv6 messages coming in or going out.

=> Neither am I that's why I didn't suggest this. 
What I suggested means that every TFT has what 
you called "wild card" filter in it by default even
if the UE doesn't ask for it. If the UE overwrites it
then its the UE's responsibility.

 > should not be delivered anyway ? How would the GGSN know this ?

=> Don't know what you mean. MIPv6 signalling messages are
clearly specified and the current spec does not allow piggybacking
of other data on them.

 > moves around from one CoA to another. 

=> Yes.

   If the SBLP is taken 
 > into account,  GGSN

=> I hope that by MN you are referring to the CN not the UE because
obviously the UE doesn't move. If you are referring to a CN
then yes the above is correct. But of course any of these 
problems is only relevant when you use route optimisation.

 > 3GPP specs are changed in a way to limit the use of MIPv6 

=> The cost is only a result of the core network design.
Normally, filtering in the access router is not as costly
when it serves a small number of nodes. So that's why this 
is a special case.

 > sessions with different QoS/resource configurations.

=> Why not? it's a default filter that is unilaterally added
by the GGSN in addition to whatever the UE requests. What's
the problem?

 > to the air interface and the GGSN as I explained before.

=> See answers above and previous mails about why this is 
not a big issue for access routers serving a small number of nodes.

 > possible especially when end-to-end IPSec is used.  

=> We're going in circles here. We already discussed this
and I suggested that the SPI or flow label can be used. 

   There 
 > may well be a simpler
 > systems  that have been widely going on today. 

=> A Hop-by-Hop option is not an option (pardon the pun).
If there is another feasible option please suggest it.

   And I believe 
 > that MIPv6 WG is
 > the right group to help  find the solution(s). 

=> Well, here we are :) 

Hesham