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

[Phil Karn <karn at qualcomm.com>]

>By creating an *option* of supplying port information to the
>classifier, it allows a user to give up a small amount of security and 
>gain the benefit of being classified into a different traffic category 
>that has different (presumably better) service.  I believe this is a
>valuable option.

Other, far better-layered mechanisms already exist to categorize
traffic with various levels of service. The TOS field in the IP header
is the prime example. Also, policy routing based on IP source and
destination addresses is also possible.

Admittedly, both these mechanisms raise difficult security issues of
their own if the economic incentives to abuse them are ever
created. E.g., if Internet backbones were to interpret the TOS
Precedence bits as a queuing priority indicator, charging by the
packet for high priority traffic while continuing to deliver routine
traffic on a best-effort basis for free, then there would be an
incentive to use false IP source addresses on high precedence packets
to avoid charges.

The use of IPSEC by end systems or border routers neither creates nor
eliminates such issues. But one can certainly conceive of applying
IPSEC to them.  E.g., an IPSEC tunnel from end user to carrier gateway
could authenticate the precedence fields on encapsulated packets that
are extracted and routed at high priority by the carrier. These
packets could in turn contain further layers of IPSEC encryption
operating on an end-to-end basis to protect against eavesdropping
within (or by) the carrier.

IPSEC was originally designed to protect hosts on small private
networks from the big bad public network. But it's also possible to
use it to protect (parts of) the public network itself from all those
hosts on private networks.  It's really a very flexible protocol.
It just takes a little imagination and creativity in using it.

Phil