Proxying IP in HTTP
draft-ietf-masque-connect-ip-13

[Ballot comment]
Thanks to the authors for the document and for addressing my previous DISCUSS points (see https://mailarchive.ietf.org/arch/msg/masque/pv_wmj3wSaHgtqvEdzWuW9eZdTg/)

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).

Regards

-éric

# 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 192.2.0.42 ?

## 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/ ?

[Ballot comment]
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"...

[Ballot comment]
Hi,

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.

Regards,
Rob

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
# 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
(https://mailarchive.ietf.org/arch/msg/gen-art/xDzbLIml2cnNcLA_g6Sj8YPuQiQ).

## Comments

### "MASQUE", paragraph 1
```
                            Proxying IP in HTTP
                      draft-ietf-masque-connect-ip-09
```
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
    9298.
```
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 https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.11, 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
    control.
```
Why not use RFC6040 "normal-mode" behavior here instead of marking Not-ECT?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* 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 https://github.com/larseggert/ietf-reviewtool), 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].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
# 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.

[Ballot discuss]
Thank you for the work put into this document. I *really* find the idea and the protocol interesting and useful. The text is also easy to read and to understand (albeit underspecified in some cases -- hence my DISCUSS).

Please find below some blocking DISCUSS points (easy to address by adding some text), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Chris Wood for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status.

Other thanks to Tim Winters, the Internet directorate reviewer (at my request):
https://datatracker.ietf.org/doc/review-ietf-masque-connect-ip-09-intdir-telechat-winters-2023-04-07/ (and I have read the email exchange, thanks to all)

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 8

Several parts of this section are unspecified, see below.

`Note that ICMP messages can originate from a source address different from that of the IP proxying peer.` is of course obvious, but I think that this case (ICMP originating from the global Internet to the proxy client) deserves a section on its own. Notably whether this source must be within the target ?

The source address to be used by the proxy when originating an ICMP should also be specified, even if just a reference to RFC 6724 for IPv6.

## Section 9.2

In the example where the IP proxy has an IP address in the same prefix as the legacy client (there is no on-link / off-link state for IPv4 as opposed to IPv6), the encapsulation behavior of section 7 requires the TTL to be decremented before entering the tunnel, which is really wrong as it this case it is not formally a routing to a different prefix and some protocols may expect TTL=255, which won't be the case.

Request to add some text about this "issue".

[Ballot comment]

# 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 192.2.0.42 ?

## 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/ ?

[Ballot comment]
# John Scudder, RTG AD, comments draft-ietf-masque-connect-ip-09
CC @jgscudder

## COMMENTS

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 (0.0.0.0/32 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.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

# CONNECT-IP Shepherd Writeup

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

This document reached broad agreement across the group.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

There was some controversy on the mechanics of CONNECT-IP prior to the work being adopted by the group. However, all of those points have since been resolved with a balance of essential core behavior and room for extensions.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

Yes, there are several interoperable implementations of the document, including from Google [1], Ericsson, and Apple. Some of them are open source [1] whereas others are closed source.

[1] https://github.com/google/quiche/tree/main/quiche/quic/masque

5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred?

Early INTDIR review was requested [1] but not yet completed. This can happen alongside IESG and IETF Last Call reviews.

[1] https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/reviewrequest/17045/

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Wire format details (Capsule message structures) have been validated by multiple people.

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

Yes, this document is needed, clearly written, complete, correctly designated, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. Do any such issues remain that would merit specific attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, similar to RFC 9298. The Datatracker state attributes correctly reflect this intent.

12. Has the interested community confirmed that any and all appropriate IPR disclosures required by BCP 78 and BCP 79 have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails.

Yes. The authors confirmed that they are not aware of any IPR related to this draft.

13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification.

Yes. Each author is willing to be listed as such.

14. Identify any remaining I-D nits in this document. (See the idnits tool and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document.

All nits are resolved.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

All normative references are freely available.

17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them.

No.

18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

This document updates RFC 9298, and this is note in the document title, abstract, and introduction.

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

The IANA considerations are correct, with one exception: the value of the CAPSULE types defined in this document will change once the document passes IESG review. The reason they are not changing now is to continue enabling experimental interop without superfulous changes that will only be repeated. See this issue: https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/99

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

This document introduces a new registry for MASQUE URI Suffixes (described in Section 11.2), maintained by expert reviewers. The instructions for reviewers are clear. Suggestions for designated experts include Tommy Pauly (tpauly@apple.com) and Magnus Westerlund (magnus.westerlund@ericsson.com).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-masque-connect-ip-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry located at:

https://www.iana.org/assignments/http-upgrade-tokens/

a new registration is to be made as follows:

Value: connect-ip
Description: Proxying of IP Payloads
Expected Version Tokens: None
Reference: [ RFC-to-be ]

Second, a new registry page is to be created on the IANA Matrix including a new registry called the MASQUE URI Suffixes registry. The new registry will be managed via Expert Review as defined in RFC8126. There are two initial registration in the new registry as follows:

Path Segment Description Reference
------------+---------------+--------------
udp UDP Proxying RFC 9298
ip IP Proxying [ RFC-to-be ]

Third, the entry for "masque" URI suffix in the "Well-Known URIs" registry located at:

https://www.iana.org/assignments/well-known-uris

will be modified so that the "Reference" field to include [ RFC-to-be ] in addition to previous values from that field.

IANA will also replace the "Related Information" field with "For sub-suffix allocations, see registry at IANA_URL_TBD." where IANA_URL_TBD is the URL of the new registry described action number two above.

Fourth, in the HTTP Capsule Types registry on the Hypertext Transfer Protocol (HTTP) Capsule Protocol registry page located at:

https://www.iana.org/assignments/http-capsule-protocol/

three early registrations will be made permanent and their references changed to [ RFC-to-be ]:

Value Capsule Type Description
-------+---------------------+---------------------
0x01 ADDRESS_ASSIGN Address Assignment
0x02 ADDRESS_REQUEST Address Request
0x03 ROUTE_ADVERTISEMENT Route Advertisement

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-03-15):

From: The IESG
To: IETF-Announce
CC: caw@heapingbits.net, draft-ietf-masque-connect-ip@ietf.org, martin.h.duke@gmail.com, masque-chairs@ietf.org, masque@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Proxying IP in HTTP) to Proposed Standard


The IESG has received a request from the Multiplexed Application Substrate
over QUIC Encryption WG (masque) to consider the following document: -
'Proxying IP in HTTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-03-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes how to proxy IP packets in HTTP.  This
  protocol is similar to UDP proxying in HTTP, but allows transmitting
  arbitrary IP packets.  More specifically, this document defines a
  protocol that allows an HTTP client to create an IP tunnel through an
  HTTP server that acts as a proxy.  This document updates RFC 9298.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/



No IPR declarations have been submitted directly on this I-D.

# CONNECT-IP Shepherd Writeup

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

This document reached broad agreement across the group.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

There was some controversy on the mechanics of CONNECT-IP prior to the work being adopted by the group. However, all of those points have since been resolved with a balance of essential core behavior and room for extensions.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

Yes, there are several interoperable implementations of the document, including from Google [1], Ericsson, and Apple. Some of them are open source [1] whereas others are closed source.

[1] https://github.com/google/quiche/tree/main/quiche/quic/masque

5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred?

Early INTDIR review was requested [1] but not yet completed. This can happen alongside IESG and IETF Last Call reviews.

[1] https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/reviewrequest/17045/

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Wire format details (Capsule message structures) have been validated by multiple people.

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

Yes, this document is needed, clearly written, complete, correctly designated, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. Do any such issues remain that would merit specific attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, similar to RFC 9298. The Datatracker state attributes correctly reflect this intent.

12. Has the interested community confirmed that any and all appropriate IPR disclosures required by BCP 78 and BCP 79 have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails.

Yes. The authors confirmed that they are not aware of any IPR related to this draft.

13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification.

Yes. Each author is willing to be listed as such.

14. Identify any remaining I-D nits in this document. (See the idnits tool and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document.

All nits are resolved.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

All normative references are freely available.

17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them.

No.

18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

This document updates RFC 9298, and this is note in the document title, abstract, and introduction.

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

The IANA considerations are correct, with one exception: the value of the CAPSULE types defined in this document will change once the document passes IESG review. The reason they are not changing now is to continue enabling experimental interop without superfulous changes that will only be repeated. See this issue: https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/99

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

This document introduces a new registry for MASQUE URI Suffixes (described in Section 11.2), maintained by expert reviewers. The instructions for reviewers are clear. Suggestions for designated experts include Tommy Pauly (tpauly@apple.com, David Schinazi (dschinazi.ietf@gmail.com), Mirja Kuehlewind (mirja.kuehlewind@ericsson.com), Magnus Westerlund (magnus.westerlund@ericsson.com), and Alex Chernyakhovsky (achernya@google.com).

# CONNECT-IP Shepherd Writeup

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?

This document reached broad agreement across the group.

2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough?

There was some controversy on the mechanics of CONNECT-IP prior to the work being adopted by the group. However, all of those points have since been resolved with a balance of essential core behavior and room for extensions.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?

Yes, there are several interoperable implementations of the document, including from Google [1], Ericsson, and Apple. Some of them are open source [1] whereas others are closed source.

[1] https://github.com/google/quiche/tree/main/quiche/quic/masque

5. Does this document need review from other IETF working groups or external organizations? Have those reviews occurred?

Early INTDIR review was requested [1] but not yet completed. This can happen alongside IESG and IETF Last Call reviews.

[1] https://datatracker.ietf.org/doc/draft-ietf-masque-connect-ip/reviewrequest/17045/

6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Wire format details (Capsule message structures) have been validated by multiple people.

9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?

Yes, this document is needed, clearly written, complete, correctly designated, and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. Do any such issues remain that would merit specific attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, similar to RFC 9298. The Datatracker state attributes correctly reflect this intent.

12. Has the interested community confirmed that any and all appropriate IPR disclosures required by BCP 78 and BCP 79 have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails.

Yes. The authors confirmed that they are not aware of any IPR related to this draft.

13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification.

Yes. Each author is willing to be listed as such.

14. Identify any remaining I-D nits in this document. (See the idnits tool and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document.

All nits are resolved.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?

All normative references are freely available.

17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them.

No.

18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.

This document updates RFC 9298, and this is note in the document title, abstract, and introduction.

20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).

The IANA considerations are correct, with one exception: the value of the CAPSULE types defined in this document will change once the document passes IESG review. The reason they are not changing now is to continue enabling experimental interop without superfulous changes that will only be repeated. See this issue: https://github.com/ietf-wg-masque/draft-ietf-masque-connect-ip/issues/99

21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.

This document introduces a new registry for MASQUE URI Suffixes (described in Section 11.2), maintained by expert reviewers. The instructions for reviewers are clear. Suggestions for designated experts include Tommy Pauly (tpauly@apple.com, David Schinazi (dschinazi.ietf@gmail.com), Mirja Kuehlewind (mirja.kuehlewind@ericsson.com), Magnus Westerlund (magnus.westerlund@ericsson.com), and Alex Chernyakhovsky (achernya@google.com).