Liaison statement
Reply LS on XRM metadata exchange between 3GPP Core and an Application server

1. Description

NOTE: This reply LS is sent as a follow up and to replace a previous reply LS
on XRM metadata exchange between 3GPP Core and an Application server [5].
Comments from the mailing list were inadvertently omitted from the text and
attachment in the previous reply LS [5]. This reply LS includes the comments
from the mailing list as originally intended.

Thank you for the request entitled "LS on XRM metadata exchange between 3GPP
Core and an Application server" [1].

Whilst we appreciate your interest in the views of the MASQUE WG, for future
questions of this nature, we'd recommend writing via email to the MASQUE public
mailing list (masque@ietf.org [2]). Posts to the mailing list can directly
engage with working group participants and offer a convenient mechanism to
supply additional information in response to questions or comments, as is often
necessary to resolve technical questions such as those in your request.

The chairs of the MASQUE working group have interpreted the LS as a 'Request
for Comments' in line with the IETF's processes outlined in RFC 4053 3.2.2.2
[3]. We asked the working group to read and evaluate the details attached in
the Statement and solicited their opinions on the questions posed. You can find
those collected comments included at the bottom of this message and preserved
in full in the mailing list archive [4].

Thank you,
Dennis and Eric
(MASQUE WG Chairs)

2. Upcoming Meetings

IETF 122, 15 - 21 March 2025, Bangkok, TH
IETF 123, 19 -25 July 2025, Madrid, ES

3. References

[1] https://datatracker.ietf.org/liaison/1958/
[2] https://mailarchive.ietf.org/arch/browse/masque
[3] https://datatracker.ietf.org/doc/html/rfc4053#section-3.2.2.2
[4] https://mailarchive.ietf.org/arch/msg/masque/QFDTHi3YWHbJQLyqhkD8PVV0PkE/
[5] https://datatracker.ietf.org/liaison/1965/

4. Comments made on the mailing list:
--
I don't think the proposed architecture will work, nor would it be consistent
with IETF standards.  It would also be less efficient than other options
available to 3GPP. When processing QUIC packets without acting as a QUIC
endpoint, standards-compliant processing is limited to the invariants
documented in RFC 8999.  Nothing in that RFC promises that Connection ID
lengths will be fixed for the duration of a connection. In the proposed design,
the UPF decides whether each packet is tunneled or forwarded, and the UE is not
aware of which path was taken.  This prevents the UE from correctly
implementing Path MTU detection, as these different paths are likely to have
distinct MTUs. The proposal mentions defining a new Packet Transform that adds
metadata to each packet.  This indicates that "zero overhead" forwarding is not
a requirement. If only UDP flows are considered relevant, I would recommend
implementing the forwarding function using a trivial UDP forwarder such as
SOCKS5-UDP (RFC 1928).  This avoids any reliance on the details of QUIC,
removes the need to double-encrypt long-header packets, and prevents the issues
I've mentioned above. -- I tend to agree...  Anything like this is only likely
to add overheads, in the form of additional encapsulation bytes, additional
encryption effort, and additional delays.  Establishing a case for that
additional would require fairly extraordinary justification and should come
with a comparative analysis against alternatives (anything driven by endpoints
would be strong candidates). There also appears to be an overlap here between
the ideas that seem to be driving the request and the work in the newly-formed
SCONE working group. -- I would propose a reply somehow like this: Thanks for
reaching out to the MASQUE working group. We would like to note that technical
questions as contained in your liaison statement are best addressed directly to
the MASQUE mailing list [1]. All IETF mailing are open and anybody can post
questions like this. This will ensure the most rapid reply to you matters and
will provide you more detailed expert input. Further, note that inline with
RFC4052 [2] these kind of “informal channels” are the preferred way of
communication for the IETF generally. With respect to your questions, RFC9000
[3] and RFC9298 [4] specify the following: Connection IDs in the QUIC header
are not encrypted. A client that is aware of QUIC connection IDs can register
them using REGISTER_CLIENT_CID and REGISTER_TARGET_CID capsules as defined in
draft-ietf-masque-quic-proxy [5]. If a received UDP datagram does not contain a
registered QUIC connection ID, the UDP payload is sent in tunnelled mode. We
don’t have any further comments on the mechanism under specification by 3GPP.
As noted above, please feel free to reach out for any further questions
directly to the masque mailing list [1]. -- Agreed that a solution driven by
the endpoints would be preferable here, and that this seems like it needs to
coordinate with what SCONE will work on.