Reviewer: Joseph Touch Review result: Not Ready This review focuses on the behavior of the tunnel from an IP perspective. The HTTP aspects are not considered. In summary, the document presents a method for tunneling IP packets over an HTTP connection. Its terminology and discussion is confusing, being presented largely from the perspective of the HTTP mechanism and not sufficiently from the perspective of the resulting IP tunnel that is provided. Details are provided below. -- The terminology is confusing. Because HTTP is a client/server protocol, it makes sense to refer to a web (or HTTP) proxy, a single entity that acts as both server and client, relaying requests received on the server side and initiating them on the client side. An IP proxy would relay datagrams received on one IP address and issue them with at least some new addressing. What appears to be described here is way to create an IP tunnel over a web connection, which is not a proxy. It is (and should be called) just an IP tunnel. The web client and server are not co-located as they are in a proxy; the term proxy is nonsensical in this context. Sec 4.6 indicates that ipproto can be any number in [IANA-PN]; this is not consistent with the document title or remainder of the document description. That list is of protocols that can be payloads of IP packets, not of IP protocols - e.g., IPv6 is not 6 but 41, and when it is 41 it describes IPv6 as a payload of an outer IP packet, not an IPv6 packet. There does not appear to be a way to indicate the outermost IP packet protocol version, e.g., https://www.iana.org/assignments/version-numbers/version-numbers.xhtml. The claim that implementations MUST walk the chain of extensions to find the protocol is unboundeded as stated; it needs to be limited, e.g., it needs to stop at the first non-IP protocol (e.g., it should not “find” TCP in IP in UDP in IP, if limited to protocol=6). Note that this also raises a further concern, that of the utility of an IP tunnel. The Internet is composed of links and tunnels emulate links. This document appears to describe tunnels that can be limited to specific types of IP packets, but it overlooks the outermost IP packet version. It also overlooks support for non-IP protocols that are critical to IP operation, e.g., for IPv4, these include ICMP and ARP. If an “IP proxy” were limited to protocol 6 (TCP), it would block ICMP (which protocol 1) and ARP (which isn’t an IP packet at all). Note that this is also inconsistent with the ROUTE_ADVERTISEMENT capsule as described in Sec 4.7.3, which asserts that ICMPs are exceptions to the indicated protocol (at a minimum, this needs to be noted here as well). Sec 4.7, although defining new capsules, is really about tunnel configuration. It should be moved to a top-level section and presented as such. Except for Sec 4.7, which explains how IP addresses and routing can be obtained over the HTTP connection, the document views the necessary behavior from only the perspective of the tunnel ingress as an HTTP client and the tunnel egress as an HTTP server. It is missing the way in which these ingress/egress components are viewed a their endpoints, e.g., to be useful as an IP tunnel, these need to appear as attached to (possibly virtual) network interfaces, i.e., to appear as a link, which allows them to then be used for local processes (via sockets), packet forwarding, etc. E.g., the mechanism in Sec 4.7 is only one way that endpoints may be configured; others should be discussed – including using DHCP or IPv6 RAs over the tunnel itself. Sec 7 explains many aspects of IP packet handling that are already sufficiently described in RFCs 1122 and 1812 (for IPv4) and 8200 (for IPv6). That section unnecessarily repeats that detail and is also vague as to where particular behaviors are to be realized. I.e., parsing the IP header, hopcount processing, and packet forwarding. The document should just clearly state that tunnels behave as links (as explained in draft-ietf-intarea-tunnels) and the rest of processing happens *outside* the HTTP server as defined for a host or router. It seems incorrect to design these tunnels as something less than a typical IP interface, esp. for IPv6 (autoconfig, neighbor discovery). Doing so only serves to invite incompatibility and/or undermine existing mechanisms that are useful in detecting misconfiguration (e.g., duplicate address detection). If there is believed to be a technical justification for this limitation, the argument needs to be presented and its implications reviewed (e.g., an IPv6 tunnel that isn’t a true IPv6 interface may not be useful as an IPv6 tunnel). The end of section 7 on link MTUs needs to address the additional requirement of IPv6 EMTU_R of 1500 bytes. Source fragmentation and reassembly need to be addressed for both IPv4 and IPv6, and path-fragmentation for IPv4 (unless it is not supported, which needs to be noted). Sec 8 should be clear on what entity is responsible for ICMP packet generation and receipt. This presumably should be the HTTP endpoint device, not the HTTP client or server. I.e., the tunnel transits ICMP packets but tunnel endpoints should neither generate nor consume them, just like any other link. As other reviewers have noted, Sec 10 on nested congestion control is quite thin. The current statement is equivalent to “if you KNOW congestion is nested, turn it off” – it should be the opposite, i.e., “turn congestion ON only if you KNOW congestion is NOT nested”. Section 11.1 refers to fragmented packets; it should refer to them as not being able to be “re-fragmented”; source-generated fragments are still fragmented and can cross the tunnel subject to the tunnel MTU. Section 11.1 should require that the IP tunnel be created with a given MTU and to indicate that to the endpoint where the client/servers reside; issuing ICMP PTBs is the responsibility of those endpoints when they are seeking to use those tunnel endpoints, NOT of the tunnel endpoint itself. Tunnels are links; links do not issue ICMPs. Sec 12 should indicate how access to the HTTP proxy itself should be access limited, i.e., to avoid presenting an arbitrary traffic injection point. It should also address the potential use of HTTP-level encryption (e.g., TLS, DTLS) to protect the tunnel contents and tunnel configuration exchanges. -- -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
