The MPLS-OPS Archive

["Tim A. Irwin" <tirwin@bellsouth.net>]

Daniel wrote:

[snip]

>     A $1200 vanilla desktop PC from two years ago can fill a T3's
> worth of bandwidth with high-grade IPSec.  The fact that my cisco
> can't means that I'll use my cisco for what it's good at.

I don't recall mentioning Cisco in my response.  I don't really care who the
vendor is, you still have overhead associated with encryption/decryption.
If you know of a vendor that doesn't take a performance hit WITHOUT hw
acceleration, please let me and the rest of us know.  Let's also not forget
that cryptographic algorithms must increase with complexity over time
because Moore's Law tells us that processing power is ever increasing,
thereby increasing the likelihood that the cryptographic algorithm can be
compromised over time.  (i.e., it has already been shown that DES can be
compromised, hence 3DES.)  That means the cryptographic algorithms will use
more and more CPU in the future, and these calculations are not exactly
trivial.  Most vendors that I'm aware of have gone to hw-based acceleration
for precisely this reason.  For the SP it's scalable, because YOU DON'T HAVE
TO DO ANYTHING to support it. It's NOT scalable for customers.

As far as performance, it's not the size of the pipe, it's the number of
encrypted sessions.  You don't have to be a math major to realize that as
the number of IPsec sessions per circuit increases, there is less bandwidth
is available for actual data because of the ESP/AH overhead.  Furthermore,
as the number of sessions increases linearly, no device without hw-based
acceleration can maintain linear performance. Since this is being done on
the CE end, the customer is the one who actually loses, not the SP.

I'm not saying that IPsec doesn't have a place, just that it's not without
it's scalability limitations, as was suggested.

>  > to assist a customer in troubleshooting problems since the SP
> intermediate
>  > devices can't see what's going on inside the IPsec ESP payload.
>
>     For some of us, that's the point.

Maybe that's why your customers might be my customers one day. :)

>  > By the way, in reference to your statement about "standard IP
> packets" take
>  > a look at IPsec in transport mode and tell me if I doesn't
> look a lot like
>  > MPLS labels...  A shim header right behind the IP header and
> before the TCP
>  > header. Hmmm.... looks pretty similar to me!
>
>     One requires a pile of intermediate stuff to have any meaning.
> The other only cares about being delivered to the far edge of the
> network.

All I'm saying is that I don't see what was meant by "standard IP
packets"... when it comes right down to it, IPsec packets don't look any
different from IP w/ MPLS packets.  Both approaches use shim headers.  All
an MPLS device does is forward based on the label, not the IP header.  The
difference is MPLS does it on the provider side, and IPsec does it on the
customer side.

-Tim


-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml