Re: [rfc2461bis issue 252] Security considerations issues

"James Kempf" <kempf@docomolabs-usa.com> Wed, 11 February 2004 23:15 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 SAA08473 for <ipv6-archive@odin.ietf.org>; Wed, 11 Feb 2004 18:15:17 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3ZC-0007iI-S6 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:14:51 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BNEoBV029641 for ipv6-archive@odin.ietf.org; Wed, 11 Feb 2004 18:14:50 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3ZC-0007hz-LM for ipv6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 18:14:50 -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 SAA08428 for <ipv6-web-archive@ietf.org>; Wed, 11 Feb 2004 18:14:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3Z9-0002aF-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:14:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3YD-0002UN-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:13:49 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3Xl-0002OO-00 for ipv6-web-archive@ietf.org; Wed, 11 Feb 2004 18:13:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3XS-0006zu-2F; Wed, 11 Feb 2004 18:13:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar3XG-0006xa-BF for ipv6@optimus.ietf.org; Wed, 11 Feb 2004 18:12:50 -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 SAA08136 for <ipv6@ietf.org>; Wed, 11 Feb 2004 18:12:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar3XD-0002LR-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:12:47 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar3WC-00027i-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:11:45 -0500
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ar3V3-0001rE-00 for ipv6@ietf.org; Wed, 11 Feb 2004 18:10:33 -0500
Message-ID: <03d501c3f0f4$5089f210$936015ac@dclkempt40>
From: James Kempf <kempf@docomolabs-usa.com>
To: Soliman Hesham <H.Soliman@flarion.com>, ipv6@ietf.org
Cc: Russ Housley <housley@vigilsec.com>, Steve Bellovin <smb@research.att.com>, Thomas Narten <narten@us.ibm.com>
References: <9E3BA3946476AD4EB94672712B12A85F04212E@ftmail.lab.flarion.com>
Subject: Re: [rfc2461bis issue 252] Security considerations issues
Date: Wed, 11 Feb 2004 15:11:00 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

>> 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.
>
>
> => I just want to clarify one thing: it is not my intention
> to recommend IPsec in any way. I just wanted to mention
> when it can be used and its limitation. I can add something
> to say that SEND is the preferred option in general. If the WG
> wants to remove any reference to IPsec I'm happy to do that
> too.
>

Sure, I understand.

My preference would be to say that use of IPsec is deprecated, since, as
outlined above, there may be significant deployment consequences if it is
used, and having one way to do something is generally simpler than having
many.

What do other WG members think?

Also, what do the Security ADs (cc'ed) think?

            jak


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------