Transcript Day 2: Working Sessions
slides-semiws-transcript-working-sessions-00

---------------
Possible Working Sessions Overview
--------------

1. Trust Domain - Ted (no slides)
---
- Any box that modifies w/o permission is a MITM; question is whether it is
recognized by the ends. - There are cases where one or the other end would
consent if they knew. However, it's easier to stand up a MITM rather than
configure something explicitly. - On path, explicitly configured MBs (e.g.,
HTTP proxy) require change in destination - Questions:
        - Given failure of deployment is that the best deployment model for
        other things? - Can you take consent and not change destination? - If
        you wanted to do with on path devices, need a pre-shared key or another
        trust mechanism
- Pre-shared key: client encrypts, if mb has the key it can mangle. This
reduces the problem to a previously unsolved problem, namely how to establish a
shared secret with the Internet. :-) - Currently two models that work in some
situations:
        - CDN works if explicitly configured as CDNs are part of the trust
        domain of the content provider. - Explicit proxies work fine but they
        don’t scale and don’t work where you have services in path that are
        unexpected by one of the endpoints.
- Both models don't work because they require that you know explicitly
something... - Is there a different model or way to resolve problem with the
current model?

* David Black: wonder if we should do this here - DNSSEC could help leverage
this one; do we have the expertise here? * Bob: must be split into 2 different
problems: MBs that just want to look, and others that want to mangle (change
bits).  Leads to different use cases: look but don't touch (or drop), mangle
and forward. * Ted: but "drop" is a form of mangle. * Eliot: we’re dealing with
this problem at the wrong layer. Problem is that when there are signaling
aspects around “normal” transport mechanisms. * Brian: this sounds like a
constraints on what we do on middlebox interaction (point 3 below) and balance
of power (point 6 below) * Brian: these are things we can learn from when we
are setting constraints for MB interaction * Gorry: If we trust the first MB,
does that mean we trust those in the chain? * Ted: it doesn’t mean you trust
them.  Once you have handed unencrypted bits, there’s not much you can do to
control how they’re used.  Enforcement is not a protocol activity. * Jana:
trust domains is a transport problem since it’s e2e. But, don’t know purpose of
a working session here. Need to solve it if we want to think about how
transports would evolve.  If we are trying to articulate problems rather than
come up with solutions... It’s an important problem but don’t know that we need
to find a solution here. * Christian: believe that this kind of protocol with
contracts, application, etc. tend to evolve organically.  Not sure we can plan
them in advance.  Maybe just need to try things and see what works.

2. Path Characteristics API
---
- How to get control of e2e in-network functions back to the client?
- MB detection mechanisms

* Bob: not interested because I think it’s impossible
* Brian: but is it useful? :-)
* Bob: have been trying to get these things to talk ECN...
* Brian: an incentive problem
* Christian: competing between e2e and explicit agents on the path...
* Joe: we haven’t tried providing any info to an app such that they can do
something with it. IF we had a paradigm that you could get access to it and
also make use of it, people would do interesting things with it. * Bob: had
this with ECN: can't do it in 2 bits? => forget it. * Gorry: If we maybe take
it as hints from the network, we can do it.  Hard signaling I don't believe in.
* Brian: as long as we can ensure you can't win by lying. * Costin: E2E sensing
of the path is not enough.  Test doesn't work. API: Doable if you go toward a
cloud model - talk to your first-hop provider. * Colin: we've tried to build
this E2E signaling thing many times, and failed every time.  What has failed. *
Lars: network can already tell the ES s/t via ICMP. * Ken: but application
can't get to that info. * Jana: no standard way to get info.  Problem is not
unsolved.  It’s a deployment problem.  Bits can already be made available.  
This isn’t something we can move much on.   Many things show up as Path
characteristics.  It might be useful to talk about precisely what
characteristics we'd actually want to expose with this API. * Michael: it’s
true that we’ve tried these things again and again.  Have never seen an example
of a way to do this (making use of info) that’s useful. * Joe: agree hints is
the right way to think about it, but trust domains raises the possibility/need
for getting something stronger.

3. MB Interaction (Joe)
- Which information would be needed?
- Protocol design
- Requirements for path API
        - Deploy on existing inet w/existing kernels (deploy via
        libs/browsers). Implicit: in user space, non-root. - choices for cong,
        retrans, etc.

