## MASQUE IETF 118, Monday II Session (1300-1500)   {#masque-ietf-118-monday-ii-session-1300-1500}

(6 Nov 2023)

### Administrivia (5 minutes) (Dennis in room, Eric remote)   {#administrivia-5-minutes-dennis-in-room-eric-remote}

    Blue sheets / scribe selection / NOTE WELL
    Agenda revision

Eric welcomes Dennis as new chair and thanks Chris Wood for his service.
David Schinazi then reminisced about Chris's service throughout the
pandemic and the working group's early years. He recognized Chris's work
in getting the three main documents published. David led a round of
applause for Chris and then one welcoming Dennis.

Eric then recognized the publication of the current document set.

### Working Group Documents (90 minutes)   {#working-group-documents-90-minutes}

#### QUIC-Aware Proxying Using HTTP - Tommy Pauly, 30 minutes   {#quic-aware-proxying-using-http---tommy-pauly-30-minutes}

https://datatracker.ietf.org/meeting/118/materials/slides-118-masque-quic-aware-design-team/

https://datatracker.ietf.org/meeting/118/materials/slides-118-masque-quic-proxy-loops

Tommy Pauly then began the presentation of the design team's thoughts on
MASQUE-aware connect UDP Encryption; see the slides linked above. The
scope here was the "forwarded" proxy mode versus the standard "tunneled"
mode. The executive summary was that they analyzed passive and active
attacks, are proposing a re-encryption model for forwarding, and are
proposing a re-encryption called "scramble" which protects against
byte-matching attacks.

Threat model: attacker's goal is to violate CONNECT-UDP's privacy
properties and learn which targets are being accessed. Slide 6 has a
description of the attacker categories. Common attacks include packet
metadata observation and traffic correlation attacks using timing,
inter-packet arrival, or packet size differences. Slide 9 presents the
passive attacks.

**Alex Chernyakhovsky** asks why RFC 9298 would be vulnerable to timing
and mapping attacks, given the possibility of coalescing; the naive
implementation would be vulnerable. Tommy agrees that this represents
the naive implementation risk. You must do something else (like
coalescing, chaff, or padding) to get past the risk. These are not core
to the RFC methods. Alex agrees with the yes/no checkboxes, but that it
would be more useful to have a shades of gray analysis and a comparison
of the effort needed to apply mitigation with the different approaches.
Tommy agrees that this would be useful and that there could be
discussion of how to mitigate in tunneled mode. Those may or may not be
the same as forwarded mode. Alex believes that more effort would be
required for forwarded mode and this implies that we should spend
efforts. **Mirja Kühlewind** interjects that the design team agreed not
to do that analysis during its efforts, and that this separate analysis
and might need a different design team. The attacks against TOR and
similar system demonstrate that this is not simple to mitigate.

**Martin Duke** then started a discussion about the continuum of
linkability and called attention to the impact of number of clients.
Tommy agreed that a good bit needed to be written here. **Cullen
Jennings** then noted that one of the few common responses to this is
constant bit-rate protocol behavior. Cullen then asked whether it would
be valuable to indicate how easy it would be to achieve constant bit
rate with this set of mechanics. Tommy agreed and noted that some
protocol mechanics negotating this would be needed. **Mirja Kühlewind**
and **David Schinazi** then commented on the relation between the
attacks and mechanics needed for Connect-UDP. Tommy asked that we hold
that for later slides. **Martin Duke** then asked for a diff between
proxied mode and tunneled mode. Tommy noted that they had talked about a
proposal that added random padding. Mirja Kühlewind said that she didn't
want to design at the mic but that padding with UDP options is easy.
**Gorry Fairhurst** said also crazy.

Tommy then sketched out the "Scramble" encryption mode. It should work
for existing QUIC versions.

