Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
Hi, On 03/15/2017 04:37 PM, Jeff Ahrenholz wrote: I might suggest to recommend NOTIFY (and define the keepalive) and state that other messages including ICMPv6 or UPDATE may be substituted. If there is a need for bi-directional connectivity checking, recommend to use UPDATE; if there are specific known scenarios where an ICMPv6 is recommended instead, state those scenarios. Tom, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I think we shouldn't device a new UPDATE mechanism tied to controlled role (sorry for thinking aloud :) Jeff, is this ok for you? Yes, this sounds good. I have reflected this discussion now in section 5.3 of the preliminary version: http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets as specified in [RFC7401] with Notify message type field set to NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification data field. It is worth noting that sending of such a HIP NOTIFY message MAY be omitted if the host is actively (or passively) sending other traffic to the peer host over the UDP tunnel associate with the host association (and IPsec security associations since the same port pair is reused) during the Tr period. For instance, the host MAY actively send ICMPv6 requests (or respond with an ICMPv6 response) inside the ESP tunnel to test the health of the associated IPsec security associations. Alternatively, the host MAY use UPDATE packets as a substitute. A minimal UPDATE packet would consist of a SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve rekeying procedures as specified in section 6.8 in [RFC7402]. It is worth noting that a host actively sending periodic UPDATE packets to a busy server may increase the computational load of the server since it has to verify HMACs and signatures in UPDATE messages. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
Hi Tom, On 03/14/2017 11:19 AM, Miika Komu wrote: [..] A couple of fixes for me to edit: * Appendix B: normative vs non-normative terminology > [...] so the appendix was using normative terminology which was a bit strange. As a quick fix, I thought about moving this appendix to the body, but after reading this extension (that was inherited as a legacy from the earlier specification) I decided to remove it. The section basically suggested allowing source routing via HIP relay for the sake of compatibility with RVS servers. I think this could be exploited in a bad way to DoS other hosts. I think it is more secure if the HIP relay only forwards inbound packets, not outbound. If you disagree with this change, please discuss on the list. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
Hi, a preliminary version here: http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt Not yet on IETF site since I missed the cut-off deadline. On 02/19/2017 05:18 PM, Tom Henderson wrote: Hello, I have read the latest (-17) draft and sent some purely editorial comments to Miika. I had a few non-editorial questions and comments. 1) In appendix D, it states: o A minimal implementation would conform only to Section 4.7.1 or Section 4.7.2, thus merely tunneling HIP control and data traffic over UDP. The drawback here is that it works only in the limited cases where the Responder has a public address. However, in section 5.4, it states: Implementations conforming to this specification MUST implement both UDP-ENCAPSULATION and ICE-HIP-UDP modes. The contradictory text should be resolved. In my opinion, implementations that want to support only the UDP-ENCAPSULATION mode (and its restricted set of use cases) should be allowed. However, I don't know what might need to be done to avoid a situation where a product claims RFC compliance but only implements one of the two modes. It could perhaps be avoided by a statement that states "Implementations that choose to only support the UDP-ENCAPSULATION mode should clarify this point when any claims of compliance are made." now it says: "Implementations conforming to this specification MUST implement UDP- ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes." I can also add some other wording if it is really necessary (and common in RFC specifications). Btw, while ICE lite is not really the same as ICE-HIP-UDP, ICE lite vs full ICE is not really enforced in the specification. 2) Appendix C states: o The considerations on Diffserv Codepoint markings in ICE are not applicable to HIP since Diffserv is not used in HIP. Why wouldn't the same issues arise in HIP as in ICE on this matter? Should this draft instead copy or reference the RFC 5245 recommendation: If the agent is using Diffserv Codepoint markings [RFC2475] in its media packets, it SHOULD apply those same markings to its connectivity checks. Also, I don't think that the HIP control plane should be excluded from using diffserv. done. 3) In section 4.10 (NAT keepalives), it states: Both a registered client and relay server SHOULD send a HIP NOTIFY packets to each other every 15 seconds (the so- called Tr value in ICE) unless they have exchange some other traffic over the used UDP ports. However, I couldn't find an explanation anywhere (also in RFC 5770) about how to code this NOTIFY. Would it make sense to define also a "NAT_KEEPALIVE" NOTIFY message type for this purpose? Once these issues are resolved, I think that the draft would be ready to publish. done. P.S. The new version of the draft also includes some nits from Alex Elsayed. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
>> I might suggest to recommend NOTIFY (and define the keepalive) and state >> that other messages including ICMPv6 or UPDATE may be substituted. If >> there is a need for bi-directional connectivity checking, recommend to use >> UPDATE; if there are specific known scenarios where an ICMPv6 is >> recommended instead, state those scenarios. > > Tom, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I > think we shouldn't device a new UPDATE mechanism tied to controlled role > (sorry for thinking aloud :) > > Jeff, is this ok for you? Yes, this sounds good. thanks, -Jeff ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
[Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
Folks, I would like to start a WGLC on the following draft. This WGLC will end on February 19th: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ Thanks, Gonzalo ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
