This issue addresses RFC 2461's assumptions about
securing ND messages.
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'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.
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.
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."
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.
Section 11 is too long to send. I'm interested to know if the
above steps are ok with everyone.
Comments?
Hesham
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
