Default Router in NETLMM (was RE: New I-D: Security Threats to NETLMM)

The benefits of DNA are, in fact, minor if ARs use different
link-local
source addresses.  As Mohan said, MNs would simply record a
new AR in
their default-router lists, but they would stick to the
current, stale
default router until NUD reveals the unreachability.

As a result of NUD, the old AR's NC entry would then be
deleted, so the
MN would select a new AR according to section 6.3.6,
"Default Router
Selection", in RFC2461bis.  But even then is it not
guaranteed that it
will select *the* (most recently discovered) new AR.

The single benefit of DNA, in this situation, is that the MN
sets its NC
entry for the new AR to REACHABLE state due to the received
*unicast*
RA.  With RFC2461bis, the new AR's NC entry is always set
to STALE
state, regardless of whether the RA was received by unicast
or
multicast.  Consequently, the new AR is in a better position
if DNA is used.

But what's wrong with using the same link-layer addresses
for all ARs?
(I wrote this in my email from March 12, but it was
apparently lost in
the noise.)  If you use the same link-layer addresses, DNA
*does*
provide a huge benefit:  When the MN receives a L2 trigger,
it does the
RS/unicast-RA exchange, leaves the Default Router List
untouched
(because the AR's link-local address did not change),
updates its NC
entry for the AR to the new AR's MAC address, and sets the
NC entry's
state to REACHABLE.  All further packets will hence go via
the new AR
without delay.  This should work--- without NUD, BTW.  Plus,
you can use
different MAC addresses for different ARs.

Regards,
- Christian

PS:  I did not read Julian and Sathya's on the MN-AR
interface, which
James mentioned.  Maybe, their approach is similar...

-- 
Christian Vogt, Institute of Telematics, Universitaet
Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/


James Kempf wrote:
> Why would the MN continue to use the old router when it
has no
> confirmation of reachability? I have not looked at the
DNA draft lately,
> but it seems to me that this is the whole point of DNA.
> 
>            jak


_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

Christian,

On Wednesday 15 March 2006 14:42, Christian Vogt wrote:
>
> But what's wrong with using the same link-layer
addresses for all
> ARs? (I wrote this in my email from March 12, but it
was apparently
> lost in the noise.)  If you use the same link-layer
addresses, DNA
> *does* provide a huge benefit:  When the MN receives a
L2 trigger,
> it does the RS/unicast-RA exchange, leaves the Default
Router List
> untouched (because the AR's link-local address did not
change),
> updates its NC entry for the AR to the new AR's MAC
address, and
> sets the NC entry's state to REACHABLE.  All further
packets will
> hence go via the new AR without delay.  This should
work--- without
> NUD, BTW.  Plus, you can use different MAC addresses
for different
> ARs.

AFAICS there is three reasons not to use the same link layer
(and IP) 
address for all ARs in a NetLMM domain:

1) That's a hack (I did it myself to quickly finish first
stage 
prototyping ;)

2) Although I am not sure, you might want to support various
link 
layers in a NetLMM domain, with e.g. possibly different
types of link 
layers addresses.

3) It might not be possible to change link layer address of
interfaces 
with all media (e.g. 802.16 has digitally signed MAC
addresses, 
albeit only for SS, not BS)

> PS:  I did not read Julian and Sathya's on the MN-AR
interface,
> which James mentioned.  Maybe, their approach is
similar...

No, we tried to use DNA. But it seems that the MN-AR
interface we 
described has the issue we discuss here (i.e. the old AR
will still 
be used by the MN until NUD fails.)

--julien
_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm

Julien, James,

note that the approach I was describing uses...

- DIFFERENT MAC addresses for different ARs
- THE SAME link-local address for all ARs

I don't think this would be a hack:  NETLMM ARs do belong
to different
links, even though their RAs suggest to MNs that they belong
to the same
link.  So why shouldn't ARs use the same link-local
addresses?

Again, the ARs' MAC addresses can (and should) be
different.

- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet
Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/


James Kempf wrote:
> One problem with using the same link address is that
there will often
> be more than one router on the last hop, for
redundency. One could of
>  course use the same set of link addresses, but it is a
bit of a
> hack, as Julien has indicated.
> 
> jak


Julien Laganier wrote:
> Christian,
> 
> On Wednesday 15 March 2006 14:42, Christian Vogt wrote:
>> But what's wrong with using the same link-layer
addresses for all 
>> ARs? (I wrote this in my email from March 12, but
it was apparently
>>  lost in the noise.)  If you use the same
link-layer addresses, DNA
>>  *does* provide a huge benefit:  When the MN
receives a L2 trigger,
>>  it does the RS/unicast-RA exchange, leaves the
Default Router List
>>  untouched (because the AR's link-local address
did not change), 
>> updates its NC entry for the AR to the new AR's
MAC address, and 
>> sets the NC entry's state to REACHABLE.  All
further packets will 
>> hence go via the new AR without delay.  This should
work--- without
>>  NUD, BTW.  Plus, you can use different MAC
addresses for different
>>  ARs.
> 
> AFAICS there is three reasons not to use the same link
layer (and IP)
>  address for all ARs in a NetLMM domain:
> 
> 1) That's a hack (I did it myself to quickly finish
first stage 
> prototyping ;)
> 
> 2) Although I am not sure, you might want to support
various link 
> layers in a NetLMM domain, with e.g. possibly different
types of link
>  layers addresses.
> 
> 3) It might not be possible to change link layer
address of
> interfaces with all media (e.g. 802.16 has digitally
signed MAC
> addresses, albeit only for SS, not BS)
> 
>> PS:  I did not read Julian and Sathya's on the
MN-AR interface, 
>> which James mentioned.  Maybe, their approach is
similar...
> 
> No, we tried to use DNA. But it seems that the MN-AR
interface we 
> described has the issue we discuss here (i.e. the old
AR will still 
> be used by the MN until NUD fails.)
> 
> --julien
_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm