[Openswan dev] RFC 3947 on Negotiation of NAT-Traversal in the IKE

From: rfc-editor <at> rfc-editor.org
Date: Wed, 05 Jan 2005 17:04:58 -0800

[1. text/plain]   

A new Request for Comments is now available in online RFC libraries.

        RFC 3947

        Title:      Negotiation of NAT-Traversal in the IKE
        Author(s):  T. Kivinen, B. Swander, A. Huttunen, V. Volpe
        Status:     Standards Track
        Date:       January 2005
        Mailbox:    kivinen <at> safenet-inc.com,
                    Ari.Huttunen <at> F-Secure.com, briansw <at> microsoft.com,
                    vvolpe <at> cisco.com
        Pages:      16
        Characters: 34759
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ipsec-nat-t-ike-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3947.txt

This document describes how to detect one or more network address
translation devices (NATs) between IPsec hosts, and how to negotiate
the use of UDP encapsulation of IPsec packets through NAT boxes in
Internet Key Exchange (IKE).

[Openswan dev] RFC 3947/3948 support for Openswan 1.0.8

Here is a small patch to enable the newly released RFC 3947 and 3948
(NAT-Traversal) in Openswan 1.0.8. All the code was already here for
months, the only missing values were the RFC number and the official
IKE payload numbers (for NAT-D and NAT-OA).

This is for openswan-1 but should be easy to adapt for openswan-2.

Let Openswan (and Arkoon...) be the first IPSec implementation to
support RFC 3947 and RFC 3948. 

And happy new year for all the Openswan team. Keep doing such a good
work.

--

-- 
Mathieu Lafon - Arkoon Network Security

_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev

Re: [Openswan dev] RFC 3947/3948 support for Openswan 1.0.8

> Here is a small patch to enable the newly released RFC 3947 and 3948
> (NAT-Traversal) in Openswan 1.0.8. All the code was already here for
> months, the only missing values were the RFC number and the official
> IKE payload numbers (for NAT-D and NAT-OA).

> This is for openswan-1 but should be easy to adapt for openswan-2.

Do not apply the '#define FORCE_NAT_TRAVERSAL' line included in the
patch (nat_traversal.c). This is for debug only...

--

-- 
Mathieu Lafon - Arkoon Network Security

Re: [Openswan dev] RFC 3947/3948 support for Openswan 1.0.8

>>>>> "Mathieu" == Mathieu Lafon <mlafon <at> arkoon.net> writes:
    Mathieu> And happy new year for all the Openswan team. Keep doing
    Mathieu> such a good work.

  Hey, if we are doing such good work... why are you still running OSW 1.x?

  This is a serious question. What's missing in 2.x?

--

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

Re: [Openswan dev] RFC 3947/3948 support for Openswan 1.0.8

Michael Richardson <mcr <at> sandelman.ottawa.on.ca> writes :

>     Mathieu> And happy new year for all the Openswan team. Keep doing
>     Mathieu> such a good work.

>   Hey, if we are doing such good work... why are you still running OSW 
1.x?
>   This is a serious question. What's missing in 2.x?

I need to maintain a stable version (only bugixes) now based on Openswan-1
(initially on FreeS/WAN). Openswan-1 is rock solid and is perfect for 
that.

However I keep an eye on Openswan-2 and use it for my personal needs.

--

-- 
Mathieu Lafon - Arkoon Network Security

Re: [Openswan dev] RFC 3947/3948 support for Openswan 1.0.8

>>>>> "Mathieu" == Mathieu Lafon <mlafon <at> arkoon.net> writes:
    Mathieu> And happy new year for all the Openswan team. Keep doing
    Mathieu> such a good work.

    >> Hey, if we are doing such good work... why are you still running
    >> OSW
    Mathieu> 1.x?
    >> This is a serious question. What's missing in 2.x?

    Mathieu> I need to maintain a stable version (only bugixes) now
    Mathieu> based on Openswan-1 (initially on FreeS/WAN). Openswan-1 is

  I guess I don't understand how adding DPD RFC is a bugfix 

--

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Openswan dev] [Openswan Users] Fragmentation/reassembly bad behaviour (fwd)

Albert reported a very interesting bug, probably related to NETKEY.
Unfortunately, the Openswan regression network has not been extended
yet to cover both KLIPS and NETKEY.

