Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)

[Tom Herbert <[e-mail]>]

On Fri, Feb 12, 2016 at 1:07 AM, Brian E Carpenter
<[e-mail]> wrote:
> On 11/02/2016 22:57, Tom Herbert wrote:
> ...
>> Suppose we define an "EH chain length" extension header. This would
>> include the length of the chain starting from the first byte of the EH
>> and also a next header value for the header that follow the chain.
>> This EH could follow HBP. Network nodes can use this to skip over a
>> long chain to parse the transport header. The receiver would need to
>> validate the length and protocol are correct in order to prevent
>> someone from spoofing transport headers.
>
> https://tools.ietf.org/html/draft-zhang-6man-offset-option-01
>
> But it doesn't help, because any middlebox that insists on trying
> to parse all the headers will not make use of this feature.
>
Right, but realistically if we want to send extension headers into the
Internet we can't wait an indefinite amount of time for every single
device to properly handle them. It seems that we'd want to apply a
happy eyeballs approach. If the offset option makes it more palatable
for some devices to forward packets with EH that could move things
forward by some amount. I also see a use case for this at the end
hosts, a ridiculously long chain could be a nice DOS attack and the
offset option might mitigate that. For instance, before processing the
chain we could verify if an encapsulated TCP packet refers to a valid
connection.

Tom

>    Brian