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

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:
> 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
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>