Re: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-01.txt

"C. M. Heard" <heard@pobox.com> Thu, 30 January 2014 16:56 UTC

Return-Path: <heard@pobox.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF871A044C for <opsec@ietfa.amsl.com>; Thu, 30 Jan 2014 08:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcKqTgQGiQ_6 for <opsec@ietfa.amsl.com>; Thu, 30 Jan 2014 08:56:28 -0800 (PST)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF781A0443 for <opsec@ietf.org>; Thu, 30 Jan 2014 08:56:28 -0800 (PST)
Received: (qmail 1622 invoked from network); 30 Jan 2014 08:56:24 -0800
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jan 2014 08:56:24 -0800
Date: Thu, 30 Jan 2014 08:56:24 -0800
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: OPSEC <opsec@ietf.org>
In-Reply-To: <20131021222229.32495.36420.idtracker@ietfa.amsl.com>
Message-ID: <Pine.LNX.4.64.1401300805190.25041@shell4.bayarea.net>
References: <20131021222229.32495.36420.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-dhcpv6-shield-01.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 16:56:30 -0000

Hello,

In Section 5, bullet #1, I see:

   RATIONALE: [RFC6564] specifies a uniform format for IPv6
   Extension Headers, thus meaning that an IPv6 node can parse
   an IPv6 header chain even if it contains Extension Headers
   that are not currently supported by that node.

Actually, it's NOT possible for a node to safely parse an IPv6 
header chain containing Next Header values that it does not know, 
even with the uniform TLV format for IPv6 extension headers defined 
in RFC 6564.  The reason for that is because unkown Next Header 
value could represent an upper-layer protocol rather than an 
extension header, so it's not safe to attempt to follow the header 
chain any further.

The same issue affects draft-ietf-v6ops-ra-guard-implementation-07.  
Whatever solution applies to that document also applies to this one.  
Since ra-guard is in AUTH48 it's rather more urgent to get it fixed, 
so I suggest that those interested in this matter follow the 
discussion thread regarding that doc that I will start on the v6ops 
list shortly.

Thanks and regards,

Mike Heard

On Mon, 21 Oct 2013, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.
> 
> 	Title           : DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
> 	Author(s)       : Fernando Gont
>                           Will Liu
>                           Gunter Van de Velde
> 	Filename        : draft-ietf-opsec-dhcpv6-shield-01.txt
> 	Pages           : 9
> 	Date            : 2013-10-21
> 
> Abstract:
>    This document specifies a mechanism for protecting hosts connected to
>    a broadcast network against rogue DHCPv6 servers.  The aforementioned
>    mechanism is based on DHCPv6 packet-filtering at the layer-2 device
>    at which the packets are received.  The aforementioned mechanism has
>    been widely deployed in IPv4 networks ('DHCP snooping'), and hence it
>    is desirable that similar functionality be provided for IPv6
>    networks.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-dhcpv6-shield-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
>