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

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

	 | 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.
	 
	 No; it _may_ be inappropriate to trust such routers.
	 There _may_ be some set of traffic that even paranoid
	 people would not feel the need to protect, if that lack
	 of protection would lead to better performance.

I very carefully used the qualifier "random" in my comment.  Very clearly,
there are some routers whom one may wish to trust.  Equally clearly,
there are some which should not be trusted.  How can one tell the
difference?  Even more to the point, how can one tell that a given
TCP circuit (or worse yet, UDP exchange) will transit a particular
path or router.

One of the challenges of our architecture -- note carefully that I do
not say "problems" -- is that end systems do not and can not, in general,
know the path traversed.  Even if a determination is made, the path
could change at any time.  Thus, Path MTU requires periodic attempts
to raise the MTU.

You're certainly right that not all traffic need be encrypted.  There
is a major challenge to end system designers here, in that they need
rational mechanisms by which administrators or end users can request
encryption, authentication, or neither, depending on the type of
traffic involved.
	 
	 | You don't know who they are, and have no reason to trust them.  
	 | (Remember that the initial "sniffer" incidents involved compromised 
	 | ISP machines.)
	 
	 Or deliberately configured stations sitting on conference
	 terminal room LANs...  :)

Yup.  (At this meeting, I was rather intrigued to notice an attempt to
connect to my X server, from an address assigned to this group.  Hacking?
It turned out to be the printer server, wanting to tell me that it had
finished printing, by popping up a window on my screen.  Thoughtful
of it, I suppose, though in general I'm not fond of random parties
connecting to my X server...)
	 
	 Presumably if some device in the path between you and the
	 opposite end of a "conversation" offers a service whereby
	 your conversation cannot happen unless it is in the clear,
	 you have a fairly straightforward black-and-white decision
	 to make.   It is liklier that there may be some shades of
	 grey.  
	 
	 For example, Mike O'dell mentioned some devices which do "unspeakable"
	 things to HTTP traffic passing through them, which, in a charging
	 regime which is not exclusively flat-rate, might reduce a subscription
	 fee paid to the operator of such devices.  (This happens now).
	 
	 The trade-off in this case is not one of "don't encrypt or it won't wo
	rk",
	 but rather, "don't encrypt and you may save money".
	 
	 I think as ISPs better understand how to deal with known scaling
	 issues -- and how to manage not-yet-known ones that will arise --
	 by modifying their pricing structure to better follow costs, rather
	 than by making policy edicts to stem costly unbilled-for behaviour,
	 more choices will be put into the hands of users, who should be
	 aware that a poor choice will work but may be rather expensive.

Sure.  They should also be informed of the other consequences of such
a choice.  And it's poor architecture, in my opinion, if the choice
should have to depend on a variable path.  And we may be better off
if people designing intermediate node or link mechanisms -- including
firewalls, NAT boxes, satellite gateways, and the like -- looked for
design alternatives that could co-exist better with IPsec.