"J. Noel Chiappa" <jnc(_at_)ginger(_dot_)lcs(_dot_)mit(_dot_)edu> writes:
For a classic example, look at the recommendations of the IAB Workshop last
year about IPSEC (and I'll asssume for the moment that IPSec is important to
securing the Internet, and stay away from the debates about IPSEC versus SSL,
etc):
It is urgent that we implement and deploy IPsec using some other
identifier than 32-bit IP addresses ... The current IPsec specifications
support the use of several different Identity types (e.g. Domain Name,
User(_at_)Domain Name). ... We strongly urge the IETF to completely
deprecate the use of the binary 32-bit IP addresses within IPsec
... in particular any IP address dependencies should be eliminated from
ISAKMP and IKE. Ubiquitous deployment of the Secure DNS Extensions ([8])
should be strongly encouraged to facilitate widespread deployment of IPsec
(including IKE) without address-based Identity types.
So, has any of this happened?
If I had a dollar for every time someone suggested just fixing
IPsec...
"Fixing" IPsec really also means fixing TCP/UDP, since they have
checksums that cover the IP addresses in use. Sure, if IPsec is in use
its MACs are stronger than the TCP/IP checksum, but one still has to
fix TCP/UDP to be IPsec aware so that they don't step on each other's
toes and do the wrong thing.
Bernard Aboba's recent posting to ipsra provides some excellent
details on some of the issues.
From: "Bernard Aboba" <aboba(_at_)internaut(_dot_)com>
To: <ietf-ipsra(_at_)vpnc(_dot_)org>
Date: Sat, 15 Apr 2000 15:56:35 -0700
Subject: NAT and IPSEC issues
Reply-To: <aboba(_at_)internaut(_dot_)com>
Importance: Normal
While we're on the subject of NAT and IPSRA issues, it might
make sense to articulate what the issues are exactly.
Here's my understanding:
a) IPSEC AH will not go through the NAT, because the AH header
incorporates the IP source and destination fields in the
authentication hash.
b) IPSEC ESP does not incorporate the IP source and destination
fields in its authentication hash. However, there is an
implicit dependency on source and dest. addresses within
TCP and UDP checksums which cover the "pseudo-header."
Therefore ISPEC ESP will only go through the NAT if
TCP/UDP protocols are not involved (as in IPSEC tunnel
mode or IPSEC/GRE), UDP/TCP checksums are turned off, or
if UDP/TCP checksums are ignored by the receiving party.
c) IKE will only go through the NAT if the parties do not
check or use IP addresses in IKE MM identifiers (several
current implementations don't do this) AND if in addition
they don't check or use IP addresses in IKE QM identifiers
(most implementations DO use addresses and check them).
d) Because of IKE rekeying behavior, it is necessary for
implementations to float their IKE source port in order
to enable NATs to de-multiplex incoming rekeys which may
not use the same cookies as the earlier traffic.
e) In order to enable an IPSEC implementation to send traffic
down the correct IPSEC SA, it is necessary for those SAs
to be differentiated in some way. In practice this implies
negotiation of non-overlapping filters.
Some conclusions resulting from the above:
1) Because many IPSEC tunnel mode implementations negotiate
filters of "ANY to ANY" it is possible for their IKE traffic
to pass through NATs. However, the issue of overlapping filters
means that there can only be a single IPSEC tunnel up from
behind the NAT box to the security gateway. If there were two
tunnels up, each with the same filters, the security gateway
could be confused and send traffic down the wrong one.
2) While it might be helpful to use something other than IP
addresses as identifiers in IKE MM, in practice the real
issue is the identifiers used in IKE QM. While FQDNs or
userIDs could be used to signify "me" and "you" if it is
necessary to use subnets in the filters it is not clear
how this could be addressed.
3) While IPSEC tunnel mode with "ANY to ANY" filters
can pass through a NAT, IPSEC/L2TP cannot, due to the
specific filters that need to be negotiated.
4) To get IPSEC transport mode to work (with ESP) it would
be necessary to either turn off UDP/TCP checksumming or
have receivers not do checksum checks on packets protected
by ISPEC SAs. At first glance, it wouldn't appear that
ignoring checksum checks would do much damage since
the cryptographic hashes are stronger than checksums
anyway.