Subject: RE: Last Call Issue: Deprecating RFC 2461 Security

From: Soliman Hesham <[email-masked]>
Date: Mon, 2 Feb 2004 18:00:34 -0500

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

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

Hesham

 > 
 >             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.
 > 
--------------------------------------------------------------------
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: Jari Arkko <[email-masked]>
Date: Tue, 03 Feb 2004 07:44:14 +0200

> 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

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 3 Feb 2004 11:37:41 +0100

Hi,

I agree with Hesham regarding the use of IPsec : if someone wants to use
IPsec, let's him to use it (why to deprecate something that works ?)

Regards.

JMC.

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19

> -----Message d'origine-----
> De : [email-masked]
> [mailto:[email-masked]]De la part de Soliman
> Hesham
> Envoyé : mardi 3 février 2004 00:01
> À : 'James Kempf'; [email-masked]
> Objet : RE: Last Call Issue: Deprecating RFC 2461 Security
>
>
>
> 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: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 3 Feb 2004 11:41:17 +0100

> [mailto:[email-masked]]De la part de Jari Arkko
> Envoye : mardi 3 fevrier 2004 06:44
> A : Soliman Hesham; 'James Kempf'
> Cc : [email-masked]
> Objet : Re: Last Call Issue: Deprecating RFC 2461 Security
>
>
> Soliman Hesham wrote:

Agree

>      . Pointing to SEND as the current official security

Agree

> but would give sufficient warning, at the right place, that

Fine.

JMC.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Feb 2004 08:28:54 -0800

> ND on this link is s/he doing something wrong?

Not wrong, it just won't work very well. That is what ref. 21 describes.

> know how valuable this section would be.

Are you planning on rewriting Section 11? And what is the timeline for the
rewrite? It may not matter if the new version comes out within a year or so.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Feb 2004 08:59:10 -0800

Jari,

This sounds like a good plan.

I think we should publish your draft about limitations on IPsec security for
ND. Since we are trying to wind down the WG, I'd suggest publishing it as an
individual submission, with the WG chairs recommending it. But it might be a
good idea to solicit someone with IPsec experience to do a review.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Soliman Hesham" <[email-masked]>; "'James Kempf'"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 02, 2004 9:44 PM
Subject: Re: Last Call Issue: Deprecating RFC 2461 Security

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 3 Feb 2004 18:10:13 +0100

Lost in the Internet 'space' ...

(sorry if you received this mail twice)

> De : Jean-Michel COMBES [mailto:[email-masked]]
> Envoyé : mardi 3 février 2004 11:38
> À : Soliman Hesham; 'James Kempf'; [email-masked]
> I agree with Hesham regarding the use of IPsec : if someone wants
> to use IPsec, let's him to use it (why to deprecate something
> that works ?)
>
> Regards.
>
> JMC.
>