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

[Fernando Gont <[e-mail]>]

On 02/12/2016 05:02 AM, Tom Herbert wrote:
> 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.

Other things aside, this would be done by a totally different layer of
code... layer-3 vs layer-4...

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492