Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01

[Fernando Gont <[e-mail]>]

Hi, Gorry,

On 1/12/20 13:30, Gorry Fairhurst wrote:
[----]
> 
> Hope this helps, Fernando. If you need any clarification or other help, 
> just let me know,

I had promised to read "Threats and Surprises behind IPv6 Extension 
Headers" (http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf)

My read of the paper is essentially that EHs are largely unused. And 
when it comes to actual use of EHs, they seem to boil down to fragmented 
UDP (already considered fragile, per RFC8900), local-link traffic (e.g. 
MLD), some IPsec, and what seem to be bogus traffic (e.g., ICMPv6 errors 
being fragmented or employing HbH headers).

No surprises here.


Then, in the "Conclusions" section, the authors note:

"Dropping all packets that contain Extension Headers is a bad practice" 
-- with which I disagree. Not that I think it is great to have to resort 
to dropping packets with EHs, but rather because folks that a network to 
run, and if allowing such packets will prevent them from doing what they 
need to do, or open their network to DoS, then, given the options they 
have on the table, dropping such packets might be the most acceptable one.

They also note:
"The share of traffic containing more than one EH however,
is very small. For the design of hardware able to handle the
dynamic nature of EHs, we therefore recommend to support
at least one EH: the exceptional packets containing more EHs
can be handled in the slow-path, i.e. a slower CPU in the
network device, without substantial performance loss, while
still offering flexibility to drop packets with e.g. more than
three EHs to prevent the possible Denial of Service attack"

This doesn't seem to make a lot of sense. A key design choice is the 
EH-chain length to be supported, rather than EH # count.  And no, I 
don't think you want to process packets in the slower path -- unless you 
rate limit them to such a small number, that it wouldn't make sense, anyway.

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