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

Hello

", "time": "2023-11-10T08:31:09Z"}, {"author": "Antoine Fressancourt", "text": "

<clap>

", "time": "2023-11-10T08:35:46Z"}, {"author": "Valentin Go\u0219u", "text": "

:clap:\ud83c\udffb

", "time": "2023-11-10T08:35:51Z"}, {"author": "Antoine Fressancourt", "text": "

<clap>

", "time": "2023-11-10T08:35:57Z"}, {"author": "Eric Orth", "text": "

<clap:

", "time": "2023-11-10T08:36:00Z"}, {"author": "altanai", "text": "

<claps>

", "time": "2023-11-10T08:36:05Z"}, {"author": "Antoine Fressancourt", "text": "

even when yu aggregate packets in a single outgoing packet, there is a possibility to corelate packets with outgoing packets

", "time": "2023-11-10T08:47:42Z"}, {"author": "Antoine Fressancourt", "text": "

I am not convinced the tunneled mode makes the attack less simple

", "time": "2023-11-10T08:50:28Z"}, {"author": "Spencer Dawkins", "text": "

@Martin Duke +2 on this as a continuum. +1 understates how right this is

", "time": "2023-11-10T08:52:24Z"}, {"author": "Kazuho Oku", "text": "

I'd probably say that the left column is \"baseline RFC 9298\" (in sense that it does not do anything like padding or coalescing), but otherwise looks correct

", "time": "2023-11-10T08:53:28Z"}, {"author": "Mike Bishop", "text": "

Can we go ahead and see the slides, please?

", "time": "2023-11-10T08:56:02Z"}, {"author": "Madhan Kanagarathinam", "text": "

https://ieeexplore.ieee.org/document/9153913

\n

in this work, i tried to use SOCKS for QUIC (an older version though) .. it was easier to implement evaluate but security was not considered extensively ..

", "time": "2023-11-10T08:59:14Z"}, {"author": "Antoine Fressancourt", "text": "

thanks for the reference, I will read it

", "time": "2023-11-10T09:00:30Z"}, {"author": "Nick Banks", "text": "

How does ECN apply to MASQUE? Is it meant to pass through the proxy?

", "time": "2023-11-10T09:03:45Z"}, {"author": "Antoine Fressancourt", "text": "

The active attacker is modeled as a attacker able to look at incoming / outgoing connections of a proxy and deleting traffic on those connections

", "time": "2023-11-10T09:06:05Z"}, {"author": "Mike Bishop", "text": "

For CONNECT-UDP, ECN can't be used between the proxy and the target (https://datatracker.ietf.org/doc/html/rfc9298#name-tunneling-of-ecn-marks); you can do that with CONNECT-IP.

", "time": "2023-11-10T09:06:28Z"}, {"author": "Antoine Fressancourt", "text": "

(because all traffic manipulation can be modeled as an attacker deleting packets)

", "time": "2023-11-10T09:06:44Z"}, {"author": "Mike Bishop", "text": "

@Nick Banks , there have been some extensions suggested that could carry ECN marks, but IIRC they've not been adopted.

", "time": "2023-11-10T09:09:51Z"}, {"author": "Nick Banks", "text": "

Ok. Thanks Mike. Because I assume that'd be yet another (easy?) active attack vector here...

", "time": "2023-11-10T09:10:32Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Martin Duke re DoS I think you only said that having another box (with state) on the path means you have another attack point. I guess that is always true.

", "time": "2023-11-10T09:11:32Z"}, {"author": "Mike Bishop", "text": "

Probably -- ECN mark a lot of forwarded-mode packets and look to see which ones are marked on the other side. But that's equivalent to injecting/dropping traffic to look for load changes.

", "time": "2023-11-10T09:11:54Z"}, {"author": "Nick Banks", "text": "

Yeah. Perhaps a little easier because you also have the payload on both sides to help correlation (compared to dropping).

