Subject: Re: Securing Neighbor Discovery BOF

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 10 Jun 2002 15:01:43 -0400

In message <002f01c210af$df9ec240$246015ac@T23KEMPF>, "James Kempf" writes:
>Hi Steve,
>
>> >Key distribution could be done via Layer 2 AAA or using the roaming
>> >consortia idea we had in the ABK draft. However, I think that might
>> >require some change in IPsec policy, because I believe the policy
>only
>> >allows IKE or manual keying for key distribution.
>>
>> That's not correct.  In fact, there's another working group, KINK,
>> whose goal is Kerberos key management for IPsec.
>>
>
>Thanx for the correction.
>
>So is it the case then that there would be no change in IPsec policy
>required for doing AAA-based or roaming consortia-based key management?
>Is so, then perhaps this problem is fairly straightforward to solve.

Well, as straight-forward as any key management issue...

But the word "policy" is important; there's a lot more to setting up an 
IPsec than key exchange.  Deciding exactly what to encrypt and how has 
to be negotiated, imposed, or otherwise agreed-upon.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

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

Jari,

Can you be more clear.  Customers are using IPsec for IPv4 just fine and now using IPv6 in test beds.  The bake-offs work. 

Whats the problem.

IPR is only issue for the keying.  And that the IETF has punted on IMO.

/jim

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 8:12 AM
> To: Pekka Savola
> Cc: James Kempf; [email-masked]
> Subject: Re: Securing Neighbor Discovery BOF
> 
> 
> 
> Pekka Savola wrote:
> 
> 
> > Are there any non-encumbered technologies to Secure ND?
> 
> 
> IP Security, for one. The current IPsec can be used, though
> it's pretty cumbersome due to (a) large number of similar SAs
> needed for manual keying due to destination address being a
> part of SA lookup and (b) chicken-and-egg problem for IKE.
> The problem (a) could be solved, and the result would be a
> more easily usable IPsec for securing large private networks.
> For public networks manual keying does not scale, however.
> Perhaps something can be done for (b). For instance, one
> possible, even if ugly, solution is to provide an ND-level
> message to carry IKE-like traffic between the ND
> peers until an IPsec SA can be established. Contributions
> on this space are sought -- feel free to jump in here ;-)
> 
> Then there are ABK and CGA-based techniques.
> 
> Anyway, I'm not sure we at this point have all the solutions.
> If we agree the issue is a problem, the group will figure out
> the possible solutions and their pros and cons. (IPRs are
> likely to be taken in account.)
> 
> Jari
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:51:29 -0400

the market will solve the keying problem James while the IETF is still working on it :--)
/jim

> From: James Kempf [mailto:[email-masked]]
> Sent: Sunday, June 09, 2002 2:41 AM
> To: Pekka Savola
> Cc: [email-masked]
> Pekka,
> We will shortly be releasing the ABK draft with a statement like the
> Photuris statement, which was included in IKE.
> 
> Also, some people believe that IPsec will work. If some way 
> can be found
> around the keying problem, it could be a viable alternative.
> 
>             jak
> 
> ----- Original Message -----
> From: "Pekka Savola" <[email-masked]>
> To: "James Kempf" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, June 07, 2002 1:51 AM
> > On Fri, 7 Jun 2002, James Kempf wrote:
> > > 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]).
> >
> > Thought so...
> > --
> > 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: "Bound, Jim" <[email-masked]>
Date: Fri, 14 Jun 2002 09:07:18 -0400

Hi James,

> Sent: Thursday, June 13, 2002 1:21 PM
> To: Bound, Jim; [email-masked]
> 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).

So your talking about either coming on a public link or over PPP and there is ND and you want IPsec right?  If so just use IPsec?  I still don't know what your missing.
If you mean folks don't like the keying or have not figured that out I agree.  But then it is a misnomer to say it is an IPsec problem.  It is an IPsec Keying problem and this is a different statement.  IPsec does work over ND.

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

OK so it is a Keying problem.  We as architects have very important responsiblity here.k
Saying in public mail "IPsec don't work on ND" is bad thing.  Keying is of course an issue and all of us who have implemented IPsec are well aware of this issue and real time in the market place.  We work around it via 3rd party Certificate Keying ISVs in that business and get the job done.  Once that happens it works for ND and other parts of IPv6.

Yes I can see AAA working and advantages of PANA exactly for this purpose for sure as an alternative solution.  And probably will perform better IMO. (unless IPsec and keys can be downloaded to a smartcard or net processor).

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

Agreed and I would also argue it needs to work between wireline and wireless as the user sticks their handheld back in the docking station at work or home.

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

Well you know me James I am very secure individual and think the paranoid have way to much influence over our technology :---)  But I will read this spec on my todo list as a professional and if have questions will get back to you privately or Pekka or both.

thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 14 Jun 2002 09:10:06 -0400

Bill,

I agree see my response to James I just sent.  Just wanted to flush our IPsec protocol vs Keying which I think we just did.

thanks
/jim

> From: Bill Sommerfeld [mailto:[email-masked]]
> Sent: Thursday, June 13, 2002 3:16 PM
> To: Bound, Jim
> 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
>