[{"author": "Antoine Fressancourt", "text": "

Have you investigated the use of mix neworks here ?

", "time": "2023-07-24T16:42:09Z"}, {"author": "Christian Huitema", "text": "

Pemature optimizations are bad. Especially when dealing withencryption.

", "time": "2023-07-24T16:47:45Z"}, {"author": "Antoine Fressancourt", "text": "

Doing onion like routing without reencrypting the whole packet at the proxy is not doing onion routing, it is wasting header space without any protection

", "time": "2023-07-24T16:55:25Z"}, {"author": "David Schinazi", "text": "

To clarify what I said at the mic: I'm supportive of doing a thorough security analysis before this document is published to clearly identify the possibilities and threat model

", "time": "2023-07-24T16:58:50Z"}, {"author": "Christian Huitema", "text": "

Reduce overhead without the forwarding mode should be a priority. Or maybe the base line..

", "time": "2023-07-24T17:06:12Z"}, {"author": "Erik Nygren", "text": "

Are there any security issues with ECN marking forwarding in this? It seems like there might be tagging issues there as well.

", "time": "2023-07-24T17:09:00Z"}, {"author": "Erik Nygren", "text": "

(probably as a corner-case for the design team to think about)

", "time": "2023-07-24T17:09:35Z"}, {"author": "Eric Orth", "text": "

I would say I see at least enough clear usecases to make adoption reasonable.

", "time": "2023-07-24T17:10:47Z"}, {"author": "Mirja K\u00fchlewind", "text": "

No hums :pensive:

", "time": "2023-07-24T17:11:50Z"}, {"author": "Mike Bishop", "text": "

Should we hum the Jeopardy theme while we wait for show-of-hands results?

", "time": "2023-07-24T17:12:46Z"}, {"author": "Eric Orth", "text": "

Since I'm remote, you can't prove I'm not humming.

", "time": "2023-07-24T17:13:53Z"}, {"author": "Martin Thomson", "text": "

Why not four?

", "time": "2023-07-24T17:18:01Z"}, {"author": "Antoine Fressancourt", "text": "

Similar remark as with the previous draft, in the literature about mix networks there are constructrions fro doing this in a secure way

", "time": "2023-07-24T17:19:02Z"}, {"author": "Mike Bishop", "text": "

IIUC, those mechanisms require that one of the sides be less restrictive. (\"Cone NAT\", etc.) The current construction of CONNECT-UDP makes it the most restrictive variant.

", "time": "2023-07-24T17:20:03Z"}, {"author": "Mike Bishop", "text": "

Two of those can't communicate without a relay server in any construction I'm aware of.

", "time": "2023-07-24T17:20:21Z"}, {"author": "Christian Huitema", "text": "

+1 on having Masque UDP Connect behave like Turn!

", "time": "2023-07-24T17:22:35Z"}, {"author": "Mike Bishop", "text": "

CONNECT-Teredo! (/s, mostly)

", "time": "2023-07-24T17:23:25Z"}, {"author": "Christian Huitema", "text": "

We could call it CONNECT-shipworm, for differentiation

", "time": "2023-07-24T17:23:55Z"}, {"author": "Eric Orth", "text": "

+1 to what everybody is saying. Overall, I think the current draft is very specific to WebRTC needs where we happen to have that STUN server in place. Other usecases, that might not be the case and passing back the public connection info is reasonable.

", "time": "2023-07-24T17:24:36Z"}, {"author": "Eric Orth", "text": "

UNCONNECTED-UDP

", "time": "2023-07-24T17:25:50Z"}, {"author": "Eric Orth", "text": "

Or maybe NONCONNECT-UDP?

", "time": "2023-07-24T17:26:30Z"}, {"author": "Eric Orth", "text": "

Or just call it \"UDP\". That won't confuse anybody.

", "time": "2023-07-24T17:27:00Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Turn is clunky and old :scream:

", "time": "2023-07-24T17:28:24Z"}, {"author": "Christian Huitema", "text": "

Yes, Turn is old, but EKR is right. Denial does not begets deployment.

", "time": "2023-07-24T17:32:03Z"}, {"author": "Antoine Fressancourt", "text": "

TCP is old too

", "time": "2023-07-24T17:32:20Z"}, {"author": "Alex Chernyakhovsky", "text": "

And we (tried to) replace TCP with QUIC!

", "time": "2023-07-24T17:34:07Z"}, {"author": "Eric Orth", "text": "

I stepped out for 10 minutes to watch something in another WG. Are we still debating the same thing?

", "time": "2023-07-24T17:45:22Z"}, {"author": "Mike Bishop", "text": "

Chairs, should the queue be closed if he's trying to drain the queue?

", "time": "2023-07-24T17:45:43Z"}, {"author": "Watson Ladd", "text": "

I think we should rename this Twirl as it's a quic turn. More seriously think the name needs tweaking since it's not a purely listen.

", "time": "2023-07-24T17:47:52Z"}, {"author": "David Schinazi", "text": "

Totally agree the name isn't great. Any thoughts on a better name?

", "time": "2023-07-24T17:48:27Z"}, {"author": "Alex Chernyakhovsky", "text": "

MASQUE LISTEN?

", "time": "2023-07-24T17:50:50Z"}, {"author": "Alex Chernyakhovsky", "text": "

It could work for all IP protocol families in theory

", "time": "2023-07-24T17:51:00Z"}, {"author": "Martin Duke", "text": "

What are the objections to adoption?

", "time": "2023-07-24T17:52:02Z"}, {"author": "Erik Nygren", "text": "

Amused the transcript transcribed \"PvDs\" as \"DVDs\".

", "time": "2023-07-24T17:52:23Z"}, {"author": "Lucas Pardue", "text": "

StILT - Stable Inbound Listen Techniques

", "time": "2023-07-24T17:55:16Z"}, {"author": "Alex Chernyakhovsky", "text": "

@Lucas Pardue does that make all MASQUE proxies circus performers?

", "time": "2023-07-24T17:55:45Z"}, {"author": "Lucas Pardue", "text": "

I have an internal wiki page called \"The MASQUE client zoo\", so if I can take them to the circus it would be a good symbiosis

", "time": "2023-07-24T17:56:39Z"}, {"author": "Mike Bishop", "text": "

This looks a lot like Ben Schwartz's proxy config file, too. That's been looking for a home; maybe the proposals need to merge?

", "time": "2023-07-24T17:56:57Z"}, {"author": "Marc Blanchet", "text": "

it looks to me that the PvD proxies should be a dictionary instead of array, so the reader knows what is this proxy offerring. I would say an array of objects, where object has 2 properties: types as an array of possible proxy servers, and then the array of the proxy urls serving this set of types.

", "time": "2023-07-24T18:01:50Z"}, {"author": "Eric Orth", "text": "

While I'm hesitant on the specifics here, I'm generally very supportive of anything trying to fix PAC/WPAD. Send this to INTAREA or similar and see if we can develop a good solution.

", "time": "2023-07-24T18:04:20Z"}, {"author": "Martin Thomson", "text": "

I think that INTAREA is maybe not the right place for this. This group might be a better choice.

", "time": "2023-07-24T18:07:53Z"}, {"author": "Martin Thomson", "text": "

INTAREA might have defined PvD, but the implications for use are application domain concepts that might better fit in HTTP and/or MASQUE

", "time": "2023-07-24T18:08:31Z"}, {"author": "Eric Orth", "text": "

If we take it in this group, that is the exact sort of draft that risks turning this into the general proxy WG, which I don't think the WG wants.

", "time": "2023-07-24T18:08:46Z"}, {"author": "Martin Thomson", "text": "

+1 Mirja's point, see above :)

", "time": "2023-07-24T18:09:04Z"}, {"author": "Abhijit Singh", "text": "

Watson Ladd said:

\n
\n

I think we should rename this Twirl as it's a quic turn. More seriously think the name needs tweaking since it's not a purely listen.

\n
\n

DIS-CONNECT UDP

", "time": "2023-07-24T18:09:58Z"}, {"author": "Martin Thomson", "text": "

Take it to HTTP then

", "time": "2023-07-24T18:10:14Z"}, {"author": "Lucas Pardue", "text": "

Connect USB next!

", "time": "2023-07-24T18:11:47Z"}, {"author": "Eric Orth", "text": "

Connect radio waves.

", "time": "2023-07-24T18:12:53Z"}, {"author": "Erik Nygren", "text": "

I guess rfc3040 went through the Network WG?

", "time": "2023-07-24T18:12:56Z"}, {"author": "Antoine Fressancourt", "text": "

Connect semaphore

", "time": "2023-07-24T18:13:32Z"}, {"author": "David Schinazi", "text": "

MASQUE ALL THE THINGS!

", "time": "2023-07-24T18:14:38Z"}, {"author": "Martin Thomson", "text": "

I want to see a stronger use case for this, along with that analysis

", "time": "2023-07-24T18:14:55Z"}, {"author": "Watson Ladd", "text": "

Radio has some very big use cases like remote radio operation. Right now I think there's a grab bag of proprietary protocols

", "time": "2023-07-24T18:16:52Z"}, {"author": "Erik Nygren", "text": "

Would this then be useful for things like replacing (insecure) VXLAN or for VPC peering? (VXLAN-over-HTTPS?)

", "time": "2023-07-24T18:17:20Z"}, {"author": "Alex Chernyakhovsky", "text": "

oooh, vxlan in masque would be interesting

", "time": "2023-07-24T18:18:42Z"}, {"author": "Lucas Pardue", "text": "

no opinion on this draft but obligatory Malcolm

\n

Screenshot-from-2023-07-24-19-17-33.png

\n
", "time": "2023-07-24T18:18:42Z"}, {"author": "Markus Amend", "text": "

In 3GPP ATSSS discussion also alternative solutions are discussed to transport Ethernet. It does not need to be MASQUE which provides the support here.

", "time": "2023-07-24T18:20:08Z"}, {"author": "Eric Orth", "text": "

I am actively not voting either way because I do not feel I can gauge the usecases/interest to make it worthwhile.

", "time": "2023-07-24T18:20:26Z"}, {"author": "Lucas Pardue", "text": "

Same

", "time": "2023-07-24T18:20:37Z"}, {"author": "Christian Huitema", "text": "

+1 watson. The ethernet bridging scenario is already solved in many ways. This woudl require deploying a Masque server in the target network, which is not very appealing.

", "time": "2023-07-24T18:21:51Z"}, {"author": "Chris Box", "text": "

Offtopic but FYI if you're still hunting for a social ticket, 40 have just been released - see secretariat email.

", "time": "2023-07-24T18:22:48Z"}, {"author": "Antoine Fressancourt", "text": "

You may also do network coding over packets to replicate using a more complex strategy

", "time": "2023-07-24T18:25:40Z"}, {"author": "Marten Seemann", "text": "

Why would you need a PN to achieve deduplication? You can just use H(datagram) to dedup without any wire overhead

", "time": "2023-07-24T18:26:46Z"}, {"author": "Antoine Fressancourt", "text": "

Hashing is more costly than header parameter lookup, though

", "time": "2023-07-24T18:27:51Z"}, {"author": "Hang Shi", "text": "

Hash is more computationally expensive than a number?

", "time": "2023-07-24T18:27:58Z"}, {"author": "Marten Seemann", "text": "

I'm not talking about cryptographic hashes

", "time": "2023-07-24T18:28:22Z"}, {"author": "Eric Orth", "text": "

We're now over time, right?

", "time": "2023-07-24T18:32:04Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

Yeah, just a bit.

", "time": "2023-07-24T18:32:23Z"}, {"author": "Antoine Fressancourt", "text": "

Even fast hashing is slower than a header parameter lookup

", "time": "2023-07-24T18:34:13Z"}]