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 |