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(_at_)qualcomm(_dot_)com]
Sent: Sunday, October 29, 2006 8:36 PM
To: Jari Arkko; IETF Discussion
Cc: HIP; discuss(_at_)apps(_dot_)ietf(_dot_)org; Internet Area;
iesg(_at_)ietf(_dot_)org;
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf