Subject: [Stackevo] Notes from Friday morning meeting

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 23 Mar 2018 09:42:31 +0000

Greetings, all,

Thanks for coming to an 8am Friday meeting. Here are some rough notes:

## wire-image

Aaron: Things these documents should say: "Implicit signaling considered harmful"

Mirja: You can't avoid implicit signaling. That's always in the wire image.

Ted:

Christian: Divorcing signaling from the transport removes the honesty of the signal.

Ted: Attestation of miracles: it was in the interest of endpoints to be honest in TCP, but not in the interest of midpoints.

Tommy: The wire image is a tunnel.

Aaron: We know there are problems with tunnels.

Jari: You want to encrypt the wire image, maybe including the packet order. How do you do that?

Martin: Privsec are looking at traffic analysis. That draft should reference wireimage.

Tommy: What are the boundaries of the wire image?

Mirja: Did we limit the wire image to one flow, or did we expand that? Look at that.

Ted: In things like SIP, it's clear that multiple flows are linked.

Brian: Wire image is a property of a protocol, not a flow, or a packet, or a user.

Spencer: ML traffic recognition, yay.

Gabriel: What are the implications to ossification?

Brian:

Martin: Invariants is a promise: here is what we will not change, and things we

Aaron: Should invariants exist in the document?

No agreement on this...

Christian: Why are you telling me this? What's the problem? Very clear the problem you're trying to solve?

Brian: Define "wire image".

Brian: note, point wire image at quic invariants as a

Christian: How are we going to handle the problems that kathleen is discussing?

Might be a different document.

Martin: Don't overload this doc. Don't go down the path of adding traffic analysis or how to design

Tommy: There is implicit conversation of ossification. Expand the definition of the things you're talking about. Define what an invariant is. Some properties of wire image might be an invariant. (Invariant is a promise).

Martin: Some boxes already use patterns

Aaron: Scope of project: future of protocol dev in a world with ossification. Two recent concepts: Invariants and greasing. We should talk about those.

Gabriel: Consolidation? Is this something we can say about protocol design...?

Mirja: Greasing is something different... Invariants is inverse of greasing. Wire image and path signals should stay separate and go out soon

Erik: A paragraph/short pointer to related issues. For example: Before I run a protocol I do a

Eliot: Consolidation: look at ITAT protocol diffusion / economic aspects. Reach outside IETF. Image should explain its scope. Include multiple protocols or not?

Brian

Ted: Cast related work. Applications have mechanics. DNS lookup is not part of wire image or the application, but it's part of the substrate (and the document needs to talk about the interaction of application mechanics with the infrastructure). In related work: traffic signals analysis, application state mechanics. Point out what happened with HTTP.

Christian: Congestion control is TCP.

## path-signals

Ted: Rework introduction to make this look less like a rant about TCP (general consensus on this)

Brian: Then send it up to the IAB.

Ted: Send up path signals first, point the IAB at wire image.

Aaron: The money section of path signals: four options. Existence of four options should be in abstract.

Mirja: Integrity protection of the path signals?

Ted: Yep. Mirja, give me a PR.

Martin: Signals should be integrity protected otherwise the network will me

## greasing

Spencer: Should we say something about greasing now?

Christian: Invariants, encryption, and greasing go together.

Spencer: IAB should produce greasing guidelines. Might also make sense to do as a IAB

## doctor scope

Eliot: discussion in SAAG on trying to improve BGP security... should we nuance things about where this recommendation applies

Martin: If you know better, you will ignore the recommendation.

Spencer: IAB should do high-level. IETF should do details and nuance...

## future of the program

Aaron: architecture is spending a lot of time arguing with each other so we agree on the high level principles. We have a lot of conversations here that cause other conversations to happen. We're management.

Mirja: Review membership?

Spencer: Program more effective when we clock things faster.

## M3S

Mirja: summarized outcomes. principle: replace transparent proxies with explicit proxies.

Ted: NFV. Routing of packets depends quite heavily on decisions made by these functions.  "High level" functions made by chains of functions, which can be quite long. Very difficult to make all of these explicit, because the path itself is making decisions...

Mirja: Base model for function chaining is first box defines the chain.

Ted: We have to be very careful about switching the model to explicit because of interaction with decision trees of in-network functions.

Note that these functions don't decrement TTL.

Ted: What is a hop?

Martin: This principle is a great idea, but it's too nebulous

Aaron: Difference between identifying middleboxes before, and auditing them after....

Mirja: We talked a lot about the inspection case. Middlebox wants access to traffic. Client should have option to veto.

Aaron: Notification that there's a thing on the path.

Ted: Someone has to be the nihilist in this room. That sounds good in theory, but I can't imagine anyone voluntarily submitting to such an audit. Lots of enterprise stuff does exfiltration. Nobody wants support calls, notification will drive these.

Eliot: 80-90% of time is problem location. Having visibility is not an anathema, it's almost a requirement about the customers

Aaron: Implicit assumption that middleboxes want to hide. Applies to some. Not all. Sometimes developers thought they had to be transparent, attempting to follow e2e principle. And sometimes they got it wrong. You can split these cases.

Eliot: A reasonable architecture to point to would be a big help here.

Actions:

- Brian to set up a call soon (early-mid April) to continue this discussion.
- Ted to apply comments from this meeting to path-signals (Mirja to send text on integrity protection) and send up to IAB soon
- Brian to rev wire-image with comments from this meeting. issues and PRs cheerfully accepted at https://github.com/britram/draft-trammell-wire-image.

cheers,

Brian