Subject: [rfc2461bis issue 252] Security considerations issues

From: Soliman Hesham <[email-masked]>
Date: Wed, 11 Feb 2004 00:47:37 -0500

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Feb 2004 10:58:55 +0200

> This issue addresses RFC 2461's assumptions about 

Thanks for taking this up.

> - 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?

> this doc and refer to SEND work. It also explains when IPsec

Perhaps the latter explanation could go into the security
considerations section.

> 4. Rewrite most of section 11. 

Ok.

> considering multicast links) and are therefore limited to small networks

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.

>          (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.

> above steps are ok with everyone. 

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 11 Feb 2004 08:46:26 -0800

Hi Hesham,

Comments embedded.

> this doc and refer to SEND work. It also explains when IPsec

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.

> 4. Rewrite most of section 11.

These look OK.

> 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.

> considering multicast links) and are therefore limited to small networks

Reads well.

If there is support for completely deprecating IPsec for ND, I'd suggest
adding that instead.

> 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