Subject: [Masque] Unified CONNECT-IP document

From: Tommy Pauly <[email-masked]>
Date: Thu, 21 Oct 2021 09:31:35 -0700

Hello MASQUE WG,

I’ve been working with the authors of the various CONNECT-IP protocol proposals (draft-cms-masque-connect-ip, draft-kuehlewind-masque-connect-ip) to write a shared document. We’ve just published the -00 version!

https://www.ietf.org/archive/id/draft-age-masque-connect-ip-00.html <https://www.ietf.org/archive/id/draft-age-masque-connect-ip-00.html>

We believe this represents the core functionality that various use cases need for IP proxying. It allows proxying of full IP packets, and focuses on defining options about assigning, routing, and filtering out the common fields in the IP protocol headers (source and destination addresses, IP version, IP protocol). Work on compressing, handling ICMP, etc, is left to future documents.

Please take a look at the document. It would be great to discuss this at IETF 112, and see if the WG thinks this can be adopted as our starting point.

Best,
Tommy

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-age-masque-connect-ip-00.txt
> Date: October 21, 2021 at 9:22:16 AM PDT
> To: Alex Chernyakhovsky <[email-masked]>, David Schinazi <[email-masked]>, Magnus Westerlund <[email-masked]>, Mirja Kuehlewind <[email-masked]>, Tommy Pauly <[email-masked]>
> 
> 
> A new version of I-D, draft-age-masque-connect-ip-00.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
> 
> Name:		draft-age-masque-connect-ip
> Revision:	00
> Title:		IP Proxying Support for HTTP
> Document date:	2021-10-21
> Group:		Individual Submission
> Pages:		20
> URL:            https://www.ietf.org/archive/id/draft-age-masque-connect-ip-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/
> Html:           https://www.ietf.org/archive/id/draft-age-masque-connect-ip-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-age-masque-connect-ip
> 
> 
> Abstract:
>   This document describes a method of proxying IP packets over HTTP.
>   This protocol is similar to CONNECT-UDP, but allows transmitting
>   arbitrary IP packets, without being limited to just TCP like CONNECT
>   or UDP like CONNECT-UDP.
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Oct 2021 10:52:10 -0700

Thank you for all your work editing this document, Tommy.
I'm personally very happy that we landed on a joint proposal that all of
the known CONNECT-IP enthusiasts are happy with.
I'd love to hear the WG's thoughts on this draft.

David

On Thu, Oct 21, 2021 at 9:31 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello MASQUE WG,
>
> I’ve been working with the authors of the various CONNECT-IP protocol
> proposals (draft-cms-masque-connect-ip, draft-kuehlewind-masque-connect-ip)
> to write a shared document. We’ve just published the -00 version!
>
> https://www.ietf.org/archive/id/draft-age-masque-connect-ip-00.html
>
> We believe this represents the core functionality that various use cases
> need for IP proxying. It allows proxying of full IP packets, and focuses on
> defining options about assigning, routing, and filtering out the common
> fields in the IP protocol headers (source and destination addresses, IP
> version, IP protocol). Work on compressing, handling ICMP, etc, is left to
> future documents.
>
> Please take a look at the document. It would be great to discuss this at
> IETF 112, and see if the WG thinks this can be adopted as our starting
> point.
>
> Best,
> Tommy
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-age-masque-connect-ip-00.txt*
> *Date: *October 21, 2021 at 9:22:16 AM PDT
> *To: *Alex Chernyakhovsky <[email-masked]>, David Schinazi <
> [email-masked]>, Magnus Westerlund <
> [email-masked]>, Mirja Kuehlewind <
> [email-masked]>, Tommy Pauly <[email-masked]>
>
>
> URL:
> https://www.ietf.org/archive/id/draft-age-masque-connect-ip-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-age-masque-connect-ip/
> Html:
> https://www.ietf.org/archive/id/draft-age-masque-connect-ip-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-age-masque-connect-ip
>
>
> Abstract:
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 21 Oct 2021 16:44:45 -0400

I like it!

Some minor notes:

After fighting with URI Templates for the past week or two, I'm less fond
of them than previously.  For example, they are specified to be unicode (in
unspecified representation), so any system for processing them needs to
consider unicode issues, even though this is almost always irrelevant.  In
DoH, I think they've mostly been more trouble than they're worth: despite
their enormous flexibility, all deployments that I'm aware of have just
tacked "{?dns}" onto the end of the URL.

I would consider specifying fixed query parameters and leaving it at that.
That would also allow a single URL to be used for CONNECT, CONNECT-UDP, and
CONNECT-IP, which seems valuable.

If URI templates are a must, I think we need some tweaks to harmonize
CONNECT-IP and CONNECT-UDP (e.g. "target" vs. "target_host").  A single
template could work for both!  You'll also probably want to copy RFC 8484's
prohibition on templating the origin.

> If the target is a hostname, the server is expected to perform DNS
resolution to determine which route(s) to advertise to the client.

This is fascinating, but perhaps underspecified.  I think the proxy SHOULD
return route advertisements for _all_ addresses for the target name (in all
families).  Then the client can implement racing and failover as
appropriate.  (Also, some clients have policies that depend on whether two
hostnames resolve to _overlapping_ RRSets, which requires them to learn all
the addresses.)

