Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

[Tom Herbert <[e-mail]>]

On Mon, Nov 4, 2019 at 9:09 PM Martin Thomson <[e-mail]> wrote:
>
> On Tue, Nov 5, 2019, at 15:36, Tom Herbert wrote:
> > > Please refer to draft-ietf-quic-manageability for that discussion.
> >
> > I looked at that draft. While it does mention RFC7605, the explanation
> > for how non-QUIC packets that match port 443 aren't misinterpreted
> > isn't particularly satisfying. Other than assuming port number match
> > is sufficient, the recommended approach seems to be for middleboxes to
> > track flows by handshake. But, that then requires state to be
> > maintained and implies that packets for the flow must be consistently
> > be routed through the same device (a common problem for any stateful
> > device in the network). I don't think the QUIC spin bit serves as an
> > exemplar for reliably exposing transport layer information in a
> > transport protocol that is otherwise encrypted.
>
> Yeah, not saying that this is ideal, but it's what we're handing out.  Well, some of us might, I don't think that our implementation has any intention of leaking anything at this stage.
>
> Note also that QUIC allows for migration where the new path will not see the handshake.
>
> I don't think that there is a lack of interest in this subject, just that there is no real drive toward finding e2m and m2e signaling that will be deployed.  Personally, my interests are aligned more with removing signals, not adding them.

That is happening in IPPM WG and others. Options are being defined in
extension headers for the purposes of host to network signaling.