Re: [MEXT] Issue #17: Multi-homed mobile node can cause routing loop between home agents
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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  


On 10/9/08 12:00 PM, "ext Julien Bournelle" <julien.bournelle at gmail.com>
wrote:

> 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
> 
> On Mon, Oct 6, 2008 at 7:16 PM, Basavaraj Patil
> <basavaraj.patil at nokia.com> wrote:
>> 
>> 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
>> 
>> 
>> On 10/2/08 6:50 PM, "Charles Perkins" <charles.perkins at earthlink.net> wrote:
>> 
>>> 
>>> 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
>> 

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



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.