Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jul 2008 13:27:05 -0500
From:      Matthew Grooms <mgrooms@shrew.net>
To:        vanhu@freebsd.org, Sam Leffler <sam@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: FreeBSD NAT-T patch integration [CFR/CFT]
Message-ID:  <4884D4F9.4050707@shrew.net>
In-Reply-To: <4884C28F.4020402@shrew.net>
References:  <4884C28F.4020402@shrew.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> And I also have doubts about a change in udp_ctloutput(), in the
> switch statement which process optval and searches for an
> UDP_ENCAP_ESPINUDP* flag.
> 
> The way you changed it forces a flags cleanup anytime.
> I don't see why someone would set both UDP_ENCAP_ESPINUDP and
> UDP_ENCAP_ESPINUDP_NON_IKE, but as I was tracking down a problem, I
> changed it again to be processed "the old way" to ensure it was not
> the source of the issue.
>

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.

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?

Thanks,

-Matthew



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