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

From: Pekka Nikander <[email-masked]>
Date: Wed, 12 Feb 2003 15:43:21 +0200

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 12 Feb 2003 15:58:18 +0100

In your previous mail you wrote:

=> both reasons. In the same kind of design ideas, it is
forbidden to mix unicast and multicast between layers, i.e.,
if the IPv6 destination is unicast, the link-layer destination
MUST be unicast, and same with multicast in place of unicast.

=> this problem is the same than creating a secure binding
between a DNS name and an IP address (i.e., the DNSSEC one).

=> I stronly disagree: CGAs are very different: they
don't provide authentication, only ownership.
And there is a third way, Key-Based Addresses (KBA),
i.e., the opposite of CGAs.

   
=> I don't understand your problem: with public keys you
can sign NAs so secure the IPv6 to link-layer address binding.
To secure the reverse binding we can reuse inverse ND (RFC 3122).
So the only issue (:-) is the public key distribution...

Regards

[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 12 Feb 2003 09:56:09 -0800

> MUST be unicast, and same with multicast in place of unicast.

Can you point me to the text that forbids this? I was under the
impression that multicast emulation mechanisms (e.g. MARS, etc.)
use unicast link-layer destination addresses when the IPv6
destination is multicast. The whole point of multicast
emulation is to propagate network-layer multicasts over
unicast-only link layers - not true?

Thanks,

Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 12 Feb 2003 13:45:02 -0800

There is an explicit unjustified one-liner in 1812 (pg 34):
A router MUST not believe any ARP reply that claims that the Link
Layer address of another host or router is a broadcast or multicast
address.

While it is clearly the intent of the security do-gooders to avoid arp
cache pollution as a dos tool, there is a vast difference between
'SHOULD NOT do this without explicit intent', and 'MUST NOT do this'. As
you point out there are cases where multicast over unicast makes sense,
and there are cases where IP-anycast over multicast link layer make
sense for load sharing. Unfortunately, the line above ends up as the
basis for declarations that the types have to match.

Tony

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred L. Templin
> Sent: Wednesday, February 12, 2003 9:56 AM
> To: Francis Dupont
> Cc: Pekka Nikander; IPV6 WG; SEND WG
> Subject: Re: Reason for the explicit link-layer address options in ND?
> 
> 
> Francis Dupont wrote:
> forbidden to 
> > mix unicast and multicast between layers, i.e., if the IPv6 
> > destination is unicast, the link-layer destination MUST be unicast, 
> > and same with multicast in place of unicast.
> 
> Can you point me to the text that forbids this? I was under 
> the impression that multicast emulation mechanisms (e.g. 
> MARS, etc.) use unicast link-layer destination addresses when 
> the IPv6 destination is multicast. The whole point of 
> multicast emulation is to propagate network-layer multicasts 
> over unicast-only link layers - not true?
> 
> Thanks,
> 
> Fred
> [email-masked]
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Feb 2003 18:15:17 +0100

> MUST be unicast, and same with multicast in place of unicast.
   
   Can you point me to the text that forbids this?

=> RFC 1122 3.3.6 but I recognize this needs to be clarify
for IPv6.

   I was under the
   impression that multicast emulation mechanisms (e.g. MARS, etc.)
   use unicast link-layer destination addresses when the IPv6
   destination is multicast.

=> in the case of MARS for ATM there is no real link-layer addresses
for the point-to-multipoint virtual circuits. Even if MCS are used
in fact we can argue the link-layer address is a set of addresses
with possible indirection.

   The whole point of multicast emulation is to propagate
   network-layer multicasts over unicast-only link layers - not true?
   
=> yes but the special mark for link-layer broadcast/multicast packets
is still needed.

Regards

PS: the exact quote is (see also TCP/IP illustrated V2 page 1101):

         When a host sends a datagram to a link-layer broadcast address,
         the IP destination address MUST be a legal IP broadcast or IP
         multicast address.

         A host SHOULD silently discard a datagram that is received via
         a link-layer broadcast (see Section 2.4) but does not specify
         an IP multicast or broadcast destination address.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------