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

[Vijay Devarapalli <vijay at wichorus.com>]

Hi Ahmad,

Ahmad Muhanna wrote:

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

I read the above multiple times, but I am not convinced. An LMA deciding 
to accept uplink packets from both the pMAG and the nMAG for a short 
duration during a handover does not weaken the security of the PMIPv6 
protocol in any way. I would just drop the word "securely" in appendix B.

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

So, you will be re-writing the above paragraph, I assume. With or 
without the transient BCE extension, the LMA does not accept uplink 
packets from the nMAG without a PBU from the nMAG for a particular 
mobility session.

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

Ok.

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

Just remove the word "secure".

Vijay

>  
>
> > Vijay