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

[RJ Atkinson <[e-mail]>]

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.

> 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.  So deploying the RA Guard
will create a new avoidable DOS attack vector.

To prevent that, no matter what the RA Guard spec says, it is extremely
likely that many implementations will give up on parsing after N bytes
-- and generally it is a byte limit (rather than a header count limit)
from an implementation perspective.

>> 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").

That expectation appears to be disjoint from the way this is likely
to be implemented, especially on a Layer-2 only device.

Ethernet switch implementers are, for performance reasons, under
a lot of pressure to avoid a "store and forward" implementation
strategy.  Instead, to get the switching times down into a range
competitive with the marketplace, the switches try to forward
frames after looking at the first N bytes (for the smallest N practical,
as a larger N typically increases the switch latency).  In turn,
many customers buy switches with smaller switching latency.  So
their product optimisation is strongly biased away from being able
to perform deep packet inspection -- which is what RA Guard effectively
requires.

My expectation is that useful RA Guards will be implemented inside
firewalls or inside IPv6 routers that have extensive ACL capabilities
(extensive L4 ACLs typically require packet parsing and examination
well beyond the IPv6 base header, so adding the RA Guard won't be as
big a change).

> 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.  

Firewalls typically have some implementation-specific DPI limit, 
but they normally go MUCH deeper into a packet than a Layer-2 device 
such as an Ethernet switch.  

Also, a state-less firewall is much more likely to have some form of
silicon assistance (e.g. FPGA/ASIC) in parsing into the packets
to keep performance up.  This also helps firewalls with functions 
such as allowing some ICMP message types, but disallowing other 
ICMP message types.

Based on these implementation differences, the RA Guard built into
a Layer-2 switch is the likely place that otherwise valid packets 
might be dropped.  The firewalls are much more likely to be able
to parse the whole received 1st fragment and make an informed decision.


>> 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.

The probability is that those host implementations will get updated
MUCH MUCH faster than the RA Guard implementations built to this spec
could be implemented, shipped, and deployed.  The host OS implementers
have been known to ship exactly this kind of security fix in maintenance 
releases, without waiting for a new major release of their OS.

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.

One of the differences between the IETF and some other standards
bodies is that the IETF tries to remain grounded in implementation
realities.  In this case, that means we want a specification that
is realistic about various products having varying ability to 
perform DPI at speed to check for rogue RAs.

"Do no harm" is a very good principle here that needs to be kept in mind.
Dropping valid IPv6 packets is harmful to the network, and needs to be 
explicitly forbidden.  The best way to ensure this is to modify Rule 4.

>> 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).

I'm glad we at least agree on process.  I look forward to seeing the
new revision of these I-Ds.

Yours,

Ran