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

From: RJ Atkinson <[email-masked]>
Date: Fri, 1 Jun 2012 08:44:46 -0400

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

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 01 Jun 2012 14:33:33 +0100

> the disease -- as the Ethernet switch connecting everything dies.

not really: this is why we have control plane policing.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Jun 2012 22:34:36 -0300

Hi, Ran,

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

> at interesting fractions of wire-speed. 

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

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

> implementation limitation within that RA Guard -- then the packet 

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 7 Jun 2012 11:45:12 -0400

> *that* case the cure could be worse than the disease.

This issue ought to be mentioned in Security Considerations
for the RA Guard, along with advice that implementers add
IPv4/IPv6 packet parsing capability to future packet processing 
hardware.

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

Yes, please.  See my comments just above.

> probably not be relied upon.

** I believe most IPv6 NATs will be able to handle many/all IPv6
   packets with chained-headers.  Where they don't, those devices
   are violating IPv6 specifications.

** I also believe that most IPv6 firewalls will be able to handle
   many/all IPv6 packets with chained-headers.  Where they don't,
   those devices are violating IPv6 specifications.

** I strongly disagree that chained-headers already are broken
   in the deployed IPv6 Internet.  Further, IPv6 specifications
   REQUIRE that IPv6 nodes handle chained-headers properly.

The RA Guard is different from those cases above in one VERY
important respect.  The RA Guard spec (with its current language)
is a case of the IETF formally recommending that implementers 
ignore the IETF's IPv6 specifications -- which is a very inconsistent, 
very bad, message for the IETF to be sending.

This is resolvable, simply by adding normative references to the 
related 6MAN I-Ds that update the IETF's IPv6 specifications in 
specific, clearly specified, clearly justified ways.  

This process also ensures that the IPv6 specification changes
being imposed by the (current) RA Guard text actually are agreeable
to the 6MAN WG.  

If those changes are NOT agreeable, which I consider an unlikely outcome, 
then that is a strong indication that the current RA Guard text ought 
to be changed so that it fully complies with IETF IPv6 specifications. 

If some additional change to IETF IPv6 specifications seems warranted
(e.g. a per-packet limit on total number of daisy-chained headers present), 
then that proposed change ought to be written up as an I-D, normatively
cited by the RA Guard I-D, and taken to 6MAN WG for their consideration.

> will come back to you on this one in a standalone e-mail.

OK.  One important goal of mine is to avoid granting a broad
license that permits a faulty implementation to truthfully claim
that it complies with IETF specifications.

Along the same lines, I think some more general editing of the overall 
RA Guard rule set would be sensible -- so that the implementation 
requirements of the RA Guard are very clearly specified.  

Thanks for listening.

Cheers,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Jun 2012 07:04:41 -0300

> IPv4/IPv6 packet parsing capability to future packet processing 

Will do.

>    are violating IPv6 specifications.

Stateless translators require that the entire IPv6 header chain is in
the first fragment (since e.g. they will need to drop Dest Options
headers and extract the TCP info) -- that's why IPv6 header chains that
span multiple fragments won't succeed.

(Note: not that I'm happy about this, or that I consider this to be the
best possible approach...)

>    those devices are violating IPv6 specifications.

If an IPv6 header chain spans multiple fragments, the the only possible
options for firewalls are:

* stateless firewalls: simply drop such packets
* stateless firewalls: reassemble, filter, and refragment

Unless we want to (implicitly) ban IPv6 stateless firewalling, we need
to require the entire IPv6 header chain to be in the first fragment.
(My take is that if we don't formally do this, firewalls will drop such
packets anyway... so we better provide advice that such packets are not
generated in the first place)

>    REQUIRE that IPv6 nodes handle chained-headers properly.

The problem is not chained headers per-se, but rather chained headers
that span multiple fragments. (please see my comment above wrt stateless
translators and firewalls)

> specific, clearly specified, clearly justified ways.  

As noted off-list, I think this is a very sensible approach.

> that it complies with IETF specifications.

I fully agree with this. Essentially, you're arguing that you don't want
an RA-guard to drop valid packets (as a result of an implementation
constraint), whereas I don't want a device to be able to claim ra-guard
compliance while still being trivial to circumvent.

I believe that it is possible to have the ra-guard I-D address both of
our concerns. -- more about this shortly.

> Thanks for listening.

Thank *you* for constructive feedback!

Cheers,