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

From: "Bound, Jim" <[email-masked]>
Date: Wed, 12 Feb 2003 09:30:51 -0500

Hi Pekka,

I can give you one answer and recall the discussion very well in
Cambridge MA well at an early interim IPng WG meeting (~1995) and this
is where we agreed to solicited node mulitcast archictecture principle,
as a note too.

For Neighbor Discovery (ND) RFC 2461:
IPv4 and OSI too and many other previous implementations of a Internet
like network paradigm relied on address resoluton and node discovery at
the link layer of the network stack in conjunction with peeking at the
link layer (e.g. ARP, ES-IS, Novell IPX). With IPv6 the ICMP Layer,
Router Redirects, and ARP-Like funcitons were brought up to be part of
the IP layer processing, which is one of the clear advantages of IPv6
IMO that we often don't tout (though steve brings this point out in his
masters and other talks).  There is an architecture and implementation
reason.

Architecturally this affords ND to be part of the IP(v6) layer and part
of the extensibility of that architecture as required (e.g. new ICMP
types, Routing Options, Destination Options). This can be seen from the
DNS Discovery deliberation and suggestion to use new ICMP type for
finding ones DNS server on a stateless network. It can be seen in Next
Header chain. With ARP or ES-IS this was not possible. In those
archictectures the address resolution and node discovery are disjoint
from the actual "virtual" layer 3 processing.

From implementation perspective it supports the principle of
cohesiveness when building the network subsystem.  What this means is
that the code points for IP processing are now integral to the ND
methods and concepts like NUD and prefix assimilation from ND are now
part of the IP stack code base.  NUD and prefix assimilation (just two
examples as a note) are part of ND architecture and support that
principle. The "implementors" of IPv6 and SIP (initial predecessor to
IPv6 and IPng choice) learned the implementation advantages of ND
methods and its place in the IPv6 architecture over implementations they
had done for ARP and ES-IS. 

So it was a win for the Architecture, Implemenation, and combined the
best from multiple methods previously done for address resolution, node
discovery, and router redirects. The last win was only possible by
integrating into the the IP layer.

IPv6 Stateless Autoconfiguration RFC 2462. 
This just adhered to the base packet types of ND and then added the
processes.

The reason the link layer addresses are options was to permit
extensibility for ND and Autoconfig to be extensible to the win list
above of which address resolution and node discovery were only part.
Another reason is support future models for proxy and passing link-layer
addresses to those node (e.g. Mobile IPv6 HA proxy). Another reason was
to support the use of the Override bit which can be part of address
resolution and node discovery during first phase when link-layer
addresses are not shared or to inform implementation this is temporary
do not update your NUD cache.

The reason for not peeking at the link layer in ND or Autoconfig is
separation of function within the IP architecture.  There is no
requirement for this in previous models like ARP and ES-IS. If you look
at public domain network kernel implementations of BSD or Linux
derivations you will see the Ether (*) routines exist and for multiple
adapter types.  Also you might want to look at the various IPv6 over Foo
specs that deal with how to deal with different link layer types.  The
check with the link-layer is a link layer function not an IP layer
issue.  In fact it is done on most implementations before the packet
comes off the interrupt queue to hit the IP layer.  

Lastly if there is a bug here it would be caught in the NUD state
machine and time out.

Regards,
/jim

>-----Original Message-----
>From: Pekka Nikander [mailto:[email-masked]] 
>Sent: Wednesday, February 12, 2003 8:43 AM
>To: IPV6 WG
>Cc: SEND WG
>Subject: Reason for the explicit link-layer address options in ND?
>
>
>On the behalf of the SEND DT, I'd like to get
>a clarification to the current ND design from
>those who were around back when RFC2461 and
>RFC2462 were written.
>
>Specifically, we'd like the know the exact
>reasons why RFC2461 uses separate source/target link
>layer address options instead of relying on the
>actual source link layer addresses used in the
>link layer frame?  Furthermore, why are the actual
>link layer addresses used in the link layer frame
>completely ignored, and not checked to match with
>the options?
>
>Is this just a layering question, an attempt to
>avoid layer violations?  Or were there behind
>other goals, like allowing proxy ND?
>
>The reason why I am asking this is that the current
>situation makes security design tricky.  That is,
>the Secure ND part of SEND (as opposed to Secure RD)
>is all about creating a secure binding between an IP
>address and a link layer address.
>
>The WG decided to pursue the idea of using public
>key based AH to secure the NA (and NS) messages.
>That requires that the hosts learn the public keys
>of the other hosts on the local link.  Basically,
>there are two know methods for distributing the
>public keys:  Using certificates and relying on
>a (local) CA, or using Cryptographically Generated
>Addresses (CGA).
>
>Now, for zero-config operation, we would like to
>use the CGA ideas.  Furthermore, there is a possible
>attack against link local addresses, and that attack
>can be partially dwarfed if we bind both the link
>layer address and the public key to the IP address
>in CGA.
>
>Under the current design, the CGA processing at the
>AH layer becomes very tricky, if we attempt to include
>the link layer address into the CGA process.
>
>--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]
>--------------------------------------------------------------------
>

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Feb 2003 09:11:55 -0800

But isn't there a simple attack in which the attacker sends an NA message out
with the victim's link layer address in the option but its own address on the
frame? Naturally, if the link layer allows the attacker to send out frames under
a false address, it could fully spoof the victim as well.

            jak

----- Original Message -----
From: "Bound, Jim" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>; "IPV6 WG"
<[email-masked]>
Cc: "SEND WG" <[email-masked]>
Sent: Wednesday, February 12, 2003 6:30 AM
Subject: RE: Reason for the explicit link-layer address options in ND?

> To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
> body to <[email-masked]>.
> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 13 Feb 2003 12:52:53 +0200

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...)

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.

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

   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.

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.

   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?

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?

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.)

--Pekka Nikander

---

From: Mika Liljeberg <[email-masked]>
Date: 16 Feb 2003 01:37:16 +0200

> a false address, it could fully spoof the victim as well.

Cache poisoning. It seems to me that this could be made much harder with
a very slight change to the ND specification: store the Override bit
into the cache entry, and only allow an advertisment with Override=1 to
overwrite an entry with stored_Override=0, otherwise transition the
entry to STALE as with Override=0.

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 23:47:19 +0100 (CET)

> something above that doesn't belong there?

I recall there was also a feeling that since ARP provides the same separation
(ARP doesn't use the addresses in the link-layer frame) it would be a
bit too creative to remove it.

I think the separation in ARP has, if not helped, given more flexibility
e.g. when bridging between different 802 media with different bit order
in the header (e.g. Ethernet to Token ring or FDDI).
Also, I think it might have helped for media that doesn't have actual
link-layer addresses but instead just a local DLCI - where the DLCIs
each end sees is different. In that case there isn't an address in the
datalink header you can use.

  Erik