Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing loopbetween home agents

["Davis, Terry L" <terry.l.davis at boeing.com>]

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

> -----Original Message-----
> From: Benjamin Lim [mailto:benjamin.limck at sg.panasonic.com]
> Sent: Thursday, October 02, 2008 7:49 PM
> To: Davis, Terry L; Charles E. Perkins
> Cc: mext at ietf.org
> Subject: Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing
> loopbetween home agents
>
> 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
>
> Davis, Terry L wrote:
> > 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: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On Behalf Of
> >> Charles E. Perkins
> >> Sent: Thursday, October 02, 2008 4:51 PM
> >> To: Benjamin Lim
> >> Cc: mext at ietf.org
> >> Subject: [MEXT] Issue #17: Multi-homed mobile node can cause routing
> >> loopbetween home agents
> >>
> >>
> >> 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
> >> MEXT at ietf.org
> >> https://www.ietf.org/mailman/listinfo/mext
> >
> >
>

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext