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 Lampo" <marc.lampo@eurid.eu> Wed, 30 May 2012 07:34 UTC

Return-Path: <marc.lampo@eurid.eu>
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 8FA3121F86F8 for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 00:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
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 iAxDA1w8Sfx4 for <v6ops@ietfa.amsl.com>; Wed, 30 May 2012 00:34:29 -0700 (PDT)
Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id CBBFE21F86F7 for <v6ops@ietf.org>; Wed, 30 May 2012 00:34:27 -0700 (PDT)
X-ASG-Debug-ID: 1338363266-02dadd0667384bc0001-b2NLKh
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id iHUAsPvkHxZSe4ua; Wed, 30 May 2012 09:34:26 +0200 (CEST)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 02EC7E4059; Wed, 30 May 2012 09:34:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Augue8s4P84M; Wed, 30 May 2012 09:34:25 +0200 (CEST)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id E2E14E4050; Wed, 30 May 2012 09:34:25 +0200 (CEST)
From: Marc Lampo <marc.lampo@eurid.eu>
To: 'RJ Atkinson' <rja.lists@gmail.com>, 'Fernando Gont' <fernando@gont.com.ar>
References: <20120529143900.25613.76678.idtracker@ietfa.amsl.com> <3B0A71DA-8846-4FFF-9AD8-9B106EF8799B@gmail.com> <4FC52FD3.9060206@gont.com.ar> <AB2444D4-E85B-4E61-9944-47FB1E369203@gmail.com>
In-Reply-To: <AB2444D4-E85B-4E61-9944-47FB1E369203@gmail.com>
Date: Wed, 30 May 2012 09:34:25 +0200
X-ASG-Orig-Subj: 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
Message-ID: <003f01cd3e36$a3a09a60$eae1cf20$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: Ac09/+YZ5pymZ19jSr2iiaO2JIzI1wANaQMw
Content-Language: en-za
x-antivirus-status: Clean
x-antivirus: avast!
X-Originating-IP: [172.20.1.121]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1338363266
X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
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
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: Wed, 30 May 2012 07:34:29 -0000

Hello,

Just focussing on this rule #4 :
Seems to me that packets that would match this rule
might be theoretically valid, but in practice : questionable/dubious
packets.

If a packet is constructed is such a way that, before the end of the first
fragment is reached, one cannot determine if it is a RA,
I do have my questions about the nature (malicious ?) of this packet.

Compare it to IPv4 "options" : I always configured my routers to drop
IPv4 packets that had any options.  Not needed for any "production
traffic".
(unfortunately, such a simple solution does not exist, for IPv6 ...)


(out of scope for this document, but in reply to statement made)
About IPv6 not being broken by security devices :
I wonder how many security devices actually implement some kind of
security for IPv6 and if, to what extend.
Fact is that most vendors I had contact with claim to support IPv6,
but when starting to ask some further questions, it is usually
"back to some guru in the back office", with usually a "not yet"
response afterwards.


Kind regards,

Marc Lampo
Security Officer
EURid


-----Original Message-----
From: RJ Atkinson [mailto:rja.lists@gmail.com] 
Sent: 30 May 2012 03:03 AM
To: Fernando Gont
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


...

I know of lots of folks who'd be interested in RA-Guard, if the
specification weren't broken in a way that can cause valid IPv6 packets
that are not RA packets to be dropped.  So they would prefer the inversion
of Rule 4.

One of the main advantages of IPv6 is that it is not currently broken by
lots of mis-specified (pseudo-)security devices.  Please change this
document so that it won't cause valid IPv6 non-RA packets to be dropped.
Please don't break IPv6.

Yours,

Ran