Tommy then moved onto the active attacks (slide 12). Question to the
group: should we handle active attacks? While the set of attacks is
different, there are attacks possible on both sides of the proxy for
both tunneled and forwarded mode. If there are deployments in which
active attackers are able to succeed for only one type, that might be an
indicator of which mode to use. **Alex Chernyakhovsky** then suggested
that this also compare to the case without MASQUE; it otherwise looks
very bleak, but there are gains made by using either mode. **Martin
Duke** raised two points. The authentication tag is pointless because
you cannot impose requirements on the target. He also pointed out that
this is different from bare QUIC in that the proxy will have congestion
and flow control limits; this is unique to having MASQUE vs. direct to
target (though similar in both modes).

Tommy ends with a review of what Scramble protects against. He notes
that one of the most powerful attackers here is the next hop attacker
who can correlate with or without forwarding mode.

**Tianji Jiang** asks if there has been any consideration of a light
weight protocol for controlled environments (e.g. controlled 5g domain
up until the egress). Has there been any consideration of this type of
scenario? Tommy notes that the overall point of the QUIC-aware mode is
to lower the amount of processing done at the proxy, so that point of
QUIC-aware is to be lightweight, while still protecting against the
attacks which Scramble handles (correlation attacks and observation).
For the use case here, the client and proxy could agree not to use this,
as either there is no attacker or no gain. **Dennis Jackson** takes off
his chair hat and makes a comment that in the TOR community there is
agreement that a global attacker is very difficult to guard against, but
that there is a lot of nuance in the analysis of the attacker sitting
between two nodes. There is also a lot of academic work on this set of
attacks and though little of that has been shipped, might be worthwhile
to analyze those. Tommy agreed, but said that instead a protocol
mechanism that allowed this set of proposals to be slotted in. **Mirja
Kühlewind** pointed out that it would be useful to have a way for the
parties to identify the specific attacks for a particular deployment, so
that you could then slot in the right thing. **Antoine Fressancourt**
then asked about a specific reference for the TOR work. Pasted into
Zulip by Dennis.

**Martin Duke** then took over to discuss the quic-proxy loops. The
first class of attacks was amplification via looping; he's not going to
focus on that, but happy to chat in the hallways. Instead, he wants to
discuss an attack that he discovered during the course of that analysis.
He then presented a chain of proxies and discussed the client
communication to set up a specific chain. (Note that the slide for this
has arrows which are backward for the direction of communication). He
then showed what a malicious client could do with the same facilities.
The naive version of this attack relies on the proxies using only the
CID, and that basic mitigation is to use the IP sources as well.
However, if the two being conflated share a VIP, however, it will loop
infinitely.

**Tommy Pauly** then asks whether this relies on their being two
different proxies available behind the same vip. Martin agrees. Tommy
asks how the client determines that this will occur and how the client
will address the two separate proxies. They have to share a socket. As
far as anyone knows p1 and p2 are the same, but they are behind a load
balancer. David notes that this isn't a case of "doctor it hurts when I
poke my eye". In his deployment, there is some coordination among
devices behind a VIP, but avoiding this would require sharing every CID,
and this is impractical. Lars Eggert notes that this is retreading very
well trodden ground. **Ted Hardy** points out that there also well-known
mitigations, starting with decrementing TTLs and going on. **Mirja
Kühlewind** then asks for a clarification on the likelihood of the
attack and Martin notes that it will definitely some deployments (e.g.
Google, as David Schinazi pointed out) and that it will be generally an
issue if the load balancer has poor entropy.

Martin then presenting some "non-remedies". **David Schinazi** pointed
out that the naive way of doing this was to do it all in user space and
read from one side and copy to the other side; if you do it not naively,
you can copy over the IP TTL and use that, so you don't even need to add
a new decrementing TTL.

Martin then presenting other potential remedies. He asks what the least
painful, least compromising way to do this would be. **Tommy Pauly**
answered some flavor of TTL would be his preference. He and Martin then
discussed the interaction required between client and proxy before
tunneled mode can be invoked. **Tommy Pauly** came down on TTL and
prefer one socket. **Ted Hardie** agreed. **Kazuho Oku** asked whether
there was a privacy concern in decrementing the TTL.

