Skip to main content

Native NAT Traversal Mode for the Host Identity Protocol
draft-ietf-hip-native-nat-traversal-33

Revision differences

Document history

Date Rev. By Action
2021-06-17
33 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-05-24
33 (System) RFC Editor state changed to AUTH48
2021-04-22
33 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-04-02
33 (System) RFC Editor state changed to REF from EDIT
2021-04-02
33 (System) RFC Editor state changed to EDIT from MISSREF
2020-11-15
33 (System) RFC Editor state changed to MISSREF from RFC-EDITOR
2020-09-22
33 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-08-20
33 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-08-19
33 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-08-19
33 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-08-14
33 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-08-13
33 (System) IANA Action state changed to In Progress from On Hold
2020-08-12
33 (System) IANA Action state changed to On Hold from In Progress
2020-08-04
33 (System) RFC Editor state changed to EDIT
2020-08-04
33 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-08-04
33 (System) Announcement was received by RFC Editor
2020-08-04
33 (System) IANA Action state changed to In Progress
2020-08-04
33 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2020-08-04
33 Cindy Morgan IESG has approved the document
2020-08-04
33 Cindy Morgan Closed "Approve" ballot
2020-08-04
33 Cindy Morgan Ballot approval text was generated
2020-08-04
33 Éric Vyncke Per author request.
2020-08-04
33 Éric Vyncke Intended Status changed to Experimental from Proposed Standard
2020-08-03
33 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-33.txt
2020-08-03
33 (System) New version approved
2020-08-03
33 (System) Request for posting confirmation emailed to previous authors: Miika Komu , Ari Keranen , Jan Melen
2020-08-03
33 Miika Komu Uploaded new revision
2020-07-28
32 Magnus Westerlund
[Ballot comment]
Thanks for resolving and answering my questions.

I have only one minor comment that I noticed due to that you edit the text: …
[Ballot comment]
Thanks for resolving and answering my questions.

I have only one minor comment that I noticed due to that you edit the text:

Section 2:
"Following [RFC5770] and SDP [RFC3264] ..."

RFC 3264 is not SDP, it is the "Offer/Answer model with SDP" there is a significant difference, as SDP base spec is RFC4566.
2020-07-28
32 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss
2020-07-27
32 Martin Duke [Ballot comment]
Thank you for an easy-to-read document -- and for addressing my DISCUSS!
2020-07-27
32 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss
2020-07-27
32 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-27
32 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-07-27
32 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-32.txt
2020-07-27
32 (System) New version approved
2020-07-27
32 (System) Request for posting confirmation emailed to previous authors: Ari Keranen , Miika Komu , Jan Melen
2020-07-27
32 Miika Komu Uploaded new revision
2020-07-16
31 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-07-16
31 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-07-16
31 Erik Kline [Ballot comment]
Trusting previous AD's review.
2020-07-16
31 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-07-15
31 Martin Duke
[Ballot discuss]
Sec 4.2 and 4.6.2 specify a minimum of RTO of 500ms. There’s no way you would know this,  but draft-ietf-tcpm-rto-consider is close to …
[Ballot discuss]
Sec 4.2 and 4.6.2 specify a minimum of RTO of 500ms. There’s no way you would know this,  but draft-ietf-tcpm-rto-consider is close to IESG approval and specifies a minimum of 1 second without more information about the path. I would prefer that we change these minimums but perhaps there’s a compelling reason for 500ms?

RFC 5770 is a normative downref. I couldn’t find indication the procedures in RFC 3967 or 4897 were followed to address this. One solution would be to downgrade this document to Experimental.
2020-07-15
31 Martin Duke [Ballot comment]
Thank you for an easy-to-read document.
2020-07-15
31 Martin Duke [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke
2020-07-15
31 Benjamin Kaduk
[Ballot comment]
Thanks for addressing the potential "cross-message" attack on the HMAC
contents of RELAY_HMAC/RVS_HMAC by prohibiting the Control Relay Server
from offering the rendezvous …
[Ballot comment]
Thanks for addressing the potential "cross-message" attack on the HMAC
contents of RELAY_HMAC/RVS_HMAC by prohibiting the Control Relay Server
from offering the rendezvous services.  I think in order for the
protection against the attack to be complete, though, we need to say
that a HIP peer attempting to reach a Control Relay Server MUST reject
any messages appearing to originate from that server, that contain an
RVS_HMAC parameter.  That is, the current text will keep honest actors
from generating the bad situation, but we also want to protect ourselves
against accepting input from a bad actor attempting to cause the bad
situation.

Thank you as well for addressing all of my other comments on the -30.
They seem generally satisfactory, and my apologies for not responding to
them sooner.  I just have two remaining remarks:

Section 1

  tunneling overhead).  Another solution is specified in [RFC5770],
  which will be referred to "Legacy ICE-HIP" in this document.  The

nit: s/to/to as/

Section 4.6.2

  [RFC7401] section 5.3.5 states that UPDATE packets have to include
  either a SEQ or ACK parameter (but can include both).  According to
  the RFC, each SEQ parameter should be acknowledged separately.  In

