Subject: RE: [rfc2461bis issue 252] Security considerations issues

From: Soliman Hesham <[email-masked]>
Date: Wed, 11 Feb 2004 17:29:18 -0500

Thanks James, a couple of answers below.

 > > 1. Adding a new section (3.2) before the message formats
 > > to briefly explain that security is outside the scope of
 > > this doc and refer to SEND work. It also explains when IPsec
 > > can be used.
 > >
 > 
 > I think it might be wise to discuss whether the document 
 > should continue to
 > recommend IPsec with the Security ADs and get some input 
 > from the community
 > and the security directorate. 
 > draft-arkko-manual-icmpv6-sas-01.txt outlines
 > some scalability problems with IPsec, even if manual keying 
 > is used, as you
 > mention below. There is a potential deployment issue as to 
 > what constitutes
 > a "small" network and at what point the network hits the 
 > scalability barrier
 > when the network provider will have to completely 
 > reconfigure their network
 > and turn SEND on. I'm not sure whether it makes sense to 
 > recommend manual
 > keying for small networks when SEND would work as well and 
 > wouldn't require
 > a flag day reconfigure if the network grew too large. Also, 
 > manual keying
 > doesn't make sense for zeroconf networks, because it isn't 
 > zeroconf. The ND
 > part of SEND could be used for disconnected zeroconf 
 > networks, and the
 > router part could too if the host came preconfigured with a 
 > collection of
 > cert trust anchors.

=> I just want to clarify one thing: it is not my intention
to recommend IPsec in any way. I just wanted to mention
when it can be used and its limitation. I can add something
to say that SEND is the preferred option in general. If the WG
wants to remove any reference to IPsec I'm happy to do that
too. 

 > > "Neighbor Discovery messages are needed for various 
 > functions. Several
 > > functions are designed to allow hosts to ascertain the 
 > ownership of an
 > > address or the mapping between link layer and IP layer 
 > addresses. Having
 > > Neighbor Discovery functions on the ICMP layer allows for 
 > the use of IP
 > > layer security mechanisms, which are available independently of the
 > > availability of security on the link layer.
 > >
 > 
 > I would say "requires the use of IP layer", since if the 
 > user chooses to use
 > security in ND, they must use IP layer security.

=> ok, I actually changed this as per Jari's comment.

 > If there is support for completely deprecating IPsec for ND, 
 > I'd suggest
 > adding that instead.

=> I'll go with whatever the WG wants of course. So 
far only you and Jari have commented.

 > 
 > I assume you will also put a reference to draft-send-ndopts 
 > (to be changed
 > into the RFC when it passes IESG review) in the normative references
 > section?

=> Sure.

Hesham

 >             jak

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Wed, 11 Feb 2004 15:11:00 -0800

> wants to remove any reference to IPsec I'm happy to do that

Sure, I understand.

My preference would be to say that use of IPsec is deprecated, since, as
outlined above, there may be significant deployment consequences if it is
used, and having one way to do something is generally simpler than having
many.

What do other WG members think?

Also, what do the Security ADs (cc'ed) think?

            jak

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 11 Feb 2004 18:15:13 -0500

>Also, what do the Security ADs (cc'ed) think?

One of the major conclusions of SEND was that IPsec for neighbor 
discovery didn't work very well.  Given that, and given that we have a 
replacement coming, I have no objection.

However...  2461 is at Draft.  I'll have to figure out the procedural 
consequences of such a change at this point.  Of course, I also have 
to figure out the consequences of not making the change....

		--Steve Bellovin, http://www.research.att.com/~smb