Re: Last Call: IPSEC drafts -> Proposed Standards
bmanning@isi.edu writes:
I think that a significant point is not that MD5 is "weak" but that it is slow, by almost any standard. RFC 1810 discusses this problem in depth. If we, as a community are willing to live with reduced speed networks, then the use of MD5 is indicated. If we, as a community require 100Mbps and greater services, then MD5 is -NOT- a viable solution and requiring its deployment is as bad or worse than no security at all, since people will turn it off to get the performance that they have today.
People are generally not willing to sacrifice performance for security.
Use of MD5 is not required. Implementation of the MD5 transform for interoperability is required. There is no requirement to run any security at all at any time unless you like.
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. 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.) (Note to the NANOG community. Please review the proposed IP Security docs and RFC 1810. Perhaps the IESG would be willing to take input from an operations perspective here.) As for other transforms... Please contact Dr. Joe Touch (touch@isi.edu) for a writeup of his efforts in this area. -- --bill
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, etc. 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 louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 206 5908 Fairfax, VA 22031
In message <199507051531.AA10931@zed.isi.edu>, bmanning@ISI.EDU writes:
bmanning@isi.edu writes:
I think that a significant point is not that MD5 is "weak" but that it is
slow, by almost any standard. RFC 1810 discusses this problem in depth. If we, as a community are willing to live with reduced speed networks, th en the use of MD5 is indicated. If we, as a community require 100Mbps and greater services, then MD5 is -NOT- a viable solution and requiring its deployment is as bad or worse than no security at all, since people will turn it off to get the performance that they have today.
People are generally not willing to sacrifice performance for security.
Use of MD5 is not required. Implementation of the MD5 transform for interoperability is required. There is no requirement to run any security at all at any time unless you like.
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.
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.)
We use kerberos with the DES encription turned on for all services for which it is supported. For some application security is more important than squeezing the last Mb/s out of the wire. The nice thing about it is this is an end-to-end authentication, not hop by hop. Maybe no one does IP security through IPv4 options partially because too much IP option traffic kills certain routers used in a few remote parts of the Internet. ;-) Ooh there one a hop away from me. Yikes. I think it has trouble somewhere well under 86 Mb/s for typical packet sizes. (way under).
(Note to the NANOG community. Please review the proposed IP Security docs and RFC 1810. Perhaps the IESG would be willing to take input from an operat ions perspective here.)
As for other transforms... Please contact Dr. Joe Touch (touch@isi.edu) for a writeup of his efforts in this area.
-- --bill
At the very minimum, the final recipient must compute the MD5. Intermediate systems can forward packets with bad MD5 checksums if it is faster and the possibility of forwarding a damaged packet is not considered a big problem. If you *must* do MD5 on an OC12, get 3 MD5 hardware crunchers and run up to three packets in parallel. At 9180 B MTU and max 3 packet delay, you have a 220320 bits. At 655 Mb/s that's 1/3 msec delay worst case. A 10 OC-12 hop path would contribute 3 msec delay. Typical cross country high speed paths today are well under 10 hops. But if Joe Touch can modify MD5 slightly and make it faster by making it easier to parallelize, all the better. So what's the problem? :-) Curtis
participants (3)
-
bmanning＠ISI.EDU -
Curtis Villamizar -
Louis A. Mamakos