I don't see anything to support "acknowledged separately"; on the
contrary, I see "A host MAY choose to acknowledge more than one UPDATE
packet at a time; e.g., the ACK parameter may contain the last two SEQ
values received, for resilience against packet loss."  Perhaps the
intent was "each SEQ parameter needs to be explicitly acknowledged"?
2020-07-15
31 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-07-14
31 Éric Vyncke
[Ballot comment]
The -31 version addresses all DISCUSSs and COMMENTs raised during the May 2018 first ballot on version -28 and in March 2020 2nd …
[Ballot comment]
The -31 version addresses all DISCUSSs and COMMENTs raised during the May 2018 first ballot on version -28 and in March 2020 2nd ballot on version -30.
2020-07-14
31 Éric Vyncke Ballot comment text updated for Éric Vyncke
2020-07-10
31 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-07-08
31 Éric Vyncke Telechat date has been changed to 2020-07-16 from 2020-03-05
2020-07-08
31 Éric Vyncke IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2020-04-23
31 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-04-23
31 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-04-23
31 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-31.txt
2020-04-23
31 (System) New version approved
2020-04-23
31 (System) Request for posting confirmation emailed to previous authors: Ari Keranen , Miika Komu , Jan Melen
2020-04-23
31 Miika Komu Uploaded new revision
2020-03-17
30 Tero Kivinen Request for Telechat review by SECDIR Completed: Ready. Reviewer: Carl Wallace. Submission of review completed at an earlier date.
2020-03-05
30 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-03-05
30 Tero Kivinen Request for Telechat review by SECDIR Completed: Ready. Reviewer: Carl Wallace.
2020-03-05
30 Magnus Westerlund
[Ballot discuss]
So I think the below are important things that needs to be discussed before proceeding. However, I might have missed things as I …
[Ballot 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 chair@ietf.org. 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.
2020-03-05
30 Magnus Westerlund [Ballot comment]
May I inquire about the reasoning why this document do not obsolete RFC 5770?
2020-03-05
30 Magnus Westerlund Ballot comment and discuss text updated for Magnus Westerlund
2020-03-05
30 Magnus Westerlund
[Ballot discuss]
So this discuss should be relatively easy to address.

1. So this document recommends the usage of port 10500 as default listening port. …
[Ballot discuss]
So this discuss should be relatively easy to address.

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 chair@ietf.org. 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.
2020-03-05
30 Magnus Westerlund Ballot discuss text updated for Magnus Westerlund
2020-03-05
30 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-03-04
30 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2020-03-04
30 Barry Leiba
[Ballot comment]
Given this document’s dependency on concepts and terminology from 5770, I think that document has to be a normative reference.  Can someone really …
[Ballot comment]
Given this document’s dependency on concepts and terminology from 5770, I think that document has to be a normative reference.  Can someone really understand and implement this without any reference to 5770?

— Abstract —

  The main
  difference from the previously specified modes is the use of HIP
  messages instead of ICE for all NAT traversal procedures due to its
  kernel-space dependencies.

The antecedent to “its” is unclear: it could be “use of HIP messages”, or “ICE”, or “NAT traversal”.  Please rephrase to clarify.

— Section 1 —

  Also, especially NATs usually require the
  host behind a NAT to create a forwarding state in the NAT before
  other hosts outside of the NAT can contact the

What does “especially” mean in this sentence?  It doesn’t make sense to me.  Does it add anything?

  which will be referred as "Legacy ICE-HIP" in this document.

Nit: “referred to”

  HIP poses a unique challenge to using standard ICE, due not only to
  its kernel-space implementation, but also due to its close

Same comment about “its” as in the abstract: please replace “its” with what you’re talking about, as it isn’t clear.
2020-03-04
30 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-03-04
30 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-03-04
30 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-03-04
30 Magnus Westerlund
[Ballot discuss]
So this discuss should be relatively easy to address.

1. So this document recommends the usage of port 10500 as default listening port. …
[Ballot discuss]
So this discuss should be relatively easy to address.

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 chair@ietf.org. 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?

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?
2020-03-04
30 Magnus Westerlund Ballot discuss text updated for Magnus Westerlund
2020-03-04
30 Magnus Westerlund
[Ballot discuss]
So this discuss should be relatively easy to address.

So this document recommends the usage of port 10500 as default listening port. A …
[Ballot discuss]
So this discuss should be relatively easy to address.

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 chair@ietf.org. 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.
2020-03-04
30 Magnus Westerlund [Ballot comment]
May one inquire about the reasoning why this document do not obsolete RFC 5770?
2020-03-04
30 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2020-03-03
30 Benjamin Kaduk
[Ballot discuss]
One fairly minor point to start: Section 4.3 says that we define a new
mode (ICE-HIP-UDP) for the NAT_TRAVERSAL_MODE parameter type, but then …
[Ballot discuss]
One fairly minor point to start: Section 4.3 says that we define a new
mode (ICE-HIP-UDP) for the NAT_TRAVERSAL_MODE parameter type, but then
goes on to say that "the presence of the parameter in a HIP base
exchange means that the end-host supports NAT traversal extensions
defined in this document".  If I undrestand correctly, only the specific
presence of the ICE-HIP-UDP mode of the NAT_TRAVERSAL_MODE parameter
does so, and so to say that the presence of "the [NAT_TRAVERSAL_MODE]
parameter" indicates support for this document would be backwards
incompatible with RFC 5770.

I'd also like to delve a little further into the potential
"cross-protocol" attack (same protocol, really, but the same attack)
that Ekr raised, between RVS_HMAC and RELAY_HMAC.  This is probably a
"discuss discuss", so let's see where it leads...

The semantics for either type of HMAC is that it is an HMAC over the HIP
packet excluding itself and subsequent parameters.  Pulling up the HIP
packet format from RFC 7401, that looks like:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Next Header  | Header Length |0| Packet Type |Version| RES.|1|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Checksum            |          Controls            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Sender's Host Identity Tag (HIT)              |
  |                                                              |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Receiver's Host Identity Tag (HIT)              |
  |                                                              |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  /                        HIP Parameters                        /
  /                                                              /
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The HMAC key is the integrity key for that direction of traffic between
HITs, so the "cross-protocol" part can only come in by confusing the
packet recipient into confusion as to whether it is processing an
RVS_HMAC or a RELAY_HMAC (but any other entity will reject the packet by
virtue of it using the wrong key).  Modern best practices are to go
through a key derivation step that incorporates as much information as
possible about what the derived key will be used for, which would in
this case include the TLV type of the HMAC parameter and presumably the
HITs in question as well.

In particular, the TLV type of the HMAC parameter is *not* input into
the HMAC calculation (at least for RVS_HMAC), so the trivial
discriminator is not present.  The "packet type" in the header in the
header is potentially going to differ across usages, so I think that's a
good place to focus discussion.  Unfortunately, Section 4.2.1 of RFC
8004
suggests that RVS_HMAC is going to be present a lot of the time, so
it's not really clear to me what packet types either RVS_HMAC and/or
REPLAY_HMAC are expected to occur in.  Could a HIP expert please jump in
and help clarify?
2020-03-03
30 Benjamin Kaduk Ballot discuss text updated for Benjamin Kaduk
2020-03-03
30 Benjamin Kaduk
[Ballot discuss]
One fairly minor point to start: Section 4.3 says that we define a new
mode (ICE-HIP-UDP) for the NAT_TRAVERSAL_MODE parameter type, but then …
[Ballot discuss]
One fairly minor point to start: Section 4.3 says that we define a new
mode (ICE-HIP-UDP) for the NAT_TRAVERSAL_MODE parameter type, but then
goes on to say that "the presence of the parameter in a HIP base
exchange means that the end-host supports NAT traversal extensions
defined in this document".  If I undrestand correctly, only the specific
presence of the ICE-HIP-UDP mode of the NAT_TRAVERSAL_MODE parameter
does so, and so to say that the present of "the [NAT_TRAVERSAL_MODE]
parameter" indicates support for this document would be backwards
incompatible with RFC 5770.

I'd also like to delve a little further into the potential
"cross-protocol" attack (same protocol, really, but the same attack)
that Ekr raised, between RVS_HMAC and RELAY_HMAC.  This is probably a
"discuss discuss", so let's see where it leads...

The semantics for either type of HMAC is that it is an HMAC over the HIP
packet excluding itself and subsequent parameters.  Pulling up the HIP
packet format from RFC 7401, that looks like:

    0                  1                  2                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Next Header  | Header Length |0| Packet Type |Version| RES.|1|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Checksum            |          Controls            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Sender's Host Identity Tag (HIT)              |
  |                                                              |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Receiver's Host Identity Tag (HIT)              |
  |                                                              |
  |                                                              |
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  /                        HIP Parameters                        /
  /                                                              /
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The HMAC key is the integrity key for that direction of traffic between
HITs, so the "cross-protocol" part can only come in by confusing the
packet recipient into confusion as to whether it is processing an
RVS_HMAC or a RELAY_HMAC (but any other entity will reject the packet by
virtue of it using the wrong key).  Modern best practices are to go
through a key derivation step that incorporates as much information as
possible about what the derived key will be used for, which would in
this case include the TLV type of the HMAC parameter and presumably the
HITs in question as well.

In particular, the TLV type of the HMAC parameter is *not* input into
the HMAC calculation (at least for RVS_HMAC), so the trivial
discriminator is not present.  The "packet type" in the header in the
header is potentially going to differ across usages, so I think that's a
good place to focus discussion.  Unfortunately, Section 4.2.1 of RFC
8004
suggests that RVS_HMAC is going to be present a lot of the time, so
it's not really clear to me what packet types either RVS_HMAC and/or
REPLAY_HMAC are expected to occur in.  Could a HIP expert please jump in
and help clarify?
2020-03-03
30 Benjamin Kaduk
[Ballot comment]
[My latest reply to the ballot thread for my previous ballot position,
https://mailarchive.ietf.org/arch/msg/hipsec/iP_of3P2RfxJIbeVDz2qGonO8nY/
, seems to have not gotten a response]

Why did …
[Ballot comment]
[My latest reply to the ballot thread for my previous ballot position,
https://mailarchive.ietf.org/arch/msg/hipsec/iP_of3P2RfxJIbeVDz2qGonO8nY/
, seems to have not gotten a response]

Why did some rfc5245bis references get converted to RFC5245 and others
to RFC8445?

The phrase "Control Data Relay" occurs just five times in the document
(vs. over a hundred for "Control Relay") and seems to needlessly
conflate "Control Relay" and "Data Relay".  I'd suggest rewording to
avoid this phrase.

Abstract

  and UDP encapsulation of data and signaling traffic.  The main
  difference from the previously specified modes is the use of HIP
  messages instead of ICE for all NAT traversal procedures due to its
  kernel-space dependencies.

It might be worth disambiguating what "its" refers to.

Section 1

  messages tunneled over a single UDP flow.  The benefit of using ICE
  and its STUN/TURN messaging formats is that one can re-use the NAT
  traversal infrastructure already available in the Internet, such as
  STUN and TURN servers.  Also, some middleboxes may be STUN-aware and
  may be able to do something "smart" when they see STUN being used for
  NAT traversal.

Don't we go on to say that we can't actually use stock TURN
infrastructure since we'd need extra encapsulation for the HIP bits?

Section 2

  HIP offer:
      Before two end-hosts can establish a communication channel using
      the NAT traversal procedures defined in this document, they need
      exchange their locators (i.e. candidates) with each other.  In
      ICE, this procedure is called Candidate Exchange and it does
      specify how the candidates are exchanged but Session Description

nit: s/does specify/does not specify/

      handover.  Following [RFC5770] and Session Description Protocol
      (SDP) [RFC3264] naming conventions, "HIP offer" is the the

nit: we just expanded SDP a few lines previously; we probably don't need
to do it again.

Section 3

  connected to the public Internet.  To be contacted from behind a NAT,
  at least the Responder must be registered with is own Control Relay
  Server reachable on the public Internet.  The Responder may have also

nit: "is own" is not right; I'm not sure whether "his own" or "its own"
was intended (but the "a Control Relay Server in the -28 didn't seem
wrong to me either).

Section 4.1

  In step 3, the Relay Client selects the services for which it
  registers and lists them in the REG_REQ parameter.  The Relay Client
  registers for the Control Data Relay service by listing the
  RELAY_UDP_HIP value in the request parameter.  If the Relay Client
  requires also ESP relaying over UDP, it lists also RELAY_UDP_ESP.

(This is one of the five "Control Data Relay"s I mention previously.)
I'd suggest using "Data Relay Service" in combination with RELAY_UDP_ESP
to reinforce the link between the two terms.  The current "mix and
match" of "Control [...] Relay" and "RELAY_UDP_ESP" requires more effort
to understand than using a uniform set of terminology would.

  ECHO_REQUEST_SIGNED . In case the Data Relay Server admitted a new
  relayed UDP port for the Data Relay Client, the REG_RES parameter
  MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also
  include a RELAYED_ADDRESS parameter describing the relayed UDP port.

nit: "admitted" is a surprising word choice, to me.

Section 4.2

  local preference value MUST be unique.  Dual-stack considerations for
  IPv6 apply also here as defined in [RFC8445] in section 5.1.2.2.

It looks like this should be 5.1.2.1, not 5.1.2.2.

  where Ta is the value used for the connectivity check pacing and Num-
  Of-Cands is the sum of server-reflexive and relay candidates.  A
  smaller value than 500 ms for the RTO MUST NOT be used.

nit: I don't think addition is defined on (set-of-server-reflexive
candidates, set-of-relay candidates); presumably there's some missing
"number of"s here.

Section 4.3

  In step 4, the Responder concludes the base exchange with an R2
  packet.  If the Initiator chose ICE NAT traversal mode, the Responder

nit(?): s/ICE NAT/ICE-HIP-UDP/?

Section 4.5

  repeated here.  Similarly, the NAT traversal mode negotiation process
  (denoted as NAT_TM in the example) was described in Section 4.3 and
  is neither repeated here.  If a Control Relay Server receives an R1

nit: AFAIK this is not a correct usage of "neither".

  It is RECOMMENDED that the Initiator send an I1 packet encapsulated
  in UDP when it is destined to an IPv4 address of the Responder.

  Respectively, the Responder MUST respond to such an I1 packet with a
  UDP-encapsulated R1 packet, and also the rest of the communication
  related to the HIP association MUST also use UDP encapsulation.

Is this Responder behavior also restricted to IPv4?

  Server.  The Control Relay Server protects the I1 packet with
  RELAY_HMAC as described in [RFC8004], except that the parameter type
  is different (see Section 5.8).  The Control Relay Server changes the

I suggest dropping the 8004 reference and just using Section 5.8 of this
document.

  In step 3, the Responder receives the I1 packet.  The Responder
  processes it according to the rules in [RFC7401].  In addition, the
  Responder validates the RELAY_HMAC according to [RFC8004] and
  silently drops the packet if the validation fails.  The Responder

[likewise here]

  In step 7, the Responder receives the I2 packet and processes it
  according to [RFC7401].  The Responder validates the RELAY_HMAC
  according to [RFC8004] and silently drops the packet if the
  validation fails.  It replies with an R2 packet and includes a

[and here]

  Hosts MUST include the address of one or more Control Relay Servers
  (including the one that is being used for the initial signaling) in
  the LOCATOR_SET parameter in I2 and R2 if they intend to use such
  servers for relaying HIP signaling immediately after the base
  exchange completes.  The traffic type of these addresses MUST be "HIP
  signaling" and they MUST NOT be used as HIP candidates.  If the

