Skip to main content

Proxying IP in HTTP

Note: This ballot was opened for revision 08 and is now closed.

Erik Kline
Comment (2023-04-12 for -09) Sent
# Internet AD comments for draft-ietf-masque-connect-ip-09
CC @ekline

## Comments

### S4.7.1

* What are the expectations for receivers of non-max-length addresses if the
  IP address field is not the "zero-th" address of the IP prefix?
  For example:

      IP Address{2001:db8::1}
      IP Prefix Length{64}

  I assume the receiver should just "truncate" the IP address according to
  the given length and proceed as if it had received

      IP Address{2001:db8::}

  but that might just be me.  Another approach might be to say that this is
  an error (likely indicative of some poorly written originator) and the
  receiver should not be liberal in what it receives.

  Is this worth a few words?

### S4.7.1, S4.7.3

* I don't think it's worth trying to retrofit it in now, but I'll note that
  the absence of lifetime information in the ADDRESS_ASSIGN and the
  ROUTE_ADVERTISEMENT capsules means that graceful migration off of
  soon-to-be deprecated addresses is not possible.  This is perhaps less
  of a concern for IPv4, but if a proxy is allocating IPv6 addressing from
  a delegated prefix it will not be able to communicate an imminent
  deprecation, only the complete withdrawal.

### S7

* "IP forwarding tunnels described in this document ... do not necessarily
   have IPv6 link-local addresses"

  This makes the advice later to send ICMPv6 Echo Requests to ff02::1 rather
  suspect, IMHO.

  What signal is the sender looking for to detect any MTU issues?

  If it's some HTTP/QUIC-level signal then that should be documented because
  the choice to not have/require IPv6 link-local addresses within the tunnel
  would seem to mean that this technique, which MUST be supported, has no
  guarantee it can be relied upon to work even in the absence of MTU issues.

* "endpoints will decrement the IP Hop Count (or TTL) upon encapsulation"

  Does this mean that an endpoint receiving a packet within the tunnel from
  its peer that has a TTL/HopLimit of 255 is impossible?  If so, this should
  be added to the list of validation steps.  It would also act as a natural
  defense against IPv6 Neighbor Discovery messages that might (accidentally)
  leak out because RFC 4861 has many places where ND packets are required
  to have HopLimit==255.

* "If an endpoint does not send ROUTE_ADVERTISEMENT capsules, ..."

  What is the relevance of this subclause?  Shouldn't proxied ICMP errors be
  processed regardless?

### S12

* I think you could drop in a reference to many related points discussed in
  RFC 6169, probably around the open-ended closing paragraph.
Paul Wouters
Comment (2023-04-13 for -09) Sent
Thanks for a clear document. A few minor COMMENTS.

        If the "target" variable is a DNS name, the IP proxy MUST perform
        DNS resolution (to query the corresponding IPv4 and/or IPv6
        addresses via A and/or AAAA records)

Maybe change "to query" to "to obtain", because it might need to follow CNAMEs or other
queries, depending on its DNS validations scheme (eg using a forwarder or being a recursor,
using dns query chains, etc etc)

        The :method pseudo-header field SHALL be "CONNECT".

Why use SHALL instead of MUST for these? It seems MUST was used for these mandatory cases in the
document before this point. Please settle on one of these and use that throughout the document
to prevent people from thinking SHALL is not the same as MUST. This oddness happens throughout
the document.

        * IP Version of A MUST be less than or equal to IP Version of B

I don't think that restriction is technically needed, as two lists (one v4 and one v6) are built.

A "start IP and "end IP" could theoretically be a non-CIDR range. With IKEv2/IPsec, where this
is also possible, we have seen that often only CIDRs are implemented, leading to some interoperability
issues. I would recommend not allowing ranges to be non-CIDR.

        This document will request IANA to register 

