Date: Tue, 13 May 2003 10:51:15 -0500 From: Randall Stewart <randall@stewart.chicago.il.us> To: "Andrew P. Lentvorski" <bsder@mail.allcaps.org> Cc: "Crist J. Clark" <cjc@FreeBSD.ORG> Subject: Re: IPSEC/NAT issues Message-ID: <3EC11473.8030605@stewart.chicago.il.us> In-Reply-To: <20021018222132.P68535-100000@mail.allcaps.org> References: <20021018222132.P68535-100000@mail.allcaps.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew: One little correction for your consideration :-D Andrew P. Lentvorski wrote: > On Fri, 18 Oct 2002, Me, Myself, and I blathered: > >>You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the >>packet will get rejected when it reaches the other IPSEC node. > > > I still stand by my original statement. However, it won't be true for > much longer. There is now a draft document (as of August 18, 2002) for > dealing with NAT traversal. > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-02.txt > > <quote> > a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header > incorporates the IP source and destination addresses in the > keyed message integrity check, NAT or reverse NAT devices making changes > to address fields will invalidate the message integrity check. > Since IPsec ESP [4] does not incorporate the IP source and > destination addresses in its keyed message integrity check, > this issue does not arise for ESP. > > b) Incompatibility between checksums and NAT. TCP/UDP/SCTP > checksums have a dependency on the IP source and destination > addresses through inclusion of the "pseudo-header" in the > calculation. As a result, where checksums are calculated and > checked on receipt, they will be invalidated by passage through > a NAT or reverse NAT device. SCTP does NOT use a "pseudo-header". Psuedo-headers were introduced to protect against mis-routing.. i.e. if a router mis-sent a message TCP/UDP to you to whom which you had a connection as well you could easily mistaken it.. but by putting it in the c-sum the packet would be invalid.. For SCTP there is a V-Tag in every packet. This is a random number that is selected by each side at association/connection startup. This V-Tag protects you from mis-routed packets since a wrong V-tag will result in discarding the packet silently (assuming its from an old connection). The V-Tag also obviates the need for timed-wait state for ports... You do need to do a timed-wait on V-tags themselves.. but it won't prevent you from setting up an association ever :> And you can get a very nice implementation of SCTP with one of the KAME snaps.. (I and Peter Lei wrote it so forgive me for being a bit in-modest). Hey speaking of which, is anyone in the FreeBSD world interested in getting SCTP into the base release yet? I do think we are stable enough now..... Regards R > > As a result, IPsec ESP will only pass unimpeded through a NAT if > TCP/UDP/SCTP protocols are not involved (as in IPsec tunnel > mode or IPsec/GRE), or checksums are not calculated (as is > possible with IPv4 UDP) > </quote> > > -a > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EC11473.8030605>