Re: [Mipshop] Appendix B of draft-ietf-mipshop-transient-bce-pmipv6

["Ahmad Muhanna" <amuhanna at nortel.com>]

Hello Vijay,
Thanks for the review and the comments, I think I can address some of
your comments while it is too late at night in Europe:-) please see
inline.

Regards,
Ahmad
 

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay at wichorus.com] 
> Sent: Wednesday, August 12, 2009 3:49 PM
> To: draft-ietf-mipshop-transient-bce-pmipv6 at tools.ietf.org
> Cc: mipshop at ietf.org
> Subject: Appendix B of draft-ietf-mipshop-transient-bce-pmipv6
> 
> Hello,
> 
> Here are some comments on Appendix B in the Transient BCE draft.
> 
> > Appendix B.  Applicability and Use of Static Configuration 
> at the LMA
> > 
> >    During the workgroup discussion of the functionality 
> introduced by
> >    this draft, it was mentioned that some current Home Agents are
> >    already handling some features and functionality 
> introduced in this
> >    draft via some static configuration.  This Appendix captures the
> >    analysis which describes which functionality can be 
> handled securely
> >    using a static configuration and which can not.  
> 
> What does "securely" imply here? If the transient BCE 
> functionality can be achieved with implementation techniques 
> on the LMA, why wouldn't it be secure? More below.

[Ahmad]
The intention for Securely here to mean: with IP mobility signaling that
is protected following the security requirement of the IP mobility
protocol at hand; In this case, PMIPv6. The intention here is to say
that static configuration at the LMA will not address this without
violation of IPv6 mobility protocol. IPv6 mobility protocol allows the
anchor node to accept the mobile nodes traffic with home address as the
source IP address tunneled from the currently registered
care-of-address. In other words, if the MN is currently registered
(securely) at MAG1 with pCoA1, the LMA should not accept uplink traffic
from the mobile node from another pCoA, e.g., pCoA2.


> 
> In these cases where
> >    static configuration can be used, this section documents 
> the possible
> >    disadvantages versus using the procedures captured in 
> this document.
> > 
> > B.1.  Early Uplink Traffic from the nMAG
> > 
> >    This use case is related to the handoff scenario when the access
> >    network establishes the uplink tunnel to the LMA before 
> the downlink
> >    portion is done.  Consequently, when the mobile node is 
> attached to
> >    the nMAG and in the case of active handoff, the UE will 
> start sending
> >    uplink traffic to the LMA through the nMAG.
> > 
> >    Since the LMA has a proxy BCE for this mobile node which 
> points to
> >    the Proxy-CoA that is hosted at the pMAG, the LMA has a 
> routing entry
> >    for the MN HNP which points to the pMAG-LMA tunnel.  Any uplink
> >    packet coming from the nMAG will be dropped by the LMA.
> > 
> >    Allowing the LMA to forward the received uplink traffic 
> from the nMAG
> >    to the Internet is a violation of all mobility protocols which
> >    require secure signaling exchange between the nMAG and 
> the LMA before
> >    forwarding such traffic to the Internet.  Otherwise, the 
> LMA will be
> >    modifying the mobile node routing entry based on an 
> unsecured data
> >    traffic packet coming from the nMAG.
> > 
> >    Therefore, this case can not be addressed by any statically
> >    configured information on the LMA.  On the contrary, a secure
> >    signaling using Transient Binding option as detailed in 
> this draft is
> >    required to create a transient state for the mobile node 
> BCE at the
> >    LMA.  This transient state will allow a temporary 
> routing entry of
> >    the mobile node to point to the nMAG Proxy-CoA.
> 
> I don't understand this. Even with the transient BCE 
> mechanism, the LMA does not accept packets from the nMAG 
> without a PBU with the transient binding mobility option from 
> the nMAG. In the above, you are saying it is a bad idea to 
> accept MN uplink packets from the nMAG before any signaling 
> message from the nMAG. But who is disagreeing with this?
>
[Ahmad]
You are right. We never heard the specifics on how those HA/LMA handle
such case with static configuration. all what we heard are claims that
it is being done. However, due to the lack of information we have to go
with whatever information available in comparison to the well known case
of allowing in-flight uplink traffic from the pMAG. 
 