I'm not sure I understand how the recipient will know that a given "HIP
signaling" candidate is intended only for signaling and is not to be
used as a HIP candidate.  Is that inherent to the "HIP signaling"
traffic type (vs. ESP)?  (We don't seem to define "HIP candidate"
specifically", which probably contributes to my confusion.)

Section 4.6.2


  All of the connectivity check packets MUST be protected with HMACs
  and signatures (even though the illustrations in this specification
  omit them for simplicity).  Each connectivity check sent by a host

Are these the RELAY_HMACs defined by this document or the normal
HIP_MAC?

  [RFC7401] states that UPDATE packets have to include either a SEQ or
  ACK parameter (or both).  According to the RFC, each SEQ parameter
  should be acknowledged separately.  In the context of NATs, this

I'm not finding where RFC 7401 says that each SEQ parameter should be
"acknowledged separately".  (A few sentences later we say that an ACK
parameter may acknowledge multiple sequence identifiers, too...)

  Full ICE procedures for prioritizing candidates, eliminating
  redundant candidates, forming check lists (including pruning) and
  triggered check-queues MUST be followed as specified in section 6.1
  [RFC8445], with the exception that the foundation, frozen candidates

nit: missing "of"

Section 4.7.2

  traversal mode as one of the supported modes in the R1 packet.  If
  the Responder has registered to a Control Relay Server in order to
  discover its address candidates, it MUST also include a LOCATOR_SET
  parameter in R1 that contains a preferred address where the Responder

Previous mentions of LOCATOR_SET have mandated an ENCRYPTED container.
If this instance is notable in its exception from that, I suggest
calling it out explicitly as not encrypted; otherwise, I think a
reminder might be in order.

  is able to receive UDP-encapsulated ESP and HIP packets.  This
  locator MUST be of type "Transport address", its Traffic type MUST be
  "both", and it MUST have the "Preferred bit" set (see Table 1).  If
  there is no such locator in R1, the source address of R1 is used as
  the Responder's preferred address.

Given the last sentence, it seems like the "MUST also include [...]
preferred address" is unenforceable by the Initiator.

Section 4.9

  responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in
  Figure 6.  Upon receiving the valid response from host M as described
  in step 6, the peer host MUST restart the connectivity checks with
  host M.  This way, both hosts start the connectivity checks roughly
  in a synchronized way.  It is also important that peer host does not
  restart the connectivity checks until it has received a valid "fresh"
  confirmation from host M because the UPDATE message carrying locators
  could be replayed by an attacker.

Can you remind me which step this "fresh" confirmation is in?  Step 6
doesn't really seem to match that description...

Section 5.4


  The format of NAT traversal mode parameter is borrowed from Legacy
  ICE-HIP [RFC5770].  The format of the NAT_TRAVERSAL_MODE parameter is

"Borrowed from"?  It had darn well better be *the same as* (i.e.,
"retained from") the RFC 5770 format, the way we're using the IANA
registry for NAT traversal modes...
(The "defined in [RFC5770]. but repeated for completeness" language we
use for TRANSACTION_PACING seems much better.)

Section 5.7

Should we say that the LOCATOR_SET must always appear within an
ENCRYPTED wrapper?

Section 6.1

It's hard to see the phrase "requires further experimentation" in a
proposed standard.  (Maybe it shouldn't be, given the "proposed" part,
but in practice it seems to be.)  Perhaps we could just say that which
host addresses to exclude from the LOCATOR_SET is a matter of local
policy?

  This scenario is referred to as the hairpin problem [RFC5128].  With
  such a legacy NAT, the only option left would be to use a relayed
  transport address from an Control Relay Server server.

Data Relay Server, no?  (Also, nit: "Server server".)

Section 6.7

  replay attacks that are difficult to prevent.  The connectivity
  checks in this protocol are immune against replay attacks because a
  connectivity request includes a random nonce that the recipient must
  sign and send back as a response.

If I was feeling particularly pedantic I'd request "effectively immune",
since there is the minor risk of collision in the random nonce values.

Section 10.1

RFC 5766 could probably be just an informative reference; RFCs 6146 and
6147 as well.

Section 10.2

I'm not sure that we still need to reference RFC 5245 (vs. 8445)?

The status of RFC 5770 is less clear; in Section 5 we note that "most of
the parameters are shown for the sake of completeness", implying that
not all are shown, which would in theory leave a normative dependency on
RFC 5770 for those parameters' interpretation.

Similarly, the status of RFC 3948 is also less clear; we do use a fair
bit of machinery from it and it's not trivially clear that we reproduce
everything that is needed.

Could we get "draft-rosenberg-mmusic-ice-nonsip" included in the
[MMUSIC-ICE] reference, assuming that's the right I-D?

Similarly, a draft name for [HIP-MIDDLE] would be helpful.

Appendix A

["further experimentation" here as well]
2020-03-03
30 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-03-03
30 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-03-03
30 Roman Danyliw
[Ballot comment]
** Section 6.1.  Per “Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments.”, …
[Ballot comment]
** Section 6.1.  Per “Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments.”, concur with the sentiment.  However, this desire to reduce exposure may be beyond just “corporate” environment – recommend dropping the “corporate” modifier.

** Section 6.1. Per “For these two local policy reasons, an end-host MAY exclude certain host addresses from its LOCATOR_SET parameter, but this requires further experimentation.”, what actions should implementers take from the “this requires further experimentation”? 

** Section 6.2.  Per “In opportunistic HIP mode (cf.  Section 4.1.8 in [RFC7401]), an Initiator sends an I1 with without setting  the destination HIT of the Responder”, the text conflicts on whether to send the destination HIT – it likely should say “without the destination HIT” (i.e., “initial I1 packet contains all zeros as the destination HIT” per RFC7401).

** Section 6.3.  Could the reference to [HIP-MIDDLE] be clarified:
-- The reference says its: “Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", Work in Progress, February 2009”.  Is that the same as draft-heer-hip-middle-auth-04, from October 2011? 

-- How much confidence is there in making this recommendation to an unpublished, expired experimental draft?

** Editorial Nits important for clarity in security considerations:
-- Section 5.8.  s/Similarly as with RVS_HMAC, also RELAY_HMAC is keyed .../Similarly as with RVS_HMAC, RELAY_HMAC .../

-- Section 6.1. Editorial.  s/Especially, this could be problematic with a …/This could be especially problematic with a …/

Section 6.1.  Recommend being clearing on the privacy and DoS protection by:
s/This partially protects the …/This use also partially protects the …/

-- Section 6.7  Editorial.  Recommend clarification how HIP is immune to the Section 19.2 of RFC8445 attack with:
s/HIP bases its control plane security  on Diffie-Hellman key exchange, public keys and Hashed Message Authentication codes, meaning that the mentioned security concerns do not apply to HIP either./
As HIP bases its control plane security  on Diffie-Hellman key exchange, public keys and Hashed Message Authentication codes, this attack is mitigated in this protocol./

-- Section 6.7.  Editorial.
s/The mentioned section discusses also of …/
Section 19.2 of [RFC8445] also mentioned also discusses …/

-- Section 6.7. Editorial.  Recommend referencing the text of the connectivity check that prevents the MiTM replay attack:
s/The connectivity checks in this protocol are immune … and send back as a response./
The connectivity checks in this protocol are immune … and send back as a response per Section 4.6.1./

Editorial Nits
-- Section 1.  Editorial.  Per “Also, especially NATs usually …” reads awkwardly to me – perhaps “Also, NATs usually ..”

-- Section 1.  Editorial.  Per “… so that basically ICE is responsible for NAT traversal …” reads colloquially – perhaps “so that ICE is responsible for NAT traversal …”

-- Section 1.  Editorial.  Per “Similarly as Legacy ICE-HIP, also this specification …”, it might be more readable as “As with Legacy ICE-HIP, this specification …”

-- Section 2.  Typo. s/prodecure/procedure/

-- Section 2. Typo. s/the the/the/

-- Section 3.  Typo.  s/Cotrol/Control/

-- Section 5.6.  Typo. s/reserved/reserved/

-- Section 6.5.  Typo. s/a another/another/

-- Section 7.  Typo. s/emphemeral/ephemeral/
2020-03-03
30 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-03-03
30 Éric Vyncke Following Alvaro Retana's suggestion. (even if https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-30 clearly show the relationship, it seems that the datatracker does not have the relationship)
2020-03-03
30 Éric Vyncke This document now replaces draft-keranen-hip-native-nat-traversal instead of None
2020-03-03
30 Alvaro Retana [Ballot comment]
Just for completeness, this document should be tagged as Replacing draft-keranen-hip-native-nat-traversal.
2020-03-03
30 Alvaro Retana Ballot comment text updated for Alvaro Retana
2020-03-03
30 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-03-03
30 Warren Kumari [Ballot comment]
Re-applying my ballot position from previous. This is largely based on the OpsDir review.
2020-03-03
30 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-02-26
30 Tero Kivinen Request for Telechat review by SECDIR is assigned to Carl Wallace
2020-02-26
30 Tero Kivinen Request for Telechat review by SECDIR is assigned to Carl Wallace
2020-02-26
30 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss points and most of my other comments. I believe the following comments from my previous ballot are still …
[Ballot comment]
Thanks for addressing my discuss points and most of my other comments. I believe the following comments from my previous ballot are still valid:

I agree with other ADs that it is not clear to me why this mechanism is needed in addition RFC5770. This is a use case for ICE and I would think that re-using existing code and library would make implementation easier, faster and less error-prone. I especially agree to the comments from Adam!

Other comments:

4) sec 4.8: "When a host does not receive
  acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout
  based on local policies, a host SHOULD resend the packet through the
  associated Data Relay Server of the peer (if the peer listed it in
  its LOCATOR_SET parameter in the base exchange."
I did not really find anything about this in section 5.10 of RFC5770. In think the timeout needs to be further specified.
2020-02-26
30 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2020-02-26
30 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss comment and most of my other comments. I believe the following comments from my previous ballot are still …
[Ballot comment]
Thanks for addressing my discuss comment and most of my other comments. I believe the following comments from my previous ballot are still valid:

I agree with other ADs that it is not clear to me why this mechanism is needed in addition RFC5770. This is a use case for ICE and I would think that re-using existing code and library would make implementation easier, faster and less error-prone. I especially agree to the comments from Adam!

Other comments:

4) sec 4.8: "When a host does not receive
  acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout
  based on local policies, a host SHOULD resend the packet through the
  associated Data Relay Server of the peer (if the peer listed it in
  its LOCATOR_SET parameter in the base exchange."
I did not really find anything about this in section 5.10 of RFC5770. In think the timeout needs to be further specified.
2020-02-26
30 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2020-02-24
30 Adam Roach
[Ballot comment]
Thanks to the authors for taking some of the concerns I laid out in my original ballot into account. I still do not …
[Ballot comment]
Thanks to the authors for taking some of the concerns I laid out in my original ballot into account. I still do not believe this approach is good for HIP's benefit, but am no longer worried about collateral damage from other protocols imitating this approach. Accordingly, I am balloting "No Objection."

There is one remaining comment from my initial review that I think can and should be addressed prior to publication:

Appendix B:

>  o  Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
>    protocol in order to avoid middlebox tampering.

This bullet should explain why such obfuscation is unnecessary.
2020-02-24
30 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2020-02-21
30 Éric Vyncke IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2020-02-21
30 Éric Vyncke Telechat date has been changed to 2020-03-05 from 2018-05-10
2020-02-21
30 Éric Vyncke [Ballot comment]
The -30 version addresses all DISCUSSs and COMMENTs raised during the May 2018 first ballot on version -28.
2020-02-21
30 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2020-02-21
30 Éric Vyncke Created "Approve" ballot
2020-02-21
30 Éric Vyncke Closed "Approve" ballot
2020-02-21
30 Éric Vyncke Ballot writeup was changed
2020-02-21
30 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-30.txt
2020-02-21
30 (System) New version approved
2020-02-21
30 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2020-02-21
30 Miika Komu Uploaded new revision
2020-02-19
29 Adam Roach
[Ballot comment]
Thanks to the authors for taking some of the concerns I lay out below
into account. I still do not believe this approach …
[Ballot comment]
Thanks to the authors for taking some of the concerns I lay out below
into account. I still do not believe this approach is good for HIP's
benefit, but am no longer worried about collateral damage from
other protocols imitating this approach. Accordingly, I am
updating my ballot to "No Objection." The original comments
from my Abstain ballot are preserved below for posterity.

===========================================================================

I share Ben's concerns about the disjointedness of this document's
specification, and am likewise abstaining. My reasons for abstaining are
deeper than Ben's, however.

I recognize that the effort put into this document is substantial, and that
the recommendations I make are unlikely to be taken at this point in time,
but I believe that the HIP ecosystem would be far better served by an "RFC
5570 bis" approach rather than a modified form of ICE recast using HIP
messages. Among other reasons: several companies already offer
geographically-distributed hosted TURN solutions, largely due to the relative
popularity of WebRTC. HIP will have to reach a similar level of popularity
before HIP-specific relay nodes are similarly commercially available.  Using
ICE as-is would allow HIP to use those services that are available today.

As a further concern, I worry that this pattern may end up replicated in other
protocols. For example, although ICE was initially developed with RTP/RTCP in
mind, it was not implemented as a series of extensions to RTP or RTCP;
instead, it is its own protocol, intended to be re-used in other contexts. I
would not like to see, e.g., ICE-like extensions to the QUIC protocol to enable
its use in peer-to-peer situations; I would certainly hope that such an effort
would use ICE as currently defined.

Given that the headline rationale offered in this document is that
"Implementing a full ICE/STUN/TURN protocol stack as specified in Legacy
ICE-HIP results in a considerable amount of effort and code which could be
avoided by re-using and extending HIP messages and state machines for the same
purpose," this document puts forth an implication that all protocols could
benefit from similar not-quite-ICE-but-almost-ICE extensions. I believe
this implication is harmful. I also believe this analysis overlooks the
availability of multiple existing, open-source, already-debugged, and
"compatible with commercial use" ICE implementations.

It is not clear that the four additional reasons offered in Appendix B are
sufficient to justify the design. Taken in turn:

>  For example, ICE is meant for application-layer protocols, whereas HIP
>  operates at layer 3.5 between transport and network layers.

This doesn't have practical effect: ICE is designed to work with generic UDP
packet flows, subject only to the ability to demultiplex STUN from such
packets.

>  This is particularly problematic because the implementations employ IPsec
>  ESP as their data plane: demultiplexing of incoming ESP, HIP and TURN
>  messages required capturing of all UDP packets destined to port 10500 to
>  the userspace, thus causing additional software complexity and an
>  unnecessary latency/throughput bottleneck for the dataplane performance.

This doesn't seem like a foregone consequence. If you're using user-space HIP
implementations, this user-space diversion is already necessary. If you're
using kernel-space HIP implementations, it seems a modest step to add minimal
STUN demultiplexing to the kernel implementation that is already performing
ESP/HIP demultiplexing.  It's possible that I'm misunderstanding some subtle
aspect of the way these protocols interact with each other, but isn't this
described performance impact simply the result of specific implementation
design decisions rather than inherent to the design of RFC 5570's mechanism?

>  Also, relaying of ESP packets via TURN relays was not
>  considered that simple because TURN relays require adding and
>  removing extra TURN framing for the relayed packets.

While it's been a while since I've looked at network kernel code, my
recollection is that implementation of the POSIX "sendmsg()" system call
generally maintains scatter/gather buffers all the way down the stack until
such bytes are copied from system memory to the network hardware. Stripping
such headers on receipt can be accomplished with simple pointer arithmetic.
It's not clear what aspect of the system "simple" is intended to refer to, but
both implementation and performance impacts should be immeasurably small when
implemented in this way, unless I'm missing something.

>  Finally, the developers of the two Legacy ICE-HIP implementations concluded
>  that "effort needed for integrating an ICE library into a HIP
>  implementation turned out to be quite a bit higher that initially
>  estimated.  Also, the amount of extra code (some 10 kLoC) needed for all
>  the new parsers, state machines, etc., is quite high and by re-using the
>  HIP code one should be able to do with much less.  This should result in
>  smaller binary size, less bugs, and easier debugging.".

Such size is not inherent in the implementation of ICE: for example, the ICE
stack used by Firefox is 2.2 kLoC in size (if you ignore the ~1.2 kLoC of
boilerplate copyright notice). Having seen the debugging of an ICE stack
up-close-and-personal, I'm pretty comfortable saying that the effort to
integrate a working stack has to be orders of magnitude less than implementing
even the simplified ICE procedures defined in this document correctly. There
are a lot of surprising corner cases that don't really turn up until you get
into production.

For the foregoing reasons, it is my conclusion that publication of this
document is harmful for HIP and is harmful as a precedent that other protocols
may mistakenly emulate. I believe that a restructuring of the document to more
clearly explain why HIP chose this path while other protocols should not would
limit some of these concerns. However, I do not believe that the fundamental
flaw -- a partial respecification of ICE for the cited reasons --  can be
fixed. I do not support publication of a document describing this mechanism,
and encourage the working group to withdraw the document from consideration
for publication.

To be clear: despite the length and detail of my preceding objections, I
recognize that I may be off in the weeds. I am happy to be corrected about
any of the assertions I make above, up to and including corrections that make my
conclusion incorrect. I will further note that this is not a blocking ballot
position, and that, procedurally, the document can be published despite my
misgivings.

===========================================================================

I have included some additional comments below.

---------------------------------------------------------------------------

§1:

>  As one solution, the HIP experiment report [RFC6538] mentions that
>  Teredo based NAT traversal for HIP and related ESP traffic (with
>  double tunneling overhead).

This isn't a sentence. Perhaps remove "that"?

Also: "Teredo-based"

---------------------------------------------------------------------------

§4.6:

>  The connectivity checks follow the ICE methodology [MMUSIC-ICE], but
>  UDP encapsulated HIP control messages are used instead of ICE
>  messages.  Only normal nomination MUST be used for the connectivity
>  checks, i.e., aggressive nomination MUST NOT be employed.

The cited document does not describe aggressive nomination, and deprecates its
use. Consider removing the mention of aggressive nomination in this document.

---------------------------------------------------------------------------

§5.4:

>    The following NAT traversal mode IDs are defined:
>
>        ID name            Value
>        RESERVED            0
>        UDP-ENCAPSULATION    1
>        ICE-STUN-UDP        2
>        ICE-HIP-UDP          3

This should probably point to the IANA table rather than replicating a snapshot
of its contents.

---------------------------------------------------------------------------

Appendix B:

>  o  Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
>    protocol in order to avoid middlebox tampering.

This bullet should explain why such obfuscation is unnecessary.
2020-02-19
29 Adam Roach [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Abstain
2020-02-19
29 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-19
29 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-02-19
29 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-29.txt
2020-02-19
29 (System) New version approved
2020-02-19
29 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2020-02-19
29 Miika Komu Uploaded new revision
2019-07-30
28 Mirja Kühlewind
[Ballot discuss]
1) This document should also update the IANA port registry to add a reference to this RFC-to-be to the existing entry for port …
[Ballot discuss]
1) This document should also update the IANA port registry to add a reference to this RFC-to-be to the existing entry for port 10500 (eventually even with note that this RFC-to-be discusses how to distinguish the services using NAT_TRAVERSAL_MODE).

2) Sec 4.4: "Hosts SHOULD NOT use values smaller than 5 ms for the minimum Ta,..."
In rfc5245bis this is a MUST. Why is this a SHOULD here?

Also in sec 4.6.2.:
"If neither one of the hosts announced a minimum pacing value, a value of 50 ms SHOULD be used."
This must be a MUST to be inline with sec 4.4.

3) Appendix A: "Ta value so that only two connectivity check messages are sent on every RTT."
Why two? RFC8085 recommends (SHOULD) at most one packet per RTT for non-congestion control transmissions
2019-07-30
28 Mirja Kühlewind Ballot discuss text updated for Mirja Kühlewind
2019-03-27
28 Amy Vezza Shepherding AD changed to Éric Vyncke
2018-05-10
28 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-05-10
28 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-05-10
28 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-05-10
28 Mirja Kühlewind
[Ballot comment]
I agree with other ADs that it is not clear to me why this mechanism is needed in addition RFC5770. This is …
[Ballot comment]
I agree with other ADs that it is not clear to me why this mechanism is needed in addition RFC5770. This is a use case for ICE and I would think that re-using existing code and library would make implementation easier, fast and less-error-prone. I especially agree to the comments from Adam!

Other comments/nits:

1) sec 4.6.2: "Upon successful nomination an address pair, a host MAY immediately stop sending such retransmissions."
Not sure I understand this sentence; why MAY?

2) sec 4.1: The registration to the Control Relay Server can be achieved using
  RELAY_UDP_ESP parameter as explained later in this section."
I guess that should be RELAY_UDP_HIP?

3) sec 4.1: "It is RECOMMENDED that the Relay Client select a random port number..."
Please say source port -> s/random port number/random source port number/

