IPsec processing & NAT (was Re: moving to IPv6)

Mon Nov 3 23:26:24 UTC 1997

>> I agree 100% when it comes to payload, but network addresses serve
>> the network as much as the packet.  To the extent that we start
>> deploying networks with more functionality (such as mail relaying
>> and web caching), then the same logic applies to DNS names.

>One big problem we have today is that transport addresses have
>embedded within them network addresses. To cryptographically protect
>transport-level connections in practice means that network level
>addresses (i.e., those in the IP header) cannot be safely modified.

% I don't think that this is correct.  IPsec relies on IP in IP
tunneling,
% thus the transport level identifiers can be modified without affecting
% the payload.  Since I don't think we have any boxes doing signatures
% on single packets, I don't see a problem here.  Unless you are
modifying
% the addresses presented to the application insided the NATed network,
% during the session interval, you will be able to use the transport
level
% indentifiers as a session tag for the decryption.

	Wrong.

	IPsec input processing (regardless of transport/tunnel-mode and
regardless of ESP/AH) always requires that the Destination IP Address in
the outer IP header be used to locate the correct IPsec Security
Association for the received packet.

	If the NAT function changes that Destination Address, the attempt
to locate the IPsec Security Association will fail and the received
packet
will be dropped.

	If the NAT function changes the Source Address, then the required
(to prevent IP spoofing attacks on IPsec) Source Address check will fail
and again the received packet will be dropped.

	The only way to make IPsec work through a NAT box is to have the
NAT box participate in the IPsec session(s).  Sample topology follows:

	NOTATION:
	=	IPsec protected traffic flow
	-	unprotected IP traffic flow
	[]	delimiters for a single box
	Hn	Arbitrary IP host
	Nn	Interface "n" on the NAT device

	TOPOLOGY DIAGRAM:

	[H1]======[N1----N2]======[H2]

	COMMENTS:
	  Traffic is unencrypted between interfaces N1 and N2.
	NAT function occurs somewhere between N1 and N2.
	IPsec protects traffic between (H1 and N1) and between
	(N2 and H2).  The NAT device N could modify the unencrypted
	traffic and {H1, H2} have no method of determining whether
	modification happened -- hence {H1,H2} are forced to trust
	N whether or not they desire to do so.

% If you have a payload that is encrypted and signed, there is
% fundementally no reason for the application to know anything other than
a
% magic cookie return address.

	False, at a minimum the identity of the signer needs to be known
(so the signature can be verified if appropriate).  A key identifier or
other attributes might also be needed, depending on your precise meaning.

Ran
rja at home.net