Subject: [IPsec] IANA port number assignment name for IKEv2

From: Micah Anderson <[email-masked]>
Date: Fri, 08 Oct 2010 12:47:57 -0400

Hello,

The IANA port number assignment for UDP/TCP port 500[0] reads as follows:

isakmp          500/tcp    isakmp
isakmp          500/udp    isakmp
#                          Mark Schertler <mjs&tycho.ncsc.mil>

isakmp was originally designated in RFC2408[1] § 2.5.1 "Transport
Protocol" to be port 500 UDP. It was assigned to be named isakmp by the
Internet Assigned Numbers Authority (IANA).

It has come to my attention that RFC5996[2] has been designated as
obsoleting RFC2408 (via RFC 4306) and describes IKEv2 as the
non-backwards compatible protocol that is used for this purpose, and is
transported over port 500 UDP, and port 4500 when NAT traversal is
enabled (cf. RFC5996 § 2[3])

However, the IANA port assignment list still shows isakmp as being the
port name for 500. Should this port assignment name be changed?

I have CC'd the original IANA assignment requestor on this email.

Thanks,
Micah

0. http://www.iana.org/assignments/port-numbers
1. http://tools.ietf.org/html/rfc2408
2. http://tools.ietf.org/html/rfc5996
3. http://tools.ietf.org/html/rfc5996#section-2

--

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 8 Oct 2010 16:19:21 -0700 (PDT)

Hi,

  I'm not sure what non-backwards compatibility issue there is because
the IKEv2 header is, intentionally, the same as the ISAKMP header. The
former has MajVer as 2 and the latter has MajVer as 1. It's possible to
demultiplex a packet unambiguously.

  I don't know what problem would be solved by having IANA go through
the motions. For what it's worth, I am unaware of any plain-jane ISAKMP
versions out in the world. There's RFC 2409 that uses port 500 and there's
RFC 4306/5996 that uses port. It hasn't been a problem for the past 12
years and it doesn't look like a problem now.

  regards,

  Dan.

On Fri, October 8, 2010 9:47 am, Micah Anderson wrote:
> isakmp was originally designated in RFC2408[1] Â§ 2.5.1 "Transport
> enabled (cf. RFC5996 Â§ 2[3])
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: micah anderson <[email-masked]>
Date: Sat, 09 Oct 2010 12:56:04 -0400

Hello,

> demultiplex a packet unambiguously.

My understanding of reading RFC5996 page 71[0] is that they are only
backwards compatible in the sense that you can at least talk to an older
version. However that conversation is limited to establishing that you
will not shake hands. They share a lineage and basic structure but they
diverge with some specific version number fields and are incompatible
From there onwards:

       The Internet Security Association and Key Management Protocol
       (ISAKMP) [ISAKMP] fixed message header includes two eight-octet
       fields called "cookies", and that syntax is used by both IKEv1
       and IKEv2, although in IKEv2 they are referred to as the "IKE
       SPI" and there is a new separate field in a Notify payload
       holding the cookie.

       The syntax of Security Associations, Proposals, Transforms, and
       Attributes is based on ISAKMP; however, the semantics are
       somewhat different.

IKEv2 is not backwards compatible with IKEv1, as the Introduction to
RFC5996[1] says:

   This document describes such a protocol -- the Internet Key Exchange
   (IKE). . .  IKEv2 was a change to the IKE protocol that was not
   backward compatible.

> the motions. 

Having a properly named port that matches its intended protocol name is
much more useful than having a port named after an obsolete protocol
that has been supersceded. 

> For what it's worth, I am unaware of any plain-jane ISAKMP versions
> out in the world. There's RFC 2409 that uses port 500 and there's RFC
> 4306/5996 that uses port. 

RFC2409 has been obsoleted by 4306 which was then obsoleted by 5996. My
understanding of obsoleted rfcs means that what they contain is no
longer valid. RFC 2409 used port 500 for ISAKMP, but RFC 5996 has
overtaken that port by the IKEv2 protocol. If we move forwards with port
500 named after the obsolete RFC 2409 ISAKMP, but use it for IKEv2, then
we are doing a disservice to people trying to understand what is going
on.

IKEv1 was ISAKMP+oakley+skeme, and IKEv2 is none of that. From what I
can tell, IKEv2 has nothing to do with ISAKMP, except for the lineage as
described above.

> It hasn't been a problem for the past 12 years and it doesn't look
> like a problem now.

It was only last month that RFC5996 was released, and 5 years ago that
the RFC that it now obsoletes was released (RFC 4306). 

micah

0. http://tools.ietf.org/html/rfc5996#page-71
1. http://tools.ietf.org/html/rfc5996#page-5

---

From: Dan McDonald <[email-masked]>
Date: Sat, 9 Oct 2010 15:00:49 -0400

On Sat, Oct 09, 2010 at 12:56:04PM -0400, micah anderson wrote:

<SNIP!>

> can tell, IKEv2 has nothing to do with ISAKMP, except for the lineage as

So if you want to be a pedant, let's call 500 (and 4500) what they really
are:

	500/udp  Internet Key Exchange (IKE), versions 1 and 2

	4500/udp NAT-Traversal for IPsec and IKE

Here are the entries in Solaris's /etc/services, e.g.:

ike             500/udp         ike             # Internet Key Exchange
ipsec-nat-t     4500/udp                        # IPsec NAT-Traversal

Why is this a big deal?  Are you just wanting to make sure IANA reflects
reality?

Dan

---

From: micah anderson <[email-masked]>
Date: Sun, 10 Oct 2010 17:15:22 -0400

> 	4500/udp NAT-Traversal for IPsec and IKE

Precisely.

> ipsec-nat-t     4500/udp                        # IPsec NAT-Traversal

Great, Solaris has updated them, but its not updated in IANA's port
assignment database.

> Why is this a big deal?  Are you just wanting to make sure IANA reflects

Yes, I think having IANA reflect reality is a good idea. 

micah