Skip to main content

Minutes IETF120: masque
minutes-120-masque-00

Meeting Minutes Multiplexed Application Substrate over QUIC Encryption (masque) WG
Date and time 2024-07-23 22:30
Title Minutes IETF120: masque
State Active
Other versions markdown
Last updated 2024-07-24

minutes-120-masque-00

MASQUE at IETF 120

Quic Aware Proxying

Speakers: Tommmy and Eric

Nice logo of QUIC covered with a MASQUE

Changes:
* Design team input
* Scrmbling forward mode
* Security considerations
* Loop prevention
* Editorial cleanup

Proxy is now responsible for ID selection

Terminology and examples before details

Open Issues

Issue #113

Prefered address migration: Target says "migrate here", how does proxy handle it?

Options: reconnect, signal proxy new address, something else

Ben Schwartz: Clients can do what they want

Mike Bishop: Proxy doesn't care. Separate request works.

Tommy: If client used name, client might not know address, might do extra work

Mike Bishop: Why would the target do that?

Alessandro: Capsule adds complexity

Mirja: I agree with Ben: why do we need to say anything

Christian: CONNECT-UDP is right solution, you may want to use a different proxy

Magnus: Just connect again

Alex Chernyakhovsky: Simple, but should have text for name initial connection.

Mirja: Why here, not somewhere else

David (off mic): The other one's already published

CID registration limitation

Eric: should proxies advertise limit on CIDs or just cancel registrations above limit?

Tommy: how to communicate
Eric: offset base, similar to flow control

Antoine Fressancourt: sound thing to do, credit based mechanism

Mirja Kuehlwind: We should do something, why not same as QUIC? Copy whole CID mechanism. Seems big, but it works.

Ben Schwartz: Was going to say same thing. Could just use same limits from transport params.

conversation ensues about coupling making this a good idea or not

Kazuho Okhu: +1 Mirja, would want flow control to avoid rapid reset issue.

Marten Seemann: +1

Eric to write flow control text

Client VCID Length

Should be as long as the one in the client connection. Should SHOULD be MUST?

Magnus: What if migration inward happens? Why does proxy see?

Tommy: about registration. Just needs to be long or longer than in capsule

MASQUE CONNECT-UDP Bind

Client listens at proxy for incoming packets

Add header, target has *

What's new? Compress the targets

Two new capsules, one for grabbing compression, one for releasing it. Compression removes IP information.

Context ID instead of repeating target

Alex Chernyakhovsky: Are these IDs reuseable?

David Schinazi: hope answer is no. Decided in an RFC 9297

Alex: text should be clear we release resources not number

When proxy can't do more, can respond with compression close to reject. Clients can do same

Not only compression: also allows specification of which sources are needed

Proxy advertises public address to clients

Discussion: more than one per family? ICE dealt with this. Strong opinions let us know

Right now proxy picks address for a target. If benefit to client picking let us know.

Ben Schwartz: can extend later if needed.

Jonathan Lennox: seeing these two in a row, not sure the work together. Third extension for running QUIC server through MASQUE?

David Schinazi: before we move, last open issues. Editorial pass, and then how do chairs feel about WGLC?

Tommy: Implementation and testing status. Would be nice

Implementations of previous versions, new additions relatively completed. Finish up and editorial pass. Once interop between implementations and anyone wants to join last call.

Who read? Who wants to interop/hackathon? show of hands

Zaheduzzaman Sarker: don't feel 6 people means 6 implementations.

Chairs volunteer to help coordinate with interop.

Ethernet proxying

Presented by Alejandro Sedeno

Open Issues - Vlan tagging, client, ethernet versions, layer separation

VLAN - Recommend each VLAN different connection though you could tag in here if things work

Didn't say how to differentiate. Borrowed a lot from CONNECT_IP, stripped out template language, should put back and let you name networks.

Naming networks not numbering VLANS

Thumbs up in room

Watson: names run to numbers?
A: dropped onto interface on a VLAN, tags are appropriately put on each side.

Supported versions:
Just say 802.3 Ethernet v2 frames

Magnus: Think this is fine. Only issue is multiple versions. Hopefully compatibility is here

Dennis (chair hat): Think we have a commitment to ask IEEE about this. Can sort out final stage, or sooner

Alejandro: Sooner!

