Subject: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 02 Oct 2008 16:50:55 -0700

Hello Benjamin,

I have not seen any further discussion about this issue,
but I agree that the problem does exist.

It might be possible to specify that the Home Agent should (or,
?may?) use the RFC 2473 "Tunnel Encapsulation Limit Option".
to help avert the threat.  Otherwise, the loop could persist for
an annoyingly long amount of time.  It is also possible for the
home agent to enforce a policy by which a home address on
a network cannot be bound to a care-of address on the same
network, but in fact there may be cases where that would be
a valid binding.

I hope that other people in the working group will
express an opinion about this.  At minimum, we could
certainly include text within the Security Considerations
section.

The existing discussion is documented at the following URL:
http://trac.tools.ietf.org/wg/mext/trac/ticket/17

Regards,
Charlie P.

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Davis, Terry L" <[email-masked]>
Date: Thu, 2 Oct 2008 19:09:00 -0700

Charlie

Seems like a potential solution; but I'm not sure the cause would necessarily relate to security.

The natural state of an aircraft will be to attempt to be multi-homed in the "Air Traffic Management Network" (ATN) domain with two or more active links and most of the links available to an aircraft will be "narrow-band", a megabit or less. If we do really well, our new aviation communication link providers may get us to a shared "broadband" link capability of 10 megabits.  The good thing is that this ATN domain will likely be run as a closed network so that routing loops only impact the ATN domain.

(Our existing OSI "broadband links", which we don't intend to convert to IP, run from 2K "bits" to 30K "bits".)

However the other two aircraft network domains will have the potential to impact general Internet routing with their mobility services; "airline operations" which will look like a corporate business network and "passenger Internet and Entertainment" which will look like an ISP.  And at least at times, both may be multi-homed, if for no other reason than the satellite handoffs or air-to-ground tower handoffs being done at layer three instead of two.

Take care
Terry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Charles E. Perkins
> Sent: Thursday, October 02, 2008 4:51 PM
> To: Benjamin Lim
> Cc: [email-masked]
> Subject: [MEXT] Issue #17: Multi-homed mobile node can cause routing
> loopbetween home agents
>
>
> Hello Benjamin,
>

---

From: Benjamin Lim <[email-masked]>
Date: Fri, 03 Oct 2008 10:49:29 +0800

Hi Charlie and Terry,

I agree with Charlie that using TEL option would ensure that packets
does not stay in the loop for a long time.  But this might not fully
solve the problem, as the loop still exist.

I think a solution to the problem can be seen as two steps.

(a) A loop detection mechanism at HA.
(b) A correction procedure when a loop is being detected.

For (a), there would a draft submitted to the coming IETF meeting for
discussion.  The general idea is to tag a packet with some ID that HA
can identify if the packet is looped.

For (b), my understanding from Terry would be that the correction steps
to be taken would be based on the policy of controller of the network.
I.e. for aviation, they can have a policy that states that if loop is
detected for ATN traffic, its ok. If loop is detected for operations and
passenger traffic, then HAs would remove the affected binding to break
the loop.

Regards,
Benjamin Lim

---

From: "Davis, Terry L" <[email-masked]>
Date: Thu, 2 Oct 2008 20:26:46 -0700

Benjamin

It would not "be ok" for the ATN to loop; it just wouldn't affect the global Internet routing, just ATN.

The onboard policy routing would hopefully prevent the loop in any case for any of the networks.

Take care
Terry

> From: Benjamin Lim [mailto:[email-masked]]
> Sent: Thursday, October 02, 2008 7:49 PM
> To: Davis, Terry L; Charles E. Perkins
> Cc: [email-masked]
> Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing
> loopbetween home agents
>
> Hi Charlie and Terry,
>
> > The natural state of an aircraft will be to attempt to be multi-homed in
> the "Air Traffic Management Network" (ATN) domain with two or more active
> links and most of the links available to an aircraft will be "narrow-band",
> a megabit or less. If we do really well, our new aviation communication
> link providers may get us to a shared "broadband" link capability of 10
> megabits.  The good thing is that this ATN domain will likely be run as a
> closed network so that routing loops only impact the ATN domain.
> >
> > However the other two aircraft network domains will have the potential
> to impact general Internet routing with their mobility services; "airline
> operations" which will look like a corporate business network and
> "passenger Internet and Entertainment" which will look like an ISP.  And
> at least at times, both may be multi-homed, if for no other reason than
> the satellite handoffs or air-to-ground tower handoffs being done at layer
> three instead of two.
> >
> >
> > Take care
> > Terry
> >
> >
> >
> >
> >

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 06 Oct 2008 12:16:16 -0500

Charlie,

I don't see this issue being specific to MIP6 base spec. The fact that such
a threat may arise as a result of multihoming is outside the scope of MIP6
protocol itself.

IMO this is a non-issue for MIP6.

-Raj

---

From: <[email-masked]>
Date: Tue, 7 Oct 2008 16:30:54 +0200

Hello Benjamin,

I agree with your two steps proposal. For a), a solution could be to use GRE encapsulation and the GRE key option as the identifier you propose. What do you think?

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Benjamin Lim
> Envoyé : vendredi 3 octobre 2008 04:49
> À : Davis, Terry L; Charles E. Perkins
> Cc : [email-masked]
> Objet : Re: [MEXT] Issue #17: Multi-homed mobile node can cause
> routingloopbetween home agents
> 
> Hi Charlie and Terry,
>

---

From: "Julien Bournelle" <[email-masked]>
Date: Thu, 9 Oct 2008 19:00:25 +0200

Hi,

 I'm not sure that this is a non-issue for mip6. The fact is that any deployment
of mip6 will have this issue and it would be probably best if IETF comes with
a solution.

 Regards,

 Julien

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 09 Oct 2008 12:13:38 -0500

Julien,

One minor recommendation for deployments concerned with this issue would be
to avoid using the Alt-CoA address in creating the binding.

But I guess you will have to convince the WG about the scenario which
results in such a threat more explicitly and then determine if there is a
need to deal with it.

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 31 Oct 2008 19:15:14 -0400

Hi Charlie, 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Charles E. Perkins
> Subject: [MEXT] Issue #17: Multi-homed mobile node can cause 
> routing loop between home agents
> 
> 
> Hello Benjamin,
> 

Recommending the use of the Tunnel Encapsulation Limit Option" in the
security considerations section seems to be the best option to me. Here
is some text.

   A malicious mobile node associated to multiple home agents could 
   create a routing loop amongst the home agents. This can be 
   achieved when a mobile node binds one home address located on a 
   first home agent to another home address on a second home agent. 
   This type of binding will force the home agents to route the same 
   packet among each other without knowledge that a routing loop has 
   been created. To present this routing loop, it is recommended for
   the home agents to use the Tunnel Encapsulation Limit Option 
   [RFC 2473], when tunneling packets for the mobile node. 

It would be good to recommend a default value for the "Tun Encap Lim"
field, but I don't know what to recommend. How about '5'? This should be
sufficient for any additional GTP, PMIPv6, HMIPv6 or FMIPv6 tunneling
between the home agent and the mobile node. :)

Vijay