", "time": "2023-11-10T09:12:59Z"}, {"author": "Dennis Jackson", "text": "

Non comprehensive overview of
\nhttps://eprint.iacr.org/2018/162.pdf
\nhttps://www.cs.ucdavis.edu/~rogaway/aez/rae.pdf
\nhttps://eprint.iacr.org/2017/239.pdf

", "time": "2023-11-10T09:16:35Z"}, {"author": "Antoine Fressancourt", "text": "

Thanks !

", "time": "2023-11-10T09:17:34Z"}, {"author": "Madhan Kanagarathinam", "text": "

Just a suggestion .. for connected UDP --> it would be good to explore Unreliable QUIC together .. again not on the encryption-front .. from the latency perspective ..

", "time": "2023-11-10T09:17:44Z"}, {"author": "Antoine Fressancourt", "text": "

I didn't know the first reference, I am more used to the work of Lysinskaia et al. or Kuhne et al., but I will read it carefully

", "time": "2023-11-10T09:19:46Z"}, {"author": "Dennis Jackson", "text": "

These are just the tabs I had open.

", "time": "2023-11-10T09:20:59Z"}, {"author": "Mike Bishop", "text": "

If you're sharing VIPs, you should be sharing CID state as well, no?

", "time": "2023-11-10T09:23:28Z"}, {"author": "Alex Chernyakhovsky", "text": "

Not necessarily if you're sharding port space

", "time": "2023-11-10T09:25:07Z"}, {"author": "Mike Bishop", "text": "

True, I guess we're actually looking at the outbound side, where they'll have potentially separate IPs, separate port ranges, etc.

", "time": "2023-11-10T09:28:12Z"}, {"author": "Kazuho Oku", "text": "

Isn't adding TTL a privacy concern?

", "time": "2023-11-10T09:30:49Z"}, {"author": "Antoine Fressancourt", "text": "

@Kazuho at least it is a signal that can be used to correlate incoming and outgoing packets

", "time": "2023-11-10T09:31:56Z"}, {"author": "Alex Chernyakhovsky", "text": "

How so? In that you get a colleratable bit?

", "time": "2023-11-10T09:32:03Z"}, {"author": "Antoine Fressancourt", "text": "

@Alex yes, incoming packets with a given TTL correspond to outgoing packets with a lower TTL

", "time": "2023-11-10T09:32:59Z"}, {"author": "Kazuho Oku", "text": "

Yeah, in the scramble mode we are trying to change every bit that's being forwarded, and then we are arguing to have a field that is decremented by one

", "time": "2023-11-10T09:32:59Z"}, {"author": "Antoine Fressancourt", "text": "

@Kazuho maybe we need a scrambled TTL

", "time": "2023-11-10T09:33:56Z"}, {"author": "Eric Kinnear", "text": "

Closing the queue momentarily, join now if you want to comment

", "time": "2023-11-10T09:34:22Z"}, {"author": "Mike Bishop", "text": "

Seems like if the proxy is the one receiving and routing the packet, the proxy should be the one selecting the CID.

", "time": "2023-11-10T09:39:10Z"}, {"author": "Kazuho Oku", "text": "

Yeah, so all nodes need to agree on how TTL is going to be scrambled, or each endpoint needs to have it's own TTL field appended (but the latter changes the size of the datagrams as they traverse between the hops).

", "time": "2023-11-10T09:39:18Z"}, {"author": "Antoine Fressancourt", "text": "

referring to the first presentation, if the TTL observer is not a neighbouring proxy of the proxy on which the attack is done, then the scramble mode designed by Ben Schwartz does the job, and the TTL can be among scrambled data

", "time": "2023-11-10T09:41:45Z"}, {"author": "Mike Bishop", "text": "

Antoine, doesn't it merely need to know how many hops it is from the proxy?

", "time": "2023-11-10T09:42:27Z"}, {"author": "Jonathan Lennox", "text": "

