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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Feb 2003 01:02:45 -0500

Jari,

> 
> > But it is a clear DOS and can happen in ARP, ES-IS, et al.  I would 
> > argue if this is a problem then IPsec can be used before 
> ICMP in ND. 
> > And this has been implemented by some.  I would think most SA 
> > verification code happens at the IP layer when the packet 
> is received 
> > by routine like ip_input (v4 or v6) and IPsec mandates all 
> packets be 
> > checked for SA.
> 
> Yes, though you run into a couple of practical problems when 
> you actually try to do this, namely problems getting IKE to 
> run before you can send UDP packets, and the relatively large 
> number of manual SAs if manual keying is used (2*n+2 SAs per 
> node where n is the number of interface ids on the network, 
> or something like that).

The IKE UDP issue is only an implementation issue the spec works.  We
have known this about manual keying since the beginnning.  IPsec will
work and with IKE.

> 
> > The other point is except for the mobile nodes roaming the link is 
> > secure at layer -0 (the link in the building and your not 
> allowed in 
> > the building without an identification per the armed 
> guards).  But for 
> > public links this is an issue and for wireless nodes but 
> that is the 
> > work for SEND to do is my belief.  I think you need to look 
> at using 
> > IPsec as one method. But redefining the ND or Addrconf architecture 
> > should not be in the SEND charter.
> 
> Exactly, so that's why SEND is actually trying to use IPsec 
> and Pekka is asking clarifications on why certain things are 
> like they are in ND. We are working on the problems mentioned 
> above. Work still remains, as you can see one of the issues 
> we are thinking about is the relevance of link layer 
> addresses and what checks are necessary or possible.

Clarification is good.  Was the spec not clear?

/jim

--------------------------------------------------------------------
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: Jari Arkko <[email-masked]>
Date: Thu, 13 Feb 2003 12:46:03 +0200

Jim,

> have known this about manual keying since the beginnning.  IPsec will

Yes, the manual keying issue is mostly implementation, or rather
configuration.

But the IKE issue is more fundamental than just implementation.
For one, Neighbor Discovery uses multicast extensively and IKE
of course only handles unicast. So from the start we can't really
use dynamic keying for all of ND. Furthermore, even if you would
ignore multicast, some chicken-and-egg problems remain. For instance,
assume that we need to talk to a peer, and do address resolution
first. If all unicast traffic between the two peers is expected to be
secured, this would imply that a solicited NA would have to
be secured as well. But in order to secure the NA, we would need IKE
to send IP packets to the peer, which in turn would require
us to see the NA first, right? So it doesn't really work as of
now.

> Clarification is good.  Was the spec not clear?

I think we now have gotten more information on the role
of the link-layer addresses in ND and why they are not
checked. Thanks. I'm personally leaning towards leaving
link-layer address checks away from SEND.

Jari