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!
_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