This is an IP-layer field so IP routers will be decrementing it...the router hop count isn't necessarily stable.

", "time": "2023-11-10T09:43:28Z"}, {"author": "Antoine Fressancourt", "text": "

If we implement this in userland, I would assume that the TTL is specific to the QUIC layer, and not aligned with IP layer TTL

", "time": "2023-11-10T09:43:51Z"}, {"author": "Antoine Fressancourt", "text": "

But may well be wrong

", "time": "2023-11-10T09:44:06Z"}, {"author": "Eric Orth", "text": "

For the HTTPS DNS record naming bikeshed, somebody set up and sent a poll link to the list, and we used that to end the debate.

", "time": "2023-11-10T09:44:10Z"}, {"author": "Peter Thatcher", "text": "

Naming ideas: \"connect-udp-many\" or \"connect-udp-multi\"

", "time": "2023-11-10T09:47:40Z"}, {"author": "Alex Chernyakhovsky", "text": "

connect-protocol-octopus

", "time": "2023-11-10T09:49:29Z"}, {"author": "Mike Bishop", "text": "

Re: proxy changing ports on you mid-stream -- that's actually not awful for vanilla CONNECT-UDP, since that's just a NAT rebinding. For a listen target, you need stability.

", "time": "2023-11-10T09:50:23Z"}, {"author": "Ted Hardie", "text": "

I need to step out a moment; if someone could take over the doc, I'd appreciate it.

", "time": "2023-11-10T09:52:54Z"}, {"author": "altanai", "text": "

Is this beginning to sound like an ACL ?

", "time": "2023-11-10T09:53:42Z"}, {"author": "Peter Thatcher", "text": "

Well, In the TURN world, it's called \"CreatePermission\"

", "time": "2023-11-10T09:55:51Z"}, {"author": "Peter Thatcher", "text": "

