Hi Magnus, pe, 2020-04-03 kello 09:49 +0000, Magnus Westerlund kirjoitti: > Hi, > > See below. > > On Fri, 2020-04-03 at 06:41 +0000, Miika Komu wrote: > > Hi Magnus, > > > > to, 2020-04-02 kello 22:56 +0300, Miika Komu kirjoitti: > > > > > > > 4. MTU impact of NAT traversal. > > > > > > > > Section 5.1 states > > > > "It is worth noting that UDP encapsulation of HIP packets > > > > reduces > > > > the > > > > Maximum Transfer Unit (MTU) size of the control plane by 12 > > > > bytes." > > > > > > > > There is also a similar text in Section 5.11: > > > > > > > > It is worth noting that UDP encapsulation of ESP reduces the > > > > MTU > > > > size > > > > of data plane by 8 bytes. > > > > > > > > I think the document needs a discussion and impact on MTU which > > > > this > > > > NAT > > > > traversal has on the HIP packets being sent. - First of all > > > > there > > > > appears to be > > > > more packet expansions happening in some cases, for example the > > > > RELAY_HMAC > > > > option expands packets on one leg. - Secondly, HIP requires IP > > > > fragementation > > > > support, however IP fragmentation through NAT is commonly not > > > > working. Thus an > > > > HIP packet being UDP encapsulated that results in packet > > > > exceeding > > > > MTU will > > > > likely end up in an MTU black hole on path. > > > > > > > > The addition of the NAT traversal encapsulation actually > > > > increases > > > > the need for > > > > MTU discovery or care in MTU handling by the HIP initiator. I > > > > think > > > > there need > > > > to be discussion of that in the document. > > > > > > I am stil iterating some text on this, I hope Jeff Ahrenholz can > > > help > > > with this. > > > > I got text from Jeff Ahrenholz and Robert Moskowitz: > > > > Section 5.2 > > > > replaced this: > > > > It is worth noting that UDP encapsulation of HIP packets reduces > > the > > Maximum Transfer Unit (MTU) size of the control plane by 12 bytes. > > > > with: > > > > UDP encapsulation of HIP packets reduces the Maximum Transfer Unit > > (MTU) size of the control plane by 12 bytes (8-byte UDP header plus > > 4-byte zero SPI marker), and the data plane by 8 bytes. This > > encapsulation overhead increases the need for MTU discovery. A HIP > > host SHOULD have the option to enable ICMP path MTU discovery > > (PMTUD) > > [RFC1063] [RFC8201]. Otherwise, support for IP fragmentation is > > required, which may not be commonly supported through NATs. When > > HIP > > encapsulation is implemented using a virtual tunneling interface, > > consider using a reduced MTU (e.g. 1400) by default. Additional > > HIP > > relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, > > etc., further increase the size of certain HIP packets. It is > > worth > > noting that further HIP extensions can trim off 8 bytes in the ESP > > header by negotiating implicit IV support in the ESP_TRANSFORM > > parameter as described in [RFC8750]. > > > > Does this address your concerns? > > I think the recommendation for virtual interface is a reasonable one > based on > the constraints. However, I think: > > A HIP > > host SHOULD have the option to enable ICMP path MTU discovery > > (PMTUD) > > [RFC1063] [RFC8201]. Otherwise, support for IP fragmentation is > > required, which may not be commonly supported through NATs. > > maybe should be reformulated. ICMP messages are sometimes dropped in > NATs, > despite recommendations to support at least the TOO BIG messages. And > I think if > ICMP either is not working or not enabled, indicating that IP > fragmentation > could be a possible way to get thingst to work, appears even less > likely to work > as IP fragmentation handling in NATs becomes resource demanding due > to all per > packet state needed to be maintained, as only the first fragement > contains the > UDP header allowing the lookup of the translation record. > > Maybe it can be made clearer by restructuring the text so that it > says this: > > - A HIP host SHOULD implement ICMP message handling to support MTU > discovery per > [RFC1063] [RFC8201]. > - Reliance on IP fragmentation is unlikely to be a viable strategy > through NATs > so if ICMP MTU discovery is not working MTU realted path black holes > may occur. > - A mitigation is to constrain the MTU, especially for virtual > interfaces to > expected to be safe MTU values, e.g. 1400 bytes for underlying > interfaces that > support 1500 bytes MTU. > - (to include something realted to below discussion consider this > bullet also, > assumes that PLP MTUD actually can be implemented in HIP relay rather > simply): > Implement PLPMTUD [draft-ietf-tsvwg-datagram-plpmtud] in HIP to find > a working > path MTU without unnecessary constraining that size. > > Has anyone looked at implementing > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ > (document is > in IESG evaluation) style path MTU discovery between the HIP client > and the > relay? Becasue I think that would be the best to actually run a HIP > level path > MTU discovery, so that the HIP client can set its MTU to path minus > overhead and > including any for occasional messages that are required to be > included when > carrying useful payload. If HIP has a padding option, then I would > expect that > HIP has everything necessary to implement working probe messages that > can used > by the above draft. > > To be clear, I don't expect that you write up and include such a one > in this > specification. At most you could consider an informative statement > that an a > client implementor could consider to implement such a mechanism. > > I would more hope that someone in the WG considers to actually write > a draft for > a specification for PLP MTU discovery for HIP, which hopefully are a > rather > short document, but can enable a HIP based virtual interface to set > well working > MTU without unnecessary constraining the MTU.
I tried to merge your feedback with text from Jeff and Robert, so now it is as follows: UDP encapsulation of HIP packets reduces the Maximum Transfer Unit (MTU) size of the control plane by 12 bytes (8-byte UDP header plus 4-byte zero SPI marker), and the data plane by 8 bytes. Additional HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further increase the size of certain HIP packets. In regard to MTU, the following aspects need to be considered in an implementation: o A HIP host SHOULD implement ICMP message handling to support path MTU discovery (PMTUD) discovery as described in [RFC1063] [RFC8201] o Reliance on IP fragmentation is unlikely to be a viable strategy through NATs. If ICMP MTU discovery is not working, MTU related path black holes may occur. o A mitigation strategy is to constrain the MTU, especially for virtual interfaces, to expected safe MTU values, e.g., 1400 bytes for the underlying interfaces that support 1500 bytes MTU. o Further extensions to this specification may define a HIP-based mechanism to find a working path MTU without unnecessary constraining that size using Packetization Layer Path MTU Discovery for Datagram Transports [I-D.ietf-tsvwg-datagram-plpmtud]. For instance, such mechanism could be implemented between a HIP Relay Client and HIP Relay Server. o It is worth noting that further HIP extensions can trim off 8 bytes in the ESP header by negotiating implicit IV support in the ESP_TRANSFORM parameter as described in [RFC8750]. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
