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