[secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt

Dave Cridland <dave.cridland@isode.com> Tue, 06 October 2009 12:39 UTC

Return-Path: <dave.cridland@isode.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6D53A683A; Tue, 6 Oct 2009 05:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-ameDhthApt; Tue, 6 Oct 2009 05:39:50 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EA5733A63CB; Tue, 6 Oct 2009 05:39:49 -0700 (PDT)
Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <Sss65ABfGygj@rufus.isode.com>; Tue, 6 Oct 2009 13:41:08 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-Id: <15898.1254832898.040887@puncture>
Date: Tue, 06 Oct 2009 13:41:38 +0100
From: Dave Cridland <dave.cridland@isode.com>
To: Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, pasi.eronen@nokia.com, julienl@qualcomm.com, cmadson@cisco.com
MIME-Version: 1.0
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
Subject: [secdir] secdir review of draft-ietf-ipsecme-ikev2-ipv6-config-02.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2009 12:39:51 -0000

I am reviewing this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and WG chairs should treat  
these comments just like any other last call comments. Feel free to  
forward to any appropriate forum.

This document extends the limited support for IPv6 VPN solutions in  
IKEv2, in particular allowing for multiple prefixes rather than a  
fixed number of addresses, which in turn allows various addressing  
strategies to be used.

The Security Considerations section is actually quite unclear to me -  
at first glance, the opening phrase suggests that the solution does  
indeed do the thing it warns against, that is, assigning each client  
a unique, and therefore identifiable, prefix. It also fails to draw  
the reader's attention to any other relevent considerations - I'm  
assuming that the two and a half pages of security considerations in  
RFC 4306 have some direct relevance here.

Also, the informative references noted in the Acknowledgements  
section would appear to have some potentially important security  
considerations - for example, RFC 4891's final consideration is:

   Please note that using IPsec for the scenarios described in Figures
   1, 2, and 3 does not aim to protect the end-to-end communication.   
It
   protects just the tunnel part.  It is still possible for an IPv6
   endpoint not attached to the IPsec tunnel to spoof packets.

... given that IKEv2's previous support for IPv6 limited it to a  
single host at the client end, one assumes that this document  
introduces at least this security consideration.

Dave.