Hi Eric, (some other questions still remain to be discussed besides the second preimage collision issue)
On 11/21/18 21:37, Eric Rescorla wrote: > > > On Tue, Nov 20, 2018 at 12:07 PM Miika Komu <[email protected] > <mailto:[email protected]>> 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. the WG has been experimenting with different ways implementing things. Some things are implementation specific (and hence outside of the focus of IETF), but, in general, I would argue the most common approach to "go from HI or HIT to the corresponding locator" in a typical Linux system in the case of a non-hip-aware application works as follows: 1. client app makes are getaddrinfo() call to look up foo.bar from DNS 2. local dns proxy (e.g. standard dnsmasq in Linux) catches the call 3. dns proxy looks up A, AAAA and HI records for foo.bar 3.a. no HI found: dns proxy operates as normally and returns only A/AAAA records to the getaddrinfo() call (via glibc) as it would normally 3.b. HI found: - dnsmasq sends the HI, HIT and IP address to the local HIP daemon - dnsmasq returns the HIT to the application The "generic" approach listed here has been tested and implemented (in addition some other implementation alternatives mentioned in the HIP experiment report). And three different HIP implementations have been tested to interoperate with each other. If this still does not address you concern, please be more specific? > > 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. Would the following replacement text fix the issue? "Transitioning a number of HIP specifications to the standards track in IETF has already taken place, but the authors suggest other additional measures based on the interviews." As an alternative, I can just omit the related paragraph. > > 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 associatedwith the related > locators, or a > >> single shared locator in the case theservers 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. Without opportunistic HIP, i.e, by using a destination HIT explicitly, the situation is challenging because the HI(T)-IP binding at the client would be: * A HI(T) belonging to server A (returned by DNS look up) * IP anycast address (would be bound to some server B during routing process) The challenge here is that we want make sure that server A is the same server as B. AFAIK, this has not been experimented before. Is this what you meant by suboptimal routing? With opportunistic HIP, the problem is easier because the HI(T)-IP binding at the client would be: * "Wild card" HIT (would be bound to a specific HIT after receiving R1 packet from the anycast address) * IP anycast address (would be bound to some server B during routing process) Implementation experience exist on HIP opportunistic mode, but AFAIK none in the context of IP anycast. Would this address your concern (so that I can draft some proposal text)? _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
