Re: [Hipsec] Magnus Westerlund's Discuss on draft-ietf-hip-native-nat-traversal-30: (with DISCUSS and COMMENT)

[Miika Komu <[e-mail]>]

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].