Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



| 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.

| 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...  :)

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 work",
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.

	Sean.



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.