Re: [Hipsec] Alissa Cooper's No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

[Miika Komu <[e-mail]>]

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.