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

From: Miika Komu <[email-masked]>
Date: Thu, 2 Apr 2020 19:56:12 +0000

Hi Magnus,

to, 2020-03-05 kello 03:08 -0800, Magnus Westerlund via Datatracker
kirjoitti:
> 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 [email-masked]. 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.

This document reuses the same default UDP port number 10500 as
specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
plane and data plane traffic.  The port was was registered 
separately for RFC5770 to co-author Ari Keranen but should now be re-
assigned for IESG control.  With the permission of Ari Keranen, the new
assignee is IESG and contact "[email-masked]".  In addition, IANA is
requested to add a reference to this document in the entry for UDP port
10500 in the Transport Protocol Port Number Registry.  The selection
between Legacy ICE-HIP and Native ICE-HIP mode is negotiated using
NAT_TRAVERSAL_MODE parameter during the base exchange.  By default,
hosts listen this port for incoming UDP datagrams and can use it also
for sending UDP datagrams.  Other emphemeral port numbers are
negotiated and utilized dynamically.

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

I am not an expert on the topic but based on some discussions with some
colleagues, the SRV records seem to more suitable for infrastructure
discovery, not really for end-host discovery. Since you asked for this,
I wrote a new section in the appendix:

Appendix E.  DNS Considerations

[RFC5770] did not specify how an end-host can look up another end-
host via DNS and initiate an UDP-based HIP base exchange with it, so
this section makes an attempt to fill this gap.

[RFC8005] specifies how an HIP end-host and its Rendezvous server is
registered to DNS.  Essentially, the public key of the end-host is
stored as HI record and its Rendezvous Server as A or AAAA record.
This way, the Rendezvous Server can act as an intermediary for the
end-host and forward packets to it based on the DNS configuration.
Control Relay Server offers similar functionality as Rendezvous
Server, with the difference that the Control Relay Server forwards
all control messages, not just the first I1 message.

Prior to this document, the A and AAAA records in the DNS refer
either to the HIP end-host itself or a Rendezvous Server [RFC8005],
and control and data plane communication with the associated host has
been assumed to occur directly over IPv4 or IPv6.  However, this
specification extends the records to be used for UDP-based
communications.

Let us consider the case of a HIP Initiator with the default policy
to employ UDP encapsulation and the extensions defined in this
document.  The Initiator looks up the FQDN of a Responder, and
retrieves its HI, A and AAAA records.  Since the default policy is to
use UDP encapsulation, the Initiator MUST send the I1 message over
UDP to destination port 10500 (either over IPv4 in the case of a A
record or over IPv6 in the case of a AAAA record).  It MAY send an I1
message both with and without UDP encapsulation in parallel.  In the
case the Initiator receives R1 messages both with and without UDP
encapsulation from the Responder, the Initiator SHOULD ignore the R1
messages without UDP encapsulation.

The UDP encapsulated I1 packet could be received by three different
types of hosts:

1.  HIP Control Relay Server: in this case the A/AAAA records refers
    to a Control Relay Server, and it will forward the packet to the
    corresponding Control Relay Client based on the destination HIT
    in the I1 packet.

2.  HIP Responder supporting UDP encapsulation: in this case, the the
    A/AAAA records refers to the end-host.  Assuming the destination
    HIT belongs to the Responder, it receives and processes it
    according to the negotiated NAT traversal mechanism.  The support
    for the protocol defined in this document vs [RFC5770] is
    dynamically negotiated during the base exchange.  The details are
    specified in Section 4.3.

3.  HIP Rendezvous Server: this entity is not listening to UDP port
    10500, so it will drop the I1 message.

4.  HIP Responder not supporting UDP encapsulation: the targeted end-
       host is not listening to UDP port 10500, so it will drop the I1
       message.

The A/AAAA-record MUST NOT be configured to refer to a Data Relay
Server unless the host in question supports also Control Relay Server
functionality.

It also worth noting that SRV records are not employed in this
specification.  While they could be used for more flexible UDP port
selection, they are not suitable for end-host discovery but rather
would be more suitable for the discovery of HIP-specific
infrastructure.  Further extensions to this document may define SRV
records for Control and Data Relay Server discovery within a DNS
domain.

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

Yes (by relays or end-hosts)

> And the listening stack can determine which
> version is used to determine which of the protocol is run.

HIP version is in the header. If a middlebox or end-host does not
support the HIP version, it will respond to with an ICMP:

https://tools.ietf.org/html/rfc7401#section-5.4.1

