Ted, You make several good points and I'd like to respond from the perspective of someone trying to conduct the HIP experiments. > -----Original Message----- > From: Ted Hardie [mailto:hardie@xxxxxxxxxxxx] > Sent: Sunday, October 29, 2006 8:36 PM > To: Jari Arkko; IETF Discussion > Cc: HIP; discuss@xxxxxxxxxxxxx; Internet Area; iesg@xxxxxxxx; > IETF IPv6 Mailing List > Subject: [Int-area] Re: Last Call: 'An IPv6 Prefix for > Overlay RoutableCryptographicHash Identifiers (ORCHID)' to > Experimental RFC (draft-laganier-ipv6-khi) > (snip) > > In my own reading, there were a couple of issues that > struck me as potential problems. The first is that this draft > has a view of how applications interact with IPv6 > addresses that it somewhat unidimensional. It presumes > that the application always passes IPv6 addresses "down" the stack > where a routing layer takes care of them. That leads to the idea > that inserting a shim between the application layer and the > routing layer can introduce new functionality without > changing the way in which addresses pass across those APIs. > > That may be true, but it is certainly not the only way in > which applications pass IPv6 addresses. Two trivial examples > which do not pass that way are the IPv6 addresses given in > SDP packets and the IPv6 addresses which may appear in > URIs. By choosing to retain the same syntax (but not the > same semantics) as the basic IPv6 address, the draft may > be making it possible to pass them "down" through shims, > but it is also guaranteeing that if they leak out through > application-layer pointers, that non-participating hosts > will not know that they cannot be passed to the routing > system. Once there, they will (hopefully, anyway) not > be routable, which will give some pretty hard to diagnose > errors for the non-participating users. The draft is careful > to note that this should be used only among consenting > hosts, but there is no clear way to determine if a host > is participating. A few points here: - this requested allocation does not necessarily presume that these identifiers are passed to applications, although this draft spends a lot of time discussing that scenario. Even if applications are never given these identifiers and HIP is performed completely in the stack, there is still a need for a name space for these identifiers, and it is preferable to separate them from possible IPv6 addresses. - if one does choose to pass these as pseudo-addresses to applications, I agree that referral problems could occur. One open question in the HIP experiment is how often that this causes a problem. For instance, will a non-HIP host ever get one of these identifiers via a HIP host that does this? In the HIP case, presumably the host will have to be running HIP to get the application-level exchange in the first place, so maybe it is a rare event. > > It is also somewhat problematic that the range set aside > may be used for *any* experimental use of this type > (not just, say, HIP). I encourage folks to read the draft > and see if they believe it would be possible for a host to > participate in multiple experiments of this type, or if it > would be effectively limited to a single shim. In that same vein, > imagine the case where an application layer pointer is sent > to a host that is participating in a *different* experiment > from the one originally meant. I agree that it is not possible to identify the experiment by examining the ORCHID value. I think you are pointing out that the solution sketched in the last paragraph of section 4 is insufficient in solving the "referral" problem of these identifiers, when the remote host has multiple of these experiments going on, unless that host can get the context from some lookup somewhere. I wonder if there is any security risk of putting the context-ID outside of the hash, or whether it is purely a bit conservation technique. > > Stepping up a few thousands of feet, I believe that the > draft's setting aside these syntactically-but-not-semantically-equal > addresses is implying a value judgement that this is the > appropriate way to conduct experiments of this type. While > it *may* be true for one or more experiments, that meta-statement > is not yet born out by experience, and encouraging that choice > seems to run ahead of our facts. Though this draft discusses > "overlays", there is no requirement that these systems be > overlays in the sense > of the term I see used most commonly; they do not have to fit into the > same class as one-to-many VPNs, MPLS LSPs, or any of the > overlay-as-tunnel mechanisms we commonly see. Instead, > they may rely on the resolution of one class of identifier > before using > the common routing system (and there is no guarantee that any > of what was present before the shim did the resolution will be > present after). There may well be resolution mechanisms to be > tested here which would be much more effective if they did not > presume that the input syntax and output syntax had to be the > same. Setting aside the range in the way this draft does > seems to imply that the answer *should* lie in the class of > resolutions > where the syntax is the same on both sides of the resolution. > > Fundamentally, these identifiers are not v6 addresses at all. Setting > aside a portion of the v6 address space in this way risks, in my > mind, pushing us further down a bad road, where that syntax > is fundamentally meaningless without a context. This is bad > because we have > not successfully designed a mechanism for indicating that context. > Leaving the semantics of these identifiers reliant on inference is > a recipe for poor performance and, possibly, outright failure. > This draft raises a couple of issues: i) whether 128-bit cryptographic identifiers should be allocated from a range that does not conflict with IPv6 addresses ii) whether making these identifiers available to applications, possibly as pseudo-addresses, poses certain risks Regardless of what you may think of ii), I think that i) is very helpful in implementations to allow these identifiers to stand apart from IPv6 addresses; here, I don't care so much about the particular allocation so long as it is distinct and the prefix is not too long (allowing for ~100 bits of hash). Regarding ii), which seems to be the main source of your discomfort, I think that experiments may show whether ii) is a good idea or not, since many implementations already do this, but I am not necessarily advocating it, and personally do not care so much whether the discussion on overlay routing is retained in the draft (I am fine either way). Tom _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf