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

["[e-mail]" <[e-mail]>]

Hi, all,

Here’s a way to present the implementation issues associated with the router (and OS interfacing, which IMO is in the same realm as “implementation advice”). The text is rough, but where it diverges from the current text is intentional.

Note that it addresses issues with interfacing, ICMP, and MTU.

Joe

7.2.  Interfacing
 
The IP proxy function described in this document creates a tunnel. Tunnels are virtual links; like all links, they are associated with interfaces at hosts or routers. Those interfaces accept and emit IP packets, acting as raw IP devices.
 
In most implementations, these raw IP devices are either attached to OS devices or to stand-alone software that acts as either a host or router.
 
7.2.1. OS Interfacing
 
The IP proxy function typically presents as a user-level raw IP socket on typical Unix devices. For that socket to be used by the OS, either for OS-based routing or as a host endpoint for other applications, it needs to be represented as an OS interface. This requires additional implementation software to attach the IP proxy to the OS, e.g., as a tun device in Unix.
 
In this case, all other IP processing happens in the OS, including TTL checks, TTL decrements (when forwarded to another interface), checksum validation and recomputation (for IPv4), etc. This includes generation of ICMP errors, which originate from the OS (not the IP proxy endpoint).
 
7.2.2 Integrated with a user router
 
The IP proxy function can be implemented together with a user-space IP router. In this case, the forwarding functions between IP proxies or to other tunnels can be performed independently from underlying OS functions.
 
User-space router implementations are subject to the same requirements as any other IP forwarding device [RFC1812][RFC8200]. The router would perform the same checks an OS forwarder, including including TTL checks, TTL decrements (when forwarded to another interface), checksum validation and recomputation (for IPv4), etc. The router would also generate any appropriate ICMP error messages, which originate from the user-space router code (not the IP proxy endpoint).
 
Implementers of such user-space routers should be careful to obey all other router requirements, including not forwarding link-local traffic. They may also implement additional filtering, just as could an OS router.
 
7.2.3 Common interfacing issues
 
Whether IP proxy is attached to an OS interface or deployed with a user-space router, there are some common issues. Either way, the IP proxy acts as a link. The endpoint OS or user-space router is responsible for IP header checksum validation (IPv4) and ICMP generation as needed. Such ICMPs include failure to determine a forwarding path, MTU exceeded, or other types of endpoint or router errors.
 
TTL/hopcount decrement (and checksum recalculation for IPv4) occur during the forwarding process, not as part of the IP proxy as either encapsulation or decapsulation. 
 
Source fragmentation of the original IP packet similarly happens outside the tunnel endpoint where needed, and inside the IP proxy on the tunneled packet as needed independently. On-path fragmentation of IPv4 packets also happens inside the user-space router or OS when needed and permitted.
 
---
 
(some other place TBD)
 
X.X MTU Issues
 
IP links have three types of maximum transmission units (MTUs) source MTUs,(EMTU_S), path MTUs (MTU), and receiver MTUs (EMTU_R) [draft-ietf-intarea-tunnesls. For IPv4, these must be at least 64, 64, and 576 respsectively; for IPv6, these must be 1280, 1280, and 1500 respectively. The path MTU is the minimum of the EMTU_S of each interface on a path. IP proxy operates over different transport protocols and may try to provide an IPv6 tunnel over an underlying IPv4 service.
 
When IP proxy operates over TCP, the ingress/egress IP packet sizes need not correlate to the underlying path properties. However, when using QUIC datagram service,...
 
(I don’t know what happens here, but the text below doesn’t seem to address it)
 
IMO:
-   IP proxy MUST present an interface with an EMTU_S of at least 1280 and EMTU_R of 1500, but that means that after encapsulation, if running over a transport that does not support the encapsulated packet, it MUST perform source fragmentation after encapsulation at the ingress and MUST perform receiver reassembly at the egress before decapsulation.
 
(this is original text from this section: I don’t know how this applies or not)
 
   *  if both IP proxying endpoints know for certain that HTTP
      intermediaries are not in use, the endpoints can pad the QUIC
      INITIAL packets of the outer QUIC connection that IP proxying is
      running over.  (Assuming QUIC version 1 is in use, the overhead is
      1 byte type, 20 bytes maximal connection ID length, 4 bytes
      maximal packet number length, 1 byte DATAGRAM frame type, 8 bytes
      maximal quarter stream ID, one byte for the zero Context ID, and
      16 bytes for the AEAD authentication tag, for a total of 51 bytes
      of overhead which corresponds to padding QUIC INITIAL packets to
      1331 bytes or more.)
 
        [NO, I don’t think that even QUIC limits should ever prevent an IP tunnel from working]
 
-   IP proxy endpoints can also check for ICMPs that originate from the tunnel, which would be received in association with the underlying HTTP connection. Those ICMPs can indicate how source fragmentation needs to occur at the tunnel ingress to ensure that lower-level packets do not exceed the EMTU_S of the underlying HTTP connection.
 
-   IP proxy endpoints can also perform PLPMTUD over the tunnel to discover the path MTU, similarly indicating how source fragmentation needs to occur at the tunnel ingress to ensure that lower-level packets do not exceed the EMTU_S of the underlying HTTP connection.
 
(NO, I don’t think sending probe ICMPs is correct)