Re: [Hipsec] Ben Campbell's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

[Ben Campbell <[e-mail]>]

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 <[e-mail]> 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
>   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 that would do the trick as well
> 
>> §4.3: "This section describes the usage of a new non-critical
>> parameter type.
>> ": Which is?
> 
> It says now:
> 
>  This section describes the usage of a non-critical parameter type
>   called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP.
> 
>> §4.6, first paragraph: 2nd sentence is hard to parse.
> 
> I reworded this as follows:
> 
> The address of the Control Relay Server MUST NOT be used as a
> destination for data plane traffic unless the server supports also Data
> Relay Server functionality, and the Client has successfully registered
> to use it.