Last Call: IPSEC drafts -> Proposed Standards

then we get the 99% problem indicated earlier. slow protocols are available
now, through the use of IP options. Although there, almost no-one uses them
due to the processing constraints. This is yet one more case of selecting
the least common demoninator, which almost noone will use.

For low speed connections, like my 56K circuit at home, the overhead
of doing MD5 is completely acceptable and a no-brainer. Heck, even
doing DES at 56K in software isn't something that you have to agonize
over too much.

Further, you needn't use it on all packets. For example, FTP data
connections probably don't need this protection if there is an
external (e.g.) PGP signature on data/file being transmitted.

Louie, why doesn't your employer use IPsecurity today? It's available via
IP options. (Perhaps we should ask operations types if they are willing to
accept a security model which robs them of throughput on todays networks and
prevents them from using faster transports in the future.)

Ah, but the different is that IP options hurt all the way through,
whilst the IP security is a performance impact which is selectable on
a case by case basis by the endpoints.

One way you do this now is by encapsulation. I've got software which
tunnels endpoint together, allows you to authenticate and/or encrypt
the whole of the packets going through. Too bad it does it
differently than the UUNET LAN Guardian, or the Morning Star router,

We could choose to argue endlessly over how "strong" or "expensive" a
mechanism is required, necesssary, or reasonable. But the fact that
it's extensible truncates that discussion. If I feel strongly enough
or have specific requirements for something else, I can go off an do
it (or buy it, if enough other folks feel that way).

Louis A. Mamakos, Manager of Network Engineering, uunet!louie
UUNET Technologies, Inc. Voice: +1 703 206 5823
3060 Williams Drive Fax: +1 703 206 5908
Fairfax, VA 22031