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

[Miika Komu <[e-mail]>]

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.