ESP spi/sequence tracking and nat

ESP spi/sequence tracking and nat

[Kashyap Ashwin]

[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]

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

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            \|/ ____ \|/ 
Ashwin Kashyap                                   @~/ ,. \~@ 
Member Technical Staff                          /_( \__/ )_\ 
Thomson - Corporate Research                       \__U_/ 
                                                Don't Panic!

 


[-- Attachment #2: Type: text/html, Size: 7393 bytes --]

Re: ESP spi/sequence tracking and nat

[Pablo Neira]

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

Re: ESP spi/sequence tracking and nat

[Henrik Nordstrom]

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

Re: ESP spi/sequence tracking and nat

[Michael Richardson]

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"); [