From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kashyap Ashwin" Subject: ESP spi/sequence tracking and nat Date: Mon, 9 Aug 2004 17:28:07 -0400 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <8FC831532CEE564AB88AC1D999C29DEBD9F148@prinsmail01.am.thmulti.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C47E57.C3302200" Return-path: content-class: urn:content-classes:message To: Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C47E57.C3302200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I want to implement a connection tracking / nat module that will track the SPI and SEQ parts in the ESP header. I need this functionality because, nat will fail for ESP if the destination IP address (the VPN server address) is the same for two clients. I did a packet dump for a popular VPN client and also noticed that the SPI can be same for two clients (say client -> server direction). The idea is to remember the last SEQ the server responded for a particular tuple and when we get the next tuple, we try to do a closest match, as opposed to doing an exact match: =20 1. If pkt is traversing in original direction, just do IP nat and no more. Do it even if there we cannot generate a unique tuple. 2, If pkt is traversing in reply direction: try to do regular nat, if it fails, match the seq and spi with dst_seq and dst_spi for all connections we know of. Then demultiplex it. =20 I know, this will have problems, but I feel that the probability of these (for example SEQ collision between two clients) is pretty low and may be I can think of some way to solve these some time in the future. =20 I have read the netfilter-hacking-HOWTO. I have looked at the nat pptp patches, and I sort of understand what is happening. I still cannot figure out a few things: =20 1. How can I figure out the direction of the packet in pkt_tuple(). The idea is to store the SEQ/SPI values from the packet either into tuple->src or tuple->dst. I noticed that packet() has a ip_conntrack_info, but pkt_tuple() does not. I am not sure if I can mess ip_conntrack in packet() instead... 2. I got totally confused by the pptp patches, do I need to implement a exp_matches_pkt() for this? As far as I understand, this is needed for things like ftp, where a connection happens in reverse direction. =20 I currently have ip_conntrack_proto_esp.c and ip_nat_proto_esp.c, the corresponding changes to the header files and the build system.=20 =20 I would really appreciate any input from you!=20 =20 Thanks, Ashwin =20 =20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \|/ ____ \|/=20 Ashwin Kashyap @~/ ,. \~@=20 Member Technical Staff /_( \__/ )_\=20 Thomson - Corporate Research \__U_/=20 Don't Panic! =20 ------_=_NextPart_001_01C47E57.C3302200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

I want to implement a connection tracking / nat = module that will track the SPI and SEQ parts in the ESP header. I need this = functionality because, nat will fail for ESP if the destination IP address (the VPN server = address) is the same for two clients. I did a packet dump for a popular VPN client = and also noticed that the SPI can be same for two clients (say client -> = server direction). The idea is to remember the last SEQ the server responded = for a particular tuple and when we get the next tuple, we try to do a closest = match, as opposed to doing an exact match:

 

1. If pkt is traversing in original direction, just = do IP nat and no more. Do it even if there we cannot generate a unique = tuple.

2, If pkt is traversing in reply direction: try to do = regular nat, if it fails, match the seq and spi with dst_seq and dst_spi for all connections we know of. Then demultiplex = it.

 

I know, this will have problems, but I feel that the probability of these (for example SEQ collision between two clients) is = pretty low and may be I can think of some way to solve these some time in the = future.

 

I have read the netfilter-hacking-HOWTO. I have = looked at the nat pptp patches, and I sort of understand what is happening. I = still cannot figure out a few things:

 

1. How can I figure out the direction of the packet = in pkt_tuple(). The idea is to store the SEQ/SPI values from the packet either into tuple->src or tuple->dst. I noticed that packet() has a = ip_conntrack_info, but pkt_tuple() does not. I am not sure if I can mess ip_conntrack in = packet() instead…

2. I got totally confused by the pptp patches, do I = need to implement a exp_matches_pkt() for this? As far as I understand, this is = needed for things like ftp, where a connection happens in reverse = direction.

 

I currently have ip_conntrack_proto_esp.c and ip_nat_proto_esp.c, the corresponding changes to the header files and = the build system.

 

I would really appreciate any input from you! =

 

Thanks,

