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

[Ray Hunter <[e-mail]>]

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

RJ Atkinson wrote:
> 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.
No. It merely continues the well established practice of on-the-wire 
filtering.
>
> 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.
Please identify the affected false-positive packets so further 
mitigation can be added.
>
> 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.
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).
> Yours,
>
> Ran
>