> The Start IP Address MUST be strictly lesser than the End IP Address.

I think this is an error.  It should be <=.

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Oct 2021 13:55:34 -0700

> I like it!

Thanks Ben! Responses inline.
David

Some minor notes:
> I would consider specifying fixed query parameters and leaving it at
> that.  That would also allow a single URL to be used for CONNECT,
> CONNECT-UDP, and CONNECT-IP, which seems valuable.
>

Our idea here was to align with CONNECT-UDP, but your points apply equally
there. I think our options for both CONNECT-IP and CONNECT-UDP are:
1) represent proxy via URI templates (what both drafts have today)
2) represent proxy via URL, and use explicit query parameters to convey
host/port/etc information
3) represent proxy via URL, and use HTTP headers to convey host/port/etc
information

Having recently implemented URI templates, I agree that there be dragons in
(1). Between (2) and (3), I think that (3) is easier to implement and
reason about personally.

> hostnames resolve to _overlapping_ RRSets, which requires them to learn all

I'm not sure I follow, can you elaborate?

> I think this is an error.  It should be <=.

Indeed, nice catch. I fixed it in the editor's copy.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 21 Oct 2021 17:04:48 -0400

On Thu, Oct 21, 2021 at 4:55 PM David Schinazi <[email-masked]>
wrote:
...

> I think our options for both CONNECT-IP and CONNECT-UDP are:
>
> Having recently implemented URI templates, I agree that there be dragons
> in (1). Between (2) and (3), I think that (3) is easier to implement and
> reason about personally.
>

That makes sense to me.  I don't have any strong preferences here; I just
wanted to raise the issue.

>> This is fascinating, but perhaps underspecified.  I think the proxy
>> SHOULD return route advertisements for _all_ addresses for the target name
>> (in all families).  Then the client can implement racing and failover as

Section 6.2 shows the proxy advertising a single IP address route for "
server.example.com".  Section 4.1 says "route(s)", implying that the proxy
might choose to advertise multiple routes to the target host, presumably
because DNS resolution returned multiple A/AAAA records.

I see the current text as an implicit "MAY return all the IP addresses",
and I'm suggesting an upgrade to SHOULD.

---

From: David Schinazi <[email-masked]>
Date: Thu, 21 Oct 2021 14:11:55 -0700

> wanted to raise the issue.

Can I ask you to also raise the issue on GitHub? I think it makes sense to
discuss this in the context of CONNECT-UDP at 112:
https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/new

> server.example.com".  Section 4.1 says "route(s)", implying that the
> proxy might choose to advertise multiple routes to the target host,
> presumably because DNS resolution returned multiple A/AAAA records.
>

That makes sense to me. Esteemed co-authors, any thoughts on this?

David

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 21 Oct 2021 14:33:16 -0700

> On Oct 21, 2021, at 2:11 PM, David Schinazi <[email-masked]> wrote:
> 
> 
> 
> On Thu, Oct 21, 2021 at 2:05 PM Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Thu, Oct 21, 2021 at 4:55 PM David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
> ... 
> 2) represent proxy via URL, and use explicit query parameters to convey host/port/etc information
> 3) represent proxy via URL, and use HTTP headers to convey host/port/etc information
>  
> Having recently implemented URI templates, I agree that there be dragons in (1). Between (2) and (3), I think that (3) is easier to implement and reason about personally.
> 
> That makes sense to me.  I don't have any strong preferences here; I just wanted to raise the issue.
> 
> Can I ask you to also raise the issue on GitHub? I think it makes sense to discuss this in the context of CONNECT-UDP at 112:
> https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/new <https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp/issues/new>
> 
> > If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client.
> 
> This is fascinating, but perhaps underspecified.  I think the proxy SHOULD return route advertisements for _all_ addresses for the target name (in all families).  Then the client can implement racing and failover as appropriate.  (Also, some clients have policies that depend on whether two hostnames resolve to _overlapping_ RRSets, which requires them to learn all the addresses.)
> 
> Section 6.2 shows the proxy advertising a single IP address route for "server.example.com <http://server.example.com/>".  Section 4.1 says "route(s)", implying that the proxy might choose to advertise multiple routes to the target host, presumably because DNS resolution returned multiple A/AAAA records.
> 
> I see the current text as an implicit "MAY return all the IP addresses", and I'm suggesting an upgrade to SHOULD.
> 

Yes, I agree that it SHOULD return all addresses. I filed this: https://github.com/tfpauly/draft-age-masque-connect-ip/issues/37

Thanks,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 25 Oct 2021 08:55:13 -0700

We pushed an -01 version with these corrections here:

 https://www.ietf.org/archive/id/draft-age-masque-connect-ip-01.html <https://www.ietf.org/archive/id/draft-age-masque-connect-ip-01.html>

Best,
Tommy

> On Oct 21, 2021, at 2:33 PM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> 
> 
>> On Oct 21, 2021, at 2:11 PM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> Yes, I agree that it SHOULD return all addresses. I filed this: https://github.com/tfpauly/draft-age-masque-connect-ip/issues/37 <https://github.com/tfpauly/draft-age-masque-connect-ip/issues/37>
> 
> Thanks,
> Tommy
>> 
>> David 
>> -- 
>> Masque mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>
> 
> -- 
> Masque mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/masque <https://www.ietf.org/mailman/listinfo/masque>