Re: [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Fernando Gont <[e-mail]>]

Christian.

On 25/11/18 17:40, Christian Huitema wrote:
[.....]
> 
> I am concerned that this draft is attempting to weight the scales and
> favor one side of this ongoing tussle, which leads to something like
> "ossification in the name of security". I think that's a huge overreach.

Not really. If that was the case we'd probably say "drop all EHs you see
no use for". If you look at the advice, it esentially argues in favor of
passing everything unless the traffic is known to be harmful.



> Nick made that point, probably unintentionally, when he wrote that
> "transit operators would generally take the view that any data-plane
> packet which needs to be put through a slow path will be rate limited up
> to 100% loss". Last I checked, data plane processing is implemented in
> specialized components that are designed for speed. I am quite concerned
> that filtering recommendations made by the IETF will end up deeply
> embedded in the hardware of at least some routers, and that changing
> them in the future would be quite hard. That's pretty much the recipe
> for ossification.

PLease take a look at the advice: it essentially argues "pass everything
that has been stadardizez and that will not cause you pain". And, again,
this is in line with RFC7045.  Compare that with what we have in the
real world (RFC7872), and you'll probably agree that if folks were to
implement this advice, it would be a *huge* improvement -- at the time
of this writing you cannot even use ipsec reliably on the Internet(!).



> I understand that unwanted traffic can be used in denial of service
> attacks. But then, any traffic profile can be used in such attacks. The
> attacker who can inject packets with EH=253 can also, for example,
> inject arbitrary TCP segments, or spoofed EH packets. I also understand
> the desire to protect end systems from unwanted traffic. There is a
> history of attacks performed by various kind of "magic packets" that
> cause a catastrophic failure in some target systems. But it does not
> follow that such protection should be implement by coarse policies
> hardwired in every router on the Internet. The definition of these
> attacks changes over time, and it would be folly to implement these
> rules in systems that lack management capabilities. The proper place for
> that is specialized security functions, not in general purpose routers.

RFC7872 seems to argue that there are folks filtering these in transit
routers.



> I am also concerned that the draft does not define the difference
> between EH options and IPv6 payload types.

You mean EH types and upoer layer payloads?


> The IPv6 header contains a
> "payload type" field, that may legitimately contain any of the payload
> types defined in the IANA registry of protocol numbers
> (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).
> Some of those payload types are flagged as IPv6 extension header types
> and listed in the corresponding registry
> (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml). Discussing
> EH without discussing the other payload types seems bizarre. Do the
> reasons for blocking for the experimental payload type 253 also apply
> to, for example, the UDP Lite payload type? What about discussing ESP
> and not discussing L2TP or MANET?

This document discusses EHs. THe considerations for filtering on upper
payloads are rather different, and normally depend on the upper protocol
details. (e.g. TCP ports).

As noted in draft-gont-v6ops-ipv6-ehs-packet-drops, EHs can mess up with
the ability of intermediate devices to do their work.

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