Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

RJ Atkinson <rja.lists@gmail.com> Tue, 29 May 2012 16:38 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E2521F871C; Tue, 29 May 2012 09:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.2
X-Spam-Level:
X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTFUPwKX6zqz; Tue, 29 May 2012 09:38:09 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C79AA21F8714; Tue, 29 May 2012 09:38:08 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3115642vbb.31 for <multiple recipients>; Tue, 29 May 2012 09:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=i41KrFM7W48ASgsd/mhyzOSt/X+Y5a/T8Pb2jeBEIc0=; b=oj9cc+SqVCEf3PCcafhB+Sj13uc/rMuv8uRG7KVHq48inIhwkcxQsAHGNghSOzIVAY Hxp+0hnkeSJoB5xbTeQYstWtP8RoKom97/4UmFqqliLgYgNLpu8VX/66jXdkjOrTwoCK CCX+nXzWc/skrL3Q1/ijy+NDkvIqMPojCfJW9JTQpXbcuBX3AetSpxCZRq3+TMd7xrQq 47dTrP3FrYiaKz2PfM3lEDjnorPcmFzIRvoriVfsvhhvHregYwNC9GSD1YquK+i3mC8Y 5YbLfLdNIZ5o3Zje1IGsFgMvNuNGkXx5+CG4LZA5Q3HyJ9FODh6kywKYO4eeu6T2DbbZ 4gYg==
Received: by 10.52.174.52 with SMTP id bp20mr11366120vdc.29.1338309488306; Tue, 29 May 2012 09:38:08 -0700 (PDT)
Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id s10sm21350938vdg.10.2012.05.29.09.38.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 09:38:06 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <20120529143900.25613.76678.idtracker@ietfa.amsl.com>
Date: Tue, 29 May 2012 12:38:05 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com>
References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com>
To: v6ops@ietf.org
X-Mailer: Apple Mail (2.1278)
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 29 May 2012 16:38:10 -0000

On 29  May 2012, at 10:39 , The IESG wrote:
> The IESG has received a request from the IPv6 Operations WG (v6ops) to
> consider the following document:
> - 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
>  <draft-ietf-v6ops-ra-guard-implementation-04.txt> as Best Current
> Practice

While I generally support publication of this document, there is 
a blocking issue that ought to be resolved prior to publication.


1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped

  MULTIPLE ISSUES:

  Rule #4 in this document is overly restrictive.  Implementing
  this rule has the effect of changing the IPv6 specifications
  to prohibit otherwise legitimate packets that violate this new
  and somewhat arbitrary rule, which is an unreasonable change.  
  In effect, this cure (i.e. Rule 4) is worse operationally than 
  the potential disease.

  This rule can cause entirely legitimate IPv6 packets to be dropped,
  neither because they are invalid, nor because those packets 
  violate IPv6 specifications, nor because their header chain is
  too long (from a specification & legitimacy perspective),
  nor because they are security risks.  Instead, such packets are
  dropped because a Layer-2 device lacks sufficient information
  to perform a Layer-3 function (i.e. packet parsing/inspection).

  Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are 
  commonly, correctly, and legitimately used to interconnect different 
  segments of the same IPv6 subnetwork.  So a Layer-2 device cannot 
  know whether a particular RA Advertisement is valid or not -- that 
  information is simply not available at Layer-2 in a dependable way.
  Absent manual configuration that tells the Layer-2 device which ports
  might connect to routers, the Layer-2 device separately cannot know
  which "ports ... are not allowed to send ICMPv6 Router Advertisement
  messages".  

  Separately, in a network that contains wireless elements, routers
  might connect to different Layer-2 base stations at different times.
  In turn, those different Layer-2 base stations are very likely to 
  connect to different Layer-2 ports on different Layer-2 switches/bridges.
  Such Layer-2 switches/bridges generally cannot know that a wireless
  aspect exists in the deployment.  So this is another reason that a
  Layer-2 only device is not the correct place to be trying to filter
  ICMPv6 RA packets.

  Removing this rule creates no new security risk as the any actual
  problem packet can be detected and dropped later -- either by an 
  IPv6-capable router or an IPv6-capable firewall -- one that is 
  located at an IPv6 subnetwork boundary.

  There are existing openly specified, legitimate, IPv6 Destination
  Options that can be somewhat large in size (notably: CALIPSO).
  While such packets are not common, they are entirely legitimate
  and valid.  A BCP from an operationally focused WG ought not
  be recommending that valid IPv6 packets be dropped, as this will
  impede deployment of IPv6.


  PROPOSED ACTION:

  The current Rule #4 should be have its meaning inverted (i.e. If a
  Layer-2 device is unable to identify whether the packet is an ICMPv6
  Router Advertisement, then the packet should be transmitted without
  modification) and text referring to that rule also should be edited 
  heavily to outline the issues noted above as the reason for the
  "transmit if in doubt" policy for a Layer-2 device.


OBSERVATION:
  The only fully secure networks are those that move no packets at all.
  So our goal ought not be a "fully secure" network.  Instead, the goal
  should be taking reasonable, practical steps to reduce operational
  risks to an acceptable level -- while allowing all valid IPv6 packets
  to use the network.


Yours,

Ran