Subject: [Tsv-art] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering)

From: Warren Kumari <[email-masked]>
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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Dec 2018 00:20:55 +0000

Hiya,

> * perhaps something like a workshop?

Maybe consider moving IEPG to a more prime-time IETF
meeting week slot? (Or any equivalent.) The couple of
times I've gotten to IEPG, I was struck by how it was
higher quality than average IETF presentations. For
me, I always really like finding out about cases where
reality != theory and I bet I'm far from alone.

So, I'd argue a bit against a one-off BoF or workshop
and more for a recurring opportunity for fact-based
detailed presentations.

S.

---

From: tjw ietf <[email-masked]>
Date: Tue, 11 Dec 2018 21:33:45 -0500

I can not agree with mr Farrell enough on this.  

Tim

From my high tech gadget

> On Dec 11, 2018, at 19:20, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <0x5AB2FAF17B172BEA.asc>

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Dec 2018 09:31:57 +0100

Warren,

Thank you for your note.

> On 12 Dec 2018, at 00:58, Warren Kumari <[email-masked]> wrote:
> 
> 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!) 

How do I interpret this? Are you saying you think there is IETF consensus to publish?

Cheers,
Ole

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 12 Dec 2018 06:05:45 -0600

Fwiw,

> > and more for a recurring opportunity for fact-based

I agree with Stephen, and moving IEPG off Sunday morning actually maps onto
the stated intent of recent IESGs and IABs to improve communication and
interaction. You know this, but others may not know that the IESG has a
standing meeting on Sunday mornings each IETF week, so the IESG is less
aware of IEPG discussions than most IETF participants.

I don't think we have to choose between moving IEPG and having a workshop,
and maybe even a BOF. If we move IEPG and the community is more aware of
operator positions, workshops and BOFs might be better informed.

Is it premature to ask the nice IEPG people about this? A move would need
to work for them, too.

Spencer

>
> > S.
> > <0x5AB2FAF17B172BEA.asc>
>
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Dec 2018 16:54:46 -0500

> How do I interpret this? Are you saying you think there is IETF consensus

Yes, probably.

The discussions **on the draft itself** (and not the larger, philosophical
discussions on operations vs architecture / what is actually implemented vs
what routers should be able to do) looks like (after the editor makes the
agreed to changes) good enough rough consensus for me to progress it to
IESG evaluation.

It is entirely possible that it will not survive that step / will be sent
back to the WG / another IETF LC on the revised document will be called for
/ it will be munged beyond recognition at this point...

W

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Dec 2018 08:26:11 -0300

> and more for a recurring opportunity for fact-based

+1

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Warren Kumari <[email-masked]>
Date: Thu, 13 Dec 2018 15:22:27 -0500

[ Top-post, follow-up to my own mail]

I've had a chat with the rest of the IESG and I'm planning on going through
all of the (230+! ) emails again and classify them into:
A: related to the document itself
B: related to the larger "do intermediate routers have any role in
filtering" / "can devices actually do what it says on the tin" / related.
C:

I'd already done this, but only classified them in my head -- this will be
a large undertaking (and many emails fall into multiple categories) and
will take some time...

Also, a fair bit of the discussion felt like people talking past each other
- we will continue to investigate the information sharing / "recent changes
in protocol X" type sessions.
While looking into this I (re)discovered the "Technical Tutorials" (
https://www.ietf.org/about/participate/tutorials/technical/ ) page, but
what I hadn't known before was the
https://datatracker.ietf.org/group/edu/materials/ and
https://trac.ietf.org/trac/edu/wiki/Tutorial_by_IETF pages.
Many of these are a good way to get quick introduction to a new protocol /
sphere -- eg:
https://datatracker.ietf.org/meeting/101/materials/slides-101-edu-sesse-introduction-to-oauth-20-01.pdf

W

On Wed, Dec 12, 2018 at 4:54 PM Warren Kumari <[email-masked]> wrote:

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 14 Dec 2018 10:31:01 -0800

Stephen Farrell <[email-masked]> writes:

> meeting week slot?

One huge advantage of doing this is it then falls into
conflict-avoidance play; right now I can pretty much never make the IEPG
meetings due to other non-movable meetings.  Rotating it around the IETF
schedule, with conflict avoidance especially for speakers, will mean
wider attendance and variation with those that can only attend "sometimes".
-- 
Wes Hardaker
USC/ISI