Re: Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

Hi Eric,

On 5/7/18 00:41, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-hip-rfc4423-bis-19: 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-rfc4423-bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3709
> 
> 
> Maybe I'm missing something important, but I don't see in this
> document how you go from a HI (or HIT) to the corresponding IP
> locator. That seems pretty critical to making this work. Can you point
> me in the right direction?

(I interpret "right" direction here as how to implement this in 
practice; please let me know if you were asking for something else)

Existing applications can utilize LSIs or HITs, for instance, via 
/etc/hosts in Linux or if the developer/user uses them directly. 
Mappings can be configured manually. A better way is to use ,e.g., DNS 
to store the FQDN, HIs, IP address mappings:

https://tools.ietf.org/html/rfc8005

An application can receive LSIs or HITs from DNS queries when a HI 
record exists for a host. This can be implemented  in the local resolver 
library (e.g. glibc in Linux) supports it and sends the HI-to-IP address 
mapping to the local HIP daemon. As an alternative implementation 
technique, dynamic relinking of applications (i.e., LD_PRELOAD in Linux):

https://tools.ietf.org/html/rfc6538#section-4.1

As yet another alternative, RFC5338 (section 3.2) suggests interposing 
HIP-aware agents (think about HIP-capable DNS proxy like "dnsmasq" in 
Linux) that translate HIs into LSIs and HITs to the application and 
cache the IP address mapping to the HIP daemon:

https://tools.ietf.org/html/rfc5338#section-3.2

That's all for existing applications. New HIP native applications could 
use DNS library extensions for getaddrinfo() that would be implemented 
e.g. in glibc in Linux:

https://tools.ietf.org/html/rfc6317

All of the mentioned references are mentioned in the draft. Should I add 
something more compressed along these lines of text or is this too detailed?

> IMPORTANT
> S 11.3.1.
>>       avoiding manual configurations.  The three components are further
>>       described in the HIP experiment report [RFC6538].
>>    
>>       Based on the interviews, Levae et al suggest further directions to
>>       facilitate HIP deployment.  Transitioning the HIP specifications to
>>       the standards track may help, but other measures could be taken.  As
> 
> This confuses me, because we seem to be looking to advance some of the
> HIP specs (e.g., hip-dex) at PS

Can you elaborate? And do you mean protocol stack by PS?

(This text is based on the subjective opinions of the interviewed 
people. So I don't think it matters so much)

> COMMENTS
> S 3.1.
>>          were obtained.  For 64 bits, this number is roughly 4 billion.  A
>>          hash size of 64 bits may be too small to avoid collisions in a
>>          large population; for example, there is a 1% chance of collision
>>          in a population of 640M.  For 100 bits (or more), we would not
>>          expect a collision until approximately 2**50 (1 quadrillion)
>>          hashes were generated.
> 
> It's not just a matter of collisions being hard, but also of being
> difficult to produce an HI with a given name.

....where name would be the hash (i.e. HIT). So I added:

Besides accidental collisions, it is also worth noting that intentional 
collisions are difficult to accomplish because generating a valid, 
colliding hash along with its private-public key is computationally 
challenging.

Did I capture your thinking correctly?

> S 4.
>>       'well known', some unpublished or 'anonymous'.  A system may self-
>>       assert its own identity, or may use a third-party authenticator like
>>       DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion
>>       to another namespace.  It is expected that the Host Identifiers will
>>       initially be authenticated with DNSSEC and that all implementations
>>       will support DNSSEC as a minimal baseline.
> 
> This wasn't a very good assumption when 4423 was published, and it
> seems even worse now, given the low rate of deployment of DNSSEC and
> the fact that we know many middleboxes break DNSSEC.

Then I guess it would be fine to remove the last sentence?

> S 4.3.
>>       packet.  Consequently, a HIT should be unique in the whole IP
>>       universe as long as it is being used.  In the extremely rare case of
>>       a single HIT mapping to more than one Host Identity, the Host
>>       Identifiers (public keys) will make the final difference.  If there
>>       is more than one public key for a given node, the HIT acts as a hint
>>       for the correct public key to use.
> 
> How do you handle second-preimage attacks on the hash?

I guess you are referring to this:

https://tools.ietf.org/html/rfc7343#section-5

(Please let me know if an explicit reference is needed)

> S 5.1.
>>       At the server side, utilizing DNS is a better alternative than a
>>       shared Host Identity to implement load balancing.  A single FQDN
>>       entry can be configured to refer to multiple Host Identities.  Each
>>       of the FQDN entries can be associated with the related locators, or a
>>       single shared locator in the case the servers are using the same HIP
>>       rendezvous server Section 6.3 or HIP relay server Section 6.4.
> 
> This is becoming a less common practice. How do you handle anycast,
> which is the modern practice?

I added the following statement:

"It is also worth noting that opportunistic mode is also required 
 

in practice when anycast IP addresses would be utilized as locators:"

Does this address your concern?

Btw, opportunistic mode is further described in the following documents:

Existing apps:

https://tools.ietf.org/html/rfc6538#section-2.3.2
https://tools.ietf.org/html/rfc5338#section-3.2

HIP native apps:

https://tools.ietf.org/html/rfc6317#section-4.1.1

> S 7.
>>    
>>       The encapsulation format for the data plane used for carrying the
>>       application-layer traffic can be dynamically negotiated during the
>>       key exchange.  For instance, HICCUPS extensions [RFC6078] define one
>>       way to transport application-layer datagrams directly over the HIP
>>       control plane, protected by asymmetric key cryptography.  Also, S-RTP
> 
> Nit: SRTP, no hyphen

Thanks, fixed!