From owner-freebsd-net@FreeBSD.ORG Mon Jul 21 19:16:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37E771065678 for ; Mon, 21 Jul 2008 19:16:39 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6F76C8FC0A for ; Mon, 21 Jul 2008 19:16:37 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from albator.zen.inc (unknown [192.168.1.5]) by smtp.zeninc.net (smtpd) with ESMTP id A8DA33F7B for ; Mon, 21 Jul 2008 21:16:35 +0200 (CEST) Received: by albator.zen.inc (Postfix, from userid 1000) id B9E5E73265; Mon, 21 Jul 2008 21:16:35 +0200 (CEST) Date: Mon, 21 Jul 2008 21:16:35 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20080721191635.GA2846@zen.inc> References: <4884C28F.4020402@shrew.net> <4884D4F9.4050707@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4884D4F9.4050707@shrew.net> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: FreeBSD NAT-T patch integration [CFR/CFT] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2008 19:16:39 -0000 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.