Subject: Last Call Issue: Deprecating RFC 2461 Security

From: "James Kempf" <[email-masked]>
Date: Sat, 31 Jan 2004 02:49:32 -0800

RFC 2461 Section 11 specifies using IPsec AH for Neighbor Discovery
security. But, as described in the ND options draft, this will only work
with manual keying and then the number of SAs may become large on links with
many nodes. Therefore, I'd like to suggest inclusion of a section in
draft-ietf-send-ndopts that specifically deprecates Section 11 of RFC 2461.
In Minneapolis, I asked Steve Bellovin about this and he mentioned he
thought it would be OK. Here is the text I would like to suggest:

10.0 Deprecation of RFC 2461 Security

Section 11 of RFC 2461 [7] specifies that IPsec AH should be used for
Neighbor Discovery security. However, as described in [21], IPsec can only
be used if keys are configured manually, and even then, the number of
security associations generated can become large if many nodes are on the
link. Therefore, Section 11 of RFC 2461 is deprecated as soon as this
specification is approved as a proposed standard.

Comments?

            jak

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 3 Feb 2004 00:53:18 -0500

Jari, 

That's exactly what I think we should do. 

Thanks,
Hesham

 > -----Original Message-----
 > From: Jari Arkko [mailto:[email-masked]]
 > Sent: Tuesday, February 03, 2004 12:44 AM
 > To: Soliman Hesham; 'James Kempf'
 > Cc: [email-masked]
 > Subject: Re: Last Call Issue: Deprecating RFC 2461 Security
 > 
 > 
 > Soliman Hesham wrote:
 > > => What does "deprecated" mean here ? If someone has a link 
 > > with two nodes on it and decides to use IPsec to secure
 > > ND on this link is s/he doing something wrong? 
 > > 2461 is going to be obsolete anyway by a new RFC so I don't
 > > know how valuable this section would be.
 > 
 > The easiest option for us is to do nothing. Then we don't need to
 > ask permission from IPv6 WG, no one will get upset that we are
 > "changing" IPv6 etc. However, I believe the honest thing to do
 > is to admit that RFC 2461 has some significant limitations. Of
 > course, we already describe some of this in our document. The
 > question is perhaps whether this is sufficient or whether we need
 > to make it more explicit. And if we do something about the IPsec
 > parts, do we rip it out completely, constrain it to manual keying,
 > or just warn about its limitations? And where do we do it, in
 > 2461bis, the send protocol document, or in a separate document?
 > 
 > I do not feel strongly about this, but my preference would be
 > to do this as follows:
 > 
 >    - Leave send document as it is. It already mentions the
 >      limitations.
 >    - When updating 2461, demote the current IPsec model by
 >      . Removing the keywords
 >      . Moving it to an appendix
 >      . Deleting strong claims, such as "Confidentiality issues
 >        are addressed by the IP Security Architecture and ESP"
 >        or "The security associations may have been created through
 >        manual configuration or through the operation of some
 >        key management protocol."
 >      . Pointing to my old drafts (maybe published as RFCs) or
 >        other explanations describing the limitations in more
 >        detail.
 >      . Pointing to SEND as the current official security
 >        mechanism.
 > 
 > This would still enable compliant use of the old mechanisms,
 > but would give sufficient warning, at the right place, that
 > some problems exist.
 > 
 > --Jari
 >