Subject: [Hipsec] About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?)

From: [email-masked] (Pekka Nikander)
Date: Mon Sep 15 05:03:01 2003

Michel,

[Sorry for the late reply.  Cross-posted to HIPSEC since
  there is the specific question about HIT length.  Please
  adjust your reply list.]

Iljitsch van Beijnum wrote:
>>> Are you saying that we should make a clear distinction between
>>> identifiers and locators, and not have any values that are valid
>>> in both realms?

Pekka Nikander wrote:
>> Yes, in the long run.
> 
> Would that include going to identifiers that are longer than 128
> bits?

[I think I answered this separately already elsewhere.  Anyway.]
No, just making a clear distinction does not necessarily mean
that we have to go into identifiers longer than 128 bits.  On
the other hand, I do think that there are other reasons for going
to primary identifiers that are (considerably) longer than 128 bits.

> Sorry if I ask a stupid question, but the main deployment issue HIP
> has is basically that every host would need an HIP stack.

Yes.  If HIP is a solution for something, the hosts that want
to benefit from that solution have to implement HIP in their
stack.  On the other hand, HIP does not prevent nodes from using
legacy IPv4/IPv6 in parallel with HIP.

> Since there is not much you can't do about [requiring a HIP stack in
> participating hosts], why haven't you pushed the reasoning further
> and opted for an extended HIT that would not have some of the current
> limitations (background: we did discuss the issue in Atlanta and one
> of the things I recalled is that we both wished we had more bits).

Yes, we discussed this in Atlanta.  And yes, I think we could
fairly easily go to e.g. 256 bit HITs, if desired.  However,
the probability of collisions with 126 bit HITs seems to be
low enough so that I don't see any specific reasons to go to
256 bit HITs, at least not yet.

I don't remember any more what might have been the reasons
for having more bits.  Could you please remind me?

Anyway, this is certainly something that needs to be
reconsidered if HIP ever becomes a standards track protocol.

>> I do understand [the] point about the benefits of an identifier
>> also being a locator, but I also believe that the benefits of clean
>> separation will more than pay the drawbacks in the long run. (I
>> don't have any analysis or data to support this belief, though.)
> 
> I'd be interested in some vague rationale about this.

In a separate mail (CC:d to IPv6 list only).

>> Nodes with well-known addresses, such as servers and those using
>> stateful configuration, are most vulnerable. Nodes that are a part
>> of the network infrastructure, such as DNS servers, are
>> particularly interesting targets for attackers,
> 
> To put this in context, the paragraph above assumes that the server
> is being accessed using the identifier, and that the hackers targets
> the id/loc mapping mechanism in order to map the id to _his_ locs,
> not the legit ones.

Actually, not quite.  In its most simple form, it merely states
that if you know someone's address, it is easy to launch a flooding
DoS attack towards that someone.  On the other hand, if you don't
know the address, it is much harder.  But there are also other,
more complex reasons buried within the sentence, if I recall correctly.

And again:  The potential flooding DoS attacks opened by mobility
and multi-address multi-homing are much more serious than the
currently possible ICMP/UDP/TCP SYN DDoS reflection attacks.
Without proper protection, mobility and/or multi-address multi-homing
allow an attacker to redirect whole packet streams, and even keep
them running with a fairly simple bit of acknowledgement prediction.

> Did I get this right? And if I did, what difference does it make if
> the locators and the identifiers are segregated?

If the identifiers and locators are separated, it is no longer
important to defend individual IP address of *most* nodes.  That is,
in the most typical case you don't care what your IP address is,
and if one address doesn't work, you can try to pick a new one.

However, at least DNS servers (or id/loc mapping servers) would
continue to need having stable IP addresses.  Hence, their address
would still need to be protected.

Whether this really presents a difference remains to be fully analyzed.

--Pekka Nikander

---

From: [email-masked] (Michel Py)
Date: Thu Sep 18 14:08:01 2003

> Tim Shepard wrote:
> I do not imagine that everything will use HIP.

I have met with very enthusiastic supporters of HIP that seem to think
quite the opposite :-)

>> One day, all of these credit card gizmos will use IPv6 over
>> {broadband|wireless|foo} instead of using a dedicated copper pair;
>> when that day comes, if it takes 20kByte of HIP overhead to push
>> 50 bytes of data, you do have a problem.

> Well, what exactly do you think is the competitor to HIP for this
> story? IKE?

No. I'm not even saying there is even a competitor at this point; I was
simply trying to suggest that there is room for improvement in some
domains.

Michel.