Subject: RE: Summary: Reason for the explicit link-layer address options in ND?

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Feb 2003 08:04:28 -0500

Hi Pekka,

> Thanks, Jim and Francis, for your timely answers to my 
> question.  Yes, like Jari pointed out, we are working on 
> using IPsec for SEND, and we need to understand ND better to 
> make it *right*.  However, that discussion belongs to the 
> very silent SEND mailing list, and should be continued only 
> there, IMHO.  (I've inserted Reply-To: headers to facilitate that...)

I am fine with the strategy.

> 
> Now, the ND specs as such are clear.  No problem with
> that.  It is just that the design rationale behind the
> specs in not written anywhere (as usual), and that was
> the reason for asking my question.  We are not attempting
> to redefine or even revise the ND architecture, we are 
> attempting to understand it fully so that we can design 
> proper security for it.

OK.  I just get nervous lately esp with researchers who want to help
make IPv6 better.  I have an issue when a person shows up at the
hospital with a headache and the hospital takes the patient to a room
for open heart surgery.
Glad that is not the case.  

Also I asked the question also to yet again show in our community taking
time to put rationale appendices in completed standards specs is a wise
thing to do as the IEEE does.  Oh well I must try.  

> 
> Now, if I read correctly what you Jim and Francis are saying, 
> there seems to be a number of reasons for the design. Please 
> correct me if I get this wrong; I am rewriting what I read to 
> see if I understand it correctly.
> 
>    1. Architecture
> 
>       It was deemed architecturally good to place ND
>       at the IP/ICMP layer rather than below it.  The
>       main benefits from this are the following:
> 
>          - allows extension headers to be used
>          - allows IPsec protection for ND
>          - allows using routing and destination options

These are attributes yes.  To get them all a detailed investigation of
ND would need to be done.  Do these work for now?

> 
>    2. Implementation
> 
>       Early implementation experience showed that as
>       a consequence of the design, implementation becomes
>       simpler.  In particular, NUD and prefix assimilation
>       become part of the IP layer.
> 
>       I have one further question about that: what do
>       you mean with prefix assimilation?  I didn't find
>       the term in RFC2461 or RFC2462.

Sorry I knew that when I wrote it and did it anyway, sorry again.  In ND
a node can receive prefixes for autoconfiguration and to be used to note
prefixes on that link or just one or just both.  L bit says this prefix
can be used for onlink determination and A bit says this prefix can be
used for addrconf.

The ability to have this knowledge about prefixes permits the
verification of other nodes on the network.  So if a rogue prefix
appears a hint can be provided it is not on link valid from the L bit.  

But the code to work prefix vs link-layer is two separate functions that
can be then joined for verification and assimilation to support ND
caches and the NUD state machine.

Does that help?
 
> 
> 
> The reasons for the link layer address options were
> the following:
> 
>    3. Extensibility (with extension headers etc).
> 
>       This seems to be a direct consequence of the
>       architectural design decision.

Specifically with ICMP and new types.  If a new ICMP SEND type were
needed you would not have to reinvent the link-layer packets
"hopefully".

> 
>    4. Support for future functionality like proxy ND
> 
>       Again, this seems to follow the architectural
>       principle layed out above.
> 
>    5. Better support for the Override bit
> 
>       Now, I have a question about the Override bit.
>       I didn't quite understand how it could be used
>       for "node discovery during first phase when
>       link-layer addresses are not shared".
> 
>       What did you mean with that, Jim?

The override bit if on says don't replace this link-layer with existing
link-layer or if not set do replace it.  Throughout 2461 this bit is
used to control state and cache replacement.  This is very powerful and
a real advantage of ND over its predecessors.  Also in SEND I would look
to see if there are conditions that can be set with the override bit for
initial security benefits.

> 
> Finally, the reasons for not peeking at the actual
> link layer addresses used in the link layer frame can
> be summarized as follows:
> 
>    6. Separation of function
> 
>       This again follows the architectural principle.
>       Especially, it was viewed that checking the
>       link-layer addresses is a link layer function,
>       and it should be separate from the IP layer.
> 
> Is that all or am I missing something?  Or is there
> something above that doesn't belong there?

Yes this is the only reason.  But see the IPv6 over foo specs.

> 
> Now, if you want to discuss how security fits in this
> all, may I suggest that we do it on the SEND list?
> (Personally I have trouble in keeping track with
>   the IPv6 list volume, as I have also other things
>   to do but participate to the IETF work.) I

This makes sense.  I don't have the time to take SEND on.

But if you have direct questions and send them I will go look within a
reasonable time frame.  I implemented parts of ND and all of Addrconf so
know them well from that but that was some time ago too and even an
implementor has to go recheck specs.

Also we did identify this potential security issue in the spec under
considerations briefly speaking of it as MAC spoofing.

If SEND puts out spec saying in additon to whats in ND implementations
should also do X I see that as goodness.  Just don't want to see 2461
altered unless something is broken in ND itself is my input to our
processes.

Regards,
/jim

> --Pekka Nikander

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------