Re: [Hipsec] Alissa Cooper's No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Hi Alissa, ke, 2018-05-09 kello 08:39 -0700, Alissa Cooper kirjoitti: > Why is this document on the standards track when RFC 5770 was > experimental? I forgot to explain this. The reason was that the WG decided to push all of the experimental track work to standards track, including the earlier experimental RFC 5770 which is now draft-ietf-hip-native-nat- traversal. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Alissa Cooper's No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Hi Alissa, thanks for the comments. Let me know if you have further concerns, my corrections are listed below. ke, 2018-05-09 kello 08:39 -0700, Alissa Cooper kirjoitti: > Alissa Cooper has entered the following ballot position for > draft-ietf-hip-native-nat-traversal-28: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > > > --- > --- > 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? Eric Rescolarla commented about this first, so this text will be removed in the next version. The new text actually mandates encrypted locators: With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated within an ENCRYPTED parameter (denoted here with ENC) according to the procedures in sections 5.2.18 and 6.5 in [RFC7401]. Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP protocol but rather encrypted to avoid middlebox tampering. > 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. It is actually better to expose all IP addresses because the host may not necessarily have adequate knowledge of the (possibly cascading) NAT topologies and whether the other peer is in "intra" or "extra" network and so on. Still, I think we should not mandate exposing all network interfaces in cases where the host knows the topology and there are some privacy concerns. So to better reflect your comment, I changed the text as follows: For these two local policy reasons, an end-host MAY exclude certain host addresses from its LOCATOR_SET parameter, but this requires further experimentation. > 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. I have removed "that" so it should make more sense now: To overcome this problem, different methods, commonly referred to as NAT traversal techniques, have been developed. As one solution, the HIP experiment report [RFC6538] mentions Teredo-based NAT traversal for HIP and related ESP traffic (with double tunneling overhead). > = Section 2 = > > The paragraph about RFC2119 should also reference RFC8174. I changed the wording as follows: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Hi Benjamin, thanks for the very detailed comments and apologies for my extremely slow reaction! My corrections are below. If you think I haven't addressed your concerns, please let me know. ke, 2018-05-09 kello 08:02 -0700, Benjamin Kaduk kirjoitti: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-hip-native-nat-traversal-28: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > > > --- > --- > 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. as discussed in earlier reviews, I have already added some text to the introduction: HIP poses a unique challenge to using standard ICE, due not only to its kernel-space implementation, but also due to its close integration with kernel-space IPSec; and, that while RFC5770" provides a technically workable path, it incurs unacceptable performance drawbacks for kernel-space implementations. Also, implementing and integrating 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. [...] The differences to the Legacy ICE-HIP are further elaborated in Section [...] As requested by your, I updated the last sentence of the abstract as follows: 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. > 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. RFC8445 mentions "offer/answer" as an example but I agree it is more of an SDP terminology. The offer/answer + nat traversal procedures are coupled into a single control plane (=HIP), hence we are combining terminology from both the specifications. I updated the terminology a bit to reflect your comments better: 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 Protocol (SDP) "offer/answer" is mentioned as an example. In contrast, the Candidate Exchange in HIP is the base exchange itself or a subsequent UPDATE prodecure occurring after a handover. Following [RFC5770] and Session Description Protocol (SDP) [RFC3264] naming conventions, "HIP offer" is the the Initiator's LOCATOR_SET parameter in a HIP I2 or in an UPDATE control packet. HIP answer: The Responder's LOCATOR_SET parameter in a HIP R2 control packet. Corresponds to the SDP answer parameter [RFC3264], but is HIP specific. Please refer also to the longer description of the "HIP offer" term above. > 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
