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

[Magnus Westerlund <[e-mail]>]

Hi,

I think the below text looks good. If you are reasonably confident that HIP
supports the capabilities required for implementing PLP MTUD requirements then I
think that pargraph is good hint.

So I believe I will have no issues with clearing when a document with the
discussed updates are made available.

Thanks

Magnus 

On Sun, 2020-04-05 at 13:13 +0000, Miika Komu wrote:
> Hi Magnus,
> 
> 
> 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].
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------