Christian,
Thanks for this analysis.
Caution is indeed a must before any amendment of a basic document.
As my proposal is, its relationship with cryptographically generated
addresses (and with secure neighbor discovery which uses it) should
however not be a problem.
The proposal is, in short:
Point-1: u and g rules apply ONLY to IPv6 addresses that may be used
on IPv6 links (real or virtual).
Point-2: in IIDs, the only escape combination of u and g bits MAY be
used for ALL possible new IID formats (having universal OR local
scopes).
- Since CGAs are to be used on IPv6 links, they are not concerned
with Point-1.
- Besides, CGAs are compatible with the u and g bits rule (per RFC
3972 where step 6 is "Form an interface identifier from Hash1 by
writing the value of Sec into the three leftmost bits and by setting
bits 6 and 7 (i.e., the "u" and "g" bits) to zero."
They are therefore not concerned with point-2.
It is true that secure neighbor discovery of the RFC-3971 SEND
protocol cannot apply to any new IID format that has the escape value
1-1 of u-g bits.
But NEW IIDs that cannot be subject to SEND may be useful too (like
existing and largely deployed IIDs that are based on MAC addresses
are useful despite their impossible use in SEND).
Point-2 is only to avoid that new IID formats using the escape
combination would be a priori restricted to IIDs having universal scope.
So, be cautious, yes, but if analysis shows that some restrictions
lack technical justification, and may render some progress more
complex or impossible, don't be timorous and relax them.
Regards,
RD
May I throw a dose of caution in this debate about host identifiers
formats?
Many transition mechanisms rely on encoding information in the 64
bit host identifier. This is of course a tempting design point,
because it diminishes the amount of state that servers have to
keep. For example, Teredo encodes mapped port numbers and IPv4
addresses in the host identifiers, so Teredo servers can be
stateless. ISATAP uses a similar mechanism, and a number of
proposals follow the same design. But the gain, the reduction of
server load, comes at a cost. I am guilty, I did it with Teredo,
but I still would like to encourage designers of new protocols to
consider the downside of these "structured identifiers" encoding
when they consider new approaches.
Structured host identifiers are incompatible with cryptographically
generated addresses, as used in SEND and proposed in SHIM6. We can
argue that SEND is a local protocol, and that the use of SEND can
be decided on a subnet basis. However, cryptographically binding
addresses to public keys has huge potential, not just inside
subnets. Think about secure mobility, secure re-homing,
opportunistic IPSEC, and other kinds of end-to-end security.
Standardizing structured identifiers breaks that.
Structured identifiers are not compatible with privacy address
extensions. Moreover, embedding addresses in identifiers discloses
information that would otherwise have remained hidden behind the
NAT and the firewall. The IPv4 address encoded in the host
identifier is passed to third parties, stored in server logs. The
third parties now have access to the local addresses used inside
the corporation. They can analyze subnet structure. At a minimum,
this should be a privacy concern.
Combining embedded addresses with stateless servers opens the door
to various kind of denial of service attacks. We analyzed several
such attacks in the security analysis of Teredo, but the attacks
are not specific to Teredo. The attacks derive from the stateless
nature of the transition mechanism. A transition router, relay or
gateway will receive a packet, extract the IPv4 next hop from the
structured identifier, and blindly relay the packet towards that
next hop, whether that next hop participates in the transition
scheme or not. Based on that, attackers can build denial of service
attacks, can hide their tracks in reflection attacks, can spoof
addresses.
The alternative is obviously to leave the identifier unstructured,
and to require transition servers to maintain the required mapping
state. For example, if I had to redesign Teredo today, I would
require servers to maintain tables of mapping between the Teredo
hosts that they serve and the corresponding mapped addresses. This
would increase the cost of servers somewhat, but it would improve
security and privacy aspects of the protocol. The same could easily
be done for ISATAP, letting routers use a variation of non-
multicast neighbor discovery to enable traffic.
I would like to encourage designers of new transition schemes to
study that alternative. Leave the host identifier unstructured, or
maybe use SEND as a structure. Keep the transition state in a
transition server. Use caching to increase reliability and diminish
server load.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
