Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

[Phil Karn <karn at qualcomm.com>]

>I have one serious concern about the IP Security Architecture, which is the 
>fact that IPSEC packets encrypt the TCP/UDP port numbers in packets.

This is a deliberate feature, not a bug. Actually, it's not even a
"feature" per se -- it's an inherent property of encryption just above
the IP layer, which is what IPSEC is all about.

Encryption just above IP is in keeping with the well-established
security principle of "need to know". IP is itself designed such that
all the information a router really needs to know -- and nothing else
-- is contained in the IP header. So only it needs to be in the clear,
and everything above it can be encrypted. (Actually, this is not
*quite* true -- the Protocol field is interpreted only by the
destination host, so it doesn't really belong in the IP header. But
IPSEC fixes this by replacing the IP header Protocol field with "ESP"
and moving the "real" Protocol value into the encrypted IPSEC header.)

As an aside, I've noticed that well-layered protocols lend themselves
well to effective security mechanisms. Conversely, ill-layered
protocols are hard to secure. A major side benefit of the widespread
deployment of encryption is to force our protocols to be better
layered. In turn, this makes them easier to secure.  I consider this a
Good Thing both ways.

IPSEC is especially useful for constructing virtual private networks
over the public Internet. The IPSEC tunnels carrying packets between
the "islands" of the virtual private network will therefore carry IP
packets in their payloads, the entire contents of which will be
encrypted. Only the IP addresses of the tunnel endpoints are (and need
be) in the clear. An attacker cannot determine the identities of the
end systems using the tunnel or even how many are in each "island"
(except as can possibly be inferred by traffic analysis). This helps
protect those end systems from being identified and targeted for
attack by other means. (It's well known (see Bellovin and Cheswick)
that hosts "protected" by firewalls tend to let their own host-based
security mechanisms atrophy, making them "chewy" targets to an
attacker that can find some other means of reaching them.)

Another example of the utility of IPSEC is in protecting the identity
of a Mobile IP user. If the user runs his own foreign agent in
combination with IPSEC, then an eavesdropper can only determine that
someone belonging to a certain home agent is active from a certain
area. He cannot identify the specific user, because the Mobile IP
user's permanent IP address is encrypted inside the IPSEC tunnel
created between his foreign and home agents. If the home agent serves
many users (or if its packets are further protected by separate IPSEC
tunnels), even greater protection is obtained.

Even when IPSEC is used on an end-to-end basis, with the transport
protocol header immediately following the ESP header, encryption just
above IP is still beneficial. It prevents a potential attacker from
learning the nature of the applications being run on the machine or
even whether it is acting as client or server (though this could
probably be inferred by the timing of the packets exchanged). This
makes it that much harder for an attacker to know which services he
should attack.

In sum, by encrypting everything not absolutely essential for an IP
router to do its job, IPSEC is the single strongest Internet security
tool one can conceive of short of generating decoy traffic to thwart
traffic analysis. But it will probably not replace other security
mechanisms. PGP, SSH and SSL will continue to be widely used wherever
the end hosts support them. Much traffic that is non-sensitive (such
as public web objects) will remain in the clear (though encryption has
utility even here as a means of protecting the reader's identity.)

Those monitoring net traffic will still be able to distinguish these
applications from each other and from IPSEC ESP and AH.

Phil