Skip site navigation (1)Skip section navigation (2)
Date:      18 Dec 2001 16:09:28 -0800
From:      Joel Ray Holveck <joelh@gnu.org>
To:        freebsd-questions@freebsd.org
Subject:   IPSec: Is it possible to require tunnel AH?
Message-ID:  <87y9k0vznr.fsf@thor.piqnet.org>

next in thread | raw e-mail | index | archive | help
I've been having trouble with the use of AH in a tunnel context.  I
don't see any way to require AH on incoming packets with IPv4.

Consider the following fragment:
  spdadd 192.168.13.8/32 0.0.0.0/0 any -P in ipsec
         ah/tunnel/192.168.13.8-192.168.13.2/use ;

If I switch 'use' to 'require', then all packets are rejected.  I can
give you more context if you like, but I didn't want to make my
question overly long; in a nutshell, the 192.168.13.8 box is on an
802.11 network.

Note that the handbook uses this in an example:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html
in the section on IPv4 tunnel mode.

If there is no 'require' ability, then what is the use of tunnel mode
AH?  In this instance, I don't care if the rest of the Internet had
done icky stuff before the tunnel endpoint, because I can filter that
out at or before said endpoint.

I think this hinges around the following bit of code, from
/sys/netinet6/ah_input.c:

#if 1
		/*
		 * Should the inner packet be considered authentic?
		 * My current answer is: NO.
		 *
		 * host1 -- gw1 === gw2 -- host2
		 *	In this case, gw2 can trust the	authenticity of the
		 *	outer packet, but NOT inner.  Packet may be altered
		 *	between host1 and gw1.
		 *
		 * host1 -- gw1 === host2
		 *	This case falls into the same scenario as above.
		 *
		 * host1 === host2
		 *	This case is the only case when we may be able to leave
		 *	M_AUTHIPHDR and M_AUTHIPDGM set.
		 *	However, if host1 is wrongly configured, and allows
		 *	attacker to inject some packet with src=host1 and
		 *	dst=host2, you are in risk.
		 */
		m->m_flags &= ~M_AUTHIPHDR;
		m->m_flags &= ~M_AUTHIPDGM;
#endif

Thanks,
joelh

-- 
Joel Ray Holveck - joelh@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




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