Date: Sun, 23 Jan 2005 17:00:56 +0100 From: J65nko BSD <j65nko@gmail.com> To: Erik Norgaard <norgaard@locolomo.org> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: IPSec without AH Message-ID: <19861fba05012308005d38fe04@mail.gmail.com> In-Reply-To: <41F3ACA6.6010002@locolomo.org> References: <41F39CE7.7040209@locolomo.org> <19861fba050123053644f383f7@mail.gmail.com> <41F3ACA6.6010002@locolomo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jan 2005 14:54:46 +0100, Erik Norgaard <norgaard@locolomo.org> wrote: > J65nko BSD wrote: > >>Due to the problems of IPSec with NAT I was thinking if it is posible to > >>setup IPSec without Authenticated Headers? Does anyone know of a howto? > > > The AH (Authenticated Header) protocol cannot be used with NAT, NAT > > modifies the header of packets, while AH is supposed to protect that > > header from being modified. Another IPSEC protocol ESP (Encrypted > > Security Payload), both authenticates and encrypts, and thus has no > > problem with NAT traversal. > > Thanks, AFAIK, ESP and AH are used in conjunction in IPSec, ESP for > encrypting the packet payload, and AH for authentication. ESP in it self > does not provide authentication, but only encrypts the payload - hence > the names :-) > > Since ESP only encrypts the payload, as you say, ESP has no problem with > NAT, whereas AH appends a signed checksum of the header. And since NAT > alters the header, verifying the AH fails. > > Ofcourse, it requires access to the (public?) keys to create valid > encrypted packets. Hence, if the public key is kept as a shared secret > among the authorized users, one could assume that ESP packets are > authenticated/trusted. > > This is my idea, discard AH, rely on ESP and assume that anyone capable > of producing decryptable packets must have access to the pre-shared > secret "public" key and hence authorized. Your are not the first to have this idea. The authors of "Secure Architectures with OpenBSD" already published this ;) > AH would work, if both ends were NATaware, such that the rigth src/dst > ip could be inserted in the header before checking. It just occured to > me that maybe this could be done by adding yet another IP/IP tunnel? > > Cheers, Erik OpenBSD 3.6 supports NAT traversal. From http://openbsd.org/36.html: "isakmpd(8) now supports NAT-traversal and Dead Peer Detection (RFC 3706)." Don't know how ling it would take to before this is supported by FreeBSD ;) =Adriaan=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19861fba05012308005d38fe04>