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

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Aug 2009 13:49:16 -0700

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.

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?

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

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

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Aug 2009 16:27:57 -0500

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:[email-masked]] 
> Sent: Wednesday, August 12, 2009 3:49 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Appendix B of draft-ietf-mipshop-transient-bce-pmipv6
> 
> Hello,
> 
> 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 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. 
 
> 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.
> 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?

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 14 Aug 2009 17:11:11 -0700

Hi Ahmad,

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

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

> No problem. We can adopt your proposed text.

Ok.

> suggest a different wording?

Just remove the word "secure".

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 14 Aug 2009 20:36:23 -0500

Hi Vijay,
Please see inline.

Regards,
Ahmad

> Subject: Re: Appendix B of draft-ietf-mipshop-transient-bce-pmipv6
> 
> Hi Ahmad,
> 
> Ahmad Muhanna wrote:
> 
> 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.

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

> >> 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.
> >>
> >> 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]
> >> unsecure if there is no explicit signaling between the 
> nMAG and the 
> >> LMA.
> > 
> > [Ahmad]
> > 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?
> 

[Ahmad]
What about the following:

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Aug 2009 13:58:38 -0700

Hi Ahmad,

> pMAG. This state was created via protected PMIPv6 signaling between the

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.

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

Ok.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 17 Aug 2009 17:25:44 -0500

Hi Vijay,

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

[Ahmad]
Oh.. Sorry, I may have missed something. I am actually fine with this
usecase you mentioned. 

Regards,
Ahmad