(https://datatracker.ietf.org/doc/html/rfc5766#section-9.1)

", "time": "2023-11-10T09:56:13Z"}, {"author": "Jonathan Lennox", "text": "

Well, TURN starts from the assumption of allow-none and then permissions are only added with permissions or sending.

", "time": "2023-11-10T09:57:01Z"}, {"author": "Peter Thatcher", "text": "

I was going to say to change it to SetPermission, and let the default also be set, but I think that's what they just came up with at the mic.

", "time": "2023-11-10T10:00:58Z"}, {"author": "Peter Thatcher", "text": "

BTW, some TURN impls do start with allow-all and don't do the whole permission thing :).

", "time": "2023-11-10T10:01:44Z"}, {"author": "Jonathan Lennox", "text": "

The proposal for QUIC NAT traversal in the QUIC WG this week does require open-listen in order to work, unlike how ICE works.

", "time": "2023-11-10T10:02:15Z"}, {"author": "Peter Thatcher", "text": "

I don't think that proposal is fleshed out enough to consider constraining anything here. To be more specific, I don't think any p2p QUIC design should require anything more than what ICE needs.

", "time": "2023-11-10T10:03:38Z"}, {"author": "altanai", "text": "

+1 @Peter Thatcher

", "time": "2023-11-10T10:04:06Z"}, {"author": "Peter Thatcher", "text": "

Also BTW, I love that this work is continuing to be part of MASQUE because it makes basically makes it a better/modern version of TURN.

", "time": "2023-11-10T10:04:53Z"}, {"author": "Jonathan Lennox", "text": "

There's a tradeoff between requiring open-listen by the side doing the server role, and requiring candidate addresses to be sent by both sides. The proposal in QUIC requires the first in order to avoid the second. (I'm not sure if that's the right tradeoff.)

", "time": "2023-11-10T10:04:55Z"}, {"author": "Jonathan Lennox", "text": "

BTW is there an intention to allow connect-udp-listen and forwarded mode to work together? Are there any complexities there?

", "time": "2023-11-10T10:06:36Z"}, {"author": "Peter Thatcher", "text": "

On the topic of using it for p2p QUIC or a QUIC version of ICE: have we solve the issue of congestion control? For example, do we have a mechanism for the client to know the bandwidth available to the different remote hosts? Or are we disabling congestion control on the hop from the server out to the remote hosts and doing congestion control end-to-end? Sorry for not being up to date on the latest. Maybe that's what forwarded mode is?

", "time": "2023-11-10T10:07:27Z"}, {"author": "Eric Kinnear", "text": "

Martin: We're talking about the charter after this, but we already have interested expressed by the group to take on this work (of course pending specifics of adopted charter).

", "time": "2023-11-10T10:08:45Z"}, {"author": "Antoine Fressancourt", "text": "

can speakers make sure they talk close to the mic ? Alejandro is difficult to understand

", "time": "2023-11-10T10:10:38Z"}, {"author": "Antoine Fressancourt", "text": "

because of low sound

", "time": "2023-11-10T10:10:48Z"}, {"author": "Giles Heron", "text": "

if it's a \"patch cable\" isn't that really a pseudowire? We did all that in PWE3 20-something years ago (but over MPLS rather than QUIC)

", "time": "2023-11-10T10:13:36Z"}, {"author": "Peter Thatcher", "text": "

Answering my own question: it looks like forwarded mode is what you would want to have work with connect-udp-listen if using it for p2p QUIC (as a replacement for TURN), because that gives you one layer of congestion control. Hopefully that works with connect-udp-listen.

", "time": "2023-11-10T10:15:26Z"}, {"author": "Jonathan Lennox", "text": "

Having the peer assign an IP address makes sense, having the peer assign a MAC address doesn't seem to.

", "time": "2023-11-10T10:16:01Z"}, {"author": "Giles Heron", "text": "

yes - better to keep this away from MAC layer issues and make it purely a \"patch cable\"

", "time": "2023-11-10T10:16:52Z"}, {"author": "Dennis Jackson", "text": "

Note on the slides switchover bug: TIL the 'revoke slides' and 'take control' buttons are different and only one works if slides haven't yet been selected. 'take control' brings up 'all media slots are being used' which is not super helpful.

", "time": "2023-11-10T10:19:42Z"}, {"author": "Martin Duke", "text": "

This turns out to have been a good time slot to get a little more external feedback on these proposals

", "time": "2023-11-10T10:21:12Z"}, {"author": "Giles Heron", "text": "

happy to help (as an author of Ethernet PW over MPLS and Ethernet PW over L2TPv3)

", "time": "2023-11-10T10:25:32Z"}, {"author": "Jonathan Lennox", "text": "

I just hope no one wants to tunnel WiFi

", "time": "2023-11-10T10:25:39Z"}, {"author": "Giles Heron", "text": "

LOL

", "time": "2023-11-10T10:25:43Z"}, {"author": "Fran\u00e7ois Michel", "text": "

We should probably leave room for CONNECT-USB as well

", "time": "2023-11-10T10:26:23Z"}, {"author": "Giles Heron", "text": "

yup - and Bluetooth....

", "time": "2023-11-10T10:26:43Z"}, {"author": "Jonathan Lennox", "text": "

Which are the best RFCs to look at for the IETF state-of-the-art on this?

", "time": "2023-11-10T10:33:14Z"}, {"author": "Giles Heron", "text": "

RFC4448 is Ethernet PWE over MPLS

", "time": "2023-11-10T10:33:29Z"}, {"author": "Giles Heron", "text": "

RFC8159 is \"keyed IP tunnel\" for Ethernet PWE over L2TPv3

", "time": "2023-11-10T10:34:01Z"}, {"author": "Giles Heron", "text": "

RFC7348 is VXLAN

", "time": "2023-11-10T10:34:29Z"}, {"author": "altanai", "text": "

RFC 2784 Generic Routing Encapsulation (GRE) was also discussed

", "time": "2023-11-10T10:35:24Z"}]