[Vpn-devel] Cisco UDP Encapsulation

[Matthew Grooms]

Robert Nelson wrote:
> I'm trying to add support for Cisco's proprietary UDP encapsulation.
>  
> It differs from NAT-T in the following ways:
>     Gateway port is negotiated using xconfig instead of using port 4500.
>     ISAKMP traffic stays on port 500.
>     Keepalives are single byte UDP packets with 0xFF
>     ESP header immediately follows UDP header.
>  
> I have all the configuration work done.  I'm having a bit of a problem 
> deciphering what to change in the code to get the ESP traffic to use UDP 
> protocol packets instead of ESP protocol packets.
>  
> I would appreciate any pointers.
>

Robert,

This is would be very tricky to accomplish unless the UDP encapsulation 
format is identical to one of the formats described in these documents ...

http://www.shrew.net/support/browser/ike/head/docs/draft-ietf-ipsec-udp-encaps-00.txt
http://www.shrew.net/support/browser/ike/head/docs/draft-ietf-ipsec-udp-encaps-02.txt
http://www.shrew.net/support/browser/ike/head/docs/rfc3948.txt

On platforms like BSD and Linux, the client only provides IKE services 
and client front end utilities. It uses the PF_KEY mechanism to manage 
the kernel security policies and security associations. The SPs/SAs are 
used by the OS kernel IPsec support to protect the traffic. In other 
words, Shrew Soft doesn't provide custom code to process ESP/AH traffic.

On Windows platforms, the client provides IKE services, custom IPsec 
packet processing ( the source code for this module is not available to 
the general public ), and client front end utilities. To make the code 
as portable as possible, a PF_KEY kernel side interface is implemented 
by the Shrew Soft IPsec service. This allows the IKE daemon to manage 
SPs/SAs in the same manner it would as if it were running on a *nix 
platform. The only difference is that it communicates over a named pipe 
instead of a PF_KEY socket.

To make matters more complicated, the PF_KEY extensions used to manage a 
NAT-T security association are not fully documented in any RFC or draft 
that I am aware of. The implementation details even differ currently on 
BSD vs Linux in this regard. Luckily, Yvan ( ipsec-tools ) is working to 
correct these differences and hopefully document the requirements so we 
can all be on the same page.

Now that you know some of the gory details, the code used to manage the 
SP/SA database is contained in the ike.io.pfkey.cpp file. It makes calls 
into libpfkey which is a very thin wrapper around the PF_KEY socket 
calls on *nix or named pipes on Windows. To actually add a new type of 
UDP encapsulation ( assuming the format isn't compatible with one of the 
formats described in the documents above ), you would need to define a 
socket option ( defined in the system udp.h and set on the IKE socket in 
ike.socket.cpp ) and provide kernel source patches that handle the new 
packet format.

If the UDP format does match one of existing packet formats, then the 
only changes required would be in the IKE sources. From your brief 
description above, I would venture to guess that the rfc3948 ESP packet 
format may possibly work ( UDP header immediately followed by an ESP 
header ). You may be able set the correct option on a dummy socket bound 
to the negotiated encapsulated port and modify the IKE daemon to not 
migrate away from port 500 for IKE traffic. This way the UDP/ESP packets 
will still be processed by the kernel. It would simply never forward any 
received packets to userland ( normally multiplexed on the same port as 
UDP/ESP ) because they would never contain a NON-ESP marker. Have a look 
at the RFC document for more details.

Hope this helps,

-Matthew