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 <fernando@gont.com.ar> Fri, 01 June 2012 01:43 UTC

Return-Path: <fernando.gont.netbook.win@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 10D0621F8541 for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 18:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 1K93stofz6PE for <v6ops@ietfa.amsl.com>; Thu, 31 May 2012 18:43:00 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF621F8540 for <v6ops@ietf.org>; Thu, 31 May 2012 18:42:59 -0700 (PDT)
Received: by yhq56 with SMTP id 56so1410856yhq.31 for <v6ops@ietf.org>; Thu, 31 May 2012 18:42:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=kpRFL4pp/wXr+PId6GUdq3vSj8xl53HYUmn3PGONnh4=; b=VsD7JG5XNAkiltIAGLBFEZCMniKdYulq+YtQuUcc+oxHVmpeAG93aygUh0eo8gLxLB aNHsXzxoe2NlNVu3YuKrKehN8FuVZseKCTWZCLWrLc++YXQk0vSL61JCR7T+f90AYcIn 1I12i3e6eSMdn4/InPppD1SBms3jlXt7V3Kc+cF6ZkJVE7x0NI4EhUpHBms8B9St9LO/ XHFaA2bgGm0PKPbguzJPJekbpqIVWlsWeSoyopFCrjmZ7BqkH559r0ToyMPPoIKzv8im UjC3fU5dkH96xzCqCU4GyTh1NxNiGMLkaug6ay2TB7ay/XeLOo/0YqFlKFSlJwMXjxv5 ApSQ==
Received: by 10.236.125.135 with SMTP id z7mr861911yhh.44.1338514979246; Thu, 31 May 2012 18:42:59 -0700 (PDT)
Received: from [192.168.123.103] ([186.134.30.55]) by mx.google.com with ESMTPS id q44sm1561384yhg.3.2012.05.31.18.42.54 (version=SSLv3 cipher=OTHER); Thu, 31 May 2012 18:42:58 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4FC81786.10207@gont.com.ar>
Date: Thu, 31 May 2012 22:14:46 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: RJ Atkinson <rja.lists@gmail.com>
References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com>
In-Reply-To: <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com>
X-Enigmail-Version: 1.5pre
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, Ran Atkinson <ran.atkinson@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: Fri, 01 Jun 2012 01:43:01 -0000

Hi, Ran,

On 05/31/2012 05:32 PM, RJ Atkinson wrote:
> On 31  May 2012, at 14:52 , Fernando Gont wrote:
>> Note: the only possible "issue" here is that with SEND, packets
>> *might* grow large enough to need fragmentation. However:
>> 
>> 1) The aforementioned behaviour would be specified for traditional
>> ND, rather than SEND.
> 
> OK.  As you say, it makes sense to except SEND from the restriction,
>  since it provides stronger authentication already.

Well, in the case of SEND, one *might* want to relax the restriction to
"SHOULD". However, I'd note that having SEND rely on fragmentation seems
to me like a very bad idea: essentially, an attacker could perform a
fragmentation-based DoS attack against SEND, and hence nodes would
typically employ the malicious and non-authenticated information sent by
the attacker (unless there's no fall back for non-send nodes).


>> 2) At least the packet sizes sampled in the SEND spec are not
>> larger than 1280 bytes 3) If you do deploy send, you don't really
>> want to rely on fragmentation. If you do, then an attacker could
>> trivially "disable" SEND by performing fragmentation (DoS)
>> attacks.
>> 
[....]
> I don't know whether a SEND expert might have concerns.

I will drop a note to the authors of the SEND spec and ask for input...



>> draft-gont-6man-oversized-header-chain tackles a more general
>> problem: since we cannot ban IPv6 fragmentation altogether for
>> general traffic (for obvious reasons), for the general case we
>> require the first fragment to include the entire IPv6 header chain
>> (i.e., "put as many headers as you want (including
>> fragmentation)... but the entire IPv6 header chain must be
>> available in the first fragment").
> 
> For the RA Guard problem, I strongly prefer the approach you
> indicate is defined in draft-gont-6man-nd-extension-headers --
> because it is better scoped.  Also, the sender always knows the link
> MTU for directly attached links (i.e. always known for the ND case)
> and ND is always link-local.  So there are fewer unknowns
> operationally.

Well, draft-gont-6man-nd-extension-headers kind of tackles the
underlying problem behind filtering/monitoring ND-traffic.

OTOH, draft-gont-6man-oversized-header-chain tackles a related but
different problem (that's why it's not as scoped).


