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 <[e-mail]>]

Hi, Ran,

On 06/01/2012 09:44 AM, RJ Atkinson wrote:
> On 31  May 2012, at 21:14 , Fernando Gont wrote:
>> 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).
> 
> If the RA Guard built into the Layer-2 device is built using
> software on an off the shelf CPU/NP, then the device likely 
> can't parse the entire IPv6 header chain at wire speed -- 
> thereby creating a new easily exploited DOS attack vector
> on the RA Guard device.  This seems like a cure worse than
> the disease -- as the Ethernet switch connecting everything dies.

FWIW, this is the discussion I was referring to:
<http://www.ietf.org/mail-archive/web/ipv6/current/msg14284.html>.

My understanding is that we ended up converging on banning *only* the
Fragmentation Header (in draft-gont-6man-nd-extension-headers) based on
the outcome of that discussion (i.e., parsing the IPv6 header chain at
wire speed being doable).

If RA-Guard were to be implemented as you describe, I agree that in
*that* case the cure could be worse than the disease.


>> 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.
> 
> No.  It is a reality-check.  Absent custom silicon (FPGA/ASIC),
> it isn't going to be practical to parse deeply into the packet
> at interesting fractions of wire-speed. 

Should I add some text about this in the Security Considerations section?



>> 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.
> 
> A state-less firewall is much more likely to use a store-and-decide
> architecture than a Layer-2 switch, precisely because their main purpose
> is Deep Packet Inspection.

Agreed. However, my point is that if your packets lack the entire IPv6
header chain, they are likely to be dropped (whether by a stateless
translator, a stateless firewall, or anything else), and hence should
probably not be relied upon.



> Rule 4 ought not to allow an uninformed drop.  If the RA Guard parses
> the whole packet and confirms that the full header chain isn't present 
> in a 1st fragment packet, then dropping that packet is OK.  
> 
> However, if the RA Guard can't decide -- which will only be due to some
> implementation limitation within that RA Guard -- then the packet 
> should be sent along.

Ok, this seems reasonable -- since I've not yet gone through the
messages that you've posted on the subject, I will go through them first
(since this is probably discussed in more detail in those). Otherwise I
will come back to you on this one in a standalone e-mail.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1