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 <[email protected]> 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 > >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
