Hi Hesham,
Comments embedded.
> - 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.
>
I think it might be wise to discuss whether the document should continue to
recommend IPsec with the Security ADs and get some input from the community
and the security directorate. draft-arkko-manual-icmpv6-sas-01.txt outlines
some scalability problems with IPsec, even if manual keying is used, as you
mention below. There is a potential deployment issue as to what constitutes
a "small" network and at what point the network hits the scalability barrier
when the network provider will have to completely reconfigure their network
and turn SEND on. I'm not sure whether it makes sense to recommend manual
keying for small networks when SEND would work as well and wouldn't require
a flag day reconfigure if the network grew too large. Also, manual keying
doesn't make sense for zeroconf networks, because it isn't zeroconf. The ND
part of SEND could be used for disconnected zeroconf networks, and the
router part could too if the host came preconfigured with a collection of
cert trust anchors.
> 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.
>
These look 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.
>
I would say "requires the use of IP layer", since if the user chooses to use
security in ND, they must use IP layer security.
> 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."
>
Reads well.
If there is support for completely deprecating IPsec for ND, I'd suggest
adding that instead.
> 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.
>
I assume you will also put a reference to draft-send-ndopts (to be changed
into the RFC when it passes IESG review) in the normative references
section?
jak
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
