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

["Howard C. Berkowitz" <hcb at clark.net>]

Your comments are along the lines of what I feel needs to be in the
document or referenced by it.  Like it or not, there are many users that
want to be able to point to language "in an RFC."  Just stating the
architectural alternatives may not be enough for nonspecialists.  The
language below on tradeoffs is necessary to help IPsec deployment.

At 9:41 -0800 3/31/98, Steven M. Bellovin wrote:
>	 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.)