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

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

Jari,

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

I believe the multicast keying problem for link-local is resolvable but
that is an IPsec discussion right?  Agreed for multicast past the link.

OK. In this sense your right I thought you were concerned about the IKE
process to get keys.  Which is valid but I believe they can be
preconfigured before the node is on the network too.  In fact a model
that I believe will become more prevalent over time esp handhelds.

Yes the NA in normal environment is required but not all.  Once the node
has a link-local address it could be congfigured at boot time to load a
key.  We do this today in industry for licenses etc.  When the IPv6 node
is booting and does DAD to get link-local address verified it then goes
and gets its key.  The key can then be used for the NA and NS processes.

The hole that is open widest to an attack is DAD.  That would be very
hard to fix.

As I said we will never have perfect security any more than other
aspects of life.

I would argue you SEND should see what it can do to extend security to
the mobile node and the link it enters via ND at the point of getting a
link-local adddress. If that is more secure it will reduce many other
attacks.

Regards,
/jim
--------------------------------------------------------------------
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
--------------------------------------------------------------------