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

[Christian Huitema <[e-mail]>]

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