4) sec 4.8: "When a host does not receive
  acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout
  based on local policies, a host SHOULD resend the packet through the
  associated Data Relay Server of the peer (if the peer listed it in
  its LOCATOR_SET parameter in the base exchange."
I did not really find anything about this in section 5.10 of RFC5770. In think the timeout needs to be further specified.

5) sec 5.3: "It is worth noting that sending of such a HIP NOTIFY
  message MAY be omitted if the host is actively (or passively) sending
  some other traffic (HIP or ESP) "
This should really be a SHOULD (at least).

6) Appendix A: "One way to estimate the RTT is to use the time that it takes for the Control Relay Server registration exchange to complete;"
That does estimate the RTT between the endhost... I not aware of a good way to estimate that, so I'm actually not convinced that the recommendation in appendix A is that useful at all.
2018-05-10
28 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-05-10
28 Mirja Kühlewind
[Ballot discuss]
1) This document should also update the IANA port registry to add a reference to this RFC-to-be to the existing entry for port …
[Ballot discuss]
1) This document should also update the IANA port registry to add a reference to this RFC-to-be to the existing entry for port 10500 (eventually even with note that this RFC-to-be discusses how to distinguish the services using NAT_TRAVERSAL_MODE).

2) Sec 4.4: "Hosts SHOULD NOT use values smaller than 5 ms for the minimum Ta,..."
In rfc5245bis this is a MUST. Why is this a SHOULD here?

Also in sec 4.6.2.:
"If neither one of the hosts announced a minimum pacing value, a value of 50 ms SHOULD be used."
This must be a MUST to be inline with sec 4.4.

3) Appendix A: "Ta value so that only two connectivity check messages are sent on every RTT."
Why two? RFC8085 recommends (SHOULD) at may one packet per RTT for non-congestion control transmissions
2018-05-10
28 Mirja Kühlewind
[Ballot comment]
I agree with other ADs that it is not clear to me why this mechanism is needed in addition RFC5770. This is …
[Ballot comment]
I agree with other ADs that it is not clear to me why this mechanism is needed in addition RFC5770. This is a use case for ICE and I would think that re-using existing code and library would make implementation easier, fast and less-error-prone. I especially agree to the comments from Adam!

Other comments/nits:

1) sec 4.6.2: "Upon successful nomination an address pair, a host MAY immediately stop sending such retransmissions."
Not sure I understand this sentence; why MAY?

2) sec 4.1: The registration to the Control Relay Server can be achieved using
  RELAY_UDP_ESP parameter as explained later in this section."
I guess that should be RELAY_UDP_HIP?

3) sec 4.1: "It is RECOMMENDED that the Relay Client select a random port number..."
Please say source port -> s/random port number/random source port number/

4) sec 4.8: "When a host does not receive
  acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout
  based on local policies, a host SHOULD resend the packet through the
  associated Data Relay Server of the peer (if the peer listed it in
  its LOCATOR_SET parameter in the base exchange."
I did not really find anything about this in section 5.10 of RFC5770. In think the timeout needs to be further specified.

5) sec 5.3: "It is worth noting that sending of such a HIP NOTIFY
  message MAY be omitted if the host is actively (or passively) sending
  some other traffic (HIP or ESP) "
This should really be a SHOULD (at least).

6) Appendix A: "One way to estimate the RTT is to use the time that it takes for the
  Control Relay Server registration exchange to complete;"
That does estimate the RTT between the endhost... I not aware of a good way to estimate that, so I'm actually not convinced that the recommendation in appendix A is that useful at all.
2018-05-10
28 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to Discuss from No Record
2018-05-09
28 Adam Roach
[Ballot comment]
I share Ben's concerns about the disjointedness of this document's
specification, and am likewise abstaining. My reasons for abstaining are
deeper than Ben's, …
[Ballot comment]
I share Ben's concerns about the disjointedness of this document's
specification, and am likewise abstaining. My reasons for abstaining are
deeper than Ben's, however.

I recognize that the effort put into this document is substantial, and that
the recommendations I make are unlikely to be taken at this point in time,
but I believe that the HIP ecosystem would be far better served by an "RFC
5570 bis" approach rather than a modified form of ICE recast using HIP
messages. Among other reasons: several companies already offer
geographically-distributed hosted TURN solutions, largely due to the relative
popularity of WebRTC. HIP will have to reach a similar level of popularity
before HIP-specific relay nodes are similarly commercially available.  Using
ICE as-is would allow HIP to use those services that are available today.

As a further concern, I worry that this pattern may end up replicated in other
protocols. For example, although ICE was initially developed with RTP/RTCP in
mind, it was not implemented as a series of extensions to RTP or RTCP;
instead, it is its own protocol, intended to be re-used in other contexts. I
would not like to see, e.g., ICE-like extensions to the QUIC protocol to enable
its use in peer-to-peer situations; I would certainly hope that such an effort
would use ICE as currently defined.

Given that the headline rationale offered in this document is that
"Implementing a full ICE/STUN/TURN protocol stack as specified in Legacy
ICE-HIP results in a considerable amount of effort and code which could be
avoided by re-using and extending HIP messages and state machines for the same
purpose," this document puts forth an implication that all protocols could
benefit from similar not-quite-ICE-but-almost-ICE extensions. I believe
this implication is harmful. I also believe this analysis overlooks the
availability of multiple existing, open-source, already-debugged, and
"compatible with commercial use" ICE implementations.

It is not clear that the four additional reasons offered in Appendix B are
sufficient to justify the design. Taken in turn:

>  For example, ICE is meant for application-layer protocols, whereas HIP
>  operates at layer 3.5 between transport and network layers.

This doesn't have practical effect: ICE is designed to work with generic UDP
packet flows, subject only to the ability to demultiplex STUN from such
packets.

>  This is particularly problematic because the implementations employ IPsec
>  ESP as their data plane: demultiplexing of incoming ESP, HIP and TURN
>  messages required capturing of all UDP packets destined to port 10500 to
>  the userspace, thus causing additional software complexity and an
>  unnecessary latency/throughput bottleneck for the dataplane performance.

This doesn't seem like a foregone consequence. If you're using user-space HIP
implementations, this user-space diversion is already necessary. If you're
using kernel-space HIP implementations, it seems a modest step to add minimal
STUN demultiplexing to the kernel implementation that is already performing
ESP/HIP demultiplexing.  It's possible that I'm misunderstanding some subtle
aspect of the way these protocols interact with each other, but isn't this
described performance impact simply the result of specific implementation
design decisions rather than inherent to the design of RFC 5570's mechanism?

>  Also, relaying of ESP packets via TURN relays was not
>  considered that simple because TURN relays require adding and
>  removing extra TURN framing for the relayed packets.

While it's been a while since I've looked at network kernel code, my
recollection is that implementation of the POSIX "sendmsg()" system call
generally maintains scatter/gather buffers all the way down the stack until
such bytes are copied from system memory to the network hardware. Stripping
such headers on receipt can be accomplished with simple pointer arithmetic.
It's not clear what aspect of the system "simple" is intended to refer to, but
both implementation and performance impacts should be immeasurably small when
implemented in this way, unless I'm missing something.

>  Finally, the developers of the two Legacy ICE-HIP implementations concluded
>  that "effort needed for integrating an ICE library into a HIP
>  implementation turned out to be quite a bit higher that initially
>  estimated.  Also, the amount of extra code (some 10 kLoC) needed for all
>  the new parsers, state machines, etc., is quite high and by re-using the
>  HIP code one should be able to do with much less.  This should result in
>  smaller binary size, less bugs, and easier debugging.".

Such size is not inherent in the implementation of ICE: for example, the ICE
stack used by Firefox is 2.2 kLoC in size (if you ignore the ~1.2 kLoC of
boilerplate copyright notice). Having seen the debugging of an ICE stack
up-close-and-personal, I'm pretty comfortable saying that the effort to
integrate a working stack has to be orders of magnitude less than implementing
even the simplified ICE procedures defined in this document correctly. There
are a lot of surprising corner cases that don't really turn up until you get
into production.

For the foregoing reasons, it is my conclusion that publication of this
document is harmful for HIP and is harmful as a precedent that other protocols
may mistakenly emulate. I believe that a restructuring of the document to more
clearly explain why HIP chose this path while other protocols should not would
limit some of these concerns. However, I do not believe that the fundamental
flaw -- a partial respecification of ICE for the cited reasons --  can be
fixed. I do not support publication of a document describing this mechanism,
and encourage the working group to withdraw the document from consideration
for publication.

To be clear: despite the length and detail of my preceding objections, I
recognize that I may be off in the weeds. I am happy to be corrected about
any of the assertions I make above, up to and including corrections that make my
conclusion incorrect. I will further note that this is not a blocking ballot
position, and that, procedurally, the document can be published despite my
misgivings.

===========================================================================

I have included some additional comments below.

---------------------------------------------------------------------------

§1:

>  As one solution, the HIP experiment report [RFC6538] mentions that
>  Teredo based NAT traversal for HIP and related ESP traffic (with
>  double tunneling overhead).

This isn't a sentence. Perhaps remove "that"?

Also: "Teredo-based"

---------------------------------------------------------------------------

§4.6:

>  The connectivity checks follow the ICE methodology [MMUSIC-ICE], but
>  UDP encapsulated HIP control messages are used instead of ICE
>  messages.  Only normal nomination MUST be used for the connectivity
>  checks, i.e., aggressive nomination MUST NOT be employed.

The cited document does not describe aggressive nomination, and deprecates its
use. Consider removing the mention of aggressive nomination in this document.

---------------------------------------------------------------------------

§5.4:

>    The following NAT traversal mode IDs are defined:
>
>        ID name            Value
>        RESERVED            0
>        UDP-ENCAPSULATION    1
>        ICE-STUN-UDP        2
>        ICE-HIP-UDP          3

This should probably point to the IANA table rather than replicating a snapshot
of its contents.

---------------------------------------------------------------------------

Appendix B:

>  o  Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
>    protocol in order to avoid middlebox tampering.

This bullet should explain why such obfuscation is unnecessary.
2018-05-09
28 Adam Roach [Ballot Position Update] New position, Abstain, has been recorded for Adam Roach
2018-05-09
28 Ben Campbell
[Ballot comment]
I support all points of Ekr's discuss and comment points. I think this either needs to use ICE mostly as is (maybe with …
[Ballot comment]
I support all points of Ekr's discuss and comment points. I think this either needs to use ICE mostly as is (maybe with some minor profiling) or it needs to be self-contained here. I understand the material in appendix B, but the current mix seems untenable for implementors. Therefore I am balloting "abstain".  I will reconsider that position if there is a substantial reorganization.