I would rephrase this as "This document registers"...
Éric Vyncke
(was Discuss) Yes
Comment (2023-04-14 for -10) Sent
Thanks to the authors for the document and for addressing my previous DISCUSS points (see

Hoping that the COMMENTS points below will help to improve the published document (some PR are proposed in the above email thread but not yet merged as far as I can tell -- all of them are non-blocking).



# COMMENTS (non blocking)

## Waiting for Last Call PR ?  

May I suggest, next time, to wait until a revised I-D is submitted based on the IETF Last Call before balloting ? E.g., the PR based on the sec-dir review is not yet merged AFAIK.

## Section 3

`The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive` the fist part of the sentence appears as useless as the second part is more restrictive.

## Section 4.1

In `establishes an IP tunnel` should the other side of the tunnel specified ?

## Section 4.6

Should the text also be clear that the proxy should only proxy packets *from* the target to the client ?

## Section 4.7.1

Should the text specify what are the unused bits of the prefix when the prefix length is not the address length ? I.e., is 2001:db8:cafe:babe:f00d::/32 a valid prefix ?

## Section 4.7.3

In the previous sections, IP protocol could also be an IPv6 extension header. I.e., using "0" as a wildcard value prevents using it to signal Hop-by-hop extension header. Should 59 be used ? (even if no next header is only for IPv6)

BTW, I was about to ballot DISCUSS on this issue.

The reader (including myself and John Scudder per his ballot) would probably welcome more explanations to understand why the usual CIDR/prefix notation for routes is not used. I.e., some routers only use CIDR/prefix FIB entries and one start-end range could translate in a lot of CIDR/prefix routes in the router FIB.

## Section 7

Thanks for the text about link-local addresses and link-local multicast. But, then it raises the question about which IP address to use when replying to a link-local multicast ? I.e., can a global address be used in the absence of LLA ?

## Section 8

Please also add "hop-limit exceeded" in the non-exhaustive list of errors.

Should ICMP echo requests be mentioned ? (they are *not* error signaling but are quite useful).

## Section 9.1

In `Such VPN setups can be either full-tunnel or split-tunnel` please define (or add a reference) to full/split tunnel or simply do not mention those terms now as they are defined later.

`using a source address in its assigned prefix` while the client has been assigned a single /32 (i.e., the sentence is correct but could be confusing)

The legends of figures 15 and 16 use different templates ("capsule" in one case) is it on purpose ?

Should the split-tunnel example have two routes to exclude ?

## Section 12

RFC 5095 is probably not the best RFC about extension header security, there have been many others notably in V6OPS by Fernando Gont et al.

Should there be an informative reference to RFC 6169 (Security Concerns with IP Tunneling) ?

# NITS (non blocking / cosmetic)

## Section 4.1

s/via A and/or AAAA records/via A and/or AAAA resource records/ ?
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2023-04-06 for -09) Sent
# John Scudder, RTG AD, comments draft-ietf-masque-connect-ip-09
CC @jgscudder


Thanks for the admirably readable and thorough document, almost every point I mentally raised was answered within a few paragraphs of my thinking of it. A few residual questions are below.

### Section 4.7.2

"If the requested address was not assigned, the IP address SHALL be all-zero and the IP Prefix Length SHALL be the maximum length ( or ::/128) to indicate that no address was assigned. These address rejections SHOULD NOT be included in subsequent ADDRESS_ASSIGN capsules."

Regarding the SHOULD NOT, I assume that if the client asks again, the proxy is allowed to reject again. On thinking this through, though, I guess that's implicit because you require a unique Request ID per request, so by definition, a new request would elicit a distinct rejection (different Request ID echoed back). I leave it to you to decide if it's worth spending any extra words explicating this.

### Section 4.7.3, address ranges

I was mildly surprised that route advertisements use explicit address ranges rather than prefixes. This is unique in my experience (which is admittedly mostly with traditional routing protocols). It's fine, but I'm curious as to the reason for the choice?

### Section 13.2, expert review guidance missing

Expert review registries are supposed to provide guidance, see Section 4.5 of [IANA-POLICY]:

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry. [...]
I don't see where you provide this guidance?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

Murray Kucherawy
No Objection
Comment (2023-04-12 for -09) Not sent
Thanks to Mark Nottingham for the HTTPDIR review and Jean Mahoney for the ARTART review.
Roman Danyliw
No Objection
Comment (2023-04-12 for -09) Sent
Thank you to Nancy Cam-Winget for the SECDIR review.  I concur with the observation there identify or suggest some guidance on error codes.  I didn't see how the proposed PR in the discussion thread covered that.
Zaheduzzaman Sarker
No Objection
Comment (2023-04-13 for -09) Sent
Thanks for working on this specification. 

Thanks to Bob Briscoe for this TSVART review. Good to see that we are resolving the issues raised diligently and professionally. The work is in progress I think. This review and other reviews lead to some changes that to me would be nice to get some WG consensus call. I am sure my fellow AD and authors will do the right thing.

I have some comments for the newly added performance consideration section -

# It says -

     Bursty traffic can often lead to temporally-correlated packet losses; in turn, this can lead to suboptimal responses from congestion controllers in protocols running inside the tunnel.To avoid this, endpoints SHOULD strive to avoid increasing burstiness of IP traffic; they SHOULD NOT queue packets in order to increase batching beyond the minimal amount required to take advantage of hardware offloads.

  I believe the suboptimal response is also true for the outer QUIC connection as well. In that case, I am actually a bit confused by the term "endpoints", is this supposed to only point to the endpoint generating IP traffic or does it also refer to the tunneling endpoints? can we make that clear?

  The last sentence also creates the expectation that there is a minimal batching amount to take the advantage of the hardware offloading. Does this number easily available to the implementation of connect-ip? Have we done any investigation on that? If this number is not available to the implementation then it will be hard to follow the "SHOULD".

