Re: IPSec: 2.5.68 test results

Re: IPSec: 2.5.68 test results

[David S. Miller]

   From: Tom Lendacky <toml@us.ibm.com>
   Date: 24 Apr 2003 16:29:51 -0500
   
   We've been running the TAHI IPSec test suites against the 2.5 kernel and
   a TAHI based IKE test suite that I created.  I just wanted to post the
   results so far (up through 2.5.68) for anyone who may be interested.

Thanks for the report Tom.

IPSec: 2.5.68 test results

[Tom Lendacky]

We've been running the TAHI IPSec test suites against the 2.5 kernel and
a TAHI based IKE test suite that I created.  I just wanted to post the
results so far (up through 2.5.68) for anyone who may be interested.

  Test			Successful	Attempted
  ipsec4-udp (IPv4)	48 (*)		48
  ipsec4 (IPv4)		95 (*)		95
  ipsec (IPv6)		114 (*)		118
  ike4 (IPv4)		111 (**)	111
  ike (IPv6)		111 (**)	111

  (*) Two warnings were issued during these tests.  The warnings related
      receiving and processing ESP data with padding that was not
      sequentially numbered (ie. three pad bytes of 000000 vs. 010203).
      However, RFC 2406 states only that the receiver SHOULD, not MUST,
      inspect the padding so there isn't anything to worry about here.

  (**) These results are based on a racoon patch that I have submitted
       to KAME to resolve three minor RFC related issues:
          - Do not accept or generate transforms that specify ESP NULL
            encryption without ESP authentication
          - Do not accept or generate multiple proposal payloads during
            phase 1 processing
          - Do not accept multiple transform payloads in response to
            the SA negotiation during phase 1 processing.

The four test cases that fail for the ipsec test are related to
fragment header processing and will need to be debugged and fixed.

Overall, these are very excellent results.

Thanks,
Tom

Re: IPSec: 2.5.68 test results

[Kazunori Miyazawa]

On 24 Apr 2003 16:29:51 -0500
Tom Lendacky <toml@us.ibm.com> wrote:

> The four test cases that fail for the ipsec test are related to
> fragment header processing and will need to be debugged and fixed.

I have already posted the patch to netdev on 15, April,
whose subject is [PACTH][IPV6] Introduce ip6_append_data.
It change the style of the process like ip_append_data and
fixes outbound fragment header processing.

However this patch will not be applied soon because there is locking problem.
The bugs is in both ipv4 and ipv6 corking architecture of datagram output.
It may be applied when the bugs is removed.

About inbound processing, we can fix it with removing fragment header from the packet.
Please see function ip6_frag_reasm in  linux25/net/ipv6/reassembly.c.

Thank you,

--Kazunori Miyazawa (Yokogawa Electric Corporation)