IPSec item - RE: [cgl_discussion] POC 9/24 Cancelled
Zhao, Forrest
forrest.zhao at intel.com
Tue Oct 7 23:33:37 PDT 2003
Hi, Venkat
You mentioned that you found some issues in IP-sec tools and fixed them. I'd like to know which IP-sec tool utility are you concerned about. Is it KAME/racoon, setkey? Did you fix the bugs locally or post patches to some mailing list?
The maintainer of IP-sec tools on source-forge has disappeared for long time, so there is no progress for this project in open source community until now. If we can find the maintainer for this project, maybe we can make this project evolve into stable state as soon as we expect.
Thanks,
Forrest
-----Original Message-----
From: cgl_discussion-bounces at lists.osdl.org [mailto:cgl_discussion-bounces at lists.osdl.org] On Behalf Of Venkata Jagana
Sent: 2003年10月3日 3:22
To: Fleischer, Julie N
Cc: Shureih, Tariq; cgl_discussion at osdl.org; sdake at mvista.com
Subject: IPSec item - RE: [cgl_discussion] POC 9/24 Cancelled
Note: Modified the subject
>- IPSec -> This one we just recently added. See note with Forrest and
Mika's comments on what needs to be >done to the user space portion of
this.
>IPSec
>- Per input at the F2F: Of the two implementations, FreeSWAN is known
to
>be stable, but will not become part of the kernel for the foreseeable
>future. The implementation that is part of the kernel needs someone to
>test to see how useful it is. The tools aren't user-friendly or usable
yet.
We have validated the IPSec v4 implementation currently in 2.6.x
kernel around 2.5.70 or 2.5.71 time frame and found that the
implementation is highly stable from both functional and
stree testing standpoint.
We have used TAHI IPv4 tests for functional validation and found that
the results are really good. This validation is done for both transport
and tunnel mode operations.
Bottomline: IPsec v4 in 2.6.x kernels is as stable the other
implementations.
As far as the tools are concerned, they are in usable condition. We have
found
some issues and fixed them. Ofcourse, they have been evolving since
then.
Not sure about user-friendliness, every one's views are different.
Thanks,
Venkat
"Fleischer, Julie N"
<julie.n.fleischer at intel.c To: "Shureih, Tariq" <tariq.shureih at intel.com>, <sdake at mvista.com>,
om> <cgl_discussion at osdl.org>
Sent by: cc:
cgl_discussion-bounces at lis Subject: RE: [cgl_discussion] POC 9/24 Cancelled
ts.osdl.org
09/30/2003 02:37 PM
> -----Original Message-----
> From: Shureih, Tariq
>
> Steven:
>
> I'd like to add the following to the next meeting's agenda:
> The definition of CGL 2.0 requirement fulfillment for openhpi.
Steve -
I can't make it to tomorrow's POC (or I may be able to make it, but late).
I had some questions/tracking items from the top-10 that I wanted to bring
to the POC, though:
(from http://www.osdl.org/docs/cgl_poc_top_10_projects.txt)
- Asynchronous Events -> We haven't discussed in a meeting since finding
that epoll+libevent may implement this requirement. Do we think
epoll+libevent meets the full requirement (and this no longer needs to be
top-10)? If not, which one(s) do we want to ask steering for resources
for: AEM or epoll+libevent?
- PKI CA -> Is there additional analysis CGL needs to do to be able to get
distro input on this one?
- IPSec -> This one we just recently added. See note with Forrest and
Mika's comments on what needs to be done to the user space portion of this.
For the others, there are just status questions:
- Persistent Device Naming: status on uSDE
- TIPC status
- message passing status
- Julie
**These views are not necessarily those of my employer.**
_______________________________________________
cgl_discussion mailing list
cgl_discussion at lists.osdl.org
http://lists.osdl.org/mailman/listinfo/cgl_discussion
_______________________________________________
cgl_discussion mailing list
cgl_discussion at lists.osdl.org
http://lists.osdl.org/mailman/listinfo/cgl_discussion
More information about the cgl_discussion
mailing list