In message <9711031919.AA19222@cichlid.raleigh.ibm.com>, Thomas Narten writes:
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. 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.
Sure, we can say "that is broken and must be changed", but doing so will not be painless or free and begs the question as to whether the total cost of doing this exceeds the benefits NAT brings. It is questions like this that make me question whether we fully understand how scalable/viable NAT really is for the long term.
--- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 http://www.fc.net