Re: [Int-dir] [Last-Call] Intdir telechat review of draft-ietf-masque-connect-ip-10

[Behcet Sarikaya <[e-mail]>]

Hi Joe,
Note. This message is directed to intarea.
As a tunneling expert you are the right person to review this document, at
least I believe so.

On Fri, Apr 14, 2023 at 10:29 PM Joseph Touch via Datatracker <
[e-mail]> wrote:

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


But the draft-intarea-tunnels doesn't talk about the type of tunnel
described in this draft, i.e. tunnels over an HTTP connection.
Maybe you can add it before it becomes an RFC.

Behcet


> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>