[v6ops] Error in draft-ietf-v6ops-ra-guard-implementation-07

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

Return-Path: <heard@pobox.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034D71A0456 for <v6ops@ietfa.amsl.com>; Thu, 30 Jan 2014 09:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level:
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_HDRS_LCASE=0.01] 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 08J4EcPWxcQ4 for <v6ops@ietfa.amsl.com>; Thu, 30 Jan 2014 09:15:02 -0800 (PST)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FA11A044A for <v6ops@ietf.org>; Thu, 30 Jan 2014 09:15:02 -0800 (PST)
Received: (qmail 10795 invoked from network); 30 Jan 2014 09:14:58 -0800
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jan 2014 09:14:58 -0800
Date: Thu, 30 Jan 2014 09:14:58 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: V6OPS <v6ops@ietf.org>
Message-ID: <Pine.LNX.4.64.1401300857260.25041@shell4.bayarea.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Fernando Gont <fgont@si6networks.com>
Subject: [v6ops] Error in draft-ietf-v6ops-ra-guard-implementation-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 17:15:04 -0000

Hello,

In Section 3, bullet #3, I see:

  RATIONALE: [RFC6564] specifies a uniform format for IPv6 Extension 
  Header, 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 document is now in AUTH48, so it's still possible to fix the 
problem before it becomes and RFC.

Section 2.1 of RFC 7045 does have an applicable requirement:

   Forwarding nodes MUST be configurable to allow packets containing
   unrecognised extension headers, but the default configuration MAY
   drop such packets.

It seems to me that the proper advice for an RA-Guard implementation 
is to include a configuration switch that specifies whether it 
passes or discards packets with unknown Next Header values, 
probably with a default discard.

Thoughts?

Mike Heard