Subject: Re: Securing Neighbor Discovery BOF

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Jun 2002 10:20:54 -0700

Hi Jim,

> What is the point of this meeting.  We have so many meetings to go to.
>
> Just turn on IPsec whats not in ND to support this?
>
> What problem are you trying to solve?
>
> IPsec works for ND?
>

We are interested in discussing how to secure IPv6 Neighbor Discovery in
a way that would work well for public access networks (but not
exclusively confined to that).

RFC 2461 specifies that IPsec should be used to secure the signaling
involved in ND, but does not provide any details about how this should
be done, and, specifically, how key distribution would be done. IKE
won't work because it requires ND so there is a bootstrapping problem.
Manual keying would work for a small private network, and possibly even
for a larger enterprise network, but it would be extremely inconvenient
for public access networks. There have also been some proposals to use
other security protocols rather than IPsec for ND security.

The immediate need for this work comes out of plans by ISPs, especially
in Asia, to deploy public access IPv6 wireless networks (NTT
Communications is running a prototype deployment in Kyoto at the
moment). While the problem of ND security is not, in principle, any
better or worse with wireless than with wireline, current wireline links
tend to have less of a problem because they typically are point to point
rather than multi-access, so the issue doesn't arise, though it might
also be a problem with wireline multi-access links that do not use PPPoE
or other solutions to make the link look point to point.

If you are interested in the potential threats, I'd suggest reading
draft-kempf-netaccess-threats-01.txt, which I've just resubmitted to the
Internet drafts editor (it had timed out in April), and if you have
something specific you would like to speak about, please let either
Pekka or myself know.

            jak

--------------------------------------------------------------------
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: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:32:38 -0400

James,

IPsec works for ND?

thanks
/jim

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 4:33 AM
> To: [email-masked]
> Subject: Securing Neighbor Discovery BOF
> 
> 
> On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to
> discuss securing Neighbor Discovery. The BOF description, along with a
> suggested reading list, will appear when the agenda is posted on the
> IETF 54 Web page. If you are interested in this problem, 
> please attend.
> If you would like to speak, please send email to me or Pekka Nikkander
> ([email-masked]).
> 
> 
>             jak
>

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 13 Jun 2002 15:15:54 -0400

> What problem are you trying to solve?  

securing neighbor discovery exchanges.

> IPsec works for ND?

Using AH/ESP to protect ND works fine once the SA's exist.

However, there's a chicken & egg problem if you want to use IKE, and
manually configuring N*(N-1) SA's across N machines on the link is not
deployable.

So if you want to use IPsec to protect ND, you need to solve the key
management problem for ND.

					- Bill

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Jun 2002 22:43:28 +0300

> manually configuring N*(N-1) SA's across N machines on the link is not

Actually, it's worse. ND uses e.g. the solicited node multicast
address and the unicast address -- even if each node had a single
address. Since the RFC 2401 SAs are indexed through <dest,SPI,proto>,
you'll need _multiple_ SAs between two machines, even in one
direction. So, your formula should be more like 2*M*N*(N-1) where
M is the number of addresses per node.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Jun 2002 13:06:14 +0300 (EEST)

On Thu, 13 Jun 2002, James Kempf wrote:
> Internet drafts editor (it had timed out in April), [...]

It would have been nice to include the things I pointed out on the list
(and Cc: to you) on 23rd Nov, and an issue pointed out privately to you
and Erik on 19th Dec.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Savola <[email-masked]>
Date: Sat, 15 Jun 2002 18:11:08 +0300 (EEST)

> M is the number of addresses per node.

I'm only grasping at straws here, but the logical approach at keying would 
be requiring manual keying with a router in the subnet, through which the 
rest of the keys would then be negotiated (somehow).  

Even that may be unscalable, but manually keying like 2-4 keys is may be 
problematic also, but that might be workable.

There are some issues here (like when performing DAD for link-locals, and
someone telling that address is already in use, verifying whether that is
legit or not as one has not been able to contact the router yet) though.

I haven't really thought about this enough, but I wonder if anyone else 
has tried to follow this path, and seen where it leads.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Jun 2002 11:00:19 +0300 (EEST)

On Mon, 17 Jun 2002, Julien Laganier wrote:
> It is logic. But how do you handle the case of public hospitality
> networks, like those which could be found in airports, conference 
> rooms, etc., where there is no subscription (public wireless networks 
> are an example)?

This problem is too generic (IMO) to be solved properly in its full form.  
If we want any work to be accomplished, we must be able to make some 
assumptions.

One such (very valid IMO) assumption _could_ be that there is at least one
router with fixed connectivity in such a network, and the user can (at 
least to some extent) trust it.

> IMHO, manual keying only solves a few security threats in ND for a few
> networks policies. It is not appropriate for public access networks, it
> has a poor scalability, and so on.

I idea was to perform manual keying with the router _only_, and automatic 
for the rest.  This is a bit unscalable still, but not nearly as much as 
manually keying everything.

How router is configured with a new node's manual keys in a 
subscription-less system is more of a challenge though.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 17 Jun 2002 09:49:36 +0200

By publishing the secret keys to authorized members... You cannot know
them since the network is public.

Even in the case of a private networks, there is the problem of a rogue
node which could compromise the keys.

Folks?
-- 
Julien LAGANIER, PhD Student
RESAM Laboratory (UCB / INRIA RESO)
 Ecole Normale Superieure de Lyon

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Jun 2002 07:30:00 -0700

A possibility is for the ISP to distribute a public/private key pair
when the host gets its IP address, then use DH to generate the session
key. Or one could distribute a shared session key through secure (via
TLS over EAP) L2 authentication when the host enters the foreign
network. We proposed something similar for ABK using id crypto, and it
would work a little more cleanly there because the IP address acts as
the public key, but id crypto suffers from being a new and therefore not
well understood algorithm.

            jak

----- Original Message -----
From: "Julien Laganier" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; <[email-masked]>;
"Bound, Jim" <[email-masked]>; "James Kempf"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, June 17, 2002 12:49 AM
Subject: Re: Securing Neighbor Discovery BOF