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

[Vijay Devarapalli <vijay at wichorus.com>]

Hi Ahmad,


On 8/14/09 6:36 PM, "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.

Neither RFC 5213 nor draft-ietf-mipshop-transient-bce-pmipv6 allow the LMA
to accept uplink packets from the nMAG without a message from the nMAG. In
RFC 5213, it would be the PBU. In draft-ietf-mipshop-transient-bce-pmipv6,
it would be the PBU with the transient binding mobility option.

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

I still don't agree. There is always a message from the nMAG before the LMA
starts accepting the uplink packets from the nMAG.

Static configuration on the LMA does not mean it will accept the uplink
packets from any MAG. It means, when the nMAG initiates a handover, the LMA
can be statically configured to accept uplink packets from the pMAG for a
short duration.

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

Ok.

Vijay