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

[Joe Touch <[e-mail]>]

The core problem with this doc, IMO, is that:

- packets that cannot be distinguished from legitimate traffic MUST NOT be inferred as an attack

- the use of resources appropriate for legitimate traffic MUST NOT be interpreted as a vulnerability for that reason alone

I.e., most of the analysis in this document is flat out incorrect in assuming that merely because a packet could cause a router to do work that it is a security risk to handle that packet as intended.

Joe


> On Nov 25, 2018, at 12:40 PM, Christian Huitema <[e-mail]> wrote:
> 
> 
> On 11/25/2018 11:40 AM, Brian E Carpenter wrote:
>> On 2018-11-26 04:53, Joe Touch wrote:
>>> A reasoned discussion of the pros and cons would be useful.
>>> 
>>> What we have is the perspective, often heavily represented by vendors and operators, of the driving reality that:
>>> 
>>> a) implementing extended features is an attack on profits
>>> b) properly configuring and monitoring extended features is an attack on effort
>>> 
>>> A reasoned argument would be useful. That is not what has been repeatedly presented, IMO.
>> I don't think that's entirely fair to RFC7045. But the fact is that
>> there's a tussle here between the desire for the ability to deploy
>> new protocols freely, and the desire for the ability to block
>> potentially harmful or malicious traffic. The definition of "harmful
>> or malicious" is not universally agreed. "Harmful to my business model"
>> is certainly one possible interpretation. But then, we decided to
>> implement the Internet as a largely unregulated competitive system,
>> so we got tussles.
> 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. I would like to have a very general caveat at the beginning of the draft, explaining that it is perfectly fine to deploy routers that do not perform any such filtering and simply forward the packets. We need something significantly more forceful than merely saying that the short statement in section 2.3. 
> The policies that it describes are plausible for specialized filtering devices such as firewalls, but the draft proposes adopting these policies for "transit routers", an ill defined term that could cover pretty much every router in the the Internet. There is a big difference there. Security devices are engineered to implement specific policies, and come with management systems to update these policies over time. 
> 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.
> 
> I am also concerned that the filtering is justified by "security considerations", but that with the exception of the HBH header these considerations apply to end points, not to transit router. Take the example of the experimental options, described in section 3.4.10. The consideration says that "implications of these EHs will depend on their specific use." It fails to mention any security consequence for the transit router that would fail to filter these options. In the absence of filtering, the packets will arrive at the end system, where they will be processed if the end system is part of the experiment, or treated as unwanted traffic if the end system is not part of that experiment. There definitely will not be any harmful effect for the router that passed the traffic.
> 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.
> 
> I am also concerned that the draft does not define the difference between EH options and IPv6 payload types. 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 <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 <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? 
> -- Christian Huitema
> 
> -- Christian Huitema
> 
>