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: Wed, 30 May 2012 17:09:05 -0400

Fernando wrote:
> It's not a protocol change,

Nonsense.  

> but an operational mitigation. -- for instance, there is no change
> in the way the sending router or the receiving hosts process RAs.

Rule 4 mandates changes to whether certain IPv6 packets get forwarded,
which is a major change to the IPv6 protocol specifications.

Rule 4 is both a protocol change and (misguided) operational mitigation.  
Rule 4 is mandatory according to this document and will cause certain 
perfectly valid IPv6 packets to be dropped instead of forwarded.  The
rule damages IPv6 and impairs utility of IPv6 in the real world.

The comprehensive fix is to update the hosts as Joel Halpern and Ron Bonica
outlined earlier today.  I don't think that change would be controversial,
so likely it could proceed quickly through 6MAN.  In the meantime,
Rule 4 could be edited and cleaned up such that no valid IPv6
packets get dropped by an RA Guard.

Yours,

Ran

---

From: Ray Hunter <[email-masked]>
Date: Thu, 31 May 2012 17:27:19 +0200

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. Who says that there aren't others?

I think you'll find it impossible to write a parsing rule today that 
guarantees catching 100% of all RA messages without any false negatives. 
>From an operational standpoint, I think false negatives in this 
particular case are far worse than false positives.

IMHO Until the RA message or other control messages themselves are 100% 
guaranteed parse-able by all entities on the network in exactly the same 
way to avoid false negatives (including all RA Guard implementations, 
and all end nodes deployed in the field) we'll need a default discard 
rule. Otherwise there's always going to be someone looking for a way to 
confuse the (RA Guard) parser into giving up on its parsing and permit 
forwarding of a malformed or unusual (RA) message to some unsuspecting 
end node implementation that interprets the packet in a different way 
and which then accepts and installs the (evil) default route or other 
option, thus rendering RA Guard or other on-the-wire filter useless.

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.

It also probably wouldn't be in the spirit of the principle founded in 
RFC760 "In general, an implementation should be conservative in its 
sending behavior, and liberal in its receiving behavior.  That is, it 
should be careful to send well-formed datagrams, but should accept any 
datagram that it can interpret (e.g., not object to technical errors 
where the meaning is still clear)."

regards,
RayH

> which is a major change to the IPv6 protocol specifications.
No. It merely continues the well established practice of on-the-wire 
filtering.
> rule damages IPv6 and impairs utility of IPv6 in the real world.
Please identify the affected false-positive packets so further 
mitigation can be added.
> packets get dropped by an RA Guard.
Not comprehensive at all. It does fix the current problem. However, the 
real problem is the natural conflict between the need for flexible 
end-node implementations versus tight inflexible security filters.

Please suggest the rule clean up. I don't believe it's possible. This is 
fundamentally because of the way IPv6 is specified (without a fixed 
structure, with flexible header chains, and with loose interpretation of 
received packets).

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 31 May 2012 11:33:37 -0400

Fortunately, this is a very different problem from detecting an 
exertnal->internal message with a collaborating internal partner.

For an RA to be an attack vector, it has to be parsed by the large 
majority of hosts.  Thus, it follows that we do actually know what 
encodings can be used.

Yours,
Joel

On 5/31/2012 11:27 AM, Ray Hunter wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 May 2012 13:51:17 -0400

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