Re: [Masque] WGLC for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

[Mark Nottingham <[e-mail]>]

Hello,

This document seems to be asking for one or more HTTP extensions, but is expressed almost entirely in terms of IP. That's not terribly helpful to readers; what's needed is a mapping between IP and HTTP (in the direction opposite to that defined by RFC7230 and RFC7540!) to guide expectations. Some suggested edits:

OLD:
'There is interest among MASQUE working group participants in designing a protocol that can proxy IP traffic over HTTP. This document describes the set of requirements for such a protocol.'
NEW:
'MASQUE working group participants are interested in extending HTTP to allow it to tunnel IP traffic. This document describes the relevant requirements.'

OLD:
'This document describes the set of requirements for a protocol that can proxy IP traffic over HTTP.'
NEW:
'This document describes the set of requirements for extending HTTP to tunnel IP traffic.'

QUESTION:
'The server will have the ability to accept or deny the client's request.'  <-- which server? Any server along the request chain, or the origin server? next hop?

QUESTION:
'The Data Transports MUST be able to take IP datagrams input on one side and egress them unmodified in their entirety on the other side,' <-- are these sides the user agent and the origin server, or something else? Similar questions about 'client' and 'server' in subsequent text.

OLD:
'The IP proxying protocol discussed in this document will run over HTTP.'
NEW:
'The requirements discussed in this document will be met by the definition of HTTP/2 extension(s), HTTP/3 extension(s), and possibly one or more HTTP semantic extensions.'

Along those lines, it'd probably be helpful to add a note that if HTTP semantic extensions are defined, they are by nature usable in all versions of HTTP, although the WG might choose not to define their operation in a given protocol version.

Additionally, wherever 'protocol' is used, 'HTTP extension(s)' should be substituted. Likewise, wherever 'proxy' is used, 'tunnel' should be substituted (see <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#intermediaries>).

Finally, I don't see anywhere where it's explicitly said that after these extensions are used, the connection still needs to be usable for HTTP traffic. That seems like something that's important to establish one way or another (I have my preferences here, of course).

Cheers,


> On 27 May 2021, at 12:33 am, Christopher Wood <[e-mail]> wrote:
> 
> This email starts the working group last call for "Requirements for a MASQUE Protocol to Proxy IP Traffic", located here:
> 
>    https://datatracker.ietf.org/doc/draft-ietf-masque-ip-proxy-reqs/
> 
> This last call serves to solidify requirements for subsequent work on CONNECT-IP solutions, as discussed in [1].
> 
> Please review the document and send your comments to the list by June 11.
> 
> Note the the GitHub repository for this draft can be found here: 
> 
>    https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs
> 
> Thanks,
> Chris and Eric
> 
> [1] https://mailarchive.ietf.org/arch/msg/masque/LXObvy1DDuxLs-3dndyNKY0W4Gs/
> 
> -- 
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque

--
Mark Nottingham   https://www.mnot.net/