* ?: are you concerned at all about performance? 10-40Gbps?
* Joe: yes. Want incremental deployment and be able achieve improved
performance over time * Jana: for performance need to separate client-side and
server-side considerations. * Lars: may have different APIs

- Requirements for path API (cont'd)
        - single FW traversal mechanism, multiple transport semantics

* Joe: lots of protocols have done some of these things.  Believe we can get
some MBs to at least implement one thing in this space. * Brian: there is a
base assumption that since you’re talking about interaction being explicitly
inband, it’s tied to whatever transport you are using on top. * Joe: right, the
protocol being described is NOT in itself a transport protocol - it’s a
"session protocol", but *under* the transport.

- Requirements for path API (cont'd)
        - multiple interfaces for each endpoint (MPTCP)
        - determine which protocol is in use (fast, but not port specific)

* Ted: you’re expecting FWs to behave differently because you’re giving it when
there is start and stop on transport * Lars: if you have that requirement why
is there not a new IP protocol option.  You are teaching MBs to do UDP payload
inspection. * Joe: current MBs can’t tell start and stop of sessions. * Aaron:
there’s nothing about identity or authorization in list, is this intentional? *
Joe: intentional to be an inline protocol.  As much as possible, all pieces of
flow follow same or similar paths through the NW.

- Requirements for path API (cont'd)
        - associate packets with a flow (fast)
        - policy per-flow
        - separate contexts for in-flow path-> application (p2a) and
        application -> path (a2p)
                - possible to hide the plaintext
                - treat as ignorable hints both ways unless authorized
                - p2a, a2p, have separate security context from e2e
* Bob: lying?
* Joe: if I declare I’m using this protocol, and I don't, and network breaks
me, it's my fault. * Bob: I don’t have to say I’ve stopped my UDP sessions.
Because it’s in user space, it’s easier for attackers * Jana: don’t think
holding end of flow is in interest of application. You rely on NATs not
dropping bindings.  it could be nice to have signaling to tell MB to drop the
bindings.  Are we talking about new protocol (or could be use UDP checksum
bits)?  How are you scoping this? * Joe:  don’t think we can use UDP checksum
bits.   Believe that can have a relatively small protocol inside UDP - e.g.,
you can build TCP encapsulated in this... This might just be a set of
requirements for next version of DTLS. * Jana: you would need an incredibly
minimal shim - 16 bit. * Bob: we’ve done a 32 bit shim for something similar.

Christian’s presentation: Let’s reuse TLS - define DTLS 1.3 so it meets user
level transport needs.
---
- transport innovation requires encryption. That's hard. let's re-use TLS!
- very scared of multiple TLS stacks - every one gets it wrong at first! -> So
reuse as much as possible (TLS/DTLS) - TLS/UDP doesn’t meeting many requirements
        - don’t have a multiplexing layer independent of port
        - doesn’t expose sequence number
- With DTLS 1.3,  define it to meet the needs of user level transport: headers,
sequence numbers, API...

* Ted:  agree that this seems like something we can bite off and chew. But,
this may need to be a fork.  Some don’t want to expose these bits. * Dan: we
need to figure out to do that.  There was a mailing list discussion about DTLS
- we have in the past validated ICMPs but can’t do that with DTLS. We need to
fix that with 1.3 - don’t need a sequence number but need some number. * David:
 wondering about DTLS session regularity - is there another mux layer on top of
this?  What is the right scope of a DTLS session from a security point of view
? * Christian: no, multiplx would be a library function used on top. current
DTLS design says session IDed by port. If we want to do TCP multipath, need a
single transport session getting packets from multiple ports - like HTTP2. *
Brian: in TCPinc discussion, discussed putting it in kernel. There are
possibilities when discussing this as a sublayer, that DTLS 1.3 won’t be
backwards compatible. This might tie into Ted’s suggestion that if we’re using
this as a sublayer of a transport, but there might even be features we won’t
use. * Christian: would very much like to have a single implementation of the
crypto stuff.   Most of the bugs we find in security aren’t issue with crypto,
they are bugs in wrappings of protocols and negotiations etc. * Richard:  It
will be important to be clear on what bits really need to be part of DTLS in
layer that enforces crypto boundary, in crypto boundary layer and outside
crypto boundary layer.

* Brian: Meta-question: is Joe's thing a separate thing, or is the proposal to
make it part of DTLS 1.3? * Answer (room): maybe.  Suggestion: look at/refine
requirements, then look at overlap with DTLS.

4) MB measurements
---
- failure reports in happy-eyeballs protocols
- define methodology and data model for aggregation

* Aaron: of protocols that exist today, what kinds of detections can we make?
Oughtn’t be a long discussion. Folks that want to work on this should get
together for a BoF.

5) User-space stacks
---
- can this support faster deployment of new protocols/protocol extensions?
- include UDP design goals?

* Dave: we need both how to use UDP as well as how to layer HTTPS for dummies. 
Marc’s document (position paper) says the problem is important, but doesn’t
give guidance * Jana: maybe should be more general - transport protocol design
guidance. * Brian: this is Taps * Lars: it’s not so easy. * Brian: DCCPizing it
is already happening in Taps.  2nd is guidance * Jana: not easy to get all
bits. Still valuable to talk about mechanisms. This is new framing that we
don’t know yet. The problem is that not everybody who does this takes the time
to understand. * Gorry: not sure TAPS is quite the same things.  Describing
mechanisms and how interact is a lot more detail - only exists in textbooks
that don’t reflect reality. * Michael: IETF shouldn't be giving guidance about
how to write transport protocols. Our job is to create good protocols and
interfaces to them. * Joe: if we can design a good set of protocols, then
agree. But, we need internal guidance. * Bob: Disagree most with Mark
Nottingham's paper, which says that apps should decide themselves about
transport. * Christian: amused by this business about "guidance". If you want
to provide guidance, go write a book. * ?: think of the poor PhD student who
has an idea about some piece of TCP.  Don't want him to have to re-implement
the whole thing.  We need to think about how composition can facilitate
experimentation with individual components. * Ted: Amused by the fact that this
is part of the stack evolution program  and we have already moved ISO session
layer. When we talk about transport we are conflating multiple different kinds
of "transport". Transports such as UDP and transports that will be inside a
DTLS encapsulation. They will have different characteristics. We need to invent
terminology to go along with technology. Example: what people are doing on top
of https - not a "transport", but app semantics that people are doing to get
stuff through the network. Look, there's a "fleen".  It might run over UDP or
HTTPS, but if we call it "transport"... * Jana: may have a document that has
the new terms. Back to design guidance. Want to clarify. Main point is that we
have a lot of mechanisms that we’ve built - eg. TCP roadmap. As it turns out,
all those lessons apply to any new transport. There’s not way for user space
work to fit back into the mechanism.

* Brian: conclusion - doesn't make sense to split the room. Do middlebox
interaction first. Trust & balance of power are parts of it.  Enough interest
to do that as one group. * Aaron: if you don't solve the trust problem you have
no chance. Boils down to a topic about communicating with mbs, and one about
building new transports.

6) Balance of power (encryption)
- using encryption to provide extensibility of existing protocols
- WG charter?
- How much of DTLS will we reuse?

