[Hipsec-rg] Re: The function of ULIDs and routable IPv6 LSIs?

[[e-mail] (Pekka Nikander)]

Tom,

It is indeed good to have this discussion.  I think I have some
important insights down below, but before that some details
and clarifications.

>> ... I have came down
>> with the following tentative list of desirable ULID properties.
>>
>>    - stability
>>    - referability
>>    - reachability
>>    - security
>
> I would add that there is another angle about ULIDs, and that is
> whether they are for backward-compatible APIs or not. ...
>                       ... problems arise when you try to preserve
> all of the beneficial properties but don't want to change APIs
> or applications-- I don't think it can be done.

I agree with you that this different angle is an important one.
I tried to clarify it somewhat later in my original message,
not in the discussion about the desired ULID properties that I
considered more as an academic exercise.  :-)

In the IPv4 API case I agree with you that it seems to be impossible
to fulfil all the desired properties at the same time.  However,
I would not be that sure for the IPv6 API.  Furthermore, quite a
lot of applications have been upgraded to support the IPv6 API.

>> With stability I mean ...
>>
>> With referability I mean ...
>
> I am assuming that you also mean, by the above, that the other
> user may be non-HIP-aware at the system level.  In short, that
> the other user on a non-HIP-aware system can do a connect(ULID)
> and have it succeed.

Well, my intention was not explicitly considering that in the
framing part of my mail, but I agree that it is an important
consideration, with respect to stability and referability.
Indeed, it would be good if we could provide a system
where connect(IPv6-API-ULID) would work independent of whether
the system supports HIP or not.   On the other hand, that has
also a flip side: it reduces the overall security of the system,
as sometimes you get a secure connection when using such an
ULID and sometimes you don't, depending on which system you
use.

>> Reachability ...
>>
>> With security I mean ...
>
> If I read the above correctly, it seems to argue for some type
> of routable IP(v6) address, with elements of a host ID embedded
> in the IID portion, and that you have enough lower-order bits
> for host ID that give you the security properties that you want.
> At least for a near-term solution that satisfies referral property
> for legacy hosts.

Well, I did not have any explicit solution in my mind.  Using
CGA addresses as ULIDs is indeed one possibility, but are people
willing to accept the IPRs attached to them?  Anyway, independent
of that, it would be an interesting exercise to see how that would
work.

>> In addition to trying to get these properties clear in my mind,
>> I have also started to suspect that, in the longer run,  the
>> ULIDs that we want to at the application level may not be HITs,
>> in the meaning of *Host* Identity Tags.
>
> That view is also expressed in:
> http://www.acm.org/sigs/sigcomm/sigcomm2004/ 
> papers.html#A_Layered_Naming

Yes, the Layered Naming Architecture paper was one reason
why I have started to consider these issues.

>> AFAIK, so far people have used or are planning to use the
>> following forms of LSIs in their HIP implementations:
>>
>>    1. Initial locators, or plain old IP addresses.
>>    2. IPv4 LSIs from the 1.0.0.0/8 subnet.
>>    3. "Old fashioned" HITs, or 01/10 HITs.
>>    4. "New" IPv6 LSIs, with a TBD/TBD prefix.
>>
>> If we consider the above list of properties, all 32-bit
>> LSIs suffer from problems related to stability, referability
>> and security.  Using IPv4 addresses provides reachability on
>> the cost of security, while using 1.0.0.0/8 LSIs loses
>> direct reachability completely while providing some level of
>> security and referability.
>
> I would probably interchange the use of the terms "reachability"
> and "referability" in the above.  I think all of the proposals
> satisfy reachability as you defined it above this numbered list.

Well, one issue that I apparently missed was that I seem to
make a distinction between "direct reachability", meaning
that you can use an ULID as an IP address and get packets
passed by the routing infrastructure, and "indirect reachability",
where you rely on some additional infrastructure, such as DHT.
In the statement above I was thinking about "direct reachability",
but failed to mention that.  Sorry for the confusion.

Referrability, on the other hand, has two aspects in it.
One is certainly reachability (either direct or indirect).
But that does not necessarily need to be absolute, right
now available reachability.  You can refer to a host without
being able to reach it.  The other aspec is global scope.
While HITs are not reachable (in the sense of direct
reachability), they are certainly referrable, as they denote
the same host everywhere.

Finally, there seems to be yet another property, referrability
between HIP-capable hosts and non-HIP-capable hosts.  That I
failed to include in my original list.  To recap, we seem
to come down to a new list:

  - stability
  - referability between new hosts
  - referability between new and legacy hosts
  - direct reachability / direct (as opposed to overlay) routeability
  - indirect reachability
  - security

But, again, I am wondering if these terms are of any good, and
if any better terms might be available.

