[rfc2461bis issue 252] Security considerations issues

Soliman Hesham <H.Soliman@flarion.com> Wed, 11 February 2004 05:55 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20938 for <ipv6-archive@odin.ietf.org>; Wed, 11 Feb 2004 00:55:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnKd-0006sP-5s for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 00:54:43 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B5shgf026432 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 00:54:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnKc-0006nN-1V for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 00:54:42 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20904 for <ipv6-web-archive@ietf.org>; Wed, 11 Feb 2004 00:54:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqnKZ-0000Ao-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 00:54:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqnJv-00001U-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 00:54:00 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqnIc-0007Zb-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 00:52:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnI7-0006Mo-TA; Wed, 11 Feb 2004 00:52:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqnHo-0006JV-6y for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 00:51:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20519 for <ipv6@ietf.org>; Wed, 11 Feb 2004 00:51:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqnHl-0007OU-00 for ipv6@ietf.org; Wed, 11 Feb 2004 00:51:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqnGK-00071X-00 for ipv6@ietf.org; Wed, 11 Feb 2004 00:50:17 -0500
Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1AqnEG-0006XD-00 for ipv6@ietf.org; Wed, 11 Feb 2004 00:48:08 -0500
Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2657.72) id <1FYGW3XQ>; Wed, 11 Feb 2004 00:47:40 -0500
Message-ID: <9E3BA3946476AD4EB94672712B12A85F042127@ftmail.lab.flarion.com>
From: Soliman Hesham <H.Soliman@flarion.com>
To: ipv6@ietf.org
Subject: [rfc2461bis issue 252] Security considerations issues
Date: Wed, 11 Feb 2004 00:47:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: ipv6-admin@ietf.org
Errors-To: ipv6-admin@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

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