Subject: [arch-d] Fwd: Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering)

From: "Aaron Falk" <[email-masked]>
Date: Wed, 12 Dec 2018 10:42:25 -0500

In case you’ve been sleeping on the IETF list, here’s an 
architecture thread relevant (IMO) to this program:

Forwarded message:

> From: Warren Kumari <[email-masked]>
> To: IETF Discuss <[email-masked]>, opsec wg mailing list 
> <[email-masked]>, [email-masked], 
> [email-masked]
> Subject: Architectural implications of EH / filtering (was: 
> draft-ietf-opsec-ipv6-eh-filtering)
> Date: Tue, 11 Dec 2018 18:58:05 -0500
>
> Thank you, everyone, for a spirited discussion!
>
> I've gone through the discussions and broken the emails down into a 
> few
> categories - there were a number of emails on the document itself, 
> many of
> them with helpful suggestions on how to improve / focus the document 
> (thank
> you!).
>
> More recently the discussion has become more acrimonious, and morphed 
> from
> discussion **on this document** into the larger philosophical 
> discussions
> on filtering in general, if what we have designed and call IPv6 can
> actually be implemented / deployed in the real world on core-type 
> devices,
> what it means to claim compliance with a specification, the role of 
> ISPs,
> ossification caused by operational decisions, "my network, my rules", 
> etc.
>
>
> The IETF LC thread on the document, and the TSVART review (and
> corresponding thread) both generated useful, and actionable comments, 
> and
> I've asked the authors to go through them carefully and address them 
> --
> these fall into the "on the document" category. I think that once 
> these
> have been done, the document itself will be in acceptable shape to 
> proceed
> (but keep reading!)
>
>
> There has been a significant amount of additional discussion after 
> this -
> and it mostly falls into the "larger discussion" category.
>
> It covers things such as:
>
> * the implications of protocol design on implementability / 
> deployability
> (can protocol X be deployed at scale?). Should feasibility of
> implementation in hardware be a consideration?
> * the harms caused by filtering in the network (ossification, 
> survivability
> of extensions, layering principles)
> * operators need to perform filtering for end-point protection / DDoS
> mitigation / ECMP
> * what it means to be compliant with a specification (if you can 
> forward at
> rate X, but only filter at rate x/1,000,000 are you compliant?). If it 
> is
> not possible to buy / build a device which filters at line rate, is 
> that
> the fault of the vendor, the operator or the protocol design?
> * do intermediate devices have any right to filter / role in 
> filtering? If
> operators need to be able to do X to run their service / network, and 
> they
> have to choose between "protocol correctness" and "keeping the network
> running", is it acceptable to drop / fold / spindle / mutilate 
> correctness
> to keep the network up?
>
>
>
> The discussion seems to have broken into 2 camps -- those who are 
> saying
> that
>
> 1: the network / vendors should be able to do what the RFCs say,
> vs
> 2: those who say that operational reality trumps RFCs.
>
> This seems to be one of the tussles -- the other is (largely):
>
> 1: blocking unknown X is harmful to future protocols / development
> (blacklist approach)
> vs
> 2: I run a [network / service / system] and know what packets I'm
> expecting. If I don't expect X, I'm just going to drop it (whitelist
> approach)
>
>
>
> This same discussion has come up a number of times over the past few 
> years
> -- "Why operators filter fragments" was one instance, the (multitude) 
> of EH
> discussions were another.
>
> It is clear that we are fairly far apart in many instances of this
> discussion, and it is worth further discussing the different 
> philosophies.
> I feel that we should be discussing the architectural issues 
> separately
> (not in the thread on this document). I also think that there is a 
> fair bit
> of distance between the "operators" view and the "architecture" view.
>
> I'm going to further investigate / discuss this, but I think that it 
> might
> be worth:
>
> * having some presentations / discussions on "how X works when 
> deployed /
> implementation shortcomings". As an example, at the IEPG meeting in
> Yokohama (IETF94) these was a presentation on "MODERN ROUTER 
> ARCHITECTURE
> FOR PROTOCOL DESIGNERS" -
> http://www.iepg.org/2015-11-01-ietf94/IEPG-RouterArchitecture-jgs.pdf 
> . As
> another example, I was recently informed of a surprising limitation in 
> TLS
> libraries -- these are apparently well known to those who work in this
> space, but I'd certainly never heard of them. I think that we (IETF
> participants in general) sometimes fall into believing that we know 
> how
> technology X works because we've helped design it, but don't 
> necessarily
> know what happens once it escapes our clutches / flies out of the 
> nest.
> * consider having a BoF on this / these topics.
> * perhaps something like a workshop?
>
>
>
>
> As for the current discussion, I'd like people to please:
>
> a: step back and decided if you are simply repeating your current 
> position
> (but in a new and louder voice) or if you are bringing something new 
> to the
> topic.
>
> b: move the discussion to this thread
>
>
> -- 
> I don't think the execution is relevant when it was obviously a bad 
> idea in
> the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair 
> of
> pants.
>    ---maf