>> Given all this, I would summarise the situation and the
>> recent proposals as follows:
>>
>>    - Your use of using initial IP addresses as LSIs suffers,
>>      in my opinion, from big security problems.  Personally,
>>      I find this so problematic that I almost consider the
>>      practise to violate the HIP architecture, as expressed
>>      in draft-ietf-hip-arch-02.txt, now at the IESG.
>
> I disagree strongly.  Instead, I think it has the best chance
> of allowing a smooth transition to HIP, and even though it does
> not have the security properties of other ULIDs, it potentially
> strengthens the existing situation considerably without losing
> the referral property.  And when one considers that there hasn't
> yet been a proposal that satisfies all of the above listed
> requirements (and appears that maybe there is no such solution),
> it seems even more reasonable to me.

I guess here we have currently no other choice but to agree to
disagree.  I certainly appreciate your viewpoint, but still think
that it is not consistent with the HIP architecture, at least in
the sense that I understand the architecture.

What comes to the utility value of you approach as a transition
mechanism, I see your point.  You do gain referrability between
HIP and legacy hosts, which is quite a lot.  But you lose or at
least greatly weaken the  ability to trust on ULIDs, or use them
for channel binding.  Anyway, from the transition point of view,
your approach may be the best we can do with the IPv4 API.
However, I still suspect that we can do better with the IPv6 API.

[I don't want to go to the IPv6 API here.  However, I just want
to note that CGA suffers from channel binding problems, and
therefore may not be the ideal solution for that purpose.]

> Today, if the app does a connect(A) to a routable IP address A,
> all the system can really guarantee (if it works at all) is that
> it has connected to a host reachable at address A.  With HIP,
> we can offer the following.  If there is some means (manual
> configuration, trusted name resolution) for a system to find out
> the HIT of the host that it is trying to connect to, the system
> can perform the additional checking to authenticate the host
> responding from address A.  If the HIT information is not readily
> available, then at least there is keying material set up with
> whomever you happen to be talking to that will allow direct
> authentication of announced locator changes.  Even in this latter
> scenario, it is no less secure than the current situation.

I completely agree with you here.  My security point is that when
an application does connect(A), it has no direct assurance on
whether the connection will be secure or not.  It has to rely on
local configuration for that.  On the other hand, if a host does
connect(HIT), there is assurance that either the connection is
secure and to a node having access to the private key corresponding
to the HIT, or there are no connection at all.  connect(A) clearly
succeeds sometimes when connect(HIT) does not, and some of those
cases are not secure, either due to local configuration mistakes
or due to some other problems.

Personally, I find the assurance that connect(HIT) provides very
valuable, and as one of the main personal motivations for trying
to get HIP into a level that I can use it myself.

Now, a good question is whether we could support both at the
same time on all HIP hosts?  I don't see any direct reasons why
we couldn't, but perhaps I am missing something.  Maybe you could
configure your DNS system to prefer either form, but accept both
in referrals and from the user?  The behaviour in both cases
would then depend on what configuration you happen to have a the
time, i.e., whether you have an active A <-> HIT mapping or not.

I need to think about this more, but as an initial reaction
that sounds like a good possible approach for the IPv4 API case.
However, I still suspect that we should be able to do something
better in the IPv6 case....  But I may be wrong.

> I think it is also important to note that the various
> HIP developers have managed to develop interoperable
> implementations based on different LSI assumptions. In fact,
> we have done so ourselves-- in one application scenario we
> have been using non-routable LSIs in our own implementation
> and it interworks with the variant that uses IP addresses
> as LSIs.

Well, there seems to be two "level" of interoperability
here.  I certainly agree with you that we've managed to
create interoperable implementations from the HIP protocol
point of view.  However, if you try to use some application
that does application level referrals with IP addresses,
the two different implementations most probably fail to
interoperate.  OTOH, if we decide and manage to go into
the direction where we support BOTH plain (IPv4) addresses
and 1.0.0.0/8 LSIs at the API level on BOTH hosts, we might
get quite good interoperability also at the apps level,
and also towards legacy hosts.

It would then be the admin/user/app choice to use either
an address or an 1.0.0.0/8 LSI.  Using an address would
promote referability on the cost of security assurance
while using an 1.0.0.0/8 LSI would provide security
assurance on the cost of reachability and legacy-host
referrability.

> That is why I am objecting to the current
> language in the base spec-- this issue doesn't affect
> interoperability and there are clearly multiple ways to
> solve it (and disagreement on how best to solve it) so it
> would be best to allow room for further experimentation
> and discussion.

It does affect interoperability, at the application level,
and that point _has_ been discussed in the architecture
draft.  Maybe not directly, but it does mention that the
local name abstraction should be usable in "existing
_protocols_ and APIs."  (emphasis mine)  It also explicitly
mentions their use "as the address in an FTP command".

--Pekka