Below is my rebuttal to the security analysis in draft-ietf-ipngwg-esd-analysis-04.txt. In a nutshell, I feel that use of IPSEC will prevent most of the attacks described. A concluding section discusses whether or not a global PKI is a necessary precondition for use of IPSEC. I have not addressed the concerns in the document that are not security-related. The Security of GSE A fundamental assumption when IPng was being designed was that all security would be cryptographic. That is, security associations mapped back to certificates would reliably identify endpoints. Address-based authentication -- insecure even in IPv4, and useless in the face of renumbering and mobility in IPv6 -- would not be used. Section 5.3 of draft-ietf-ipngwg-esd-analysis-04.txt asserts that there are security advantages to a locator being used as an identifier, since (Section 5.3.1) "it is impossible for some interface A to use the identification of another interface B in an attempt to receive data destined to B without being detected, unless the routing system is compromised. Unfortunately, that's just not so. Morris invented sequence number attacks -- a form of IP-spoofing -- in 1984; in 1989, I showed that source-routing (important in IPv6) could be used for such attacks. More recently, mechanisms have been developed to hijack TCP sessions. All that's needed is the ability to eavesdrop on a connection, an ability that has been demonstrated repeatedly by attackers. (Also note that an eavesdropper can defeat the defense against sequence number attacks that I proposed in RFC 1948.) Finally, many UDP-based protocols don't require a response to perpetrate a penetration. Apart from all that, attacks on the routing system are not that hard. If any ISP at all does not do suitable filtering, an attacker can inject false routes into the DFZ. This has happened repeatedly, though mostly by accident. Intrasite routing is often easier to spoof. 5.3.1 goes on to assert that ARP is a sufficient defense, since a communications failure is easily detected. Apart from the fact that failure detection is at best after-the-fact notification of a penetration, it is quite easy for an attacker on a LAN to send bogus ARP messages to both its target and the target's router. This is a classical man-in-the-middle attack, and not very hard to do. Additionally, an attacker can simply use promiscuous mode to receive all packets. But the real problem is in 5.3.2, which asserts that the routing system can't enforce authenticity with GSE. That's true, but irrelevant. If you care, use cryptographically-verified identities. 5.4.3 states that having TCP believe new RGs for existing connections would allow for trivial hijacking. Again, if the packet is authenticated before it reaches TCP, this can't be done. While the new RG can't be authenticated directly, we can ensure that it is bound to an authentic packet that isn't being replayed. Clearly, an attacker could send a burst of RG changes bound to eavesdropped packets, in the hope that one of the legitimate packets would be be a victim of congestion-induced loss. But that's only a denial of service attack; the attacker cannot inject fake TCP packets, because of the authentication. Similarly, encryption can and should be used to ensure confidentiality. Denial of service attacks are indeed a problem, but there are many other ways to perpetrate them. We could also design an authenticated host-to-border router protocol that could inform a machine of RG changes; notification of the far end can be via a TCP option, per Huitema's old draft (currently available at http://www.chem.ucla.edu/~beichuan/etcp/huitema-TCP.txt). Or, as noted, we could simply decline to handle RG changes for existing TCP connections. It isn't clear that any other proposal permits such connections to survive renumbering events, either. 5.4.4 discusses corrupted routing goop. I'm not impressed by the claim that corrupted RG in the SYN packet will lead to failed connection attempts. Given the near-universal use of link-level checksums, the actual incidence of such packets is low. Connections are far more likely to fail for other reasons, such as transient routing flaps. Yes, an attacker could corrupt the RG, but that sort of active attack is strictly harder than simply deleting the packet. 5.5 worries about duplicate ESDs. While allocation errors can occur, malicious attacks cannot, if the ESD is bound to the site's certificate. (That level of protection may require a PKI; see below.) The denial of service attack described in 5.5.2 requires the attacker to know the source's port numbers, or to use very many different port numbers in the attack. But that differs very little from today's SYN-flooding attacks. A partial defense would be for hosts to use pseudo-random selection of local port numbers, rather than today's sequential ordering. Using AH The analysis did not note that GSE is incompatible with AH. AH protects portions of the preceeding IP header, including specifically the source IP address. While this could be dealt with by excluding the RG portion of the source IP address from the AH calculation -- other fields already suffer this fate, so there's no new complexity -- I'd prefer to abandon AH, in favor of null-encryption ESP. As I've written in other places, I regard AH as difficult to implement, and of little or no security value. The Need for a PKI At first glance, using IPSEC requires the existence of a global PKI. With some exceptions, this is not necessary; in many cases, it's undesirable. Let me first distinguish between several different threats. First is an attack on authorization. That is, the caller wishes certain privileges; the server will grant them, based on the caller's identity. The second threat is what I will label "interference". A legitimate caller may have set up a connection; the attacker wishes to read it, interfere with it, etc. The third threat is denial of service, between unrelated parties. I assert that the deflecting the first two threats do not require any global PKI. In the first case, trusting an outside PKI for privilege-granting is not only unnecessary, it is unwise. To put the problem in concrete terms, if you trust guaranteed-certificates.com to authenticate your users, your security is wholly dependent on that of guaranteed-certificates.com -- if anyone can crack that site, they can impersonate your legitimate users. You're better off issuing your own certificates to your own users. That's the philosophical basis behind the SPKI work; it's also the way IPSEC is used today. The second threat is more interesting, since many of the attacks described in the analysis are on random connections, where there's no need for a local PKI. In those cases, though, all a machine really needs to know about a connection is that subsequent packets are from the same party as the original ones. That is, I can present to you a random certificate, and use the corresponding private key to encrypt and/or authenticate the connection. You don't know who I am, to any degree of certainty, but you don't really care. What matters is that a random stranger can't hijack or redirect the connection. There is, perhaps, the possiblity of an attack on the server's address, via DNS spoofing and the like. Apart from using DNSSEC -- that's a form of PKI, and is necessary anyway -- we face that threat today. An attacker who can corrupt DNS records received by a client could indeed hijack a connection, but that's true with or without GSE. To the extent that this a serious threat, it can be addressed by server-side certificates, a much smaller and simpler PKI. (It's also the one used today for SSL.) The remaining case is that of targeted denial-of-service attacks, as described in Section 5.5.2. Using certificates to block that class of attack would indeed require a PKI. As I noted, I don't see that as a serious incremental threat. The Bottom Line This is the problem that IPSEC was built to solve. While the precise form of renumbering wasn't clear when IPng candidates were being debated, renumbering was a prime goal. This in turn implied the need for something like IPSEC. We realized, at the time, that we would need to abandon anything that resembled address-based authentication. This is just a concrete instantiation of the problem; IPSEC remains the solution. Put another way, IPSEC can protect traffic's authenticity and confidentiality, regardless of routing and addresssing structure. It can't protect against misrouting -- but neither can anything else we have today.