Date: Mon, 21 Jul 2008 21:16:35 +0200 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] Message-ID: <20080721191635.GA2846@zen.inc> In-Reply-To: <4884D4F9.4050707@shrew.net> References: <4884C28F.4020402@shrew.net> <4884D4F9.4050707@shrew.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 21, 2008 at 01:27:05PM -0500, Matthew Grooms wrote: > On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote: >> >> After some more testing, I found another issue: in udp4_espdecap(), >> when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should >> not be discarded, but just returned for normal processing. >> > > I noticed this too. But the only situation that I could think of where a > valid ISAKMP packet will be smaller than this is a NAT-T keep-alive. > These are handled previously in the code path so I don't think there is > an issue from a functional standpoint. That's what I also supposed when I noticed that, but I was tracking down a negociation problem (as an initiator, responder's first exchange in Main mode was seen on tcpdump but not on racoon's log), and it has been solved by fixing that part of the code.... [...] > It should be disallowed as in Sams patch. Allowing them to be mixed > would cause problems using any of the patches I have seen. There is no > way to distinguish between a Draft 00/01 ISAKMP packet and an RFC ESP > packet without matching the port value to a SAD NAT-T mapping. And as > you mentioned, I also don't see why anyone would try to set them both. > There should never be a situation where you need to evaluate a NON-ESP > NAT-T marker on an ISAKMP socket, only NON-ISAKMP markers. Yes. As I said, I was tracking down a problem on a gate which used to run for a long time with previous patches, so every difference was suspect for me :-) > On a related note, I noticed the patch unconditionally uses a source > port of 500 when processing outbound Draft 00/01 packets. Should this > value be obtained from the SAD NAT-T mapping to support an IKE daemon > bound to a non standard port? It should really really not happen..... but yes, it would be cleaner to get it from SAD than setting 500 anytime. Yvan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080721191635.GA2846>