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

[Miika Komu <[e-mail]>]

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?

Btw, I would remove the following redundant statement in
"RELAYED_ADDRESS and MAPPED_ADDRESS Parameters" section:

It is worth noting that UDP encapsulation of ESP reduces
the MTU size of data plane by 8 bytes.