[Dropping IPv6 as this has nothing to do with IPv6 any more]
Jari and Erik,
If there is new functionality in the stack and new piece of
infrastructure, it *may* be possible to provide sufficient
incentives for upgrading the applications. I would imagine
that security might be such a feature in the long run.
But security of what? See below.
My assumption is that anybody that cares about security of the
content being communicated applies some security to that content;
IPsec, TLS, whatever. And if folks care about www.example.com
really mapping to an IP address and the routes pointing in that
direction, we need DNSsec and some routing security.
AFAICT we need this even if HIP is used (even though HIP helps to
get IPsec end-to-end).
Yes. One of the reasons why this is needed is that
the specific issues in applications typically need specific
security support that is easier to provide in application
or transport layer. Secondly, historically, we have struggled
in providing meaningful and universal information from IP
layer security mechanisms to applications. I do not
see any reason why the world would change in this regard,
particularly given the already developed and deployed
mechanisms.
I think you may be missing one aspect of CGAs/KHIs/HITs/whatever,
which is implicit channel bindings and the ability to continue
identifiers for security purposes.
We have a long tradition of using IP addresses for security. In the
original architecture IP addresses used to act as very good
approximations of host or end-point identifiers, making it natural to
use IP addresses to make a difference between more and less trusted
hosts. The same design was adopted into IPsec, and is still used in
many firewalls, configuration files, proxies, etc.
Using something which looks and tastes like an IP addresses to an
application (while not being it in the network) is able to build upon
that tradition. When we add strong security semantics to this,
basically providing a much higher level of assurance that any packet
sent to that identifier is not delivered to anyone else but the
identified recipient, we just strengthen the semantics that we used
to have and that many applications and practises still assume.
CGAs and KHIs can be seen as handles to public keys. While CGAs are
currently used only in SeND, both CGAs and KHIs could be used to
provide, implicitly, the strong security semantics. That is what HIP
does with its HITs. If you send a packet to a HIT, the underlying
HIP layer will create an IPsec ESP association with the named host
(authenticated with the public key bound to the HIT), and delivers
the packet ESP protected, if at all.
Hence, the security I was referring to is the strength of the
cryptographic binding from the IPv6-look-alike identifier to the
public key. If the hash is short, the binding is weak. Even the
currently-proposed 120-bits hash will become vulnerable during the
lifetime of many of us, and using 128 bits doesn't help much there.
Consequently, in the long run, I think there is some incentive to
move using full public keys (or something similar) as host or end-
point identifiers.
--Pekka
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
