[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
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