Then there is RFC5770 vs "native NAT traversal" (this spec)
specification issues:

1. Client registration to a Relay:

- RELAY_UDP_HIP in both specs
- New RELAY_UDP_ESP service in Native NAT traversal

https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-30#section-4.1

This is simple. The Relay Server offers services and the Client chooses
from them. The Control Relay Service is the same in both specs.

2. Base exchange between the actual end-hosts:

- NAT_TM: ICE-STUN-UDP (RFC5770) vs ICE-HIP-UDP (native NAT traversal) 

https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-30#section-4.5
https://tools.ietf.org/html/rfc5770#section-4.3

The end-hosts negotiate RFC5770 vs native NAT traversal support during
the base exchange.

> And the issue with
> multiplexing is only existing for the ports that one gathers?

What do you exactly mean by this? Is there an issue between NAT
traversal versions? Or are you referring to:

6.4.  Demultiplexing Different HIP Associations

OR

4.12.3.  Handling Conflicting SPI Values (note two scenarios here)

...which both talk about multiplexing. The latter section deals with the new service added in this specification (Data Relay Service) and port gathering with that.

> Can you please
> add a paragraph or two somewhere in the document.

I can add some text if you can confirm if I have answered to the right
questions?

> I think it should be
> referenced by the port registration update.

This was handled already my response to question 1?

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

> -------------------------------------------------------------------
> ---
> COMMENT:
> -------------------------------------------------------------------
> ---
> 
> May I inquire about the reasoning why this document do not obsolete
> RFC 5770?

This was discussed earlier but the working group decided to keep both,
and let implementor's to choose between reusing existing STUN/TURN
infra (RFC5770) vs faster data plane (native NAT traversal).

---

From: Miika Komu <[email-masked]>
Date: Fri, 3 Apr 2020 06:41:09 +0000

Hi Magnus,

> I am stil iterating some text on this, I hope Jeff Ahrenholz can help

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Apr 2020 09:17:14 +0000

Hi Miika,

Please see inline. 

> negotiated and utilized dynamically.

Thanks, this is exactly what I wanted to here. 

> I wrote a new section in the appendix:

So the main reason for my question was to ensure that you have not forgoetten
that you actually have some dependnecy on the service name that would in fact be
incompatible. That could include some supporting document, for example usage of
SRV records. However, with the below text written, I do find it informative. And
the statement at the end that you don't use SRV records currently is also good
and part to answer one aspect of my question. To conclude, it appears to be no
issues with having the two mechanisms share service name and port. 

From my perspective it appears to be some benefit in including the below
appendix in the specificaiton, but you should seek consensus on it in the WG
before the document is approved in my opinion. 

> ...which both talk about multiplexing. The latter section deals with the new
> service added in this specification (Data Relay Service) and port gathering
> with that.
> 

Deciphering my own comment, I think it was primarily the question how the relay
can separate the different traffic on that port, primarily from supporting old
version at the same time. I think the seperation of the difference client's
streams appears sufficiently well defined. 

> I am stil iterating some text on this, I hope Jeff Ahrenholz can help

Will answer the other email with text on this. 

> infra (RFC5770) vs faster data plane (native NAT traversal).

Ok. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Apr 2020 09:49:00 +0000

Hi, 

See below.

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

Ok.

Cheers

Magnus Westerlund

---

From: Miika Komu <[email-masked]>
Date: Sun, 5 Apr 2020 13:13:07 +0000

Hi Magnus,

pe, 2020-04-03 kello 09:49 +0000, Magnus Westerlund kirjoitti:
> > > > "It is worth noting that UDP encapsulation of HIP packets
> > > > reduces
> > > > the

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

---

From: Miika Komu <[email-masked]>
Date: Sun, 5 Apr 2020 13:25:10 +0000

Hi Magnus,

> before the document is approved in my opinion.

I have sent an separate email to the WG mailing list on this.

P.S. Thanks for all of your valuable comments!

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 6 Apr 2020 08:52:01 +0000

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 

-- 
Cheers

Magnus Westerlund

---

From: Miika Komu <[email-masked]>
Date: Thu, 9 Apr 2020 08:13:33 +0000

Hi Magnus,

> before the document is approved in my opinion.

I noticed that the new proposed text on DNS is handling things
differently than this part in RFC5770:

https://tools.ietf.org/html/rfc5770#appendix-B

So I would suggest that we would update RFC5770 appendix B in the
native NAT traversal draft and replace it with the new DNS text.

(I can ask WG consensus for this also)