# It says -

      The outer HTTP connection MAY disable congestion control if it knows that the inner packets belong to congestion-controlled connections.

  How does it know? Also what are the implications of nested congestion control? yes, the tsv experts perhaps knows it by heart :-) but here we at least need some reasoning based on the implications of the nested congestion control for the advice and that is missing.

# It says -

    When the protocol running inside the tunnel uses loss recovery (e.g., [TCP] or [QUIC]), and the outer HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. 

  This could also happen when outer HTTP connection run over QUIC and QUIC Datagram is not used, right? or are we assuming that when the IP proxying is done it always uses QUIC datagram?
Martin Duke Former IESG member
Yes (for -08) Unknown

Andrew Alston Former IESG member
No Objection
No Objection (for -09) Not sent

Lars Eggert Former IESG member
No Objection
No Objection (2023-04-12 for -09) Sent
# GEN AD review of draft-ietf-masque-connect-ip-09

CC @larseggert

Thanks to Vijay Gurbani for the General Area Review Team (Gen-ART) review

## Comments

### "MASQUE", paragraph 1
                            Proxying IP in HTTP
Am a bit surprised this doc doesn't refer to the guidance in draft-ietf-intarea-tunnels?

### "Abstract", paragraph 1
     HTTP server that acts as an IP proxy.  This document updates RFC
In which way does it update RFC9298?

### Section 4.7.3, paragraph 5
     IP Address Range {
       IP Version (8),
       Start IP Address (32..128),
       End IP Address (32..128),
       IP Protocol (8),
Why do start-end and not start/len, which would typically result in a shorter encoding?

### Section 11, paragraph 2
     When the protocol running inside the tunnel uses congestion control
     (e.g., [TCP] or [QUIC]), the proxied traffic will incur at least two
     nested congestion controllers.  The outer HTTP connection MAY disable
     congestion control if it knows that the inner packets belong to
     congestion-controlled connections.
There may not be just one protocol inside the tunnel, the overall tunnelled traffic needs to be congestion controlled in order to make it OK to disable congestion control on the tunnel. You might want to refer to, which discusses this in more detail. 

### Section 11.2, paragraph 1
     If a client or IP proxy with a connection containing an IP Proxying
     request stream disables congestion control, it cannot signal Explicit
     Congestion Notification (ECN) [ECN] support on that outer connection.
     That is, the QUIC sender MUST mark all IP headers with the Not-ECT
     codepoint for QUIC packets which are outside of congestion control.
     The endpoint can still report ECN feedback via QUIC ACK_ECN frames or
     the TCP ECE bit, as the peer might not have disabled congestion
Why not use RFC6040 "normal-mode" behavior here instead of marking Not-ECT?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see for background and more

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3, paragraph 11
-       of [URI].
+       of [URI]).
+               +

#### Section 9.4, paragraph 4
-    As with proxied flows, the client specfies both a target hostname and
+    As with proxied flows, the client specifies both a target hostname and
+                                          +

#### Section 10, paragraph 1
-    allows modifications to address assignement to operate atomically.
-                                          -

### Uncited references

Uncited references: `[PROXY-REQS]`.

### Grammar/style

#### Section 7, paragraph 2
ponse. Unless endpoints have an out of band means of guaranteeing that the p
Did you mean "out-of-band"?

#### Section 7, paragraph 7
s IP proxying in HTTP enables many different use cases that can benefit from
Consider using "many".

#### Section 9.2, paragraph 14
routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsu
Use "in regard to", "with regard to", or more simply "regarding".

#### Section 9.4, paragraph 9
xample, that can happen through out of band configuration information, or whe
Did you mean "out-of-band"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

Robert Wilton Former IESG member
No Objection
No Objection (2023-04-13 for -09) Sent

Thanks for this document.  Due to PTO this week, I've not had time to review it closely, and only focused on the more deployment related text.

One minor comment:

(1) p 28, sec 11.  Performance Considerations

   Bursty traffic can often lead to temporally-correlated packet losses;
   in turn, this can lead to suboptimal responses from congestion
   controllers in protocols running inside the tunnel.  To avoid this,
   endpoints SHOULD strive to avoid increasing burstiness of IP traffic;
   they SHOULD NOT queue packets in order to increase batching beyond
   the minimal amount required to take advantage of hardware offloads.

When I first read this, I assumed that endpoints was referring to Internet endpoints (e.g., end user devices), but I presume that endpoints here (and perhaps elsewhere in this document) are referring to the tunnel endpoints?  If so, please consider whether it might be helpful to clarify this somewhere early in the document.