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 11:27 , Ray Hunter wrote:
> May I humbly suggest that fragmentation headers are merely one
> (recently discovered) way of bypassing a parser (in RA Guard)
> that relies on positive identification of (RA) messages. 

Unlike some protocols, IPv6 extension headers (fragmentation 
or otherwise) can be parsed even if the particular IPv6 option
is not recognised.    

Further, several deployed IPv6 routers have silicon with the ability 
to parse past an optional IPv6 header (e.g. Dest Opts header) 
at wire-speed, for example in order to be able to read the TCP/UDP 
ports to apply a user-configured per-interface ACL to IPv6 packets.

The difficult property of the Fragmentation Header is unique to
the function of fragmentation; a device can't parse past the 
Fragmentation Header of the 1st packet to discover whether a 
2nd (or Nth) fragment contains an RA, unless the device sees
all fragments and reassembles the packet before parsing.

> IMHO Until the RA message or other control messages themselves
> are 100% guaranteed parse-able by all entities on the network ...

That is true already -- provided only that the RA is not hidden 
behind a Fragment Header.  

By mandating that hosts receiving an RA from a fragmented packet 
drop that packet without processing the RA, the only fully 
comprehensive solution is provided, without dropping any
valid IPv6 packets.  Further, hosts ought to do that check anyway, 
as not all IPv6 deployments will include an RA Guard device,
and a host can't know a priori whether its deployment does or
does not include an RA Guard.

Since hosts are the devices at risk from a rogue RA, host stack 
implementers have incentive to implement and deploy such an IPv6 
specification update quickly -- probably more quickly than RA Guard 
implementations compliant with this draft could be widely implemented 
and widely deployed.

> I suspect, going down this path might require quite a culture change
> in 6man, removing a lot of flexibility for the future in the interests
> of allowing effective on-the-wire filtering today.

IPv6 already went down the path of being much simpler to parse. 
That is a done deal long since.  

Further, the 6MAN WG recently reinforced this with RFC-6564, 
which codifies strict rules about all future potential IPv6 
Extension Headers.  Those rules are specifically designed to
ensure that silicon designed now will be able to parse/parse-past
all future IPv6 Extension headers at wire speed without
modification.

So the culture you seek already exists in 6MAN, and as I recall
even existed in the IPv6 WG in the 1990s.

A previous employer of mine shipped silicon circa 2003 that could
parse through an IPv6 packet -- including parsing past IPv6 Extension
Headers and unrecognised options -- and apply TCP/UDP port based ACLs 
that had IPv6 optional headers before the TCP/UDP header -- all 
at (very fast) wire speed (N Gbps).  The only header that silicon
couldn't do much with was a Fragment Header, because it has the
one unique property of splitting a packet in two (as noted earlier).

ASIDE: That Verilog enhancement was not a lot of gates, did not 
       increase the die size, and did not increase manufacturing cost.  

       As with software, it helps to have good engineers designing 
       one's silicon, but it isn't rocket science, in large part 
       because IPv6 was designed to be readily parseable at speed.

Yours,

Ran Atkinson