Question regarding Ra-Guard evasion (ND and extensio headers)

Fernando Gont <fernando@gont.com.ar> Fri, 10 June 2011 22:08 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=OgV8nakN1z7z7KCF4P/eNz6MetGamVjm4OdWItWgKxc1bRezqoZGb5+IKajn8LXSjI MbLZKuJewajClfgn17ZuDjeN0yoUQfF4nC90FtWzjrO1exCNJ6HbeAttDZCkMJ8k/yA2 gwVrZgStSCt6jwYwpEN94zdh7F0IlblpDdQUc=
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4DF291D0.7080707@gont.com.ar>
Date: Fri, 10 Jun 2011 18:51:12 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Question regarding Ra-Guard evasion (ND and extensio headers)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: list

Hi,

Some folks have expressed (both on-list and off-list) that they would
prefer a less agressive solution for the RA-Guard evasion vulnerability.
So I'd like to hear comments about the possible alternatives..

The current I-Ds (draft-gont-6man-nd-extension-headers and
draft-gont-v6ops-ra-guard-evasion) basically take this approach:

* Prohibit use of extension headers in ND messages. A host
implementation must not produce these packets, and must discard them if
it receives them
* This results in a RA-Guard implementation that is as simple as
possible (it only has to look at the header following the fixed IPv6
header).


A more relaxed approach would be as follows:
* Extension headers are allowed with ND messages.
* If the packet is fragmented, the upper-layer header (ICMPv6 in this
case) must be present in the first fragment (i.e., hosts must not
generate packets that violate this requirement, and must discard them if
they receive them).
* Possibly have the RA-Guard box enforce a limit on the maximum number
of extension headers that it will process (e.g., if after jumping to
the, say 10th header the upper-layer header is not found, drop the packet)
* This approach is less aggressive than the one proposed in the
aforementioned I-Ds (i.e., more flexibility), but of course would also
mean that the RA-Guard implementation would need to follow the header
chain, thus leading to increased complexity, and possible performance
issues.

Any comments/thoughts will be very much appreciated.

Thanks!

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

Question regarding Ra-Guard evasion (ND and exten… Fernando Gont
Re: [v6ops] Question regarding Ra-Guard evasion (… Mark Smith
Re: [v6ops] Question regarding Ra-Guard evasion (… Mark Smith
Re: [v6ops] Question regarding Ra-Guard evasion (… Philip Homburg
Re: [v6ops] Question regarding Ra-Guard evasion (… Bob Hinden
Re: [v6ops] Question regarding Ra-Guard evasion (… Fernando Gont
Re: [v6ops] Question regarding Ra-Guard evasion (… Fernando Gont
Re: [v6ops] Question regarding Ra-Guard evasion (… Fernando Gont
Re: [v6ops] Question regarding Ra-Guard evasion (… Ted Lemon
Re: [v6ops] Question regarding Ra-Guard evasion (… Fernando Gont
Re: [v6ops] Question regarding Ra-Guard evasion (… Mikael Abrahamsson
Re: [v6ops] Question regarding Ra-Guard evasion (… Tim Chown
Re: [v6ops] Question regarding Ra-Guard evasion (… Ted Lemon
Re: [v6ops] Question regarding Ra-Guard evasion (… Jean-Michel Combes
Re: [v6ops] Question regarding Ra-Guard evasion (… Jean-Michel Combes
Re: [v6ops] Question regarding Ra-Guard evasion (… Arturo Servin
Re: [v6ops] Question regarding Ra-Guard evasion (… Nick Hilliard
Re: [v6ops] Question regarding Ra-Guard evasion (… Nick Hilliard
Re: [v6ops] Question regarding Ra-Guard evasion (… Jean-Michel Combes
Re: [v6ops] Question regarding Ra-Guard evasion (… Joel Jaeggli
Re: [v6ops] Question regarding Ra-Guard evasion (… Fernando Gont