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

Fernando Gont <fgont@si6networks.com> Thu, 31 May 2012 14:55 UTC

Return-Path: <fgont@si6networks.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 C766421F8630 for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 07:55:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhDgSAnpuPCn for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 07:55:21 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCA421F8587 for <v6ops@ietf.org>; Thu, 31 May 2012 07:55:21 -0700 (PDT)
Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.173]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1Sa6mT-00088u-9e; Thu, 31 May 2012 16:55:17 +0200
Message-ID: <4FC7864D.8000307@si6networks.com>
Date: Thu, 31 May 2012 11:55:09 -0300
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ronald Bonica <rbonica@juniper.net>
References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net>
X-Enigmail-Version: 1.5pre
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Fernando Gont <fgont@si6networks.com>, "v6ops@ietf.org" <v6ops@ietf.org>, RJ Atkinson <rja.lists@gmail.com>
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: Thu, 31 May 2012 14:55:24 -0000

Hi, Ron,

On 05/31/2012 10:53 AM, Ronald Bonica wrote:
> The problem that we are wrestling with isn't specific to RA Guard.

We're kind of discussing to different, but entangled, problems:

a) Use of fragmentation in Neighbor Discovery
b) IPv6 header chains that span multiple fragments


Regarding "a)", use of fragmentation with ND prevents feature-parity
with IPv4: It becomes virtually impossible to e.g. perform Neighbor
Discovery inspection (a la arpwatch or the like)

Regarding "b)", it essentially prevents stateless filtering, and also
breaks stateless translators. And is not limited to ICMPv6, but to all
traffic. (please see below)


> Therefore, we might want to request the
> following from 6man:
> 
> 1) Hosts MUST NOT send fragmented ICMPv6 packets unless the IPv6
> header, all extension headers, the ICMPv6 type, code, and checksum
> are included in the first fragment

This is a subset of "2)" below. Additionally, if you still allow
fragmentation, ND inspection (i.e. inspection of the ND packets
contents) is still virtually impossible -- and fragmentation is not
needed for ND, anyway. So one can safely forbid fragmentation with ND
(for the general case).

This is why I wrote
<http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-02.txt>



> 2) Hosts MUST NOT send fragmented packets carrying any next-layer
> protocol unless the IPv6 header, all extension headers, the entire
> next-layer protocol header are included in the first fragment. TCP
> and UDP are examples of next-layer protocols.

Fully agree. For instance, that's why we wrote:
<http://tools.ietf.org/id/draft-gont-6man-oversized-header-chain-01.txt>

My take is that these "packets with an IPv6 header chain that spans
multiple fragments" will be unreliable in the public Internet (stateless
firewalls and stateless translators).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492