Last Call: IPSEC drafts -> Proposed Standards

Curtis Villamizar curtis at
Wed Jul 5 23:52:56 UTC 1995

In message <199507051531.AA10931 at>, bmanning at ISI.EDU writes:
> > 
> > 
> > bmanning at 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 at
> 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?  :-)


More information about the NANOG mailing list