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

["Steven M. Bellovin" <smb at research.att.com>]

	 The flavor I have is "end-to-end good, trusted gateway
	 bad," when the truth, as in so many things, lies inbetween
	 depending on the specific application.  I'd like to see
	 guidance for application architects.

As Steve Kent noted, ipsec was explicitly designed to support trusted
gateways.  That's one of its strengths -- you can trade cost of deployment
for granularity of protection.  People facing major threats (or people
with large budgets...) can get user-granularity protection; others,
who are less threatened, can protect an entire site with a single
ipsec gateway.

The question, though, is whom to trust.  If my corporate gateway
to the world was, say, via a satellite link, there would be no
conceptual (or in many cases, practical) objection to integrating
the ipsec function with the satellite relay, and having that box
play window size games.

On the other hand, it's clearly inappropriate to trust a random
router on the Internet, even if it claims it has to have such
access to better transmit your packets.  You don't know who they
are, and have no reason to trust them.  (Remember that the initial
"sniffer" incidents involved compromised ISP machines.)