--------------
Working Session on middlebox interaction (incl. Trust & Balance of power)
--------------
- Agenda:
        - Middlebox protocol interaction sketch
        - what info is interesting to apps?
        - What info is interesting/useful to network that apps are incented to
        provide? - Trust domains and encryption requirements

Session protocol for UDP datagrams (SPUD) (Joe) (see slides 6-11)
---
- protocol "sketch"
        - UDP for per-app demux
        - Magic number - (one possible way, not the only one)
        - Session ID
        - Command (open, close, error)
        - Transport inside (e.g., TCP or SCTP)
        - path-to-app flag, app-to-path flag
        - Simple transport for p2a, a2p: frags, CBOR (RFC 7049), MUST ignore
        unknown

* Bob: are you assuming MB state is shared?
* Joe: would expect that if there are multiple things on path, each would have
some session state * Christian: what if multiplexing on wireless NW and WiFi? *
?: Session ID - strong enough to cross IP addresses? * Joe: might want that
stronger thing to be above this... * ?: shouldn't this go right on IP? * Joe:
Make that a part of the design, but not the only way. * Ted: MBs telling app
they are on the path vs. MBs saying path to them must be stable... * Spencer:
how much more work is needed to stdize this? * Joe: please ask again right
before lunch. * Jana: what's the use of "open" and "error"?  only "close" is
interesting. * Michael: expected to see ICE here? * Joe: it's one of the things
you put inside this... * Bob: what happens in the middle of a tunnel? ICMP
doesn't work anymore because of tunnels... * Ken: is there some way for the MB
to ID itself? * Joe: yes, hold on. * Ted: whether it's on the 5-tuple or not is
a red herring. Problem is bootstrapping the crypto state. If you used another 5
tuple, you might be able to get away from making up source ID. Agree NAT
traversal will be problematic if unmodified. * Joe: agree.  Also: want this to
work through existing NATs that allow UDP to pass * D. Black: if we get this
right, is there some possibility of something picking up some ICMP and putting
it through all the pinholes all the way back?  If so that's a big win and
addresses some of Bob's tunnel problems. * Erik:  There’s a flag in the base
header and some protocol that goes along with that. * Jana: "This is just ICMP
on steroids.  It's broken in the same way." * Bob: tried to document all the
reasons ICMP was deprecated last year. * Mirja: if we also use it to get ICMP
like information, how do we ensure the same thing doesn’t happen to this
protocol? * Joe: Good question.

