Meeting minutes

IETF MASQUE Working Group Minutes - Virtual Interim - January 2021

• Jabber Chat
• WebEx (Meeting Number: 178 573 8261, Meeting Password: JXuMYDG7h23)
• Minutes

Tuesday, January 12, 2020 (UTC)

19:00-21:00 (UTC)

See this time in your local timezone

Housekeeping

• Scribe Selection / Note Well
• Agenda Bashing

• Github usage and draft status

• Lots of closed issues, but no PRs. Please use PRs to track changes in response to issues.

David: This is me, sorry. I'll be better.

Mirja: Please use PRs so we can see what the change was. Don't close issues until we have agreement.
Also, please raise design issues to the mailing list as well.

Mike: Disagree about keeping issues open after PRs merged, but maybe have a changelog so there's visibility?

Chris: Up to the editors, but close issues when the editors think they're addressed.

Mark: Don't spend too much time on process; chairs should decide and make sure to document so we're all on the same page.

Alex: Tried to include reference to the issue in the commit that referenced it. Do we need people besides the editors approving before they merge?

Mirja: Discussion on the issue, ideally including the issue opener.

Eric: Let's move on. We'll add guidelines to the repo.

Mirja: Please add additional editors in this case.

Presentations

Using QUIC Datagrams with HTTP/3 (draft-schinazi-masque-h3-datagram) - Lucas Pardue

• Lucas added as co-author

• Datagram-Flow-Id header moved into (renamed) draft-schinazi-masque-h3-datagram draft; adopt it?

Martin Duke: Is datagram an HTTP/3 frame or a QUIC frame?

Lucas: QUIC frame, but draft defines interpretation within HTTP/3.

• DFI header is now a list, not a single value; optional names for each ID

Martin Thomson: How does the name not conflict with other extensibility?

David Schinazi: Names allow assigning flow IDs to different extensions; registry in doc.

Martin: That's even worse. Will open an issue.

David: Able to interpret this even if you don't know the extension using it.

Martin: What about a parameter called "name"?

Mark: +1, this is pretty byzantine

David, Lucas: Sure.

Ben: Uniqueness doesn't seem required either.

David: Current extensions don't need more than one ID, but we could remove the requirement.

Ekr: Some repeatable and some not is hard to validate. Pick one.

Tommy Pauly: Repeatability issue goes away if we have parameters instead.

Lucas: Want to be able to have parameters for extensions, but there are lots of possibilities.

Mirja: Proposal assumes an extensibility design; let's figure out extensibility first.

Ben: Type-safe-looking parameters is potentially a layering issue.

David: Registry seems to address this today.

Ben: That puts totally different things having to register together.

David: That's why we have registries, right?

• Flow ID retirement, reuse

Ekr: We have 2^62 flow IDs; why do we need reuse?

David: File an issue if there's not already one.

• Adopt?

MT: CONNECT-UDP currently requires declaring flow IDs up-front. Can we use frames for that instead?

Lucas: Similar concept to Tommy's QUIC-Aware Proxying, fixing up the headers subsequently

MT: Many ways to spell this. Doesn't block adoption.

Victor: Concerned about the change of venue, and the fact this document keeps growing new features.

Chris: HTTP and QUIC chairs referred it here.

David: It's an individual draft, I've been changing it as I have ideas. If it's adopted, that changes.

Mirja: Would like to see naming changes incorporated before adoption happens.

• Poll results:

Poll for ability to use poll:
Yes 21/34
No 1/34
Just here for slides 10/34
Poll for adoption:
Yes 21/34
No 1/34
No Answer 12/34

Lucas: Assuming adoption happens, migrate the document first and then open issues.
David: Put this in its own repo, so we can migrate the repo to the WG and bring issues along.

CONNECT-UDP (draft-ietf-masque-connect-udp) and GitHub Issue Discussion - David Schinazi

• 16 Moved to H3-DGram draft; allows 1:1, 1:many, and many:1 relationships

MT: Intermediary might route flow IDs easily, but many:1 could get messy

