Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Jun 2008 17:32:41 -0500
From:      mgrooms <mgrooms@shrew.net>
To:        "George V. Neville-Neil" <gnn@neville-neil.com>
Cc:        freebsd-net@freebsd.org, brooks@freebsd.org, Julian Elischer <julian@elischer.org>
Subject:   Re: FreeBSD NAT-T patch integration
Message-ID:  <5cf41abb4dd14f4e24213575c348c114@localhost>
In-Reply-To: <m24p7edij8.wl%gnn@neville-neil.com>
References:  <m24p7edij8.wl%gnn@neville-neil.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, 27 Jun 2008 11:06:19 -0400, "George V. Neville-Neil"
<gnn@neville-neil.com> wrote:
> At Thu, 26 Jun 2008 12:56:41 -0700,
> julian wrote:
>>
>> I'm planning on committing it unless someone can provide a reason not
>> to, as I've seen it working, needed it, and have not seen any bad
>> byproducts.
>>
> 
> I'd be interested to know how you tested it.  NAT-T and IPsec are
> non-trivial protocols/subsystems that can have far reaching impacts on
> the network stack.  Also, are you planning to maintain it after
> committing it?  The biggest problem with NAT-T hasn't been the code,
> it's been that the author, who is doing a great job on the code, has
> been too busy to maintain it anywhere but at work.  That is not a slam
> on the person or the code, I have the highest respect for both, but it
> reflects and important reality of the situation.  Unless you're
> stepping up to maintain it as well as commit it I think it should not
> be committed.  I know the Bjoern has been working hard to pick up the
> IPsec stuff in his free time, and I value his input on this subject
> quite a bit.
> 

I have tested the patch with Cisco (PIX/ASA), Juniper (GT/SSG), Fortigate,
Zywall, Linux and NetBSD to ensure interoperability. Mostly, the RFC and
draft 2 versions of the protocol were exercised. What other kinds of tests
would you like to see?

Objections ...

1) NAT-T and IPsec are non-trivial protocols/subsystems

The patch hasn't been reviewed enough? The patch hasn't been tested enough?
An unresolved issue has been identified?

2) It can have far reaching impacts on the network stack

The changes are not been sufficiently protected by the supplied kernel
configuration option?

3) The author has been too busy to maintain it anywhere but at work

What does this mean? Since you find his level of commitment unacceptable,
what would be required for the patch to be accepted?

Thanks,

-Matthew




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5cf41abb4dd14f4e24213575c348c114>