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

From: Alissa Cooper <[email-masked]>
Date: Wed, 09 May 2018 08:39:27 -0700

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?

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.

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.

= Section 2 =

The paragraph about RFC2119 should also reference RFC8174.