David: Don't over-index on intermediaries; they'll probably be uncommon.

MT: It's an HTTP method; we need to work within the HTTP architecture. Why do we need this?

David: Let's wait for Tommy's presentation for justification.

Alex: Also concerned about many:1 based on implementation experience. Breaks horribly in unexpected ways.

• 8 and #23- Use "https" as our scheme? Scheme doesn't actually carry information here.

Mark: Why is defining a new URI scheme hard?
"https" could work, there's precedent, but a separate URI scheme is clearer

David: A separate URI scheme is interesting for configuring proxies, but this is the
reference to the endpoint.

Mark: HTTPS could actually work.

EKR: The semantics here aren't wanting to do HTTPS, they're sending UDP packets.
"https" doesn't make sense.
Was it a mistake to create a new method if the exception can't be extended?
Just do CONNECT and define a header that changes semantics. You'll learn in
the response if the proxy doesn't support UDP.

Magnus: Whatever we do here, know how we'll handle IP, other protocols, etc. that we might
want to proxy in the future.

MT: New URI scheme is a little hard, because we have to understand what it's conveying.
This is just a means to an end; getting through HTTPS. It's ugly, but works.

Tommy: "https" is more right than defining a new URI scheme. But why not use the scheme
of whatever the client is trying to reach?

Ben: Using "https" requires updating the definition of that scheme. "udp" is better,
or maybe "null".

• 15/#24/#28 Stream Format

Need to delimit datagrams on-stream when QUIC DATAGRAM not supported. Now uses sequence of TLVs, possible extensibility point.

EKR: Why do we need this alongside the multiple Flow ID stuff?

David: Have to support fallback to stream when DATAGRAM isn't supported. Would like
mechanisms to align, but haven't come up with better option.

Magnus:<...>

Tommy: Can we just Use flow IDs as the identifiers of the chunks?

• 1/#3 Intermediaries

Flow IDs are negotiated per-hop and requires negotiation on each hop.

MT: Is the intermediary required to do anything if it appears on another method?

David: Remove it if the application of Datagram-Flow-ID to the method is not understood by the intermediary.

• Please review Performance Considerations and file issues if they're not sufficient.

IP Proxying Requirements (draft-ietf-masque-ip-proxy-reqs) - Alex Chernyakhovsky

Not reviewing for time's sake.

• 3 Why would the server request an IP?

Mirja: Why does this need to be part of the core document and not an extension?

Alex: Doesn't make sense -- it would gut this document to remove it.

• 5 OAuth is an example, not normative

• 9/#11 Encourage the core MASQUE protocol to be as stateless as possible

• 13/#10 Loosened text to enable extensions that modify packet format; MUST be capable of sending unmodified

Mirja: Not sure we have to require this; there are use-cases for not sending

Alex: Sure, that's something else you can add as an extension; this doesn't preclude other modes as extensions.

Mirja: The requirement is still too strong; everything you want can be an extension.

Eric: Move this to the issue.

Magnus: Is this byte-for-byte or simply conveying information?

Alex: Byte-for-byte should be possible, but other modes are possible.

EKR: Since we're encrypting, there will always be transformation. We should be talking about
transferring all the information.

Alex: Yes; if the document doesn't say that, submit a PR.

• 16 Term "IP proxying session" is gone

• Open:

• 12- NAT?

• 2 More cross-references between use cases and which requirements result from various use cases

As Time Permits

QUIC-Aware Proxying Using CONNECT-UDP (draft-pauly-masque-quic-proxy) - Tommy Pauly (5 minutes)

Want to improve proxy reuse of 4-tuples, avoid double-encapsulation overhead. Inform proxy of client/server CIDs; if proxy approves, directly forward packets with that CID instead of unwrapping. Proxy has to map CIDs to UDP sockets; can reject in case of conflict/overload. Questions to the list.

Additional IP Proxying Requirement Considerations - Mirja Kuehlewind (5 minutes)

Two possible design approaches for IP proxying; requirements doc MUST NOT assume either solution.