#### Proxying Listener UDP in HTTP - Abhijit Singh, 30 minutes   {#proxying-listener-udp-in-http---abhijit-singh-30-minutes}

https://datatracker.ietf.org/meeting/118/materials/slides-118-masque-connect-udp-listener-slides/

Abhijit describes the creation of the connect UDP listen field. Question
from slide 4: do we want to validate the source packets? He also asks
whether the name of the document should change to better reflect the
goals of the draft (e.g. connect-udp-binding-extension). **Alex
Chernyakhovsky** expresses confusion about why you would want to rename
this, especially to binding extension, since that generates confusion on
the functionality. **David Schinazi** indicated that he thought this was
a bikeshedding. He asked if it was possible to do a quick show of hands
with the tool, but there is no alternative-mode to the current tool.
**Tommy Pauly** noted that he didn't think this was time sensitive and
that it would be better to move this to the issue. He did think it would
be better to have parallelism between connect UDP and connect TCP.
Pointer given in the slides to the issue, so discussion can continue
there.

Slide 7: allow proxy to send public IP and port to client. Response
header which gives proxy public address(es). Query--do we need to be
able to allow mid-stream change. **Tommy Pauly** likes the general idea
and maybe it could go to proxy status header as a parameter (rather than
a new header). He advises against mid-stream changes. The queue builds
rapidly, and **David Schinazi** leaps in to clarify that this was not
for mulitple ports, but multiple IP addresses (e.g. different address
families); in general, there is a need for some determinism (so a whole
/64 would be hard to manage, where a /128 v6 would be easy to manage).
**Magnus Westerlund** wanted to ask why you would want to provide
multiple addresses; if you need more than one, do more than one request.
Magnus says it is best to keep this very simple, and it may be better to
require that be requested by the client. He does agree that it is useful
to return the IP address, as otherwise it may need to do STUN. **Tianji
Jiang** says that there are real requirements from the 3gpp side
particularly how the proxy would disclose to the client, so this a good
idea. **Tommy Jensen** agrees that doing one rather than prefixes is the
right choice, but the draft should probably point to that and discuss
why it is not being done here.

Slide 8: allow restricting accessible IP. Proposition: allow all target
traffic. He feels like it might be a different extension. **Jonathan
Lennox** worries that MASQUE proxies of this type would be tempting for
griefers, so he believes these restrictions would be potentially useful.

Tommy Pauly: you have a future slide about compression, maybe we use
that mechanism to allow blocklisting IPs

Abhi: That sounds good

Mike Bishop: it would be nice to peal off a separate socket but that's
tricky. We'll want some level of solution to prevent this issue

David Schinazi: Wonders whether there is a going to be a meaningful DoS
attack here compared to just sending lots of traffic towards a client.

Tommy Pauly: Suggests that after having established a compression
context it is possible to close the arbitrary forwarding.

David Schinazi: Don't want to design at the mic, but I think we landed
on good design.

Gurtej: notes that WebRTC currently does this with STUN and that its
mode which has two step process. Do you have other use cases? Answer:
yes, possibly a server on the port. Okay, this is opening up a new
attack.

Slide 9: compress away IP and port? Proposal is to use context ID. PR is
linked in the slides, comment there since we are low on time.

#### Proxying Ethernet in HTTP - Alejandro Sedeño, 30 minutes   {#proxying-ethernet-in-http---alejandro-sedeño-30-minutes}

https://datatracker.ietf.org/meeting/118/materials/slides-118-masque-connect-ethernet