Substantive Comments:

I share Alissa's question about why this is standard track when the previous work has been experimental.

§1, second paragraph: The citation for the version of ICE used by "legacy ICE-HIP" should be RFC5245, not the bis version.

§2: There are a number of lower-case keywords. Please use the RFC 8174 boilerplate.

§4.2:
- paragraph 5: Is everything in this paragraph from the ICE specification? I suspect not, but it's hard to tease out what is from ICE and what is new specification. It would be helpful to reference the ICE bits by section number.
- paragraph 6: I'm confused in that I thought the previous text said that native ICE-HIP does not use STUN.

§6: I am skeptical of the assertion that the security considerations for Native ICE-HIP are no different than those for Legacy ICE-HIP.

Editorial Comments:

§1, 2nd paragraph:
- "responsible of NAT traversal": s/of/to
- "responsible of end-host": s/of/to

§4.3: "This section describes the usage of a new non-critical parameter type. ": Which is?

§4.6, first paragraph: 2nd sentence is hard to parse.
2018-05-09
28 Ben Campbell [Ballot Position Update] New position, Abstain, has been recorded for Ben Campbell
2018-05-09
28 Spencer Dawkins
[Ballot comment]
I'm balloting No Objection, but I'm watching the discussion in Eric's ballot thread about reusing pieces of ICE, and I look forward to …
[Ballot comment]
I'm balloting No Objection, but I'm watching the discussion in Eric's ballot thread about reusing pieces of ICE, and I look forward to some discussion about the provisions being made for middleboxes in this draft - I'm not denying that such things exist, only that it would be best if we understood why middleboxes are needed for this usage.
2018-05-09
28 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-05-09
28 Alvaro Retana
[Ballot comment]
Like Benjamin, I also found the relationship between this document and ICE somewhat confusing until the very end (Appendix B).  The attempt to …
[Ballot comment]
Like Benjamin, I also found the relationship between this document and ICE somewhat confusing until the very end (Appendix B).  The attempt to "follow ICE methodology but reuse HIP messaging format to achieve the same functionality" results in lack of clarity, so I also agree with Eric's opinion that a rewrite would help, and support his DISCUSS.
2018-05-09
28 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-05-09
28 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-05-09
28 Alissa Cooper
[Ballot comment]
I admit to not having much familiarity with HIP, so apologies if some of these questions seem off-base.

Why is this document on …
[Ballot comment]
I admit to not having much familiarity with HIP, so apologies if some of these questions seem off-base.

Why is this document on the standards track when RFC 5770 was experimental?

Section 6.1 says:

"The locators are in plain text format in favor of inspection at HIP-
  aware middleboxes in the future.  The current document does not
  specify encrypted versions of LOCATOR_SETs, even though it could be
  beneficial for privacy reasons to avoid disclosing them to
  middleboxes."

This seems to cut in the opposite direction of some of the other work we have going on in the IETF, where the justification for maintaining header information in the clear is for backwards-compatability with existing middleboxes, not to facilitate some to-be-developed middlebox behavior. Why is this justified for HIP?

Section 6.1 also says "an end-host may exclude certain host addresses from its LOCATOR_SET parameter," but I don't think this is totally clear in Section 4.5 where it talks about "all the HIP candidates." I also wonder if it would be possible to provide some guidance about the circumstances under which an initiator might choose to exclude certain addresses, e.g. if there is a common deployment scenario where it's clear that certain candidates are meant to remain private.

Nits:

= Section 1 =

" As one solution, the HIP experiment report [RFC6538] mentions that
  Teredo based NAT traversal for HIP and related ESP traffic (with
  double tunneling overhead)."

This is a sentence fragment.

= Section 2 =

The paragraph about RFC2119 should also reference RFC8174.
2018-05-09
28 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-05-09
28 Benjamin Kaduk
[Ballot comment]
This document does a poor job at convincing me that there
is a need to re-specify ICE for use in HIP contexts as …
[Ballot comment]
This document does a poor job at convincing me that there
is a need to re-specify ICE for use in HIP contexts as opposed to
just using ICE directly, up until Appendix B.  I'd suggest moving
some of the key points into at least the Introduction and arguably
the Abstract as well, to make it clear that this is not just
needless duplication for ideological purity.

I think there's some lingering terminology confusion (as a result of
needing to align the new bits in Native HIP-ICE with those retained
from RFC 5077, along with the move from 5245 to 5245bis.
Specifically, while it's fine for this document to refer to "ICE
offer" and "ICE answer", 5245bis itself does not talk of "offer" and
"answer", which are now concepts only in SDP, IIUC.  Things also
seem a bit hazy about server reflexive vs. server relay candidates
(though maybe here the confusion is just on my end) -- in regular
ICE, a server reflexive candidate is obtained by a STUN client
making a one-shot request of a STUN server to find out what address
is being used on the other side of a NAT, and doesn't require any
state on the STUN server.  But in this document we have a
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED Notify/error packet
that implies that state is needed on the Data Relay Server for a
reflexive candidate, text about "when the relay service is split
between hosts, the server reflexive candidate [from Control SHOULD
be used over the one from Data]", and also other discussion about
needing to register new reflexive candidates to avoid collisions or
in potential multihoming future work.

Some section-by-section comments follow.

Section 2

  Responder:
      The Responder is the host that receives the I1 packet from the
      Initiator.

Does this still hold if the message is misdelivered or an attacker
is in the network?


Section 3

  [...] At this point, also the HIP signaling can be sent over the
  same address/port pair, and is demultiplexed from IPsec as described
  in the UDP encapsulation standard for IPsec [RFC3948].

"demultiplex" does not appear anywhere in RFC 3948; it might be
worth using a few more words here to clarify what is going on.


Section 4.1

  A Control Relay Server MUST silently drop packets to a Control Relay
  Client that has not previously registered with the HIP relay.

How does the relay know where they are targetted without the
registration information?

  This applies both renewals of service registration but also to host
  movement, where especially the latter requires the Control Relay
  Client to learn its new server reflexive address candidate.

This is kind of awkward wording; maybe:

  This applies to both renewals of service registration and to host
  movement.  It is especially important for the case of host
  movement, as this is the mechanism that allows the Control Relay
  Client to learn its new server reflexive address candidate.


Section 4.2

  [...] A host SHOULD employ only a single server for
  gathering the candidates for a single HIP association; either one
  server providing both Control and Data Relay Server functionality, or
  one Control Relay Server and also Data Relay Server if the
  functionality is offered by another server.

The second half of this sentence seems to contradict the SHOULD, so
probably some rewording is in order.

  [...] If a relayed candidate is identical to a host
  candidate, the relayed candidate must be discarded.  NAT64
  considerations in [I-D.ietf-ice-rfc5245bis] apply as well.

I don't think this has enough detail of reference to ICE -- a
relayed candidate being identical to a host candidate is, IIUC,
quite unexpected.  This is even noted in 5245bis, at the bottom of
page 20 (of the -20).

  Unlike ICE, this protocol only creates a single UDP flow between the
  two communicating hosts, so only a single component exists.  Hence,
  the component ID value MUST always be set to 1.

ICE or SDP?


Section 4.5

  In step 2, the Control Relay Server receives the I1 packet.  If the
  destination HIT belongs to a registered Responder, the Control Relay
  Server processes the packet.

Do HIP participants register specifically as Responder/Initiator, or
is this just that the entity that is Responder in this exchange, has
registered at the Control Relay Server?

  [...] The
  RELAY_TO parameter is not integrity protected by the signature of the
  R1 to allow pre-created R1 packets at the Responder.

This seems to allow an attacker to replay R1 packets and have the
Relay transmit them to the Initiator.  Are there cases where this
presents an increase in attacker capabilities (e.g., when the Relay
is allowed to send to the Initiator but the attacker is not)?
(When would such pre-created R1 packets be useful?)

Should step 7 explicitly duplicate the "validate REPLAY_HMAC" part
of step 3?


Section 4.6

The situation with the (non-)existence of aggressive nomination between
5245bis and MMUSIC-ICE probably merits further investigation.
(That is, it may not be necessary to mention explicitly that regular
nomination is used.)

  The Initiator MUST take the role of controlling host and the
  Responder acts as the controlled host.  The roles MUST persist
  throughout the HIP associate lifetime (to be reused in the possibly
  mobility UPDATE procedures).  In the case both communicating nodes
  are initiating the communications to each other using an I1 packet,
  the conflict is resolved as defined in section 6.7 in [RFC7401]: the
  host with the "larger" HIT changes to its Role to Responder.  In such
  a case, the host changing its role to Responder MUST also switch to
  controlling role.

The last clause seems to not match the earlier text about the
Initiator being the controlling role.


Section 4.6.1

  In step 2, the Initiator sends a connectivity check, using the same
  address pair candidate as in the previous step, and the message
  traverses successfully the NAT boxes.  The message includes the same
  parameters as in the previous step.  It should be noted that the
  sequence identifier is locally assigned by the Responder, so it can
  be different than in the previous step.

Step 2 is from Initiator to Responder, and the message in step 1 got
dropped, so I'm quite confused at how the sequence identifier in
step 2 could be assigned by the Responder as opposed to the
Initiator.

Step 4 could say whether the sequence number from step 1 is reused
or a new one is allocated for the retransmission (even though it is
clarified later as "SHOULD be sent with the same sequence
identifier").


Section 4.7.2

  [...] However, the
  Responder SHOULD NOT send any ESP to the Initiator's address before
  it has received data from the Initiator, as specified in Sections
  4.4.3. and 6.9 of [RFC7401] and in Sections 3.2.9 and 5.4 of
  [RFC8046].

I don't see a Section 3.2.9 in RFC 8046.

  Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected
  MUST NOT be sent via a Control Relay Server, the Responder SHOULD
  reject such I2 packets and reply with a
  NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see
  Section 5.10).

How does this mesh with a few paragraphs back, when the Responder
MUST include the address it got by registering at a Control Relay
Server in its R1 (only when it is including UDP-ENCAPSULATION NAT as
one of its supported modes)?


Section 4.7.3

  [...] The Initiator may receive multiple R1 packets, with
  and without UDP encapsulation, from the Responder.  However, after
  receiving a valid R1 and answering it with an I2, further R1 packets
  that are not retransmissions of the original R1 message MUST be
  ignored.

We just said there may be multiple, so which one is "the" original
R1 message?


Should Section 4.8 repeat the earlier admonitions against a Relay
Server forwarding traffic that does not involve a Client that has
egistered with that Relay Server?


Section 4.9

The relay still has to apply RELAY_HMAC; that's just not currently
shown in the diagram, right?


Section 5.6

  The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
  shown in Figure 10.  All parameters are identical except for the
  type.  REG_FROM is the only parameter covered with the signature.

I suggest "Of the three, only REG_FROM is covered by the signature."


Section 6.1

The RFC 5770 text talks about TURN servers, but that's no longer
applicable in this document (instead, Data Relay Servers are used to
relay data in a similar usage).

Also, the protection against DoS described in the last paragraph
seems to only be partial protection, since incoming connections can
still be affected by DoS, but outgoing ones are still possible.


Section 6.2

This is the first mention of Opportunistic Mode at all in the
document; it might be nice to refer to the section of 7401 where
it's documented.


Section 6.6

Is the invalid list of candidates sent *for* its peer or *to* its
peer?


Appendix B

  o  Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
      protocol in order to avoid middlebox tampering.

This reads a bit oddly.  Just to check: we don't need to do the
XORing in Native ICE-HIP because the addresses are covered by an
HMAC and the "tampering" wouldn't work?
If so I'd suggest:

  o  In ICE, addresses being conveyed across a NAT are XOR-ed to
      prevent middlebox tampering.  Native ICE-HIP does not need to
      use XOR because such tampering is prevented at the HIP layer.
2018-05-09
28 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-05-07
28 Mirja Kühlewind
[Ballot comment]
sec 4.1: The registration to the Control Relay Server can be achieved using
  RELAY_UDP_ESP parameter as explained later in this section."
I …
[Ballot comment]
sec 4.1: The registration to the Control Relay Server can be achieved using
  RELAY_UDP_ESP parameter as explained later in this section."
I guess that should be RELAY_UDP_HIP?
2018-05-07
28 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2018-05-04
28 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3099


I am very familiar with ICE and yet I found this document extremely
hard to follow. …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3099


I am very familiar with ICE and yet I found this document extremely
hard to follow. The problem is that it cherry-picks pieces of ICE and
I'm just not sure that it's a complete specification when put all
together. I have noted a number of places where I actually am not sure
how to implement something, and fixing those will resolve this
DISCUSS, but IMO you really should totally rewrite this document
either (a) as a variant of ICE or (b) as an entirely new document not
with a pile of new text and then references out to ICE sections.

DETAIL
S 4.2.
>      request type SHOULD NOT create any state at the Control Relay Server.

>      ICE guidelines [I-D.ietf-ice-rfc5245bis] for candidate gathering are
>      followed here.  A number of host candidates (loopback, anycast and
>      others) should be excluded as described in the ICE specification
>      [I-D.ietf-ice-rfc5245bis].  Relayed candidates SHOULD be gathered in

If you're going to normatively cherry-pick ICE, you need to note
specific sections, I think.


S 4.6.2.

>      A host may receive a connectivity check before it has received the
>      candidates from its peer.  In such a case, the host MUST immediately
>      generate a response, and then continue waiting for the candidates.  A
>      host MUST NOT select a candidate pair until it has verified the pair
>      using a connectivity check as defined in Section 4.6.1.

Are you supposed to put this on a TODO check list as with ICE?


S 5.8.

>  5.8.  RELAY_HMAC Parameter

>      As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter
>      value has the TLV type 65520.  It has the same semantics as RVS_HMAC
>      [RFC8004].

What key is used for the HMAC?
2018-05-04
28 Eric Rescorla
[Ballot comment]
S 2.
>      Server reflexive candidate:
>        A translated transport address of a host as observed by a …
[Ballot comment]
S 2.
>      Server reflexive candidate:
>        A translated transport address of a host as observed by a Control
>        or Data Relay Server.

>      Peer reflexive candidate:
>        A translated transport address of a host as observed by its peer.

You should indicate which definitions are the same as ICE/STUN


S 3.
>      connected to the public Internet.  To be contacted from behind a NAT,
>      at least the Responder must be registered with a Control Relay Server
>      reachable on the public Internet.  The Responder may have also
>      registered to a Data Relay Server that can forward the data plane in
>      case NAT traversal fails.  While, strictly speaking, the Initiator
>      does not need any Relay Servers, it may act in the other role with

Why doesn't it need Relay Servers? This isn't true for ordinary ICE.


S 4.1.
>      for that host and close the corresponding UDP port (unless other Data
>      Relay Clients are still using it).

>      The Data Relay Server SHOULD offer a different relayed address and
>      port for each Data Relay Client because this can cause problems with
>      stateful firewalls (see Section 6.5).

by "this" I think you mean "not doing so"



S 4.2.
>      parameter discovered during the Control Relay Server registration as
>      a server reflexive candidate.  In this case, no further candidate
>      gathering is needed.

>      A Data Relay Client MAY register only a single relayed candidate to
>      be used with multiple other peers.  However, it is RECOMMENDED that a

Nit: this would be clearer if you said "that it uses with"


S 4.2.
>      gathering is needed.

>      A Data Relay Client MAY register only a single relayed candidate to
>      be used with multiple other peers.  However, it is RECOMMENDED that a
>      Data Relay Client registers a new server reflexive candidate for each
>      of its peer for the reasons described in Section 4.12.3.  The

This sentence feels like a bit of a non-sequiter. How do you
"register" a srflx? Or should this say "relayed"


S 4.2.
>      deployments in order to enable it by software configuration update if
>      needed at some point.  A host SHOULD employ only a single server for
>      gathering the candidates for a single HIP association; either one
>      server providing both Control and Data Relay Server functionality, or
>      one Control Relay Server and also Data Relay Server if the
>      functionality is offered by another server.  When the relay service

How does this interact with mult-layered NAT?>


S 4.3.
>      Servers (e.g. in the case of a single server, it would be 1).  A
>      smaller value than 500 ms for the RTO MUST NOT be used.

>  4.3.  NAT Traversal Mode Negotiation

>      This section describes the usage of a new non-critical parameter

Can you name the type here please?


S 5.6.
>        Protocol  IANA assigned, Internet Protocol number.
>                  17 for UDP, 0 for plain IP
>        Reserved  reserved for future use; zero when sent, ignored
>                  when received
>        Address    an IPv6 address or an IPv4 address in "IPv4-Mapped
>                  IPv6 address" format

Is there a concern about NATs rewriting these, as we had for XOR-
MAPPED-ADDRESS


S 5.7.
>      | Reserved  | 0        | Reserved for future extensions            |
>      | Preferred | 0 or 1  | Set to 1 for a Locator in R1 if the        |
>      | (P) bit  |          | Responder can use it for the rest of the  |
>      |          |          | base exchange, otherwise set to zero      |
>      | Locator  | Variable | Locator lifetime in seconds                |
>      | Lifetime  |          |                                            |

What is the purpose of this? It's not an ICE parameter.


S 5.7.
>      | Port      |          |                                            |
>      | Transport | Variable | IANA assigned, transport layer Internet    |
>      | Protocol  |          | Protocol number.  Currently only UDP (17)  |
>      |          |          | is supported.                              |
>      | Kind      | Variable | 0 for host, 1 for server reflexive, 2 for  |
>      |          |          | peer reflexive or 3 for relayed address    |

Why do you need to send prflx candidates?


S 10.2.
>      o  If the agent is using Diffserv Codepoint markings [RFC2475] in its
>        media packets, it SHOULD apply those same markings to its
>        connectivity checks.

>      o  Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
>        protocol in order to avoid middlebox tampering.

I noted this earlier. Why?
2018-05-04
28 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2018-04-08
28 Roni Even Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list.
2018-04-05
28 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2018-04-05
28 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2018-03-30
28 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-03-21
28 Terry Manderson Placed on agenda for telechat - 2018-05-10
2018-03-21
28 Terry Manderson IESG state changed to IESG Evaluation from Waiting for Writeup
2018-03-21
28 Terry Manderson Ballot has been issued
2018-03-21
28 Terry Manderson [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson
2018-03-21
28 Terry Manderson Created "Approve" ballot
2018-03-21
28 Terry Manderson Ballot writeup was changed
2018-03-15
28 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Carl Wallace.
2018-03-05
28 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-03-05
28 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-28.txt
2018-03-05
28 (System) New version approved
2018-03-05
28 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2018-03-05
28 Miika Komu Uploaded new revision
2018-02-27
27 Tianran Zhou Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tianran Zhou. Sent review to list.
2018-02-26
27 Colin Perkins Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Colin Perkins.
2018-02-26
27 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2018-02-26
27 Roni Even Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Roni Even. Sent review to list.
2018-02-26
27 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-02-23
27 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-02-23
27 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-hip-native-nat-traversal-27. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-hip-native-nat-traversal-27. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are six actions which we must complete.

First, in the Parameter Types registry on the Host Identity Protocol (HIP) Parameters registry page located at:

https://www.iana.org/assignments/hip-parameters/

three new parameter types are to be registered as follows:

Value: [ TBD-at-Registration ]
Parameter Type: RELAYED_ADDRESS
Length:
Reverence: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Parameter Type: MAPPED_ADDRESS
Length:
Reverence: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Parameter Type: PEER_PERMISSION
Length:
Reverence: [ RFC-to-be ]

IANA Question --> What is the length of these three new parameter types? Sections 5.12 and 5.13 seem to indicate that the length should be 16, but there is no direction in the IANA Considerations section as to how this field should be set for these three registrations.

Second, in the HIP NAT Traversal Modes registry also on the Host Identity Protocol (HIP) Parameters registry page located at:

https://www.iana.org/assignments/hip-parameters/

a new traversal mode is to be registered as follows:

Value: [ TBD-at-Registration ]
Identifier: ICE-HIP-UDP
Reference: [ RFC-to-be ]

Third, in the Registration Types registry also on the Host Identity Protocol (HIP) Parameters registry page located at:

https://www.iana.org/assignments/hip-parameters/

two new registrations types are to be registered as follows:

Value: [ TBD-at-Registration ]
Registration Type: RELAY_UDP_ESP
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Registration Type: CANDIDATE_DISCOVERY
Reference: [ RFC-to-be ]

Fourth, in the Notify Message Types registry also on the Host Identity Protocol (HIP) Parameters registry page located at:

https://www.iana.org/assignments/hip-parameters/

five new message types are to be registered as follows:

Value: [ TBD-at-Registration ]
Notify Message Type: NAT_KEEPALIVE
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Notify Message Type: NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Notify Message Type: CONNECTIVITY_CHECKS_FAILED
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Notify Message Type: MESSAGE_NOT_RELAYED
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Notify Message Type: SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these are the only actions required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2018-02-21
27 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2018-02-21
27 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2018-02-16
27 Henrik Levkowetz Request for Last Call review by OPSDIR is assigned to (None)
2018-02-16
27 Henrik Levkowetz Request for Last Call review by OPSDIR is assigned to (None)
2018-02-16
27 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2018-02-16
27 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2018-02-15
27 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2018-02-15
27 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2018-02-15
27 Wesley Eddy Request for Last Call review by TSVART is assigned to Colin Perkins
2018-02-15
27 Wesley Eddy Request for Last Call review by TSVART is assigned to Colin Perkins
2018-02-14
27 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Éric Vyncke
2018-02-14
27 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Éric Vyncke
2018-02-12
27 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-02-12
27 Amy Vezza
The following Last Call announcement was sent out (ends 2018-02-26):

From: The IESG
To: IETF-Announce
CC: hipsec@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo …
The following Last Call announcement was sent out (ends 2018-02-26):

From: The IESG
To: IETF-Announce
CC: hipsec@ietf.org, gonzalo.camarillo@ericsson.com, hip-chairs@ietf.org, draft-ietf-hip-native-nat-traversal@ietf.org, Gonzalo Camarillo , terry.manderson@icann.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Native NAT Traversal Mode for the Host Identity Protocol) to Proposed Standard


