Subject: SEND IPSec Implementation Update

From: Jonathan Wood <[email-masked]>
Date: Thu, 26 Jun 2003 11:28:51 -0700

We (DoCoMo Labs) have been implementing
draft-ietf-send-ipsec-01.txt on Linux 2.5.x. One of the
goals is to determine just how much we need to twist
the Linux IPSec implementation. We have found the
answer to be "a lot".

One of our implementation goals has been to reserve
the option of pushing to user-space things like ASN.1
parsing, RSA encryption and decryption, and cert chain
retrieval and processing. The motivation for doing so
is that all incoming and many outgoing packets are
processed in the interrupt context (more precisely,
the bottom half context, for those familiar with Linux),
where you don't want to be doing time consuming
operations. We also want to keep ASN.1 bloat to a
minimum in the kernel.

It turns out that we would need to muddy considerably
the IPSec and IPv6 stack implementation to enable
userspace offload if we need to do it from either
extension header parsing or an AH transform. Without
diving into detail too much, pausing ext header and
AH transform processing in mid-step and then restarting
it later is quite nasty.

The semantics of AH processing in Linux also create
problems for a SEND implementation. Linux IPSec
is very modular. Digest transforms all implement a
common, clean interface. Digest callers (such as AH
processing code, both inbound and outbound) simply
provide the transform with a chunk of bytes and ask it to
compute the digest according to its parameters. SEND,
however, requires that the digest do much more. First,
the transform needs to know if the packet is outbound or
inbound. If inbound, the transform needs to verify the CGA
and the crypto signature, and make the decision on whether
to drop or accept itself. Enabling these semantics would
require new interfaces on the digest code, and some
mechanism to allow AH to decide whether it should use
the traditional or SEND semantics when processing a
packet.

So we believe that while SEND as currently specified is
doable, it won't be pretty, and will probably have a very
difficult time being accepted into the mainstream Linux kernel.

draft-nikander-send-ipsec-00.txt encounters most of the same
problems discussed above, since we would still need to pause
in the middle of ext header and AH header processing.

draft-arkko-send-ndopt-00.txt, on the other hand, looks right
now like it can avoid all these problems, since we are not
bound by the semantics of AH processing, and by the time
we get to a ND option, it is easy to pause and restart later
if we need to do some heavy crypto lifting, or retrieve a cert
chain.

j

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------