**Session Date/Time:** 23 Jul 2024 22:30

# masque

## Summary

This MASQUE meeting covered several key topics, including Quick Aware Proxying, Proxying Listener UDP in HTTP (CONNECT-UDP-BIND), Ethernet Proxying in HTTP (CONNECT-ETHERNET), and DNS Configuration for MASQUE. Discussions centered on open issues, implementation status, potential adoption, and future directions for the MASQUE working group, with a focus on real-world deployment experiences.

## Key Discussion Points

*   **Quick Aware Proxying:**
    *   Discussion on handling preferred addresses and client migration. Consensus leaned towards clients initiating a separate CONNECT-UDP request for the target address.
    *   Limiting the number of concurrent registered connection IDs. The group favored a flow control mechanism similar to QUIC for managing connection ID registration to prevent resource exhaustion.
    *   The virtual connection ID should be at least as long as the actual client connection ID.

*   **Proxying Listener UDP in HTTP (CONNECT-UDP-BIND):**
    *   Address reuse for compression IDs is not allowed.
    *   Discussed the new capsule types including compression assigned and compression closed.
    *   The draft should indicate that releasing the resources is associated with the context ID, not the number itself.
    *   Recommendation for an editorial pass and subsequent working group last call after implementation and interoperability testing.

*   **Ethernet Proxying in HTTP (CONNECT-ETHERNET):**
    *   Discussion on VLAN tagging and client configuration, including the possibility of naming networks instead of numbering VLANs.
    *   Need for normative language specifying Ethernet frame (802.3 Ethernet 2 frames).
    *   Layer separation and congestion control: No protocol requirements but allowing for optional text in an appendix.

*   **DNS Configuration for MASQUE:**
    *   Not DNS over MASQUE, but rather DNS configuration when using CONNECT-IP tunnels.
    *   Using capsules to exchange DNS configuration information.
    *   Adoption of existing formats for DNS configuration (SVCB records).
    *   Discussion on bootstrapping problems and potentially different approaches to solving the problem, including JSON blobs and provisioning domains.
    *   Security considerations regarding DNS servers reachable over the tunnel, particularly for traditional DNS 53.
    *   Clarification needed to define how narrowly this applies to Connect IP.

*   **Future Directions for MASQUE:**
    *   Discussion about real-world deployment experiences, scaling, performance, and challenges encountered.
    *   Tooling, nested congestion control, and the possibility of adopting extensions to address real-world problems.
    *   Nested congestion control needs more research and better tooling.

## Decisions and Action Items

*   **Quick Aware Proxying:**
    *   Authors to update the draft to reflect the decision on preferred address handling.
    *   Eric Rosenberg to add flow control logic similar to QUIC for managing connection IDs.
    *   Authors to change "should" to "must" for VCID length requirement.
*   **Proxying Listener UDP in HTTP (CONNECT-UDP-BIND):**
    *   Editors to perform an editorial pass on the document.
    *   Implement and test the latest changes.
    *   Schedule interop testing between implementations.
*   **Ethernet Proxying in HTTP (CONNECT-ETHERNET):**
    *   Authors to add normative language specifying Ethernet frame.
*   **DNS Configuration for MASQUE:**
    *   Authors to clarify the scope of the document to focus on VPN use cases of CONNECT-IP.
    *   Authors to convert DNS configuration to use SVCB record format.
    *   Authors to clarify the DNS configuration is only accessible through the tunnel.
*   **MASQUE Working Group:**
    *   Dennis and Eric to coordinate presentations on real-world deployment experiences.
    *   Check charter to ensure DNS configuration is in scope.

## Next Steps

*   Authors of each draft will work on addressing the open issues and incorporating feedback from the meeting.
*   CONNECT-UDP-BIND implementations will be completed, followed by interoperability testing.
*   The AD will review the charter and comment.
*   The WG will solicit deployment experience presentations for upcoming meetings.