Albert. Is it possible to try and reproduce this bug with KLIPS?

Paul

---------- Forwarded message ----------
Date: Mon, 10 Jan 2005 19:50:50 +0100
From: albert agusti <aagusti <at> serialnet.net>
To: users <at> openswan.org
Subject: [Openswan Users] Fragmentation/reassembly bad behaviour

Hello,

I reported a bug (0000213   [OpenSWAN] :Other/Unknown   major   always
01-05-05 21:26   01-05-05 21:26) some days ago, but for the moment is
not assigned. After some more probes reproducing the problem, I think I
can now explain more clearly (I'll update BUG tool)
I'm not sure if this behaviour is dued to openswan or kernel 2.6 native
ipsec stack because the problem arises when routing packets one time
have correctly crossed the IPsec tunnel.

The scenario:
Running kernel 2.6.5-1.358 and Openswan-2.2.0 on Linux box on Responder
end (R)
Nortel Contivity on Initiator end (I)
NO NAT-T (real routing at both ends)

[Openswan dev] [Announce] ANNOUNCE: Openswan 2.3.0 Released

2005-01-10
Xelerance has released Openswan 2.3.0

Changes:

* KLIPS for 2.6 support (Experimental)
   (known to be dangerous on redhat kernel sources on ix86 cpus)
* Aggressive Mode Support (client and server)
   (different implementation from openswan-1. DOS protection)
* IKE Mode Config support (Experimental)
* Cisco VPN 3xxx client Interop (Experimental)
* Cryptographic helpers framework
* Fixes for NAT-T on 2.4.28+ kernels.
* AES is now the default proposal
* SHA1 is now perferred over MD5
* Fix for long-standing KLIPS bug with snmpd kernel crasher
* Fixes for DPD with multiple tunnels between the same peers
* Fixes for DPD interop with Cisco
* Always announce DPD capability, even if our end does not use it (as per RFC)
* Fixes for loading proper NETKEY kernel modules (eg xfrm4_tunnel)
* Fixes to RPM spec files in packaging/suse and packaging/redhat

It is available at the usual locations:

http://www.openswan.org/code/
ftp://ftp.openswan.org/openswan/

The repositories have been made accessible for yum, apt-get, up2date, etc.
For example, to add openswan to yum on fedora:

[Openswan dev] Re: [Openswan Users] Fragmentation/reassembly bad behaviour (fwd)

>>>>> "Paul" == Paul Wouters <paul <at> xelerance.com> writes:
    Paul> flows chipered from both networks. Tunnel up and ok.  Nortel
    Paul> does not do MTU PATH DISCOVERY and has 1500 MTU value in
    Paul> Ethernet and in WAN interfaces.

  Right. Remove it from the network.
  It is broken. Seriously. This is a Nortel problem.

    Paul> original that entered) is recovered in clear mode -- Until
    Paul> here all is OK e) Openswan decides that this packet CAN'T be
    Paul> routed to the local (protected network) claiming that he has
    Paul> an MTU of 1500 and generates ICMP error to the packet
    Paul> originator

  Well, what *CAN* we do?
    a) we can't send it (it is too big)
    b) we really can't fragment it.

    Paul> In this example, original packet was 1500 bytes, but after a
    Paul> lot of changes in interfaces MTU and generate different kinds
    Paul> of traffic, it does not matter. ALWAYS that the conditions
    Paul> explained are meet (traffic with DF that is reassembled from
    Paul> various ESP received fragments), openswan generates ICMP
    Paul> error. This ICMP is not routed to Nortel, but in any case
    Paul> would be ignored because Nortel's MTU is yet 1500. Packet fits
    Paul> in network but Openswan thinks not.

  The virtual MTU of the tunnel has to be smaller than 1500, and this
should be known by the Nortel box. The ICMP, were it to be sent back

Re: [Openswan dev] [Openswan Users] Fragmentation/reassembly bad behaviour (fwd)

I and others have had a similar problem with fragmentation. It might be the
same bug. It has also been reported here:

http://www.uwsg.iu.edu/hypermail/linux/net/0401.3/0057.html
http://www.uwsg.iu.edu/hypermail/linux/net/0402.2/0000.html

The temporary fix is to use Netfilter to force the MSS to something smaller:
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1404

Marcus