Alejandro Sedeño presenting. The draft has been adopted, pending
successful recharter. Alejandro notes the limited scope (like a cable,
not a switch), with broadcast and multicast are out of scope. Slide 4
lists folks have indicated interest; invitation to discuss motivation
(either here or on list), in order to make that section of the draft
stronger. **Martin Duke** as AD uses the moment of silence to caution
people that this work is provisional on the recharter being adopted.
**Zaheduzzaman Sarker** notes that Nokia is interested with a 3GPP ATSS
use case. He also believes that this draft needs a very strong
motivation section to get it done. **Lars Eggert** asked if anyone has
asked IEEE 802 whether the scope is appropriate. Alejandro notes that
patch cable doesn't care what frame type it is, and that's the model.
**Zaheduzzaman Sarker** agrees that this should go to the coordination
call; **Martin Duke** notes that this why the recharter is being
done--to get formal review outside. **Gorry Fairhurst** notes that this
goes on in INT area all the time and that having an INT area AD
involved.

**Tommy Jensen** asks whether this should be limited to handle the
possibility of MAC spoofing; Alejandro notes that there are cases where
there may be more than one MAC on each side. **Alex Chernyakhovsky**
notes that there are analogies to the capabilities in use here, and that
there are specific security considerations based on which analogy we use
(MAC filtering, masquerading etc.). We need to keep an eye on what is
deployable as a minimal viable protocol with extension points for later
work. **Tommy Pauly** notes that some of these limitations are similar
to the discussions during CONNECT IP, and that we could adopt parallel
methods here. That would make the family of protocols here seem more
coherent. **Lars Eggert** reiterates that it is fine for us to define
this, but our IEEE 802 has to make the call about what we are doing is
still ethernet. **Yaroslav Rosomakho** suggests we discourage the use of
this for EVPN, which is unauthenticated. We should make clear it is note
designed for that, as it will otherwise be confusing.

Notes that there is an implementation in Google QUICHE, but that more or
needed.

**Magnus Westerlund** asks what we are doing about full basic Ethernet
frame size (1518 byte), so there is a potential MTU issue unless we have
a fragmentation method and reassembly. Alejandro says he has no plans
for that. **David Schinazi** notes that we have both datagram frames
(which have an MTU limitation) but we also have a datagram capsule
(which does not). So there is a way to send these via capsules when it
does not provide the right number of bytes. Magnus-I think the question
is are we maintaining Ethernet's assumption (side, ordering, and so on).
**Yaroslav Rosomakho** notes that this is not the first tunneling
technology and we can be inspired by others in this space and why. Gorry
-1 on that. **David Schinazi** returns to the mic to say that he doesn't
know what he doesn't know about ethernet; if the simple solution here is
to say that this is 802.1 MAC layer format transport, then that might
make things easier. If reducing the scope makes this less scary, okay.
**Lars Eggert:** you're asking to do a standard here, so you have to
actually match the expectations of those who have a way of carrying
frames. We will talk to 802, everyone agrees. **Ted Hardie** suggests
that we should not try to limit the scope in ways that will break the
expectations of those folks who will want to use this to replace a patch
cable.

Eric Kinnear puts up the charter update and agrees that we need to get
external eyeballs to review this; the current document also needs to be
extended to list which groups need to be liaised with. There was a
discussion of the formal review; the next step would be a topic to the
coordination call. It might be that there is a chance it will then need
a liaison. **Gorry Fairhurst** and **Lars Eggert** then suggested that
we need additional context before going to IEEE 802 in order to have a
sensible conversation. **David Schinazi** said that we have a good path
forward, asking to start a conversation rather than leaping to the end.
**Alex Chernyakhovsky** looked at some of the existing documents and he
wants to be sure that we are not moving the bar here away from where it
has been for other documents. Eric Kinnear noted that the point that
coordination is needed is well taken and we can move forward from here.
**Zaheduzzaman Sarker** then said we can go forward by sending a mail to
Russ to discuss how to have the coordination relationship go forward.
**Lars Eggert** then said he's not asking to moving forward; the
implications of some of the simple statements you read is actually
comprehensive support.

**Martin Duke** noted that he will sit on the charter update for a bit,
while we get the meetings that have to happen first done.

Thanks from the chairs--happy masquing and enjoy the last day of the
IETF.

### Other Individual Drafts (Remaining Time)   {#other-individual-drafts-remaining-time}