Subject: [Taps] WebTransport and taps

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 14 Nov 2019 19:18:46 +0100

Hi taps folks (also cc’ing the WebTransport list),

I assume that people on the taps list are aware of the WebTransport effort that will have a BoF meeting on 13:30-15:00 Wednesday. I had another look at the WebTransport documents today in order to better understand the scope of WebTransport compared to taps. 

Looking at https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 I believe that this should be covered by pooled connections in taps + use of partial messages. WebTransport proposes to use streams as the base concept while we in taps explicitly decided against this but to use messages instead which also aligns with other protocols that are discussed in WebTransports like Websockets and WebRTC data channels. Unfortunately the draft doesn’t give any reasoning for that choice but I would still think that use of particle messages in taps should be equivalent at it is explicitly designed to address applications that actually need streaming. What do people think?

Further looking at https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 this draft defines a new ALPN value and a QUIC extension. I guess in taps we have not explicitly considered ALPN so far but we really would need to do that in any case! I guess one could see this as a protocol specific property but maybe it’s even worth to be more explicit here. Did anybody consider ALPN already?

Regarding the new QUIC transport parameter I have to say that the purpose it not fully clear to me from the draft. However it seems that this is supposed to support some kind of access control that is performed on the application layer but by a more trusted entity than the client application itself. It is not fully clear to me what the trust assumptions are, however it does seems that is should not be a transport parameter that is protocol specific but rather some function on the higher layer. However, to be able to make a proposal here, I would probably need to understand the purpose better. Do people have any insights?

Do people have thoughts? What is missing in taps to also cover the full web use case? Is that something we want to account for in taps? Or what is the difference that would not fit with the taps approach? What am I missing?

Mirja

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 Nov 2019 14:16:53 -0800

> On Nov 14, 2019, at 10:18 AM, Mirja Kuehlewind <[email-masked]> wrote:
> 

I think the notion of stream here is just a multiplexing concept; the terminology doesn't follow the terminology in TAPS, but it's not at odds. It's just a different phrasing.

> Further looking at https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 this draft defines a new ALPN value and a QUIC extension. I guess in taps we have not explicitly considered ALPN so far…

ALPN is a TLS option, so it fits into the protocol-specific options. We certainly have support for that in our implementation! (https://developer.apple.com/documentation/security/2976269-sec_protocol_options_add_tls_app?language=objc)

> Regarding the new QUIC transport parameter I have to say that the purpose it not fully clear to me from the draft. However it seems that this is supposed to support some kind of access control that…

From the TAPS side, transport parameters in QUIC do need to be able to be configured by the app or set as a default for a given use case, so that shouldn't be an issue.

> Do people have thoughts? What is missing in taps to also cover the full web use case? Is that something we want to account for in taps? Or what is the difference that would not fit with the taps ap…

Fundamentally, TAPS is about API shape and approach. It alone doesn't define any new protocol knobs. If WebTransport needs new on-the-wire protocol changes, those need to be independent. However, the shape of creating connections, and sending and receiving messages, is something that can certainly conform to a TAPS-compliant interface.

If you read through draft-vvv-webtransport-overview, it largely outlines something that is a TAPS interface, just without referencing TAPS or calling that out.

So, one way to view the relationship is that WebTransport as described is a specific set of protocol features that a web-focused implementation of a TAPS system ought to build, plus a few protocol tweaks below.

Thanks,
Tommy

> 
> Mirja
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Fri, 15 Nov 2019 09:51:01 +0100

Hi,

> On 14. Nov 2019, at 23:16, Tommy Pauly <tpauly=[email-masked]> wrote:

I largely agree. The thing they call a Stream would be represented by a TAPS connection backed by a stream of a QUIC connection. A TAPS system should also be able to provide functionally equivalent alternative transport, e.g, falling back to TCP connections or assigning the stream to a a specific connection from a pool of established QUIC connections.

>> 
>> Further looking at https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 <https://tools.ietf.org/html/draft-vvv-webtransport-quic-00> this draft defines a new ALPN value and a QUIC extension. I guess in taps we have not explicitly considered ALPN so far but we really would need to do that in any case! I guess one could see this as a protocol specific property but maybe it’s even worth to be more explicit here. Did anybody consider ALPN already?
> 
> ALPN is a TLS option, so it fits into the protocol-specific options. We certainly have support for that in our implementation! (https://developer.apple.com/documentation/security/2976269-sec_protocol_options_add_tls_app?language=objc <https://developer.apple.com/documentation/security/2976269-sec_protocol_options_add_tls_app?language=objc>)

in the long run, making the ALPN a TLS option may be a little short sighted.
We should consider to making it an optional part of the remote endpoint (remote.with_alp(“http”), as a future QUIC version that may not be based on TLS would certainly also support this concept. I can also imagine Applications only specifying a ALPN and a host name while the transport systems fills in port candidates or use appropriate proxy chains.
This can also be used to address services in Kybernetis like cloud infrastructures.

> From the TAPS side, transport parameters in QUIC do need to be able to be configured by the app or set as a default for a given use case, so that shouldn't be an issue.

Full ACK – But I would discourage using it as it makes protocol evolution harder.
> So, one way to view the relationship is that WebTransport as described is a specific set of protocol features that a web-focused implementation of a TAPS system ought to build, plus a few protocol…

Agreed.

AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/