On Tue, Nov 20, 2018 at 12:07 PM Miika Komu <mk...@kapsi.fi> wrote: > 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? >
Maybe I'm missing something, but it seems like this is not an interoperable state of affairs. > 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? > Proposed Standard. > > 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? > Well, this isn't a collision; it's what's called a preimage. I.e., computing a public key with a given HIT. Anyway, as far as I can tell, in HIP being able to compute a preimage for HIT Y = H(K_X) is equivalent to breaking key K_X, so that means that that function must have reasonable strength. 2^64 is nowhere near enough and the typical expected security level of IETF protocols is 2^128, so that means that the full width of the IPv6 address has to be used. > 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? > Yes, I think that would be good to do. > > 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) > No, I'm referring to the point I raised above. > > 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: > I'm not following how this solves the problem. It seems like you're still going to get badly suboptimal routing. -Ekr > 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
