Re: [IPsec] IANA ikev2 registry and FC values

"Black, David" <david.black@emc.com> Thu, 17 January 2013 17:16 UTC

Return-Path: <david.black@emc.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F8821F87D6 for <ipsec@ietfa.amsl.com>; Thu, 17 Jan 2013 09:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTLHtzPmm2VQ for <ipsec@ietfa.amsl.com>; Thu, 17 Jan 2013 09:16:22 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 59D6D21F87C3 for <ipsec@ietf.org>; Thu, 17 Jan 2013 09:16:22 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0HHGFUl020413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 12:16:20 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 17 Jan 2013 12:16:03 -0500
Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0HHG2Dn013893; Thu, 17 Jan 2013 12:16:02 -0500
Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Thu, 17 Jan 2013 12:16:02 -0500
From: "Black, David" <david.black@emc.com>
To: "'kivinen@iki.fi'" <kivinen@iki.fi>, "'ipsec@ietf.org'" <ipsec@ietf.org>
Date: Thu, 17 Jan 2013 12:16:01 -0500
Thread-Topic: [IPsec] IANA ikev2 registry and FC values
Thread-Index: Ac301NIal9ntXLfbTju4MYbNBC3YrgAAYEkT
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287AB6FC7@MX15A.corp.emc.com>
In-Reply-To: <20728.12021.834751.712756@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [IPsec] IANA ikev2 registry and FC values
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2013 17:16:23 -0000

No problem here - I'm one of the authors of RFC 4595.

Thanks, --David +++Sent from Blackberry

----- Original Message -----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Thursday, January 17, 2013 12:03 PM
To: ipsec@ietf.org <ipsec@ietf.org>
Subject: [IPsec] IANA ikev2 registry and FC values

I got question now about the values allocated for the "IKEv2 in the
Fibre Channel Security Association Management Protocol" and their use
in the normal IPsec use over IP. This question was about support for
AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of
using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values
everybody in IP world are using. When those values were allocated it
was assumed that they were only to be used in the FC world.

I noticed that when all other RFC4595 allocated numbers have FC_ in
their names, but these AUTH_* does not have those. Also there is
nothing that explictly forbid their use in the IKEv2/ESP over IP, it
has been implicit because there is nothing that says they can be used
in the IP world either.

One of the reasons for these is that this allocation happened when we
had this process flaw and those drafts never came to the IANA expert
for review (i.e. to me), so I only did some early comments to their
-00 draft, and then later noticed that the values had been added to
the registry.

To clear up this confusion, I would like to add note to the IANA table
saying "Only for Fibre Channel use" for those two values.

Does anybody have any objections for doing that? 
-- 
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec