Re: [Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Thank you Ben, As a side note, I have observed that the authors have addressed all your review comments in the -29 version. The current plan is to do a new ballot as the IESG has changed since the last one. -éric From: iesg on behalf of Ben Campbell Date: Friday, 21 February 2020 at 00:19 To: Miika Komu Cc: "hipsec@ietf.org" , "hip-cha...@ietf.org" , "i...@ietf.org" , Gonzalo Camarillo , "draft-ietf-hip-native-nat-traver...@ietf.org" Subject: Re: Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT) Hi, I am no longer an area director. I leave it to the current area directors to decide how to proceed with the updated version. Thanks, Ben. On Feb 19, 2020, at 2:43 PM, Miika Komu mailto:miika.k...@ericsson.com>> wrote: Hi Ben, thanks for your comments! My response below. ke, 2018-05-09 kello 19:05 -0700, Ben Campbell kirjoitti: Ben Campbell has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: Abstain 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 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. the current document has been organized for implementors of RFC5770 in mind. Substantive Comments: I share Alissa's question about why this is standard track when the previous work has been experimental. HIP WG decided to move all of its experimental work to standards track. §1, second paragraph: The citation for the version of ICE used by "legacy ICE-HIP" should be RFC5245, not the bis version. thanks, corrected. §2: There are a number of lower-case keywords. Please use the RFC 8174 boilerplate. boilerplate added. Please comment some specific lower-case keyword is incorrect in your opinion. §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. it is either adapted from ICE (by e.g. changing "agent" to "host" or referencing the ICE spec (by sections). Based on the earlier reviews, the text has evolved now into the following: The rules in section 5.1.1 in [RFC8445] for candidate gathering are followed here. A number of host candidates (loopback, anycast and others) should be excluded as described in section 5.1.1.1 of the ICE specification [RFC8445]. Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal, and implementations SHOULD support this functionality even if it will not be used in deployments in order to enable it by software configuration update if needed at some point. Similarly as explained in section 5.1.1.2 of the ICE specification [RFC8445], if an IPv6- only host is in a network that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it may also gather IPv4 server- reflexive and/or relayed candidates from IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and generate server-reflexive candidates for each IPv6-only interface, accordingly. The NAT64 server-reflexive candidates are prioritized like IPv4 server-reflexive candidates. - paragraph 6: I'm confused in that I thought the previous text said that native ICE-HIP does not use STUN. you mean paragraph 7? Gathering of candidates MAY also be performed by other means than described in this section. For example, the candidates could be gathered as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no STUN or Data Relay Server are available. Nothing prevents an implementation from gathering candidates via STUN but the recommended way is HIP control Relay as the "MAY" indicates here. §6: I am skeptical of the assertion that the security considerations for Native ICE-HIP are no different than those for Legacy ICE-HIP. I have changed this now to a more precise statement: Since the control plane protocol and Control Relay Server
Re: [Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Hi, I am no longer an area director. I leave it to the current area directors to decide how to proceed with the updated version. Thanks, Ben. > On Feb 19, 2020, at 2:43 PM, Miika Komu wrote: > > Hi Ben, > > thanks for your comments! My response below. > > ke, 2018-05-09 kello 19:05 -0700, Ben Campbell kirjoitti: >> Ben Campbell has entered the following ballot position for >> draft-ietf-hip-native-nat-traversal-28: Abstain >> >> 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 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. > > the current document has been organized for implementors of RFC5770 in > mind. > >> Substantive Comments: >> >> I share Alissa's question about why this is standard track when the >> previous >> work has been experimental. > > HIP WG decided to move all of its experimental work to standards track. > >> §1, second paragraph: The citation for the version of ICE used by >> "legacy >> ICE-HIP" should be RFC5245, not the bis version. > > thanks, corrected. > >> §2: There are a number of lower-case keywords. Please use the RFC >> 8174 >> boilerplate. > > boilerplate added. Please comment some specific lower-case keyword is > incorrect in your opinion. > >> §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. > > it is either adapted from ICE (by e.g. changing "agent" to "host" or > referencing the ICE spec (by sections). Based on the earlier reviews, > the text has evolved now into the following: > > The rules in section 5.1.1 in [RFC8445] for candidate gathering > are followed here. A number of host candidates (loopback, anycast > and others) should be excluded as described in section 5.1.1.1 of the > ICE specification [RFC8445]. Relayed candidates SHOULD be gathered > in order to guarantee successful NAT traversal, and > implementations SHOULD support this functionality even if it will not > be used in deployments in order to enable it by software > configuration update if needed at some point. Similarly as explained > in section 5.1.1.2 of the ICE specification [RFC8445], if an IPv6- > only host is in a network that utilizes NAT64 [RFC6146] and DNS64 > [RFC6147] technologies, it may also gather IPv4 server- reflexive > and/or relayed candidates from IPv4-only Control or Data Relay > Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery > [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and > generate server-reflexive candidates for each IPv6-only interface, > accordingly. The NAT64 server-reflexive candidates are prioritized > like IPv4 server-reflexive candidates. > >> - paragraph 6: I'm confused in that I thought the previous text said >> that >> native ICE-HIP does not use STUN. > > you mean paragraph 7? > > Gathering of candidates MAY also be performed by other means than > described in this section. For example, the candidates could be > gathered as specified in Section 4.2 of [RFC5770] if STUN servers > are available, or if the host has just a single interface and no > STUN or Data Relay Server are available. > > Nothing prevents an implementation from gathering candidates via STUN > but the recommended way is HIP control Relay as the "MAY" indicates > here. > >> §6: I am skeptical of the assertion that the security considerations >> for Native >> ICE-HIP are no different than those for Legacy ICE-HIP. > > I have changed this now to a more precise statement: > > Since the control plane protocol and Control Relay Server are > essentially the same (with some minor differences) in this document > as in Legacy ICE-HIP [RFC5770], the same security considerations (in > Section 6.1, Section 6.2, Section 6.3 and Section 6.4,) are still > valid, but are repeated here for the sake of completeness. New >
Re: [Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Hi Ben, thanks for your comments! My response below. ke, 2018-05-09 kello 19:05 -0700, Ben Campbell kirjoitti: > Ben Campbell has entered the following ballot position for > draft-ietf-hip-native-nat-traversal-28: Abstain > > 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 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. the current document has been organized for implementors of RFC5770 in mind. > Substantive Comments: > > I share Alissa's question about why this is standard track when the > previous > work has been experimental. HIP WG decided to move all of its experimental work to standards track. > §1, second paragraph: The citation for the version of ICE used by > "legacy > ICE-HIP" should be RFC5245, not the bis version. thanks, corrected. > §2: There are a number of lower-case keywords. Please use the RFC > 8174 > boilerplate. boilerplate added. Please comment some specific lower-case keyword is incorrect in your opinion. > §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. it is either adapted from ICE (by e.g. changing "agent" to "host" or referencing the ICE spec (by sections). Based on the earlier reviews, the text has evolved now into the following: The rules in section 5.1.1 in [RFC8445] for candidate gathering are followed here. A number of host candidates (loopback, anycast and others) should be excluded as described in section 5.1.1.1 of the ICE specification [RFC8445]. Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal, and implementations SHOULD support this functionality even if it will not be used in deployments in order to enable it by software configuration update if needed at some point. Similarly as explained in section 5.1.1.2 of the ICE specification [RFC8445], if an IPv6- only host is in a network that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it may also gather IPv4 server- reflexive and/or relayed candidates from IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and generate server-reflexive candidates for each IPv6-only interface, accordingly. The NAT64 server-reflexive candidates are prioritized like IPv4 server-reflexive candidates. > - paragraph 6: I'm confused in that I thought the previous text said > that > native ICE-HIP does not use STUN. you mean paragraph 7? Gathering of candidates MAY also be performed by other means than described in this section. For example, the candidates could be gathered as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no STUN or Data Relay Server are available. Nothing prevents an implementation from gathering candidates via STUN but the recommended way is HIP control Relay as the "MAY" indicates here. > §6: I am skeptical of the assertion that the security considerations > for Native > ICE-HIP are no different than those for Legacy ICE-HIP. I have changed this now to a more precise statement: Since the control plane protocol and Control Relay Server are essentially the same (with some minor differences) in this document as in Legacy ICE-HIP [RFC5770], the same security considerations (in Section 6.1, Section 6.2, Section 6.3 and Section 6.4,) are still valid, but are repeated here for the sake of completeness. New security considerations related to the new Data Relay Server are discussed in Section 6.5, and considerations related to the new connectivity check protocol are discussed in Section 6.6 and Section 6.7 . > Editorial Comments: > > §1, 2nd paragraph: > - "responsible of NAT traversal": s/of/to > - "responsible of end-host": s/of/to I changed to "for", I assume
[Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)
Ben Campbell has entered the following ballot position for draft-ietf-hip-native-nat-traversal-28: Abstain 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 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. ___ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
