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@home.net