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 14:52 , Fernando Gont wrote:
> Note: the only possible "issue" here is that with SEND, packets *might*
> grow large enough to need fragmentation. However:
> 
> 1) The aforementioned behaviour would be specified for traditional ND,
> rather than SEND.

OK.  As you say, it makes sense to except SEND from the restriction, 
since it provides stronger authentication already.

> 2) At least the packet sizes sampled in the SEND spec are not larger
> than 1280 bytes
> 3) If you do deploy send, you don't really want to rely on
> fragmentation. If you do, then an attacker could trivially "disable"
> SEND by performing fragmentation (DoS) attacks.
> 
> -- Just wanted to double-check this with you before the s/SHOULD/MUST/
> change.

That sounds reasonable to me at first read, but one caveat.

CAVEAT:
I'm not a SEND expert. 
I don't know whether a SEND expert might have concerns.

>>> We have expressed this requirement (in
>>> draft-gont-6man-oversized-header-chain-01.txt) as:
>>> 
>>>  All IPv6 packets MUST contain the entire IPv6 header chain within the
>>>  first "assumed Path-MTU" bytes of the packet.  If a packet is
>>>  fragmented, the first fragment of the packet (i.e., that with a
>>>  Fragment Offset of 0) must contain the entire IPv6 header chain
>>>  within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the
>>>  packet.
>> 
>> That seems OK at first reading.  
>> 
>> I hope there already is text that has the effect of requiring 
>> a receiving IPv6 node to drop any received ICMPv6 that hid 
>> behind a Fragment Header.  
> 
> Such requirement is in draft-gont-6man-nd-extension-headers.
> Essentially, draft-gont-6man-nd-extension-headers forbids the use of
> fragmentation with ND, and hence this means that when it comes to ND
> you'll always have the entire IPv6 header chain available in the same
> packet (if you don't, the packet was fragmented, and you're required to
> fragment it).
> 
> draft-gont-6man-oversized-header-chain tackles a more general problem:
> since we cannot ban IPv6 fragmentation altogether for general traffic
> (for obvious reasons), for the general case we require the first
> fragment to include the entire IPv6 header chain (i.e., "put as many
> headers as you want (including fragmentation)... but the entire IPv6
> header chain must be available in the first fragment").

For the RA Guard problem, I strongly prefer the approach you indicate
is defined in draft-gont-6man-nd-extension-headers -- because it is
better scoped.  Also, the sender always knows the link MTU for directly 
attached links (i.e. always known for the ND case) and ND is always
link-local.  So there are fewer unknowns operationally.

I am not as enthusiastic about the *-oversized-header-chain approach,
which appears to have much broader scope, because a sending node 
can't reliably know the Path MTU, sadly, and because I know of 
some odd-sized IPv6 link MTUs in the deployed world.  Also, as I recall,
you identified some special cases where the Path MTU might be 
less than the theoretical IPv6 minimum MTU and yet the Path MTU 
could be valid per various other IETF (transition-related ??) specs.

However, I can tolerate *-oversized-header-chain, if that really 
is preferred collectively over the more focused *nd-extension-headers 
approach.

>> One imagines the actual requirement
>> for receiving IPv6 nodes might be written more generically.
>> 
>> As an example to clarify things, it would not hurt to explicitly 
>> note that this does NOT preclude the use of TCP Jumbo data payloads, 
>> but instead merely requires that all *headers*, starting from IPv6 
>> base header and continuing up to & including the TCP header, 
>> be present in the 1st packet.
> 
> You mean this could/should be clarified in
> draft-gont-6man-oversized-header-chain-01, or somewhere else?

...or in *-nd-extension-headers, as applicable.

>> This means that the RA Guard document ought to:
>> (1) cite (normatively) draft-gont-6man-oversized-header-chain, 
>> (2) delete Rule 4 of the RA Guard draft (which is not needed), 
>> and 
>> (3) add clarifying text to the RA Guard draft noting that the 
>>    referenced 6MAN document ensures that RA messages that 
>>    try to hide behind a Fragment Header will be dropped 
>>    by the receiving IPv6 node.
> 
> But if it's agreed that packets that do not contain the entire IPv6
> header chain shouldn't be there, what would be the motivation for
> allowing them through ra-guard?

That logic seems to include a somewhat theoretical assumption -- 
namely that an RA Guard implementation built out of available
CPUs and available silicon will be able to read all of
the bytes in the IPv6 packet and will be able to do so at some
interesting fraction of line-rate for common interfaces.  In theory,
that might be true, and for some specific implementations 
it could be true, but it won't be universally true in practice.
For example, it is unlikely to be true anytime soon for 
very high speed Ethernet links.

In the real world, some (many ?) implementations of RA Guard 
will have an implementation-specific limit to packet inspection 
that is less than the Link MTU.  Such limits are commonplace, 
possibly universal.  Even "Deep Packet Inspection (DPI)" firewall 
implementations normally only can read several hundred bytes 
(perhaps 200 or 300) into a packet -- whereas a valid IPv6/Ethernet 
packet (e.g. ~1500 bytes long) legitimately might not reach
the final (TCP, UDP, ICMP) header by the point that the
implementation-specific DPI limit of the RA Guard implementation 
is reached.

So some (we hope not many) real world RA Guard implementations 
will not be able to figure out whether a particular valid IPv6 
packet is valid or not, due to implementation-specific limitations 
of that particular RA Guard implementation.  When an RA Guard can't
reliably figure out whether the packet is valid, the RA Guard should 
send the packet along -- on the principle of not dropping any 
valid IPv6 packets (aka: "do no harm").

Since the hosts will be protecting themselves from any RAs trying
to hide behind Fragment Headers, there is no risk to having 
Rule 4 either disappear or be changed to allow all packets
where the particular RA Guard implementation can't figure out
whether a given IPv6 packet is valid or not.

At a more architectural level, if the IPv6 specs need to change,
then I'd like to see those changes proposed and accepted by the
6MAN WG (or its successors) -- rather than having an IETF recommended
operational practice have the result of changing the IPv6 specs
without bothering to update the actual IPv6 specs.

Yours,

Ran