Date: Wed, 19 Feb 2014 11:23:01 +0000 From: Nicolas DEFFAYET <nicolas-ml@deffayet.com> To: David DeSimone <ddesimone@verio.net> Cc: freebsd-net@freebsd.org, Michael Glasgow <glasgow@beer.net> Subject: Re: ipsec foils traceroute on gre/gif Message-ID: <1392808981.10645.15.camel@srv31.corp.novso.com> In-Reply-To: <CAABACD8BCAE7B4B8A7906EEDC9DEBC501FD4D1B@IAD-WPRD-XCHB01.corp.verio.net> References: <201402180613.s1I6DdhS020353@dark.beer.net> <CAABACD8BCAE7B4B8A7906EEDC9DEBC501FD4D1B@IAD-WPRD-XCHB01.corp.verio.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2014-02-18 at 13:26 -0500, David DeSimone wrote: > My understanding of this issue is that replying with an ICMP message for traceroute carries the risk of violating security policy. > > When an ICMP Unreachable packet is generated, the first 64 octets in the packet are copied into the reply. If the packet was originally encrypted with IPSEC, those octets were never seen unencrypted on the wire. If the ICMP Unreachable were permitted to be generated and sent, it could very well reveal the unencrypted IPSEC packet contents on the wire, because the source/destination IP's of the ICMP message no longer matches SPD's. > > Thus the conservative decision in the kernel is to drop the TTL-exceeded packet coming from IPSEC, with no reply. > > In other words, "working as intended." Is it possible to add a sysctl for turn on/off this per interface or it's too complex ? -- Nicolas DEFFAYET
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1392808981.10645.15.camel>