Ashwin

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ &nbs=
p;          \|/ ____ \|/ =
Ashwin =
Kashyap           =
            &=
nbsp;           @~/ ,. =
\~@ 
Member =
Technical =
Staff           &n=
bsp;           &nb=
sp;  /_( \__/ )_\ 
Thomson - =
Corporate =
Research           =
;            =
\__U_/ 
       &nbs=
p;            =
;            =
            &=
nbsp;   Don't Panic!

 

------_=_NextPart_001_01C47E57.C3302200-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Subject: Re: ESP spi/sequence tracking and nat Date: Tue, 10 Aug 2004 12:24:28 +0200 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <4118A25C.5010103@eurodev.net> References: <8FC831532CEE564AB88AC1D999C29DEBD9F148@prinsmail01.am.thmulti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netfilter-devel@lists.netfilter.org Return-path: To: Kashyap Ashwin In-Reply-To: <8FC831532CEE564AB88AC1D999C29DEBD9F148@prinsmail01.am.thmulti.com> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org Hi, Kashyap Ashwin wrote: > 1. How can I figure out the direction of the packet in pkt_tuple(). > The idea is to store the SEQ/SPI values from the packet either into > tuple->src or tuple->dst. I noticed that packet() has a > ip_conntrack_info, but pkt_tuple() does not. I am not sure if I can > mess ip_conntrack in packet() instead… > AFAIK you can't, you know if a packet comes from the original/reply direction once you get the tuple from the conntrack table. Trace resolve_normal_ct: 1) we create a temporary tuple which will be used to match: get_tuple -> pkt_to_tuple 2) now, it's time to look up that tuple in the conntrack table: ip_conntrack_find_get at 1) we don't know which direction the packet came from, we know it at 2). Please correct me if I'm missing anything. regards, Pablo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Henrik Nordstrom Subject: Re: ESP spi/sequence tracking and nat Date: Tue, 10 Aug 2004 13:01:45 +0200 (CEST) Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: References: <8FC831532CEE564AB88AC1D999C29DEBD9F148@prinsmail01.am.thmulti.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: netfilter-devel@lists.netfilter.org Return-path: To: Kashyap Ashwin In-Reply-To: <8FC831532CEE564AB88AC1D999C29DEBD9F148@prinsmail01.am.thmulti.com> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org On Mon, 9 Aug 2004, Kashyap Ashwin wrote: > I want to implement a connection tracking / nat module that will track > the SPI and SEQ parts in the ESP header. I need this functionality > because, nat will fail for ESP if the destination IP address (the VPN > server address) is the same for two clients. I did a packet dump for a > popular VPN client and also noticed that the SPI can be same for two > clients (say client -> server direction). The idea is to remember the > last SEQ the server responded for a particular tuple and when we get the > next tuple, we try to do a closest match, as opposed to doing an exact > match: To fit the Netfilter Conntrack scheme of things you then need to implement and ESP protocol helper which tracks the ESP connections as individual connections. Once this is done NAT should work at least to a limited degree. To really work with NAT you should use a IPSEC implementation with NAT-T support. This makes IKE detect the NAT and then switch to UDP encapsulation which works very well with all forms of NAT, and also makes IKE fully aware of the NAT ip address changes. Regards Henrik From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Richardson Subject: Re: ESP spi/sequence tracking and nat Date: Mon, 16 Aug 2004 11:45:41 -0400 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <14888.1092671141@marajade.sandelman.ottawa.on.ca> References: <8FC831532CEE564AB88AC1D999C29DEBD9F148@prinsmail01.am.thmulti.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Cc: netfilter-devel@lists.netfilter.org Return-path: To: "Kashyap Ashwin" In-Reply-To: Message from "Kashyap Ashwin" of "Mon, 09 Aug 2004 17:28:07 EDT." <8FC831532CEE564AB88AC1D999C29DEBD9F148@prinsmail01.am.thmulti.com> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org I strongly recommend against doing anything more with ESP. Everytime some bright person does something to make ESP and IKE "better" in a NAT, it screws things up later. People behind NATs should use UDP encapsulation of ESP packets. -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [