RE: GPRS Tunnel Protocol (GTP)

>>The problem you're trying to solve is essentially
>>that the "application" sets the filter on a default
>>router. You are essentially saying that the application
>>only sees a home address and the default router only
>>sees the CoA therefore the filter (TFT) will never
>>match the incoming/outgoing traffic. I'm not going
>>through the Go interface just the basic problem in
>>the absence of IMS.


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

  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.


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

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


Hesham