IPsec mailing list

Tina Bird tbird at PRECISION-GUESSWORK.COM
Tue Aug 1 12:44:59 EDT 2000


Hi all --

Sorry for the brain spasm last week.  For people who
are interested in the IPsec mailing list or archive,
please visit

http://www.vpnc.org/ietf-ipsec

for more information.

thanks -- tbird

VPN:  http://kubarb.phsx.ukans.edu/~tbird/vpn.html
life: http://kubarb.phsx.ukans.edu/~tbird
work: http://www.counterpane.com

---------- Forwarded message ----------
Date: Mon, 31 Jul 2000 06:45:22 -0500
From: "Brown, Theresa" <theresa at ti.com>
To: 'Tina Bird' <tbird at PRECISION-GUESSWORK.COM>
Subject: RE: Comments regarding IPsec NAT traversal / new proposal (fwd)

Tina,
I am interested in the IPsec mailing list but could not find any information
on it at www.securityfocus.com.  Are the archives stored anywhere?

-----Original Message-----
From: Tina Bird [mailto:tbird at PRECISION-GUESSWORK.COM]
Sent: Wednesday, July 26, 2000 10:30 AM
To: VPN at SECURITYFOCUS.COM
Subject: Comments regarding IPsec NAT traversal / new proposal (fwd)


Hi all -- I'm not sure how many of you also subscribe to
the IPsec mailing list.  It's much more focussed on
standards development and such than on the implementation
topics we tend to concentrate on.

However, if you are interested in the further evolution of
IPsec, you may want to start tracking this thread, which
is a discussion of encapsulating IPsec over TCP or UDP, to
gain NAT compatibility.

cheers -- tbird

VPN:  http://kubarb.phsx.ukans.edu/~tbird/vpn.html
life: http://kubarb.phsx.ukans.edu/~tbird
work: http://www.counterpane.com

---------- Forwarded message ----------
Date: Wed, 26 Jul 2000 16:03:27 +0300
From: Ari Huttunen <Ari.Huttunen at F-Secure.com>
To: ipsec-list <ipsec at lists.tislabs.com>
Subject: Comments regarding IPsec NAT traversal / new proposal

This mail applies partly to both of these drafts:
draft-aboba-nat-ipsec-02.txt
draft-stenberg-ipsec-nat-traversal-00.txt

We believe that using UDP encapsulation is the correct way
to traverse NATs, at least in the short term. We also intend
to produce an internet draft about this, however it didn't
materialize before the Pittsburgh meeting.

The current proposals are unnecessarily complex, and I'd like
some discussion about these issues, to judge if this is indeed
the case.

ASSUMPTION: There is no *need* to enable AH traffic to traverse
through a NAT. ESP is sufficient to provide encryption and/or
authentication.

By accepting this assumption, the solution can be made less complex.
It has been argued that in some rare cases AH is necessary to
protect the IP header. If this is so, I argue that there is no need
to make this pass through a NAT as well.

Thus, we can use the following encapsulation that is less complex and
has less overhead than either of the referred drafts has, i.e. 8 octets.

Transport mode:
            ---------------------------------------------------------
      IPv4  |orig IP hdr  | UDP | ESP |              |   ESP   | ESP|
            |(any options)| Hdr | Hdr | Payload Data | Trailer |Auth|
            ---------------------------------------------------------

ASSUMPTION: We do *not* wish to use the same UDP port for both IKE and
IPsec traffic encapsulated in UDP. This is because we'd loose the
possibility
to filter these traffic types separately in a firewall. For this purpose
we've
reserved the port 2797 from IANA.

As draft-stenberg-ipsec-nat-traversal-00.txt mentions, there is a potential
need
for a keepalive to ensure NAT tables remain up-to-date. Because our proposal
uses a different port than IKE, there is a need for a keepalive that sends
packets along the ESPoverUDP path. This can be achieved for instance by
sending
empty UDP packets (i.e. without ESP contents). (Assuming the general IPsec
keepalive is along the IKE SA and can't be used.)

In particular, the method of negotiating and setting up UDP encapsulation as
defined in draft-stenberg-ipsec-nat-traversal-00.txt is too complex. We
propose the following
mechanism for discussion:
1) IKE phase 1 is not modified.
2) IKE phase 2 adds a new protocol ID,
       Protocol ID                         Value
       -----------                         -----
       RESERVED                            0
       PROTO_ISAKMP                        1
       PROTO_IPSEC_AH                      2
       PROTO_IPSEC_ESP                     3
       PROTO_IPCOMP                        4
       PROTO_IPSEC_ESP_OVER_UDP            X

This is used to send proposals for plain IPsec as well as ESPoverUDP
during the QM. As usual, the responder may use any proposal it wishes.
The proposal shall contain parameters that say which src/dst port/addresses
were used by the initiator when sending the IKE packet. If these differ
from those observed by the responder, there is a NAT acting between them,
and the responder SHOULD choose the ESP over UDP proposal.

Unlike draft-stenberg-ipsec-nat-traversal-00.txt, this method
does not leak information regarding the internal structure of the network,
because QM messages are encrypted.

We don't have patent applications regarding this, but I have no way
of knowing whether SSH has tried to patent some it.

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com

F-Secure products: Integrated Solutions for Enterprise Security

VPN is sponsored by SecurityFocus.COM

VPN is sponsored by SecurityFocus.COM




More information about the VPN mailing list