Reviewer: Joseph Touch Review result: Not Ready This documents most significant transport issue is the use of path MTU discovery. Sec 2 recommends the use of path MTU discovery [RFC1191] [RFC8201], but this is known to be problematic black holing where ICMPs are blocked or filtered (which should be noted everywhere PMTU is suggested, including Sec 4.2). It would be more appropriate to incorporate PLPMTUD [RFC4821] [RFC8899], especially in conjunction with congestion control, as both assume bidirectional stateful ingress/egress coordination. This is particularly important given the sending side’s prerogative to change the size of the tunnel EMTU_S (see below).
The most significant concern is not at the transport layer – it is the assumption of in-order delivery and insufficient consideration of the impact of loss at the network layer. Loss could orphan received fragments – for which a timeout should be recommended. Loss or reordering could generate faulty reassembly at the egress – which is actually very likely here, e.g., when a short packet is followed by a sequence of packets that are exactly the tunnel MAP (as defined in draft-ietf-intarea-tunnels). As noted below, persistent fragmentation could make this situation worse, esp. in the presence of frequent reordering or loss. Other significant issues, largely at the network/tunnel layer: There is no clear utility in having the blockoffset point past the end of the current packet. It serves – at best – as only a partially useful check on the next packet. I.e., if the two blockoffsets disagree, presumably a packet is lost – but if they agree, it cannot be concluded that a packet is not lost. It is sufficient that it points to the end of the tunnel packet. Although the mechanism allows for padding, it appears too aggressive in trying to be work-conserving. Consider a tunnel that could support 1000B payloads; if a stream of packets comes in as 200B, 1000B, 1000B, 1000B, etc. (more 1000B packets), EVERY 1000B would be fragmented, which means loss of a single tunnel packet would cause two inner packets to be incomplete. The protocol should allow padding in some cases to avoid fragmentation, e.g., every 100th packet it might allow insertion of padding rather splitting a packet across the stream. The heuristic shown here is just an example. Fig 1 shows the blocksize as always occurring in the latter half of a word; is this always the case? If so, it would be useful to indicate the left side of that word as “ESP – con’t”. If not, other examples should be provided. At the end of Sec 2.2, the blockoffset helps recover the next inner packet, but the term “full” in that sentence implies the inner packet is entirely inside that outer packet (which it may not be). The option of congestion control and the claim of “unidirectional” should be discussed more consistently (i.e., mention the need for bidirectional channels when mentioning thec claim of unidirectionality). Like all tunnels, this approach needs to more clearly indicate a number of different MTU values and how they interact [draft-ietf-intarea-tunnels], both for the underlying network and the tunnel provided: - EMTU_S - EMTU_R - Path MTU - Link MTU It may also be useful to use the terms developed in that doc, e.g., tunnel link packet (the packet that traverses a tunnel) as well as inner vs. outer fragmentation, tunnel maximum atomic packet, etc. There are a number of other tunnel considerations that should be addressed, again as discussed in draft-ietf-intarea-tunnels. These include: - The impact of tunnel traversal on the inner hopcount/TTL (there should be none, as per that doc; hopcount should be adjusted by routers, not tunnels) - Impact of errors in the tunnel on the ingress - Specification of the EMTU_R of the tunnel itself, and how that is determined - What the ingress should do if an incoming packet exceeds EMTU_R - It should be noted that this is a unicast tunnel - What you expect if there are multiple paths between the tunnel ingress and egress - Does the tunnel itself have a flow ID? (if the outer packet is IPv6) If so, is it fixed or intended to vary arbitrarily (and if so, how)? - If the outer packet is IPv4, do you expect to use DF=1? If not, how are you handling ID issues in RFC 6864? If so, it might be useful to add a reminder that the ID can be anything (including constant, which may be useful in avoiding a covert channel). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
