> -----Original Message----- > From: Rémi Després [mailto:remi.desp...@free.fr] > Sent: Tuesday, July 07, 2009 3:03 AM > To: Christian Huitema > Cc: Brian E Carpenter; Xing Li; 6man; Behave WG; Dave Thaler > Subject: Re: Perils of structured host identifiers (was: Modified EUI- > 64 format) > > 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).
Disagree on multiple accounts. First, as I stated in other threads the "g" rule doesn't apply to IPv6 addresses. It only applies to IEEE EUI-64's (not Modified EUI-64's or interface identifiers). Second, it's not true that they only apply to addresses used on IPv6 links. The u/l bit is reserved for global use as Brian Carpenter also noted. > 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). I can't parse the above sentence. > - Since CGAs are to be used on IPv6 links, they are not concerned > with Point-1. Disagree, see above. > - 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 --------------------------------------------------------------------