Mirja Kuehlewind: think WGLC is right time to not ask each time we edit

Layer separation and congesion control
Do we peek or not? Protocol not decide, but extension if people want it in an appendix

(unkown): helpful pointers, or "good luck"

Alejandro: might say more than TCP MSS clamp but not "fiddle so"

Tianji Jiang: Ethernet frame begining to SCS. If SCS is stomped on does that affect it

Alejandro: issue about carrying it earlier. Rejenerate if needed

Tianji: 5G says must strip, if using here, have to regenerate

Juliusz Chroboczek: Confused. Protocol is used to connect onlink talking devices, and now VLANS?? Need a little expansion

Chairs: will close out, then ask similar questions. If implementing let us know.

DNS Configuration for MASQUE

Speaker: David Schinazi

Not DNS over MASQUE
Rather about which resolver to use

/etc/resolv.conf

VPN protocols do this. IKE, OpenVPN, etc.

CONNECT-IP sends capsules for data, ROUTE-ADVERTISEMENT says what routes to serve.

DNS config has to be out of band. Makes life hard.

DNS_ASSIGN/DNS_REQUEST - IP address, internal domains, DNS search domains, request IDs

Inspired by IKEv2

so can say corp.example.com goes through one resolver

Also configure DNS protocol to use
We have ways to do this with SVCB

Ben Schwartz: Worth solving. Step in right direction. Really think wrong layer. Right layer is interesting question. What is bootstrap point for a MASQUE deployment? What is sent to device? Presumption is CONNECT-IP, CONNECT-UDP template, but we might need addtional info and think carefully.

We actually want multiple protocols: QUIC vs. CONNECT-IP/CONNECT-UDP, quic optimized ones, but need them all. Also TCP tunnels, so want CONNECT-TCP. Bootstrap thow in DOH, or maybe provisioning domain.

David: yes, and. Deployment model is swiss army knife, which Apple did. For that usecase works. But not only usecase: Chrome and ChromeOS where stack can't silently upgrade things aware ways. Chrome configured to do the cool thing, but ChromeOS needs IP level connectivity.

Long discussion of how this works or not and bootstrap.

David: agree with vision, but doesn't quite work.

Ben: Can still do that with blob, ignore rest.

Watson: To reach DNS can do it over tunnel, just advertise address as one served

David: yes

Tommy: Different from bootstrap case. Bootstrap in INT area somewhere. Comes down to sending separate request to proxy of "tell me your config". That's not this. Useful to explain how narrow: not all CONNECT-IP, just some uses, VPN usecase where trying to act like a tunnel.

David: yes, got it

Tommy: if you get down road of the other things, move to format that supports encrypted DNS. If name supports H3/H2, same name as server could just send DoH there. Optimization.

David: already int he draft

Alex: Why not both? not incompatible. Orthogonal or complementary. Avoids staleness, etc.

Servers over tunnel? Should say not issue if DoH, DoQ, etc. but bad if Do53 outside tunnel.

David: will add, makes sense
David: one aspect of connect IP

How do people feel about adoption etc?

Josh Cohen: like info from DHCP?
David: yup

Worth grab meal with opinions and coalesc, or make clear how narrow this is.

Lars: take look if charter allows. Says nothing about DNS.

What's next for MASQUE

Issue lists getting shorter and shorter. Making progress. Many people reading and participating. Good point to read throuhg and provide feedback. All current ones to wrap up.

What's next? Who has deployed? Could be to one Pi or a bajilion customers?

How is that going? Thumbs up

Drafts with solutions, but not necessary

Zaheduzza Sarker: I would also like to know, especially with extensions, and other things built. Necessary to understand how it has gone.

Lucas Pardue: multiple deployments of different kinds. Tooling sucks. In scope? IP tunneling over QUIC to nested congestion control. Curious if in scope.

Chairs: tooling in scope for discussion, can talk about charter/combine with quic, will find home

Tried to steer clear from it, ICCRG can talk about TSVWG talked about it, when you learn more about sharing can share it somewhere. we'll figure it out

Alex: QBONE is still deployed, original QBONE said we want nested CC but not nested reliable with early rejection from congestion control with BBR. CUBIC over BBR is good, BBR on CUBIC great, CUBIC on CUBIC sucks. Horrific hacks to fix this

Area could use research and tooling.