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

Marc Blanchet <marc.blanchet@viagenie.ca> Thu, 31 May 2012 14:03 UTC

Return-Path: <marc.blanchet@viagenie.ca>
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 E8CFC21F8618 for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 07:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
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 McZDQRalIaxJ for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 07:03:18 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2B97021F8587 for <v6ops@ietf.org>; Thu, 31 May 2012 07:02:57 -0700 (PDT)
Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3796541306; Thu, 31 May 2012 10:02:56 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-8859-1"
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net>
Date: Thu, 31 May 2012 10:02:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DF1A945-EBB7-4B24-B7C1-2FF9CD93868A@viagenie.ca>
References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1278)
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:03:19 -0000

- I like that idea, since fragments have been a problem (from a security perspective, both v4 and v6). This writing seems to provide a good way to enable any middle box to be able to apply policies.  
- should the 6man mailing list be added to that thread?

Marc.

Le 2012-05-31 à 09:53, Ronald Bonica a écrit :

> Fernando,
> 
> The problem that we are wrestling with isn't specific to RA Guard. The kind of fragmentation that we are discussing will cause problems for firewalls, in general. 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
> 
> 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.
> 
>                                             Ron
>                                             <speaking as individual contributor>
> 
> 
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
>> Of Fernando Gont
>> Sent: Wednesday, May 30, 2012 7:19 PM
>> To: RJ Atkinson
>> Cc: v6ops@ietf.org
>> 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
>> 
>> On 05/30/2012 05:59 PM, RJ Atkinson wrote:
>>> 
>>> A better approach for the RA Guard document would be:
>>> 
>>> 1) to put together a separate I-D for 6MAN that says approximately
>>>   the above (and explains why).  There is probably a little text
>>>   clarifying that any host receiving an RA that did not comply with
>>>   the proposed new rule above MUST be dropped by that receiving
>> host.
>> 
>> FWIW, something like that has already been published and presented at
>> the last IETF:
>> 
>> * <http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-
>> 02.txt>
>> 
>> Cheers,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops