[Vpn-devel] Cisco UDP Encapsulation

[Robert Nelson]

----- Original Message ----- 
From: "Matthew Grooms" <mgrooms at shrew.net>
To: "Robert Nelson" <robertn at the-nelsons.org>
Cc: <vpn-devel at lists.shrew.net>
Sent: Sunday, February 01, 2009 11:25 AM
Subject: Re: [Vpn-devel] Cisco UDP Encapsulation


> 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
>


Yep that helped a lot.  I have it working!  I was so close and heading in 
the right direction, your explanation pointed me to the one piece I was 
missing.