Re: [rfc2461bis issue 252] Security considerations issues

[Jari Arkko <[e-mail]>]

Soliman Hesham wrote:
> 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
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------