> I am not as enthusiastic about the *-oversized-header-chain
> approach, which appears to have much broader scope, because a sending
> node can't reliably know the Path MTU, sadly, and because I know of 
> some odd-sized IPv6 link MTUs in the deployed world.

Well, what *-oversized-header-chain essentially says is that if you
fragment your packets, the entire IPv6 header should be present in the
first fragment. As long as there is no intermmediate system that
fragments your datagrams *and* splits the IPv6 header chain into
multiple fragments, you're fine.


> Also, as I recall, you identified some special cases where the Path
> MTU might be less than the theoretical IPv6 minimum MTU and yet the
> Path MTU could be valid per various other IETF (transition-related
> ??) specs.

What can be less than the IPv6 minimum MTU is the advertised MTU in an
ICMPv6 PTB message (which would trigger the inclusion of a fragment
header in all further packets). However, the minimum MTU is still
considered to be 1280 bytes.


> However, I can tolerate *-oversized-header-chain, if that really is
> preferred collectively over the more focused *nd-extension-headers 
> approach.

I think that both documents complement each other. Since
*nd-extension-headers bans the use of fragmentation in ND, it not only
simplifies the implementation of ra-guard, but *also* enables
ND-monitoring (i.e., inspecting the contents of ND packets e.g. a la
arpwatch).



>>> This means that the RA Guard document ought to: (1) cite
>>> (normatively) draft-gont-6man-oversized-header-chain, (2) delete
>>> Rule 4 of the RA Guard draft (which is not needed), and (3) add
>>> clarifying text to the RA Guard draft noting that the referenced
>>> 6MAN document ensures that RA messages that try to hide behind a
>>> Fragment Header will be dropped by the receiving IPv6 node.
>> 
>> But if it's agreed that packets that do not contain the entire
>> IPv6 header chain shouldn't be there, what would be the motivation
>> for allowing them through ra-guard?
> 
> That logic seems to include a somewhat theoretical assumption -- 
> namely that an RA Guard implementation built out of available CPUs
> and available silicon will be able to read all of the bytes in the
> IPv6 packet and will be able to do so at some interesting fraction of
> line-rate for common interfaces.  In theory, that might be true, and
> for some specific implementations it could be true, but it won't be
> universally true in practice. For example, it is unlikely to be true
> anytime soon for very high speed Ethernet links.

Well, this is the reason for which the first version of
*nd-extension-headers tried to ban the use of all extension headers with
ND. But it was argued (in 6man) that of parsing the entire IPv6 header
chain at a layer-2 device was easily doable, and hence there was no need
to limit possible extensions of ND (based on ext headers).

In any case, if anything, this would be an argument to the extent to
which ra-guard is simple/possible to implement, rather than about
whether we should leave rule #4 in or out.



> In the real world, some (many ?) implementations of RA Guard will
> have an implementation-specific limit to packet inspection that is
> less than the Link MTU. 
[....]
> So some (we hope not many) real world RA Guard implementations will
> not be able to figure out whether a particular valid IPv6 packet is
> valid or not, due to implementation-specific limitations of that
> particular RA Guard implementation.

I would expect that RA-Guard implementation enforce a limit on the
number of ext headers that they process (rather than of "bytes" that are
"jumped over"). In that case, if they enforce some sensible limit (10?)
they could prevent possible DoS attacks while still allowing all
legitimate traffic.


> When an RA Guard can't reliably
> figure out whether the packet is valid, the RA Guard should send the
> packet along -- on the principle of not dropping any valid IPv6
> packets (aka: "do no harm").

My take is that those packets will not survive the public IPv6 Internet.
Stateless firewalls will block those packets when the
implementation-specific limit is hit.


> Since the hosts will be protecting themselves from any RAs trying to
> hide behind Fragment Headers, there is no risk to having Rule 4
> either disappear or be changed to allow all packets where the
> particular RA Guard implementation can't figure out whether a given
> IPv6 packet is valid or not.

I fully agree with this when it comes to updated host implementations.
However, if the rules are changed as you indicate, those "legacy"
implementations that still allow the use of fragmentation with ND would
remain vulnerable.


> At a more architectural level, if the IPv6 specs need to change, then
> I'd like to see those changes proposed and accepted by the 6MAN WG
> (or its successors) -- rather than having an IETF recommended 
> operational practice have the result of changing the IPv6 specs 
> without bothering to update the actual IPv6 specs.

I personally believe that the specs should be changed -- for instance,
we're pursuing that effort in 6man with
draft-gont-6man-oversized-header-chain (about which 6man should be
polled soon).

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1