> > B.2.  Late Uplink Traffic from the pMAG
> > 
> >    This case is a very common case where the mobile node is 
> handing over
> >    to another MAG while there is still some uplink traffic in flight
> >    coming from the pMAG.  In this case, the LMA has the MN 
> BCE points to
> >    the mobile node location before the handoff, i.e., pMAG 
> Proxy-CoA.
> >    Then the LMA receives a PBU from the nMAG over a secure signaling
> >    tunnel, e.g., IPsec tunnel, which indicates some type of 
> handoff as
> >    per the value in the handoff indicator mobility option.
> > 
> >    If the PBU received from the nMAG was sent using the 
> secure tunnel
> >    and successfully processed by the LMA, the LMA according 
> to [RFC5213]
> >    switches the IP-in-IP tunnel to point to the nMAG Proxy-CoA.
> >    However, as the LMA is fully aware of the mobile node 
> movement via
> >    secure signaling from the nMAG and the content of the 
> PBU which in
> >    particular contains the Handoff Indicator mobility 
> option, the LMA
> >    can process some intelligence to allow the mobile node's late in-
> >    flight uplink traffic coming over the pMAG-LMA tunnel to 
> proceed to
> >    the Internet.
> > 
> >    However, using a statically configured information MAY 
> not address
> >    all handoff circumstances over all types of access networks.
> >    Therefore, using the activation mechanism as described 
> in this draft
> >    would dynamically help in ending the late forwarding 
> from the pMAG
> >    based on a secure signaling from the pMAG.
> 
> hmm.. I don't see this a big deal. Just configure a large 
> enough timer on the LMA to accept uplink packets from the 
> pMAG. This timer could also be configured depending on the 
> access technologies used in a specific deployment.
> 
> In the last paragraph, maybe you should rephrase to say that 
> signaling mechanism that determines this timer is preferable 
> to configuring the timer. I am not convinced by the statement 
> that says "this MAY not address all handoff circumstances ..."

[Ahmad]
No problem. We can adopt your proposed text.
> 
> > B.3.  Late Switching of Downlink Traffic to nMAG
> > 
> >    One main use case of transient bindings is the late switching of
> >    downlink traffic routing at the LMA.  This allows to perform IP
> >    mobility protocol signaling between nMAG and LMA 
> independently of the
> >    link layer connectivity, e.g. for interfaces with time 
> consuming link
> >    setup procedure or for a make-before-break handover between
> >    interfaces.
> > 
> >    LMA behaviour according to [RFC5213] does not allow for late path
> >    switching.  LMA according to [RFC5213] can only act upon 
> the Handover
> >    Indicator and has no information on the time of 
> completion of link
> >    layer setup.  Even if an LMA implementation would be 
> configured to
> >    delay the path switching by a fixed time, which would violate
> >    [RFC5213], this would not lead to smooth handover performance but
> >    would even add latency to the handover.  Only additional 
> signaling as
> >    provided by this document provides the information that late
> >    switching is applicable and enables a synchronization of 
> the handover
> >    sequence, .i.e. the switching is adapted both to the 
> finalization of
> >    the link between mobile terminal and nMAG and to the 
> release of the
> >    link between mobile terminal and pMAG, whatever comes 
> first.  Secure
> >    and stable handover performance is achieved.
> 
> Looks ok except for the "Secure" part. I don't see anything 
> becoming unsecure if there is no explicit signaling between 
> the nMAG and the LMA.

[Ahmad]
Current PMIPv6 signaling creates a single routing state for the MN BCE.
Any time the LMA creates an additional forwarding state for the MN BCE,
it needs to be done using a securely protected IP mobility signaling
according to RFC5213. That is probably where secure came from. Do you
suggest a different wording?
 

> 
> Vijay
>