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.