[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: transport-friendly ESP
At 07:44 PM 1/30/99 -0800, Alex Alten wrote:
>Steve K.,
>
>As a technology spreads it starts to be used in ways that may
>not have been intended by the original designers. Possibly IPSEC
>is better suited for per hop protection within a security system
>which maintains and enforces intermediate node trustworthiness.
Ok, I'll say it again.
No. No, No, a thousand times No.
Most routers at the "core" of the internet (i.e. pretty much
every router from when a packet enters my ISP until it
emerges from the ISP at its destination) use, or shortly
will use, hardware-based forwarding. Putting security
"stuff" - running encryption algorithms or message digest
hashes, simply won't happen in the near term because
- The lookup for the security attributes takes memory
accesses which are in short supply. At OC48 the max
packet rate is something like 6.2M/sec. If your memory
can do 100M accesses/second, that gives you about
16 accesses per pacet before fifos back up. Think about it.
- Core Routers often channel many different Interfaces through
a single ASIC (i.e. they have multiple internal contexts).
Each such stream represents one or more packets that could
be going through the crypto-goop. Crypto-goop requires that
there are intermediate results that have to be generated
with "this" chunk of data and then used on the "next"
such chunk in the stream. This increases storage requirements
on the chips, or memory accesses to save and then retrieve
the state. And memory accesses are precious resources, not
to be used lightly.
- Encryption and hashing algorithms change frequently as
hyperadenoidal, asocial, teenagers crack the current ones.
Redesigning the ASICs in the router every time this
happens, and then doing an upgrade of all the routers,
is a non starter.
- The NRE to the FAB alone is on the order of 1M.
Thats $ spent before you even think about the designers
of it, etc, etc, etc.
- The turnaround time is measured in months. You can't pull
a couple of all-nighters, quickly test some code, and ship
out new CDs by the end of the week. There's probably a minimum
of 4-6 months here.
- It requires board replacement. No sockets today. ASICs
can have _lots_ of "pins" - 1500, 2000, or more... That
means replacing boards in the field and scrapping the boards
that are there now...
- Encryption and hashing algorithms typically have lots of
repetitive operations. A typical chunk of data is processed
many times. Each 'pass' through the process can probably be done
in one tick, but you've got P passes through the process for
each chunk, taking P ticks per chunk -- and the line rate is
probably less than P ticks/chunk. eg, assume a 100MHz asic
and OC48. OC48 is ~300MB/sec - about 3B/tick. To receive a
single 8B chunk takes ~3 ticks -- how many times do you have
to look at those bytes if doing DES?
This problem, btw, is alleviated by pipelining and parallizing
things -- looking at chunks from different packets at different
points in parallel -- but that means more storage, etc, on the
ASIC which consumes space for the storage and space for the
multiple pipeline stages...
To repeat myself
Core routers will most likely not be doing any crypto
stuff in the forwarding path for the next several years,
at least. Any solution based on an assumption that they
will is simply not going to happen.
Frank Kastenholz
Follow-Ups: