OpenBSD Journal

IPsec NAT-T

Contributed by jose on from the interop-in-IPSec dept.

Markus Räipiö writes: "Hi all, is it possible that IPsec NAT-T is coming to 3.5 ?

best regards,
Markus

http://archives.neohapsis.com/archives/openbsd/cvs/2003-12/0022.html 



CVS: cvs.openbsd.org: src

From: Markus Friedl (markuscvs.openbsd.org)
Date: Tue Dec 02 2003 - 17:16:29 CST

CVSROOT: /cvs
Module name: src
Changes by: markuscvs.openbsd.org 2003/12/02 16:16:29

Modified files:
sys/netinet : ip_esp.h ip_ipsp.c ip_ipsp.h ipsec_input.c, ipsec_output.c, udp_usrreq.c
sys/net : pfkeyv2.h pfkeyv2.c, pfkeyv2_parsemessage.c, pfkeyv2_convert.c
sbin/ipsecadm : ipsecadm.8 ipsecadm.c pfkdump.c
sbin/sysctl : sysctl.8
usr.bin/netstat: inet.c

Log message:
UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)

(Comments are closed)

Comments

  1. By Openvpn () on

    and openvpn in the port tree ?

    Comments

    1. By n00b () on

      hm what is nat-t ? =)

      Comments

      1. By Anonymous Coward () on

        NAT traversal for ipsec. Guess Marcus must have sorted out the licensing :)

  2. By gwyllion () on

    The CVS commit to sysctl.3 to document the new udpencap explicitely mentioned it will be used by NAT/T: http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107055226704519&w=2

    Comments

    1. By Foxy () foxy@free.fr on http://foxy.free.fr

      No, ESP in UDP encapsulation is necessary for NAT/T but to have a full NAT/T implementation on OpenBSD, isakmpd (IKE daemon) must also be extended.

      In recent messages, Markus said that he does want to develop full NAT-T support (isakmp part) beacause of patent issues :-(

      But how to use ESP in UDP encapsulation with manual keying ?

      Comments

      1. By MotleyFool () motley@dawg.org on mailto:motley@dawg.org

        Like this entry?

        http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107040722926454&w=2

      2. By gwyllion () on

        Yes, of course isakmpd needs to extented as well. But this is the part where all stupid patent issues are.

        I just wanted to point out that the CVS entry explicitely mentioned NAT/T as one of the applications of ESP in UDP encapsulation.

        Comments

        1. By MotleyFool () motley@dawg.org on mailto:motley@dawg.org

          per the URL I posted above, I guess noone can follow non-hyperlinked URL's.

          CVSROOT: /cvs
          Module name: src
          Changes by: markus@cvs.openbsd.org 2003/12/02 16:16:29

          Modified files:
          sys/netinet : ip_esp.h ip_ipsp.c ip_ipsp.h ipsec_input.c
          ipsec_output.c udp_usrreq.c
          sys/net : pfkeyv2.h pfkeyv2.c pfkeyv2_parsemessage.c
          pfkeyv2_convert.c
          sbin/ipsecadm : ipsecadm.8 ipsecadm.c pfkdump.c
          sbin/sysctl : sysctl.8
          usr.bin/netstat: inet.c

          Log message:
          UDP encapsulation for ESP in transport mode (draft-ietf-ipsec-udp-encaps-XX.txt)
          ok deraadt@

        2. By Foxy () foxy@free.fr on http://foxy.free.fr

          Yes but the CVS entry mentioned only ESP in transport mode and no in tunnel mode :-(

          And for full NAT-T support we need implementation for "Negotiation of NAT-Traversal in the IKE", see http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-07.txt

          Comments

          1. By MotleyFool () mott@dawgg.org on mailto:mott@dawgg.org

            I believe that NAT-T support is available in -current per a post made in misc@. It is the autoneg part of NAT-T that is not in -current, however if you have control over the endpoints you can establish an Ipsec tunnel via NAT.

            see http://www.openbsd.org/cgi-bin/man.cgi?query=ipsecadm&sektion=8&arch=i386&apropos=0&manpath=OpenBSD+Current

            -udpencap
            Enable ESP-inside-UDP encapsulation. The UDP destination port must be specified on the command line. This port will be used for sending encapsulated UDP packets.

            YMMV

            it's a start

            Comments

            1. By Anonymous Coward () on

              UDP encapsulation for transport mode doesn't help anyone though, people want VPNs to work through NAT. That means tunnel mode, and using isakmpd, not dicking with ipsecadm.

              Its pretty sad where things are at considering OpenBSD used to be thought of as the best VPN platform.

              Comments

              1. By gwyllion () on

                NAT/T is ready for quite sometime. They just haven't released it yet, because of the patent issues (same problem exist with VRRP implementation). You shouldn't be complaining to OpenBSD about this.

                Comments

                1. By Anonymous Coward () on

                  Again, not helpful. We have NAT-T, but we aren't going to release it for no reason doesn't help anyone. Everything is patented, go look. If they were seriously avoiding anything subject to patents there would be no openbsd. For the guys who were all about ignoring stupid US laws about crypto, they sure lost their balls fast.

                  Comments

                  1. By gwyllion () on

                    Patents and the US crypto law are two different things. They were able to work around the US crypto law because development was done in Canada. This trick will not work for patents.

                    Patent law is not going to change this millenium. IETF just sucks: writing standard which you can't use because of patents is just plain stupid.

                    OpenBSD was able to work around the VRRP problems by inventing their own stuff (CARP). This will not work for NAT/T because you need interoperable implementations. Instead you should send emails to SSH Communications and Microsoft asking they drop their patent claims and allow for free usage.

                    Comments

                    1. By Anonymous Coward () on

                      Microsoft has no patent, and ssh.com has a pending application last I heard, and has clearly said anyone can use it to implement nat-t as required by standards. Pending patent applications are not a reason to not do something, they are meaningless. Even if awarded, and ssh.com is lying and sues you, defense is easy, the patent is clearly not valid. Its patenting an idea, not an implimentation, its obvious, and the idea was "discovered" independantly by different people. "Try it and see if its screwed, if it is use UDP encapsulation" isn't a valid patent.

                      OpenBSD is already infringing on a bunch of other stupid invalid patents, why is this somehow different?

                      Comments

                      1. By gwyllion () on

                        Microsoft has no patent,

                        Please read Microsoft's Patent Claim pertaining to draft-ietf-ipsec-nat-t-ike and draft-ietf-ipsec-udp-encaps

                        and ssh.com has a pending application last I heard, and has clearly said anyone can use it to implement nat-t as required by standards.

                        Please read SSH's Patent Statement pertaining to NAT . It says the following:
                        "This statement is limited in that SSH Communications Security Corp retains the right to assert said patents against any party and any subsidiary of a party that asserts a patent it owns or controls, either directly or indirectly, against SSH Communications Security Corp or any of its subsidiaries or successors in title for any implementation of or operation of any software or system implementing technology specified by the IETF."
                        This statement clearly contradicts OpenBSD's goal of making available source code that anyone can use for any purpose, with no restrictions . Including NAT/T would imply restrictions: if you use NAT/T, you can not sue SSH Communications Security based on patents you have.

                        Comments

                        1. By Bacon (216.237.6.254) on

                          Which is meaningless if the patent is invalid.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]