Re: Proposal for changing how IPv6 Hop-by-Hop Options are processed

[Fernando Gont <[e-mail]>]

On 7/12/20 12:54, Tom Herbert wrote:
[...]
>> My questions are:
>>
>> 1) Does the number of options really matter?
>>
> Ron,
> 
> Yes, very much so.

I'm not saying that the limit doesn't make sense -- clearly limits are 
generally a good thing, and for a software router, it's clear that some 
limit has benefits.

However, my question is whether this particular limit would make a 
difference by the devices that are currently droping packets with HbH.



>  HBH and Destination options are encoded in TLVs and
> in their nature must be serially processed, and so processing a long
> list of TLVs is expensive for any device. Consider that someone could
> put over 700 options (zero data length) into a standard 1500 MTU size
> packet. That is going to be hard for anyone to process efficiently,
> and really the only purpose of doing that is DoS. Limiting the size of
> the EH will limit the number of options; like a 128 byte limit would
> limit the number of options to 64-- however that is still many more
> than would ever seem to be ever be needed and still is hard for low
> end devices to process.

Please note that if one is to limit the number of options in a HbH, one 
should also limit the number of HbHs. Otherwise, as an attacker I could 
simply send packets with multiple HbHs, which the current standard 
recommends nodes to process.



>> 2) Regardless of your response to #1, aren't we overlooking what's probably the bigger elephant in the room, which is the overall length of the IPv6 header chain?
> 
> Yes, that is why we have that limit in addition to the number of
> options limit in RFC8504 and ICMP errors for it in RFC8883.The hard
> part here is establishing what the exact limit should be.

Right now, we have no limit, but we also don't know the least common 
denominator. If it was me, I'd say that having something along the lines 
of "MUST support IPv6 header chains of at least 64 bytes, and SHOULD 
support IPv6 header chains of up to the link MTU" or the like would be a 
good start.

  -- Yes, some could claim that requiring EH lengths of 64 bytes. OTOH, 
I'd say that getting to "hey buddies, enough is enough, you should 
really be supporting at least X" would really be a step forward.

Note: I'm not a super fan of EHs, and I'm also skeptical about the 
extent to which something like this would make a difference. But if I 
was asked to do something to help improve the current situation, that's 
probably what I'd try.



> In the UDP
> Encapsulation Design Team, we discussed this and polled various
> hardware vendors as to what the size of their parsing buffer is (i.e.
> the number of bytes of headers that a router can parse in the fast
> path). The answers we got we're all over the board, something like 64,
> 128, 256, or MTU of the packet. We didn't see consensus and didn't
> pursue trying to specify a limit at that time.

How about sticking to the least common denominator?




> I'll also point out that not all deployed routers require specialized
> hardware, in some use cases line rate can be sustained with a
> forwarding path in a commodity CPU (I imagine this is in a lot of home
> routers). Efficient processing of options is an issue for them as
> well. For such devices, the number of options to processing is a
> bigger problem than how many bytes of header there are (i.e. serial
> processing in a CPU is more expensive than a few cache misses).

Agreed on this last bit.




> Also, routers participating in segment routing need to process
> destination options before the routing header also, therefore It makes
> sense that the same limits should be applicable to destination options
> before the routing header. So routers might process both HBH and
> Destination options and destination hosts must process them, and hosts
> send them in packets. If there are to be limits, I suggest they should
> be applicable across all nodes.

FWIW, a limit on the number of EH instances of the same type should also 
be applied if we are going to go this way.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1