This issue addresses RFC 2461's assumptions about securing ND messages.
Thanks for taking this up.
The following is needed:
- explain context in which IPSec can be used to secure NDP messages. This should include a reference to the SEND work.
- Expand Security Considerations section to discuss more security threats defined in draft-ietf-send-psreq-xx.txt.
- Need more elaborate discussion on manual vs. dynamic keying.
I think the general approach is correct. You may wish to avoid an extensive discussion of the threats and just list the main ones, then refere to the details through psreq (which I believe has been approved by IESG).
Also, I think what you are trying to achieve is (a) make it still possible to use the old AH-based approach but explain its limitations better, (b) inform the reader about the availability of another approach, SEND, and (c) inform the reader about the various vulnerabilities associated with running ND without security. This is a good approach. But there's the additional issue of what you actually are mandating in this document, and with what keywords. Do you have a suggestion on what it should be?
I'm currently doing the following:
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.
Perhaps the latter explanation could go into the security considerations section.
2. Remove the "AH" sections included under the message formats. They're not wrong per se, but they give the impression that
IPsec is always possible. Any objections to this step?
3. Remove the IPsec checks in the sections describing the validation of various ND messages.
4. Rewrite most of section 11.
Ok.
Here is section 3.2 so far:
3.2 Securing Neighbor Discovery messages
"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.
In order to allow for IP layer security, a mechanism is required to allow
for dynamic keying between neighbors. The use of the Internet Key Exchange
[IKE] is not suited for creating dynamic security associations that can be
used to secure address resolution or neighbor solicitation messages as
documented in [ICMPIKE]. The security of Neighbor Discovery messages through
dynamic keying is outside the scope of this document and is addressed in
[SEND].
In some cases, it may be acceptable to use statically configured security associations with either [IPv6-AH] or [IPv6-ESP] to secure Neighbor Discovery messages. However, it is important to note that statically configured security associations are not scalable (especially when considering multicast links) and are therefore limited to small networks with known hosts."
How about this for 3.2:
Vulnerabilities related to Neighbor Discovery are discussed in Section 11.1. A general solution for securing Neighbor Discovery is outside the scope of this specification and is discussed in [SEND]. However, Section 11.2 explains how and under which constraints IPsec AH or ESP can be used to secure Neighbor Discovery.
And then in 11.1 and 11.2 you would include text from the above.
Informative references:
[ICMPIKE]Arkko, J., "Effects of ICMPv6 on IKE", draft-arkko-icmpv6-ike-effects-02 (work in progress), March 2003.
Arkko, J., "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", draft-arkko-manual-icmpv6-sas-02 (work in progress), March 2003.
And
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-04 (work in progress), February 2004.Section 11 is too long to send. I'm interested to know if the above steps are ok with everyone.
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