The IESG has received a request from the Host Identity Protocol WG (hip) to
consider the following document: - 'Native NAT Traversal Mode for the Host
Identity Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies a new Network Address Translator (NAT)
  traversal mode for the Host Identity Protocol (HIP).  The new mode is
  based on the Interactive Connectivity Establishment (ICE) methodology
  and UDP encapsulation of data and signaling traffic.  The main
  difference from the previously specified modes is the use of HIP
  messages for all NAT traversal procedures.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-02-12
27 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-02-12
27 Amy Vezza Last call announcement was changed
2018-02-11
27 Terry Manderson Last call was requested
2018-02-11
27 Terry Manderson Ballot approval text was generated
2018-02-11
27 Terry Manderson Ballot writeup was generated
2018-02-11
27 Terry Manderson IESG state changed to Last Call Requested from AD Evaluation
2018-02-11
27 Terry Manderson Last call announcement was generated
2018-02-11
27 Terry Manderson IESG state changed to AD Evaluation from Publication Requested
2018-02-02
27 Gonzalo Camarillo
PROTO Writeup of draft-ietf-hip-native-nat-traversal-27
[2018-02-02 Fri]

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? …
PROTO Writeup of draft-ietf-hip-native-nat-traversal-27
[2018-02-02 Fri]

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

    Proposed Standard, as indicated on the title page header (i.e.,
    Standards Track).

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement
    Write-Up. Recent examples can be found in the "Action"
    announcements for approved documents. The approval announcement
    contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  This document specifies a new Network Address Translator (NAT)
  traversal mode for the Host Identity Protocol (HIP).  The new mode is
  based on the Interactive Connectivity Establishment (ICE) methodology
  and UDP encapsulation of data and signaling traffic.  The main
  difference from the previously specified modes is the use of HIP
  messages for all NAT traversal procedures.


Working Group Summary:

Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

    There was WG consensus behind this document.

Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

    As discussed in RFC 6538, there are several implementations of the
    Experimental HIP specs. Therefore, RFC 5770 (HIP Extensions for
    Traversal of NATs) has been implemented.  Nevertheless, at this
    point we do not know of any plans to implement the deltas over RFC
    5770
this specification defines.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

    Gonzalo Camarillo is the documetn shepherd. Terry Manderson is the
    responsible area director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

    The document shepherd reviewed revision 27 of this document, which
    was ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

    No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

    No.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of? For example, perhaps he or she
    is uncomfortable with certain parts of the document, or has
    concerns whether there really is a need for it. In any event, if
    the WG has discussed those issues and has indicated that it still
    wishes to advance the document, detail those concerns here.

    No concerns.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

    The whole WG understands the document and agree with
    it. Nevertheless, the number of active participants in the HIP WG
    is limited at this point.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

      The document contains no relevant nits.   

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

    No formal reviews are needed.

(13) Have all references within this document been identified as
    either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

    No.

(15) Are there downward normative references references (see RFC
    3967
)? If so, list these downward references to support the Area
    Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction? If the
    RFCs are not listed in the Abstract and Introduction, explain
    why, and point to the part of the document where the relationship
    of this document to the other RFCs is discussed. If this
    information is not in the document, explain why the WG considers
    it unnecessary.

    No.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified. Confirm
    that newly created IANA registries include a detailed
    specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and
    a reasonable name for the new registry has been suggested (see
    RFC 5226).

    The IANA Considerations Section is complete and consistent.
 
(18) List any new IANA registries that require Expert Review for
    future allocations. Provide any public guidance that the IESG
    would find useful in selecting the IANA Experts for these new
    registries.

    No new experts are required.
 
(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

    No such checks were needed.
2018-02-02
27 Gonzalo Camarillo Responsible AD changed to Terry Manderson
2018-02-02
27 Gonzalo Camarillo IETF WG state changed to Submitted to IESG for Publication from WG Document
2018-02-02
27 Gonzalo Camarillo IESG state changed to Publication Requested
2018-02-02
27 Gonzalo Camarillo IESG process started in state Publication Requested
2018-02-02
27 Gonzalo Camarillo Changed document writeup
2018-02-02
27 Gonzalo Camarillo Notification list changed to Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
2018-02-02
27 Gonzalo Camarillo Document shepherd changed to Gonzalo Camarillo
2018-02-02
27 Gonzalo Camarillo Changed consensus to Yes from Unknown
2018-02-02
27 Gonzalo Camarillo Intended Status changed to Proposed Standard from None
2017-12-20
27 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-27.txt
2017-12-20
27 (System) New version approved
2017-12-20
27 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2017-12-20
27 Miika Komu Uploaded new revision
2017-12-20
26 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-26.txt
2017-12-20
26 (System) New version approved
2017-12-20
26 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2017-12-20
26 Miika Komu Uploaded new revision
2017-12-08
25 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-25.txt
2017-12-08
25 (System) New version approved
2017-12-08
25 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2017-12-08
25 Miika Komu Uploaded new revision
2017-11-29
24 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-24.txt
2017-11-29
24 (System) New version approved
2017-11-29
24 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2017-11-29
24 Miika Komu Uploaded new revision
2017-11-12
23 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-23.txt
2017-11-12
23 (System) New version approved
2017-11-12
23 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2017-11-12
23 Miika Komu Uploaded new revision
2017-10-23
22 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-22.txt
2017-10-23
22 (System) New version approved
2017-10-23
22 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2017-10-23
22 Miika Komu Uploaded new revision
2017-10-23
21 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-21.txt
2017-10-23
21 (System) New version approved
2017-10-23
21 (System) Request for posting confirmation emailed to previous authors: Jan Melen , Ari Keranen , Miika Komu
2017-10-23
21 Miika Komu Uploaded new revision
2017-04-25
20 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-20.txt
2017-04-25
20 (System) New version approved
2017-04-25
20 (System) Request for posting confirmation emailed to previous authors: Jan Melen , hip-chairs@ietf.org, =?utf-8?q?Ari_Ker=C3=A4nen?= , Miika Komu
2017-04-25
20 Miika Komu Uploaded new revision
2017-03-27
19 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-19.txt
2017-03-27
19 (System) New version approved
2017-03-27
19 (System) Request for posting confirmation emailed to previous authors: Jan Melen , hip-chairs@ietf.org, =?utf-8?q?Ari_Ker=C3=A4nen?= , Miika Komu
2017-03-27
19 Miika Komu Uploaded new revision
2017-03-14
18 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-18.txt
2017-03-14
18 (System) New version approved
2017-03-13
18 (System) Request for posting confirmation emailed to previous authors: Jan Melen , hip-chairs@ietf.org, =?utf-8?q?Ari_Ker=C3=A4nen?= , Miika Komu
2017-03-13
18 Miika Komu Uploaded new revision
2017-02-15
17 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-17.txt
2017-02-15
17 (System) New version approved
2017-02-15
17 (System) Request for posting confirmation emailed to previous authors: "Ari Keranen" , "Jan Melen" , hip-chairs@ietf.org, "Miika Komu"
2017-02-15
17 Miika Komu Uploaded new revision
2017-02-04
16 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-16.txt
2017-02-04
16 (System) New version approved
2017-02-04
16 (System) Request for posting confirmation emailed to previous authors: "Ari Keranen" , "Jan Melen" , hip-chairs@ietf.org, "Miika Komu"
2017-02-04
16 Miika Komu Uploaded new revision
2017-02-01
15 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-15.txt
2017-02-01
15 (System) New version approved
2017-02-01
15 (System) Request for posting confirmation emailed to previous authors: "Ari Keranen" , "Jan Melen" , hip-chairs@ietf.org, "Miika Komu"
2017-02-01
15 Miika Komu Uploaded new revision
2016-11-24
14 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-14.txt
2016-11-24
14 (System) New version approved
2016-11-24
14 (System) Request for posting confirmation emailed to previous authors: "Ari Keranen" , "Jan Melen" , hip-chairs@ietf.org, "Miika Komu"
2016-11-24
14 Miika Komu Uploaded new revision
2016-07-01
13 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-13.txt
2016-06-23
12 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-12.txt
2016-06-15
11 Miika Komu New version available: draft-ietf-hip-native-nat-traversal-11.txt
2016-01-19
10 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-10.txt
2015-07-23
09 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-09.txt
2015-01-22
08 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-08.txt
2014-06-23
07 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-07.txt
2013-12-20
06 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-06.txt
2013-06-14
05 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-05.txt
2012-12-14
04 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-04.txt
2012-06-20
03 Ari Keränen New version available: draft-ietf-hip-native-nat-traversal-03.txt
2011-12-22
02 (System) New version available: draft-ietf-hip-native-nat-traversal-02.txt
2011-08-01
02 (System) Document has expired
2011-01-28
01 (System) New version available: draft-ietf-hip-native-nat-traversal-01.txt
2010-09-15
00 (System) New version available: draft-ietf-hip-native-nat-traversal-00.txt