Hi Robin, >> ILNP has no basic flaws (as known to date). > > That's a matter of opinion.
That's correct. While your opinion does not match mine, you happen to be incorrect. > 1 - Extra delays establishing communication sessions, > extra packets and/or longer packets, plus extra CPU > effort for all hosts. (Common to all CEE Loc/ID Separation > architectures.) msg07017. ILNP resolves its mapping as part of normal DNS lookups. There are no extra sessions and no extra packets during connection setup. > 2 - No prospects of wide enough voluntary adoption to provide > substantial benefits to adoptors or to scalable routing - due > in part to the benefits arising only when essentially all > hosts have adopted it: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ The lure of seamless mobility is ample motivation. > 3 - Applicable only to IPv6, since ILNPv4 requires all DFZ and > other routers be upgraded to handle the new header option. Both necessary and sufficient. > 4 - Identifier uniqueness is brittle due to dependence on host- > generated identifiers from MAC addresses and the like, which > may not be unique. Also, it is not assured that all hosts > now or in the future have any unique hardware from which > to derive a unique hardware identifying number Globally unique identifiers are not brittle. > 5 - Inability to look up an Identifier to find its one or more > Locators. This is not necessary. > As long as ILNP supports all current applications (which remains to > be seen), it should be able to support all existing protocols. If > this can be done, I think these protocols will run slower (at least > in the initial exchanges) under ILNP than they do on native IPv6. Why? > Some protocols may become very slow and inefficient under ILNP, such > as any protocol which involves UDP packets flying back and forth > between a large number of hosts, rather than concentrating on simple > two-way sessions. There are no additional packets. Where did this alleged latency come from? > Can you cite an instance where people are expecting ILNP to be more > secure, or better in any way, than IPv6 today? All of the attacks listed are exactly identical to ones that can be done on IPv6 today. > OK - hence the title of this thread. Therefore, this option in ILNP > doesn't accord with the text you wrote in the RRG Recommendation, > regarding the architecture using constructs which are first-class > citizens. Locally unique identifiers are intentionally not first class citizens. Globally unique ones are. >> Now I, and many others, don't particularly care. However, the >> fact of the matter is that there are MANY others who do care. > > "Many" is a big word. Can you document this? Please see the archives of the big-internet mailing list. > Who really cares about the ability of an IPv6 host to repeatedly > choose a fresh lower 64 bits for its IP address, thereby breaking > all sessions, but supposedly achieving a degree of privacy not > possible if it retains the one set of bits? The entire security directorate, security AD, the IESG and the IANA. > OK - but it makes the host stack much more complex, Agreed, however, it is still vitally important. > I guess there would be other complications - I haven't tried to think > of every one. I assume that a host using XXXX-BBBB can communicate > with hosts in /64s other than XXXX - otherwise, this would be no use > for privacy. So three hosts all with the same Identifier, locally > unique in their own /64s, and so with IP addresses XXXX-BBBB, > YYYY-BBBB and ZZZZ-BBBB should all be able to communicate. Note that a locally unique identifier effectively gives the host the same capabilities as a legacy v6 host plus multi-homing support. But not mobility. > I am a privacy advocate and I was never much impressed by IPv6's > option for rapidly changing lower 64 bits as a privacy enhancement > measure. While it may not be a solution, I suspect that you will concur that a trail of a permanent, globally unique identifier is an even larger privacy issue. It's the logical equivalent of a continually updated Google maps page with a red pin stuck in it that says "Robin is here right now". ;-) > I think you could get much the same level of privacy by having the > host switch between a large number of pre-existing globally unique > Identifiers. All will use the same /64 prefix for their Locators, I > guess - so this would be equivalent to the current "privacy" > arrangements in IPv6. Except that the number of identifiers necessary for a host balloons, as they basically need to be a one-time pad. This depletes the address space unnecessarily quickly. If, instead, the locally unique pool is dynamically assigned and reused, in much the same way that DHCP assigns addresses today, we avoid this issue, we get local uniqueness, and identifier reuse. > I still think ILNP would be significantly improved by getting rid of > locally unique Identifiers and using only globally unique, > hierarchically assigned Identifiers. Sorry, that won't be happening. Get over it. > I believe you can't claim that the Identifier and Locator semantics > are crisp and clear as long as you allow these locally unique > Identifiers. Fortunately, I'm a _recovering_ perfectionist. There is such a thing as good enough. > Yes - but good architecture is robust and not overly dependent on > correct configuration of external systems. As far as I know, the > only way to get robustly globally unique Identifiers involves > bureaucracy. Bureaucracy NEVER is robust. A glance at any front page should tell you this. >> IPv4 addresses are hierarchically assigned and >> should be unique. Has anyone done any significant amount of >> networking work and not seen duplicates? Hierarchical assignment >> is also an imperfect solution. > > Can you cite any actual examples? Hundreds, personally. Prior to the advent of DHCP (and even in the early days of DHCP), getting duplicates was trivial. And it still happens in the lab, when some enterprising soul decides that allocating an address manually is too hard and simple "makes one up". In defense of that, every OS that I can think of has duplicate address detection logic. And also why DAD is built into IPv6 ND. Oh, and that's just for /32's. > I know sometimes by accident or > design a whole prefix is advertised in the DFZ in a way which hijacks > traffic from the router which properly advertises this prefix. That > is not altered by any of the proposed architectures. But that kind > of attack is generally very public, easy to detect and at odds with > accepted standards of router administration. But that's not very robust, is it now? You seem to want perfection. This is clearly imperfect and therefore unacceptable. <Insert Kirk's monologue from The Changeling.> > Sure, but they are localised to Ethernets or whatever non-globally > significant domains a MAC address is used. Sorry, but no. People are talking about trans-oceanic data center migration for disaster recovery. Necessary as certain parts of the world are considered likely to slip off into the ocean. > Neither I nor anyone else is expecting ILNP to solve problems caused > by MAC clashes. Yet you consider Xu's 'attack' to be a flaw. It is EXACTLY a MAC collision. And to be frank, you can execute it today: go to your favorite WiFi hotspot. Sniff the traffic. Copy down someone's MAC address. Go again tomorrow, and use their MAC address before they show up. Your logic is inconsistent. > There have been three lines of discussion here - which have been > somewhat entwined: > > 1 - The DoS attack I call "Identity squatting", as proposed by > Xiaohu Xu. This has nothing to do with MAC addresses. It > doesn't matter whether the supposedly globally unique > ILNP Identifier results from hierarchical assignment, > MAC addresses, or radioactive decay. The point is that if an attacker has your identifier/MAC address and is authorized to join a subnet without any link level authentication, then they can either impersonate you and/or DoS you. We'll ignore the fact that they can also snoop you. The remedies for this are well known and have been mentioned to you, yet you fail to accept them or explain why they are problematic. Again: 802.1x, SeND. Instead, you endlessly repeat your allegations. Do you understand why discussions with you are pointless? You accuse, but you do not listen to responses. > 2 - Problems resulting from non-hierarchical assignment of > Identifiers - specifically the current plan of using a > MAC address or some other hardware identifier to generate > the Identifier, in a direct, deterministic, manner by the > host itself. Problems from hierarchical assignment are provably FAR worse. Experience in the field has made this very clear. > Several folks have written about MAC addresses not being > unique, and of (virtual) hosts not having any unique > hardware to gain a MAC address or any other globally > unique number from. Yes, mistakes happen. If you want a world without mistakes, you first need to remove all humans. Sorry, but you're on the wrong planet. You need to weight the probability of mistakes. So far, the odds of a duplicate MAC are FAR lower than a duplicate manually assigned /128 or /64. > But that rules out mobility. I and I guess many other people believe > that a scalable routing solution without mobility is a non-starter. Asked and answered. > Because Ran and I think you set such an elevated threshold between > "architecture" and "engineering" and since it seems the details of > the stack code fall into the latter - which you have little interest > in False. Do you understand how much code I've written? And where it runs? Hint: this message will not get to you without it. ;-) > - I don't think you have fully considered what a horror it will be > to write this stuff, and somehow support existing applications with > the assumptions they currently make about the properties of IP addresses. Incorrect. This is not even hard. > I think you are failing to distinguish between what I am discussing > here - the "Identifier squatting" attack (1) - and the matter of > whether supposedly globally unique Identifiers result from > hierarchical assignment or are generated by each host from a MAC > address or the like (2). I'm trying to respond to your comments. It's not my fault if your line of discussion is confusing. > It doesn't matter how you generate globally unique Identifiers or > whether or not they are in fact globally unique - the "Identifier > squatting" attack will still work. Until you apply the remedies as discussed. Similarly, other IPv6 attacks will work, until you apply IPsec. Nothing new here. > Not counting international roaming and switching from one 3G/GSM > network to another (which may clobber the call, for all I know) the > situation with cellphone companies is rather different than what > would be required to protect ILNP from the "Locator squatting" attack. Incorrect. You're correct about roaming dropping calls, but the ability of a handset to authenticate itself and have a unique identifier (IMEI) are well known. In the cell world, the analog to the locator squatting attack resulted in theft of services, so non-cleartext link layer authentication was introduced. We simply need the same. > The cellphone companies run their own access network so the whole > thing is integrated. The architecture is almost identical to the Internet's. Many different bands, several different protocols, all resulting in roaming with authentication and end-to-end calls. > Global mobility of the kind that ILNP aims to provide (as does TTR > Mobility, and now Fred Templin's IRON, using similar techniques) > requires that the host be able to use some access network which has > no relationship with the Mobility provider. The access network > cannot be assumed to have any special mechanisms. Disagree. If you want secure mobility (not everyone does), you need authentication. > To prevent the "Locator squatting" attack, every protected access > network would need to prevent a host getting a lower 64 bits QQQQ > until one of these was true: > > 1 - The system had determined that QQQQ was not used as a > globally unique ILNP identifier by any host whatsoever. > > (This could only be done with an Identifier indexed lookup > system, which I think would only be possible if all > Identifiers were hierarchically assigned.) > > This would require an explicit negative response from a > single global lookup system. > > 2 - The lookup indicates that QQQQ is being used as an ILNP > Identifier. Then the routing system needs to engage in > a cryptographically secure exchange with the host, and > probably with whichever organisation administers this > part of the Identifier hierarchy, so that the host can > prove it is authorized to use this Identifier. 3 - The host accessing the network was a cryptographically authenticated known host, with a non-cleartext protocol, with known host attributes, such as the MAC address and identifier. > So this would involve retrofitting every IPv6 network which could be > used for mobility, in order to protect against this attack. Only if you care about secure mobility. If you don't, you can visit Starbuck's today and squat away with IPv6 today. > I think you do not understand this attack. It has nothing at all to > do with MAC addresses. It is arguably spoofing an ILNP Identifier, > since there is nothing to prevent this from happening at present. I think YOU don't understand the attack. If I sniff your IPv6 address today and arrive at Starbuck's ahead of you, I've done _exactly_ the same thing. Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
