Re: [IPsec] IANA ikev2 registry and FC values

Tero Kivinen <> Thu, 17 January 2013 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E02C321F8765 for <>; Thu, 17 Jan 2013 10:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VLKwT5oai1rW for <>; Thu, 17 Jan 2013 10:13:41 -0800 (PST)
Received: from ( [IPv6:2001:1bc8:100d::2]) by (Postfix) with ESMTP id F10D021F85C8 for <>; Thu, 17 Jan 2013 10:13:40 -0800 (PST)
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id r0HIDXdA022064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 20:13:33 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.5/8.12.11) id r0HIDUUP002334; Thu, 17 Jan 2013 20:13:30 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Thu, 17 Jan 2013 20:13:30 +0200
From: Tero Kivinen <>
To: Yaron Sheffer <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 19 min
Subject: Re: [IPsec] IANA ikev2 registry and FC values
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Jan 2013 18:13:42 -0000

Yaron Sheffer writes:
> OTOH your proposal would mean one more difference between "regular" 
> IPsec implementations and FC-specific ones. I don't think that would be 
> a good thing.

FC-specific ones are only using these non-truncated ones, and they are
using special ID payloads, separate protocol ID values, different
types of traffic selectors etc. They are reusing the basic IKEv2
protocol, and some of the payloads, but it is different protocol than

> > They are not defined for IP use at all. None of the IKEv2/ESP over IP
> > uses those values. Ah, found text from our IPsec/IKE Roadmap:
> >
> > 		   For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry
> >     contains values for both the truncated version and the standard non-
> >     truncated version; thus, IKEv2 has the capability to negotiate either
> >     version of the algorithm.  However, only the truncated version is
> >     used for IKEv2 SAs and for IPsec SAs.  The non-truncated version is
> >     reserved for use by the Fibre Channel protocol [RFC4595].  For the
> >     other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC-
> >     RIPEMD), only the truncated version can be used for both IKEv2 and
> >     IPsec-v3 SAs.
> >
> > which actually says we always use truncated version (so I was wrong
> > they are not forbidden anywhere, missed this text last time as it uses
> > SHA-1 spelling not SHA1, which I was searching for :-).
> >
> This text is simply describing the existing situation. It is not at all 
> normative.

Which is why I also want to describe that existing situation in the
IANA registry. If you want to use those non-truncated versions in
IPsec, you can write draft describing that... 

> > That is true, and I do not consider that as a good thing. It is much
> > better to have one good way of doing things than two ways of doing
> > same thing, especially if those two ways are about the same.
> >
> Yes, but people have good reasons to add algorithms, which is (part of 
> the reason) why we negotiate them in the protocol. Thus "Tiger", 
> "camellia" and the like, and I'm sure the FC folks had a good reason for 
> the untruncated algorithms, too.

They had some reason, but on the other hand IPsec people did not want
those untruncated algorithms, and have not specified them for IP use.
This is one of the problems when sharing registries causes problems.
Suddenly you might have options for protocols which did not request
them added to them, because someone else who shares the same registry
added them.