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

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

Hi Vijay,
Please see inline.

Regards,
Ahmad
 

> -----Original Message-----
> Subject: Re: Appendix B of draft-ietf-mipshop-transient-bce-pmipv6
> 
> 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.
[Ahmad]

In the case of inflight uplink traffic from the pMAG, I agree. The
reason is that, before the handover, the MN BCE points to the pCoA at
the pMAG. During handover, I assume the LMA will receive a new PBU which
a pCoA pointing to the nMAG. In this case, the LMA knows for sure that
there is a handover happening for the MN between pMAG and nMAG. This
information is apparent through secure PMIPv6 signaling. TRUE?

NOW, a static configuration of allowing the LMA in this case to accept
uplink traffic from the pMAG is NOT a problem. Because, the LMA received
an indication of this handoff through secure PMIPv6 signaling. Do we
agree so far?

The second case is allowing UPLINK traffic from nMAG before receiving a
PBU for a short period of time: This case can NOT be achieved SECURELY
because:
1. Before the handover, the MN BCE at the LMA points to pCoA at the
pMAG. This state was created via protected PMIPv6 signaling between the
pMAG and the LMA. 

2. When the handover occurs, the LMA does not have any clue if that is a
handover or a bogus packet coming from a man in the middle or anything.
All the LMA sees is an UNPROTECTED data packet with a source IP address
of the MN pHoA tunneled from a pCoA at the nMAG which is not registered
in the MN BCE. DO you think that is good enough information for the LMA
to decide that the MN is handing over from pMAG to the nMAG and
consequently start a new forwarding entry state for the MN by accepting
traffic from the pCoA at the nMAG?

That is why I used the word SECURE or securely.

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

[Ahmad]
Sure. That also means this case CAN NOT be handled via static
configuration either. However, the transient BCE extension is used to
create an additional **temporary or transitional** forwarding state for
the MN BCE while maintaining the old forwarding state (depending on the
case being handled).

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

[Ahmad]
What about the following:

Stable handover performance is achieved using protected PMIPv6 signaling
as per RFC5213.

> 
> Vijay
> 
> >  
> > 
> >> Vijay
> >>
> 
>