- A2P examples
        - request for special handling - I would prefer you drop rather than
        delay - application/device capabilities - measurement probes, requests

* Aaron: L2 triggers.
* Miroslav: have problems when you mention this as “a path”.  Who responds when
you make a request?   this applies even more when you have multiple devices. *
Joe: kinds of things and not qualities * Ken: applications and capabilities. 
You can split into: this is what I’m doing (capability), here is my credential
- Joe wouldn’t put latter in capabilities (in a2p path) * Joe: wants to be more
explicit - what app knows when paths change. P* hilip: should be able to do
some things implicity * Joe: go back to what we’re signaling and not how * Dan:
 In PCP a single request can have multiple responses come back.  Concerned
about protocols where we want network to do what I mean.  E.g., Need different
NW characteristics for various codecs. * Lars: more info is not always better.
Much more important to have a limited Api that avoids pitfalls.   Had a draft
that argued or this in TCPM. Example: indicating link is up.  Turned out to be
bad b/c if application was stupid with it, it would make things worse. * Mirja:
also concerned about application having the info. Further NW makes a bunch of
assumptions about packets - if a2p will change assumptions, then need to
consider. network should not make assumptions. keep as declarative as possible
* Ted: Agree with Mirja. Thinking of application like a video call - a p2a
response might be that you are rate limited.   By the time the first media
packet is going out, the signaling is completed.  Should rate limit come p2a
even if you don’t know application cares.  It might be part of an application
state (e.g., webrtc context).  Anything requires request/response misses
application point of view.  What is your example of a MB? When talking about
hints, if it’s declarative, you can deploy must faster. * Brian: it might makes
sense to keep p2a and a2p separate (ala Mirja’s comment) and both as "nice to
have".  Don’t know how any of this will be used. We are trying to have a
discussion about that but we don't know. Could be enabling a bunch of
application-path signaling that works well and vice versa. * Ted:   Point you
are making is good and also high problematic.  What I was getting at was that
you needed info about rate limit before you start flows. Sending all the info
that might happen on the path is a potential DoS attack.  If you do that for
the full flow, you’ll hit lots of problems with mobiles which have to wake up
radios to receive stuff they don't want (or may not want).  Need a narrow set
of these initially.  Add to this relatively slowly. * Michael: is this
per-packet? * Joe: no, thinking about it as every packet is either E2E or
P2E/E2P, but not both. * Mirja: need use cases * Spencer:  back to Lars about
creating problems.  Do we think we’ll get enough benefit for the additional
complexity.  Trigtran (2003) - increasing complexity of TCP state machine
without enough benefit. * Jana: top part of this is massively useful, the other
is nice to have but a massive rathole also.  There is also a use case of
networks where UDP transport is inefficient. * Brian: propose to limit
discussion of trust issues to what is needed to make the stuff above the line
work. (That is, to make UDP work where it does not now.) * Christian:  I have a
bad feeling about the "below the line" part. It is basically saying "how do we
enable maximum complexity in the Internet". * Joe : what we are fighting
against is the *assertion* by people who carry a lot of traffic that the only
way they can provide their features and value-adds is to have access to the
whole plaintext sp they can change it. Believe that this protocol would mean
that they don’t need to see the plain text but could still achieve objectives.
Trying to redirect the energy to s/t that is less destructive. Christian: all
your examples are focused on the enterprise firewall and how do we open a hole
in that.  But in my experience they only open a hole when there is a business
reason: if you don't, your org will be less productive than the one that does.
Joe: if we look at service providers as the enemy we will continue to have
problems getting things deployed.

