|
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).
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? -- Christian Huitema
-- Christian Huitema
|
