NAT-T support for IPSec stack
VANHULLEBUS Yvan
Hi all.
For some months now, ipsec-tools is now the "official" version of
racoon, the KAME's isakmp daemon.
Ipsec-tools support NAT-Traversal (RFCs 3947 / 3948), but needs some
kernel support for that.
This kernel support has been done for the Linux 2.6 Kernel for some
time, has been done for NetBSD some months ago, and I made a similar
patchset for FreeBSD.
The FreeBSD 4 patchset is used for some month by various people, and I
recently ported it to the FreeBSD 6 kernel source.
The first version of this patch can be found here:
http://ipsec-tools.sourceforge.net/freebsd6-natt.diff
There are still some things to do for this patch, starting by support
for FAST_IPSEC (it only works with IPSEC for now) and probably some
cleanup (ENABLE_NATT => something else ?, etc...).
As I don't want to keep porting such patch over versions, as some
people already asked me lots of things about this patch, and as it
would be interesting to have it widely used by people, I would be
happy to do "what is needed" to have it reported to the FreeBSD source
tree.
Are you interested in it ?
Do you have some comments on the actual version, some things that
should be done before reporting it ?
Of course, it would also be interesting to have an ipsec-tools port,
I'll contact the ports list for such an integration.
Yvan.
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
Matthew Grooms
and wondering when someone was going to bring this support to FreeBSD.
>For some months now, ipsec-tools is now the "official" version of
>racoon, the KAME's isakmp daemon.
I hope it shows up in ports soon. The racoon port maintainer mentioned
that the most recent import would be the last and the KAME racoon
developer has stated he won't be maintaining the code anymore. A lot of
fixes have shown up in ipsec-tools after the fork from the KAME project
as well as hybrid user authentication support via pam. OpenBSDs isakmpd
supports NAT-T as well. FreeBSD seems to be the straggler here.
If memory serves me right, KAME IPSEC is still not SMP safe at the
moment. It seems like FAST_IPSEC had a caveat as well like it doesn't
work with IPV6 or something like that. Could it be that there is no
developer that 'owns' these subsystems? Perhaps rrwatson has this on his
list of things to attack with his ninja net hacking skills.
>Are you interested in it?
Yes ( as a user ) but I am not a FreeBSD developer. I think there was
initially resistance from open source groups to integrate this support
due to patent issues ( maybe just WRT usage w/ IKEv1 ) but must have
been resolved as both OpenBSD and Linux support this functionality now.
It would be very cool to get NAT-T + ipsec tools support as it opens the
door for FreeBSD to compete with the big boys in the client based VPN
market at some point down the road and offers an IPSEC alternative to
OpenVPN.
>Of course, it would also be interesting to have an ipsec-tools port,
>I'll contact the ports list for such an integration.
Fantastic! The website states that it compiles cleanly and works well on
FreeBSD so it should be a piece of cake.
I am in the process of moving but once settled and upgrade to 6 I will
definitely test out your patches and would be willing to test out any
ipsec-tools port as well. Thanks again for your work on this.
-Matthew
VANHULLEBUS Yvan
> Woohoo!!! Thanks!!! I was just checking poking around for this last week
> and wondering when someone was going to bring this support to FreeBSD.
Well, I made at least one guy being happy today, cool :-)
> >For some months now, ipsec-tools is now the "official" version of
> >racoon, the KAME's isakmp daemon.
>
> I hope it shows up in ports soon. The racoon port maintainer mentioned
> that the most recent import would be the last and the KAME racoon
> developer has stated he won't be maintaining the code anymore. A lot of
> fixes have shown up in ipsec-tools after the fork from the KAME project
> as well as hybrid user authentication support via pam. OpenBSDs isakmpd
> supports NAT-T as well. FreeBSD seems to be the straggler here.
Yep, we (the Ipsec-tools team) and KAME team agreed a few month ago
about that, and about the fact that the new "official" racoon's
version was now ipsec-tool's one.
> If memory serves me right, KAME IPSEC is still not SMP safe at the
> moment. It seems like FAST_IPSEC had a caveat as well like it doesn't
> work with IPV6 or something like that. Could it be that there is no
> developer that 'owns' these subsystems? Perhaps rrwatson has this on his
> list of things to attack with his ninja net hacking skills.
I don't think so.
KAME stack still uses the splnet() "giant lock", and I have a
(probably not complete) list of missing locks, but I guess it should
be quite SMP safe (at least when I'll have some time to make a clean
patch for the missing locks, but this is not SMP specific).
> >Are you interested in it?
>
> Yes ( as a user ) but I am not a FreeBSD developer. I think there was
> initially resistance from open source groups to integrate this support
> due to patent issues ( maybe just WRT usage w/ IKEv1 ) but must have
> been resolved as both OpenBSD and Linux support this functionality now.
Yep.
KAME team did not integrate another NAT-T implementation a few years
ago for those reasons.
More infos about that may be get from Emmanuel Dreyfus, a NetBSD
developper and a member of the ipsec-tools team, which made the NetBSD
NAT-T support, and told me a few month ago that NetBSD lawyers were
looking at that potential IPR issue.
But I guess Manu's personnal answer will be something like "most of us
live in Europe, so we don't care about such patents" :-)
> It would be very cool to get NAT-T + ipsec tools support as it opens the
> door for FreeBSD to compete with the big boys in the client based VPN
> market at some point down the road and offers an IPSEC alternative to
> OpenVPN.
Well, I though that OpenVPN was the alternative, and IPSec the
standard :-)
> >Of course, it would also be interesting to have an ipsec-tools port,
> >I'll contact the ports list for such an integration.
>
> Fantastic! The website states that it compiles cleanly and works well on
> FreeBSD so it should be a piece of cake.
That has been my first "job" as an ipsec-tools developer, and working
Free/NetBSD is now again an official goal of ipsec-tools.
> I am in the process of moving but once settled and upgrade to 6 I will
> definitely test out your patches and would be willing to test out any
> ipsec-tools port as well. Thanks again for your work on this.
I already have "something which can be used as a base to make a port",
I'll send it to the ports mailing list as soon as I'll have some time
to clean it up a little bit.
Yvan.
Bjoern A. Zeeb
Hi,
> > Yes ( as a user ) but I am not a FreeBSD developer. I think there was
> > initially resistance from open source groups to integrate this support
> > due to patent issues ( maybe just WRT usage w/ IKEv1 ) but must have
> > been resolved as both OpenBSD and Linux support this functionality now.
>
> Yep.
>
> KAME team did not integrate another NAT-T implementation a few years
> ago for those reasons.
>
> More infos about that may be get from Emmanuel Dreyfus, a NetBSD
> developper and a member of the ipsec-tools team, which made the NetBSD
> NAT-T support, and told me a few month ago that NetBSD lawyers were
> looking at that potential IPR issue.
do you have more info about this?
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
VANHULLEBUS Yvan
[IPSec, NAT-T, IPR]
> do you have more info about this?
I asked for more informations from NetBSD team, waiting for answers.
For ipsec-tools project, our decision for such IPR potential problems
was to provide features as optionnal, and let users decide if they
want to enable it, and ensure that they can use it.
Yvan.
VANHULLEBUS Yvan
> > More infos about that may be get from Emmanuel Dreyfus, a NetBSD
> > developper and a member of the ipsec-tools team, which made the NetBSD
> > NAT-T support, and told me a few month ago that NetBSD lawyers were
> > looking at that potential IPR issue.
>
Ok, I have more informations about what have been done for NetBSD:
There are known patents which may covert some parts of NAT-T, but
those patents are very unclear, and it is very difficult to see if
they really cover some parts of the NAT-T process, and it is still
more unclear if they are valid.
So, the solution choosen for NetBSD is the same as for ipsec-tools: it
is enabled by an option, and it is specified in the documentation that
"some parts of this code may be patent encumbered in some countries".
I also asked a few months ago what have changed for OpenBSD (they told
some years ago that they woudn't implement NAT-T until no all
potential IPR problems were solved, then they implemented NAT-T), but
had no real answer.
Matthew Grooms
others comments concerning the NAT-T / IPR debate. These two documents
get mentioned repeatedly and would appear to have something to do with
other vendors decision to adopt NAT-T support.
http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt
http://www.ietf.org/ietf/IPR/SSH-NAT
There was also some mention of a third claim but it was hard to find
details on the subject. Lastly, some people voiced concerns regarding
the application of NAT-T to IKEv2 as the first of the two disclosures
mention the IKEv1 RFC specifically where the other is quite broad.
I can't imagine anyone is actively defending any patent claims here with
so many implementations of IKE / NAT-T out there. Would a group such as
the FreeBSD Foundation be able to help find answers to legal questions
such as this?
reference : www.google.com -> nat-t patent ipsec
-Matthew
Bjoern A. Zeeb
> Not sure if this helps at all, but I did some searching a bit to read
> others comments concerning the NAT-T / IPR debate. These two documents
> get mentioned repeatedly and would appear to have something to do with
> other vendors decision to adopt NAT-T support.
>
> http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt
> http://www.ietf.org/ietf/IPR/SSH-NAT
>
> There was also some mention of a third claim but it was hard to find
> details on the subject. Lastly, some people voiced concerns regarding
ietf.org -> IPR -> Search -> NAT-T
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=88
?
> the application of NAT-T to IKEv2 as the first of the two disclosures
> mention the IKEv1 RFC specifically where the other is quite broad.
>
> I can't imagine anyone is actively defending any patent claims here with
> so many implementations of IKE / NAT-T out there. Would a group such as
> the FreeBSD Foundation be able to help find answers to legal questions
> such as this?
I had hoped to get a clear answer after I heared that NetBSD had
started on this but why does nobody send mail to those people listed
as contacts and asks?
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Matthew Grooms
> On Thu, 4 Aug 2005, Matthew Grooms wrote:
>
>>There was also some mention of a third claim but it was hard to find
>>details on the subject. Lastly, some people voiced concerns regarding
>
> ietf.org -> IPR -> Search -> NAT-T
>
> https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=88
>
> ?
>
Software patents suck. The one I was referring to concerned a third
claim also by Microsoft regarding IKEv2. As I said before, I found
mention of ( by an ssh.com employee ) but no further details. Here is
the reference ...
http://www.vpnc.org/ietf-ipsec/03.ipsec/msg01797.html
>
> I had hoped to get a clear answer after I heared that NetBSD had
> started on this but why does nobody send mail to those people listed
> as contacts and asks?
>
Sorry man, I was just trying to be helpful. Do you mean the contacts
listed along with the IP disclosures?
-Matthew