James Kempf: 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. ---------------- Hesham Soliman: 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. ---------------- Jari Arkko: 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. ---------------- Hesham Soliman: That's exactly what I think we should do. ---------------- Jean-Michel Combes: 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 ?) > 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. Agree > - 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. Agree > This would still enable compliant use of the old mechanisms, > but would give sufficient warning, at the right place, that > some problems exist. Fine. ---------------- James Kempf: > 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? Not wrong, it just won't work very well. That is what ref. 21 describes. > 2461 is going to be obsolete anyway by a new RFC so I don't > 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. ---------------- James Kempf: 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. ---------------- Jean-Michel Combes: 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 ?) ---------------- ----------------