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

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-30: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

So I think the below are important things that needs to be discussed before
proceeding. However, I might have missed things as I didn't have time to read
the whole document in detail. Several of the issues are pieces for discussion
to ensure that the right thing really is done.

1. So this document recommends the usage of port 10500 as default listening
port. A port registered by Ari and also used for RFC 5770. I get the impression
that the port was registered separately from RFC 5770. So the port is assigned
to Ari. Would Ari be willing to release the port for re-assignment to IESG
control. RFC 6335 has the recommendation for ports for IETF protocols that the
assignee is IESG and the contact [e-mail]. This to have the change
control with IETF as body rather than with individuals.

If Ari agrees to this, I think it would be good to have the IANA section be
updated to note the re-assignment and provide the necessary information.

2. Secondly, as this solution is different from the RFC 5770 should this
solution have a different service name? The reason I am asking is that it
depends on how for example how an initiator determine which of the NAT
traversal solution. If there is any intention to use DNS SRV for example
different service name would make sense. This is primarily to verify that this
has been considered.

3. So I don't quite understand what the co-existance story are for the relay
having an listener on port 10500? Is that port only used for UDP/HIPv1
(RFC5770) and UDP/HIPv2 (This doc). And the listening stack can determine which
version is used to determine which of the protocol is run. And the issue with
multiplexing is only existing for the ports that one gathers? Can you please
add a paragraph or two somewhere in the document. I think it should be
referenced by the port registration update.

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

May I inquire about the reasoning why this document do not obsolete RFC 5770?