From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: masque@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Multiplexed Application Substrate over QUIC Encryption (masque)
The Multiplexed Application Substrate over QUIC Encryption (masque) WG in the
Web and Internet Transport of the IETF is undergoing rechartering. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2024-03-11.
Multiplexed Application Substrate over QUIC Encryption (masque)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Eric Kinnear <ekinnear@apple.com>
Dennis Jackson <ietf@dennis-jackson.uk>
Assigned Area Director:
Martin Duke <martin.h.duke@gmail.com>
Mailing list:
Address: masque@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/masque
Archive: https://mailarchive.ietf.org/arch/browse/masque/
Group page: https://datatracker.ietf.org/group/masque/
Charter: https://datatracker.ietf.org/doc/charter-ietf-masque/
Many network topologies lead to situations where transport protocol proxying
is beneficial. For example, proxying enables endpoints to communicate when
end-to-end connectivity is not possible or to apply additional encryption
where desirable (such as a VPN). Proxying can also improve client privacy,
e.g., by hiding a client's IP address from a target server. Proxying
technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own
shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT
is currently limited to TCP.
The primary goal of this working group is to develop mechanism(s) that allow
configuring and concurrently running multiple proxied stream- and
datagram-based flows inside an HTTP connection. The group has specified
CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this
functionality. MASQUE leverages the HTTP request/response semantics,
multiplexes flows over streams, uses a unified congestion controller,
encrypts flow metadata, and enables unreliable delivery suitable for UDP and
IP-based applications.
The MASQUE working group will now develop HTTP extensions, which might be
specific to the HTTP version, to the core client-initiated CONNECT-UDP and
CONNECT-IP functionality. Services that a proxy initiates without any prompt
from a client are out of scope.
Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps
to make it easier to support new use cases or accommodate changes in the
environment in which these protocols are deployed. The initial set of
extensions will be in support of UDP listening, CONNECT-UDP proxying
optimizations when the UDP traffic is QUIC, and tunneling of Ethernet
packets. Additional extensions that provide missing functionality, improve
performance, or otherwise ease deployability for use cases may be adopted
where there are multiple implementation and/or deployment proponents. The
intended status is Standards Track, but the WG may downgrade if it believes
that is appropriate for the ultimate document maturity level.
Extensions to HTTP Datagrams will be coordinated with HTTPBIS. Extensions
that solely relate to generic proxying functionality, and are not specific to
the core MASQUE documents, are out of scope.
Specifying proxy server discovery mechanisms is out of scope. New congestion
control and loss recovery algorithms are also out of scope. However, the
working group will consider implications of tunneling protocols with
congestion control and loss recovery over MASQUE proxies, and may issue
recommendations accordingly.
The working group will consider how the protocols it defines might operate
over versions of HTTP that use TCP rather than QUIC, for use when QUIC is
unavailable. This might include defining alternative extensions specifically
for use in these HTTP versions.
IP multicast is out of scope. Designs need not explicitly preclude multicast,
but they will not focus on multicast-specific features.
Impacts on address migration, NAT rebinding, and future multipath mechanisms
of QUIC are not anticipated. However, the working group should document these
impacts, or those of any other QUIC developments, if they arise.
The group will coordinate closely with other working groups responsible for
maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It
will also coordinate closely with ICCRG and CCWG on congestion control and
loss recovery considerations, and intarea for IP Proxying and Ethernet
tunneling. Finally, it will coordinate with IEEE 802.3 to make sure Ethernet
concepts are correctly represented.
MASQUE is not intended to be a long-lived working group.
Milestones:
- Submit an extension for UDP listeners
- Submit an extension for QUIC-aware proxying
- Submit an extension for Ethernet over MASQUE
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
masque-chairs@ietf.org,
masque@ietf.org
Subject: WG Action: Rechartered Multiplexed Application Substrate over QUIC Encryption (masque)
The Multiplexed Application Substrate over QUIC Encryption (masque) WG in the
Web and Internet Transport of the IETF has been rechartered. For additional
information, please contact the Area Directors or the WG Chairs.
Multiplexed Application Substrate over QUIC Encryption (masque)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Eric Kinnear <ekinnear@apple.com>
Dennis Jackson <ietf@dennis-jackson.uk>
Assigned Area Director:
Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
Web and Internet Transport Directors:
Francesca Palombini <francesca.palombini@ericsson.com>
Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
Mailing list:
Address: masque@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/masque
Archive: https://mailarchive.ietf.org/arch/browse/masque/
Group page: https://datatracker.ietf.org/group/masque/
Charter: https://datatracker.ietf.org/doc/charter-ietf-masque/
Many network topologies lead to situations where transport protocol proxying
is beneficial. For example, proxying enables endpoints to communicate when
end-to-end connectivity is not possible or to apply additional encryption
where desirable (such as a VPN). Proxying can also improve client privacy,
e.g., by hiding a client's IP address from a target server. Proxying
technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own
shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT
is currently limited to TCP.
The primary goal of this working group is to develop mechanism(s) that allow
configuring and concurrently running multiple proxied stream- and
datagram-based flows inside an HTTP connection. The group has specified
CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this
functionality. MASQUE leverages the HTTP request/response semantics,
multiplexes flows over streams, uses a unified congestion controller,
encrypts flow metadata, and enables unreliable delivery suitable for UDP and
IP-based applications.
The MASQUE working group will now develop HTTP extensions, which might be
specific to the HTTP version, to the core client-initiated CONNECT-UDP and
CONNECT-IP functionality. Services that a proxy initiates without any prompt
from a client are out of scope.
Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps
to make it easier to support new use cases or accommodate changes in the
environment in which these protocols are deployed. The initial set of
extensions will be in support of UDP listening, CONNECT-UDP proxying
optimizations when the UDP traffic is QUIC, and tunneling of Ethernet
packets. Additional extensions that provide missing functionality, improve
performance, or otherwise ease deployability for use cases may be adopted
where there are multiple implementation and/or deployment proponents. The
intended status is Standards Track, but the WG may downgrade if it believes
that is appropriate for the ultimate document maturity level.
Extensions to HTTP Datagrams will be coordinated with HTTPBIS. Extensions
that solely relate to generic proxying functionality, and are not specific to
the core MASQUE documents, are out of scope.
Specifying proxy server discovery mechanisms is out of scope. New congestion
control and loss recovery algorithms are also out of scope. However, the
working group will consider implications of tunneling protocols with
congestion control and loss recovery over MASQUE proxies, and may issue
recommendations accordingly.
The working group will consider how the protocols it defines might operate
over versions of HTTP that use TCP rather than QUIC, for use when QUIC is
unavailable. This might include defining alternative extensions specifically
for use in these HTTP versions.
IP multicast is out of scope. Designs need not explicitly preclude multicast,
but they will not focus on multicast-specific features.
Impacts on address migration, NAT rebinding, and future multipath mechanisms
of QUIC are not anticipated. However, the working group should document these
impacts, or those of any other QUIC developments, if they arise.
The group will coordinate closely with other working groups responsible for
maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It
will also coordinate closely with ICCRG and CCWG on congestion control and
loss recovery considerations, and intarea for IP Proxying and Ethernet
tunneling. Finally, it will coordinate with IEEE 802.3 to make sure Ethernet
concepts are correctly represented.
MASQUE is not intended to be a long-lived working group.
Milestones:
- Submit an extension for UDP listeners
- Submit an extension for QUIC-aware proxying
- Submit an extension for Ethernet over MASQUE