Date: Fri, 05 Apr 2002 17:26:20 +0900 From: Shoichi Sakane <sakane@kame.net> To: sam@errno.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: kame ipsec vs. openbsd ipsec Message-ID: <20020405172620N.sakane@kame.net> In-Reply-To: Your message of "Wed, 3 Apr 2002 10:13:35 -0800" <2c1d01c1db3b$460c7720$52557f42@errno.com> References: <2c1d01c1db3b$460c7720$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
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,
with fine-grain kernel threads present, i hope to see no restructuring
of ip_input/output path. (openbsd splitted the function into two)
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.
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?20020405172620N.sakane>