Date: Fri, 5 Apr 2002 08:31:34 -0800 From: "Sam Leffler" <sam@errno.com> To: "Shoichi Sakane" <sakane@kame.net> Cc: <freebsd-net@FreeBSD.ORG> Subject: Re: kame ipsec vs. openbsd ipsec Message-ID: <354301c1dcbf$5a6d95c0$52557f42@errno.com> References: <2c1d01c1db3b$460c7720$52557f42@errno.com> <20020405172620N.sakane@kame.net>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Shoichi Sakane" <sakane@kame.net>
To: <sam@errno.com>
Cc: <freebsd-net@FreeBSD.ORG>
Sent: Friday, April 05, 2002 12:26 AM
Subject: Re: kame ipsec vs. openbsd ipsec
> > 1. Has anyone else seriously looked at doing this?
> > 2. Has anyone compared the OpenBSD and KAME implementations and
understand
> > their relative strengths? (e.g. is there some reason to work with KAME
other
> > than it's already in the system)
>
> i have summarized what some people argued to merge OpenBSD IPsec
> implementation into FreeBSD.
>
> some people say that OpenBSD has advantage because:
> 1. it supports the crypto hardware acceleration.
The advantage is that openbsd has it working now. I started this thread
because it appeared that adding the same functionality to the KAME
implementation would cause the KAME code to look a lot like the openbsd
implementation.
> 2. because SA is shown as a pseudo interface,
> 2-a. we can see how packets are flowed through the interface
> by netstat(8).
> 2-b. it can configure packet rules easily.
> 2-c. routing information can be flowed into the interface.
> 3. we can see parameters and the statistics of the SA.
> 4. SPD is implemented into the routing table.
>
> i can say about KAME implementation against above points.
> 1. doesn't support it.
> 2-a. we can see them.
> 2-b. we can define it.
> 2-c. cannot do it.
> 3. we can see them.
> 4. SPD is implemented by a filtering base.
>
> about 1, OpenBSD gives up to support the multiple mixed SA
> both ESP and AH in order to support hardware acceleration.
> it means the kernel cannot construct a packet like IP|ESP|AH|ESP|ULP.
> but KAME can do that because RFC2401, which is the specification of
> IPsec architecture, doesn't prohibit to generate the packet.
> itojun@kame.net says that why we haven't supported the feature,
>
openbsd supports mixed SA, but only with a single ESP and AH. itojun
explained privately, however that openbsd does not support multiple ESP/AH
headers as required by an iterated VPN cloud (VPN cloud within VPN cloud).
This issue is, however, separate from the hardware acceleration of the
crypto operations.
> with fine-grain kernel threads present, i hope to see no restructuring
> of ip_input/output path. (openbsd splitted the function into two)
>
I've exchanged several notes with itojun about this. The key requirement
that I see is that the input processing thread be able to block when a
crypto operation is dispatched to the hardware. itojun (and it sounds like
you too) suggest forking from the softnet context to wait for the crypto
operation to complete. This would require obtaining a new context in which
one can sleep and possibly also require changing the existing software
interrupt thread to a different context (e.g. a process) in which one can
block. This seems expensive--I don't see how to do this cheaply in FreeBSD.
openbsd dealt with this problem by not blocking, but instead using
continuations (crypto ops are queud to a crypto processing thread/process
and when they complete a callback is made to continue the packet/protocol
processing).
The other concern I have with your approach is that each crypto operation
must be dispatched and waited for separately. This means, for example, if a
packet requires both AH+ESP crypto operations then there would be two
"fork+wait" exchanges. openbsd batches these operations and continues
packet processing only after both have completed. Again, this could be done
for KAME whether one blocks directly or uses a continuation-style approach.
Perhaps I've misunderstood your intention. Can you explain in more detail
how you expected to do things as you suggest? Remember also that I need a
solution that works in both -stable and -current.
> about 2-a, KAME records how packets are transmitted, when the SA is used,
> when the SA is created and so on. we can see them of each SA by using
> setkey(8).
> about 2-b, i'm not sure how easy to configure the packet filter
> rule in OpenBSD. KAME can do that similarly by using setkey(8), ipf(8)
> or ipfw(8).
> about 2-c, is it possible on OpenBSD surely ?
> KAME cannot do it when we use IPsec tunnel mode. larse@isi.edu tell us
> how the feature can be implemented.
> about 3, KAME can show them by using setkey(8) because SA has them.
> about 4, we don't like to create a pseudo interface of each SA,
> in particular, when we use IPsec transport mode. each userland
> process can use individual SA in KAME. this function is specified by
> RFC2401. when we would choice to implement SA by a interface base,
> how many interface we would need. also we want to avoid infinity
> loop due to mistaken the configuration of IPsec tunnel mode.
> basically we have many tunnel protocols on several layer. there are
> many methods in the internet for implementing a single purpose.
>
> please, correct me if i'm misunderstanding.
>
> _IMHO_, if IETF would employ the draft-touch-ipsec-vpn approach,
> we could get rid of the redundant protocol.
>
Yes, I read the draft-touch document yesterday and agree. The above items,
while different, do not look so difficult to reconcile (e.g. add to
openbsd). I'd prefer to work with the KAME implementation for many reasons,
not the least of which is adding hardware support would benefit the most
people. I started this discussion because I was concerned that adding
hardware crypto support would lead me down the same path as openbsd and
result in more work than starting from the openbsd implementation.
Sam
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?354301c1dcbf$5a6d95c0$52557f42>