- p2a examples:
        - mtu
        - BW
        - ECN
        - Pacing
        - Timeout info
        - Backout scatter: find non-complaint path elements?
        - errors with URL reporting, diagnosis
        - non-error status for determining break point (Ping++ on path)

* Gorry: first 4 P2A examples (MTU, BW, ECN, pacing) are things I want to know
E2E, rather than getting them from individuals.  ... you created a space that's
"this wide" (holds arms apart). * Joe: yes, some of these are path
characteristics. * Mirja: if all nodes on the path have to reply to get the
requested information it should not be on the list.

* Brian: we have 19 minutes to solve the trust problem.
* Eliot: first action item from workshop = develop use cases in which this
should be deployed.  Swiss army knife - figure out a way to ensure that it's
used for good and ensure that it's not used for evil. People in the room should
think about how they could use the capability.

Trust Problems
---
- Can you make the problem smaller?
- What are properties of trust model?  Probably depends on sematics of
information being exchanged. - If we say "all we are doing is start/stop,
session ID and flags", can we draw a box around the trust problems?

* Mirja: need use cases first
* Bob: Tunneling issue needs to be understood before trust model can be
discussed. Trust model is easier if you signal things only in forward direction
* Spencer: you’re talking about two vaguely related sets of issues.  The
further you can pry them apart, the better the uncontroversial issue can be
resolved. "Basic SPUD" is 'not quite a no-brainer', the other is fabulously
complicated. * Brian: the rest of the agenda (except middlebox measurement) is
figureing out how we are going to organize. * Gorry: it would be useful to know
if there's anything useful in the backscatter? Because we know how to do
forward. * Ted:  slide with vague framing format - we’re talking about a
framing substrate.  Many things are being born inside it - “fleens”  that we’ve
been calling transports.  There are a small number of things we can send
forward or back.  If you make Session ID sufficiently strong, anyone that is
backscattering using this Session ID is on path that knows enough about the
flow.  For things inside, there’s way too much information - e.g. app
semantics.  If we solve framing substrate trust model and let people that are
specifying specific things inside figure that out.   Suggest to defer the
latter.   Bad news is that we may have to specify an addition to the framing
substrate that carries crypto information.  e.g., session key encrytpted.  If
you decrypt that, then you can decrypt more information  Need a general
mechanism is substrate to trust someone with information inside.  Might not
encrypt all the payload.

Dave: Is there some way to draw a trust box around a smaller portion?    Yes,
thinks we can do this if constrained use cases.  1) endpoints are
authoritative. 2) some p2a stuff.  may need hints ala current ICMP model  3)
everything else resolves into existing unsolved problems.

David: there may be a division of the trust problem based on who is introducing
the MB.

Erik: think ICMP thing that Dave brought up, this is better than that - can
restrict to on path attackers.   are we doing enough?  It’s not just about the
protocol.  What are the things that the actual MBs do?

Aaron: ?

Joe: over lunch, boil your question down to a few syllables.

---------------------
Afternoon Session
---------------------
* Brian: What is the best way to take what we got this morning and turn it into
something that we can actually move forward on? * Mirja: is this already close
to something that you would write down in your charter? * Joe: Bob's tunnel
issue is an existential question.  Have to figure out whether we're going to be
able to do anything.  If not, we'll weaponize https and the providers get
nothing. * Aaron: if Bob has a show-stopper, best use of time may be to explore
that. * ?: Do we have consenus on put a header with session id, and a very
little bit more? * Christian: we should document what we have consensus on.  It
can inform DTLS 1.3 or 1.4. * Joe: we have consensus but it might not be
informed consensus. Have Bob put up his slide and we argue with it.

Interlude: Middlebox measurement and aggregation (Aaron)
---
- There has been some research on probing for compatibility with ECN, some
options. - First question: what are the existing protocols that are candidates?
HTTP, happy eyeballs. - If a stack tries to make an ECN connection and it
doesn't work, record that fact...steal from EDNS0 privacy guidelines.

* Michael W: I think this is great.
* Aaron: work for some people, like Microsoft.
* Dave t: first step is collect the same common data.
* Brian: sounds like a BOF, or a doc coming out of a bar BOF.

!!!Action Item: Aaron will work with others and put together a doc. Target Bar
Bof in Dallas on client-side middle box detection and error information
aggregation

SPUD and tunneling - Bob's slide (12)
---
- in diagram are three layers of tunnel but cell networks may have 7 layers of
tunnels or more - Need to know how far to search to find SPUD - Big problem if
it’s creating a packet that’s going an opposite direction, needs to turn around
all the addresses in the outer headers. - Needs to understand all possible
protocols and existence of shim layer: VXLAN, GRE, GTPv1, GTPv2, L2TP, IPv4,
IPv6, Another tunnel, future tunneling protocols

* Mirja: thinks most use cases don’t have the MB in the tunneling
* Bob: our NW has this
* Brian: problem is for reverse path, need to keep a lot of state
* Joe: for some of these kinds of tunneling protools, ones with relatively good
encryption, it’s unlikely you’ll be looking inside to get access to stuff. *
Christian: … ICMP to the tunnel endpoint …. * Bob: how do you deploy a load of
tunnels that will understand SPUD * Christian: need a conversion from ICMP to
SPUD * Erik: if a MB can't understand the tunnel protocol, it can't be a
middlebox doing DPI. if you’re going to build MB, it needs SW to parse tunnels.
 In itself, needing to reverse addresses is not that difficult. Problem is when
tunnels are asymetric - g.e., MPLS. * David: to what extent are you assuming a
content aware MB. Are the MBs possibly doing something else where if we weren’t
talking about SPUD, MBs would do something clever at another layer. * Brian:
anything that can mess with SPUD or anything under SPUD have already solved the
how to find SPUD problem. Reverse path is a separate problem. * Mirja: we
haven’t decided that we even need to send the packets back. * Bob: security
issue - can get it injected into the forward path.  Don’t know how to get it to
work in the opposite direction. * Joe: think we can take another approach.  Not
all  MBs will have the ability to send traffic in the backward direction.  for
boxes that can send protocol back, they can perform the backwards.  For those
that can’t, then add a bit (two bits on) that indicates it can’t. Some will
only be able to send forward, so the receiver has to bounce.  Bouncing has a
trust issue - but it's a smaller unsolvable problem. :-) Can say "there's
something in-path that needs you to start doing traffic analysis"... * Bob:
bouncing has less of a security problem. * Joe: could imagine leaving space in
early packets so you can add something that’s reflected * Bob:  Use cases about
path characteristics and not box characteristics * Brian: reflective mode is a
problem * Joe: okay with different MBs have different performance
characteristics * Erik: It’s not clear to me what the trust model is in the
reverse. Lots of details to work out. * Jana: want to take a step back.  Worry
that we are going forward with a solution that may not be a solution to a
particular problem.  Don't know what path characteristics are useful.  What can
the path tell me that I will use, and solve a problem that I can't already
solve right now?  Back to the question of what problem are we trying to solve?
Joe: if we come up with one use case that's not stupid, will be enough? Ted:
will volunteer to write up a use case centered around RTCWEB

!!! Action Item: Ted writes WebRTC use case for sub transport session (SPUD)
-00 draft

* Jana: have some real problems that we could use this for
* Brian: pretty much consensus that start, stop etc are useful
* Jana: want a minimal transport
* Joe: I want a minimal transport that has incentives enough to be deployed. 
May not be optimal for everyone. * Jana: that reduces incentive * Ted: can I
invite the two of you to dinner? :-) * Brian: this conversation needs to go
into a smaller group

* Christian: if we think about bits and packets, the bits that the Internet box
can trust are the bits that the end application would use no matter what.  It's
much more robust to say "I designed this because it's a natural thing that I
need in the transport protocol, but I designed it in such a way that it's also
useful to middleboxes."  If we remove the redundancy, it increases the trust by
the operators. * Mirja: basically when writing LEDBAT doc saw need for a
general feedback mechanism in UDP.  If we want to use this for MBs, then need
to explicitly allow MBs to look at this * Jana: need to think about what we
want to be de-ossified. think what we would like to ossify for minimal SPUD. I
would consider that success. * Joe/Brian: have to design it in such a way that
it's *necessary* to implement the options. * Ken: CBOR is absolutely crucial
for that.

!!! Action Item: Joe write Minimum-SPUD draft.
- Have two weeks to get to a BOF proposal (can do it w/o publishable document).
- Input to stack evolution program -> input to IETF...?

* Joe: Would like to request a BOF.  Whether it is WG-forming, don't know.
* Dave T: in an actual BOF, most useful thing to start with is what is the
problem we are trying to solve? Bob: there are things that are implicit - basic
assumptions that we didn’t talk about; maybe need an IAB statement  on basic
assumptions about transport evolution. Discuss on Stackevo mailing list. *
Brian: yes, these are so uncontroversial that we didn't even discuss them. *
Lars: I think this is a bad idea.  I wanted to see one concrete thing that had
incentive for deployment.  I didn't see that.  As far as I am concerned, we are
done. * Jana: there are things that apps want to deploy.  I want two bits: Stop
bit and session ID that can be used by midboxes to pin a flow. * Brandon: agree
on the question of incentives.  I see incentives for the application and for
the network, but not seeing them line up. Network's are not big enough to do
the implementation. * Dave T: again, 3 categories: (i) info to the network;
(ii) hints from the network; (iii) other stuff that reduces to a currently
unsolved problem. * Brandon: Use cases need to be able to get critical mass
without the middlebox support.  Has to be deployed first in the clients. *
Brian: agree, need to be a clear win even if no middlebox vendor ever reads the
document. * Christian: DTLS work item - need to document how it can be used as
the framework.  Consensus that most of these E2E apps will be using encryption.
 If they do they will very quickly get into trouble. * Mirja: is that a
requirements document? * Richard: two parts: what does DTLS already provide? 
What can we add to DLTS that would make this easier? * Christian: take SPUD as
a requirements document.

!!!Action Item: Brian, Eliot, Mirja:  Minimum-SPUD Dallas (non-WG?) Bof proposal

* Lars: this assumes that we all think this is a good idea.  Name one piece of
info that you want from the NW that the NW is willing to give you that you
trust enough to act on it * Brandon: need incentives articulated.  Use cases
need to be compelling without MB support.

Brief discussion about extensibility of existing protocols (Bob)
---
- Should there be a BOF?  UDP, TCP, both?

* Brian: need to regard extensibility/encrytion of UDP and TCP together
* Michael (?): TAPS?  Not chartered to create new transport protocols.

!!! Action Item: Bob, Mirja, Jana: BoF? on transport protocol extensibility.
- Do we need it?

* Jana: don't think we actually need a BoF.
* Mirja: but we have work on Minion on going and innerspace ongoing. It's not
tcpm, not in taps, so where? * Brandon: concern is that tcpm is not necessarily
the right place to deal with the middlebox.  Not a receptive audience for
discussing talking to middleboxes. * Gorry: if you want to implement in tcp
stack, tcpm is the right area. Why not give a useful presentation in tsvarea,
explain the use case and how it's useful. * Bob: As currently written, Inner
Space has to be done in the kernel.  It's nearly impossible to do things that
can be out of order except in the kernel. * Christian: not sure this last thing
is really overlapping with DTLS - lots of things it wants to do tcp already
does. * Dan Wing: there is a proposal in IETF right now to do layered keying
for SRTP.  Cisco and Ericsson both have protocol. * Bob: last TCPINC session in
honolulu was mostly about "this".  EKR was there. * Aaron: this has been one of
the more architectural discussions I've seen in an IAB context.  WS report will
not be done by Dallas.  But we are starting conversations in Dallas with a lot
of people not in the room.  We should have a plenary presentation on the
workshop, not presenting too many findings, but saying what was discussed.