Subject: Re: [v6ops] Question regarding Ra-Guard evasion (ND and extension headers)

From: RJ Atkinson <[email-masked]>
Date: Fri, 17 Jun 2011 09:50:47 -0400

Earlier, someone wrote:
> it's expensive because you have to set them aside and re-assemble 
> and nd is going to be reassembled in a control-plane processor, 
> which leads to cases where the attacker deliberately maximizes 
> the expense associated with doing so. 

For fragmented ND packets the above is clearly true for many
(most ?) implementations.  So I totally understand the 
motivation for disallowing fragmentation of ND packets.  
I suspect that most folks agree with this subset of the 
RA Guard I-D.  Certainly I agree with this.

Banning all forms of the IPv6 Routing Header in ND packets
also seems reasonable, primarily because in all cases ND packets 
ought to be bridged (i.e. via link layer methods) between 
source and destination, rather than routed.  So I also 
suspect that most folks agree with this.  Just to be clear,
I agree with this.

What I don't find convincing, and I gather some other folks 
also don't find convincing, is Fernando's extrapolation that 
any and all IPv6 extensions should be prohibited in ND packets.

The philosophy of the RA-Guard I-D seems to be "ban everything, 
just in case it might be a problem later".  I think that is 
too strong a position and needlessly limits IPv6 evolution,
for little to no actual reduction of operational risk.
I propose to invert that philosophy to one where "known
serious risks" (e.g. Fragmentation Header, Routing Header) 
are prohibited while other extensions are permitted.

In the special case of ND packets, the Hop-by-Hop Extension 
Header has behaviour identical to the Destination Options Header
-- because there are no hops between source and destination.
As RFC-2460, Section 4.3 clearly shows, it IS possible for
a device functioning as an RA-Guard to parse *past* the
Hop-by-Hop header without knowing anything about its
contents (and without needing to know anything about its
contents).  So in this case, the Hop-by-Hop Extension Header 
does NOT have the problematic behaviours that it would have
in many other situation (e.g. the potential to DOS transit 
routers simply does NOT exist for an ND packet because those 
packets are *never* routed).

In particular, I believe that ND packets should be allowed
to have at least 1 instance each of the IPv6 Hop-by-Hop Options
Header, IPv6 Destination Options header, and IP Authentication
Header.  In practice, such packets will be extremely uncommon.

The IPv6 packet design makes it computationally simple and easy
to move past that header to get to whatever payload is behind
(e.g. ICMPv6, TCP, UDP, SCTP).  The incremental cost to a 
low-cost CPU-based implementation to support this would be 
incurred only on packets that contained one of these 3 IPv6
extension headers.  The cost per extension header present
in the packet would be (roughly) to read 2 bytes extra 
(i.e. the "Next Header" field in the extension header and 
also the "Hdr Ext Len" field), and then add the value of 
"Hdr Ext Len" that was just read to the packet pointer.  
For all 3 of those IPv6 Extension Headers, those 2 bytes are 
located in precisely the same place, eliminating a need for 
per-extension special case code.  This is a tiny amount
of code, with a tiny memory footprint, and would consume a 
tiny amount of additional CPU instructions, so any device 
that already is parsing into the IPv6 frame to perform the 
RA-Guard checks could easily support the presence of these 
extension headers.

While I realise most folks here already understand this, 
I think it is really important for everyone to understand 
that it is *impossible* to prevent Denial-of-Service attacks 
in a useful network deployment.  What can and should be done
is to find ways to increase the work function of the
attacker's least/less expensive attack vectors.  The DoS 
attackers (or at least the attack tool authors) are not 
stupid and they are lazy, so operational experience 
consistently has shown that they consistently deploy the 
least expensive (to the attacker) viable DoS attack they can.

So I do not find Denial-of-Service attack concerns particularly
credible in the special case of "these 3 (DO, HbH, AH) extension
headers appearing in ND packets", because the attacker already
would have to be on-link to undertake an ND-oriented DoS attack.   
An on-link attacker has *numerous* simpler, widely known, and
lower-cost-to-the-attacker ways of DoS'ing *any device* on that 
same link.  

[WELL KNOWN EXAMPLE:  Perhaps the simplest on-link DoS attack 
would be to flood a large number of link-layer broadcast frames.  
Even if the receivers simply discarded the frames, such a flood 
could be quite damaging to normal use of the network.  Many many 
other low-cost link-layer DOS attack vectors are widely known; 
this is just a simple example.]

Yours,

Ran Atkinson

PS:  Having a CALIPSO option (RFC-5570) in an ND packet is a real-world 
     use case, albeit an extremely uncommon kind of IPv6 deployment at
     present.  In an MLS network deployment, devices that have disjoint 
     authorised sensitivity-label ranges ought not be aware of each other.  
     This is easy to achieve by simply putting a CALIPSO option in all 
     IPv6 packets sent within the MLS network deployment.  The receiving
     MLS-enabled node will perform the CALIPSO label check early in the
     ipv6_input() code, before either passing the packet up to the
     next protocol xor dropping the packet as having an out-of-range
     sensitivity label.  Per the CALIPSO spec, the CALIPSO option is
     ignored by nodes that don't support it.