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
- [IPsec] IANA ikev2 registry and FC values Tero Kivinen
- Re: [IPsec] IANA ikev2 registry and FC values Yaron Sheffer
- Re: [IPsec] IANA ikev2 registry and FC values Black, David
- Re: [IPsec] IANA ikev2 registry and FC values Dan Harkins
- Re: [IPsec] IANA ikev2 registry and FC values Tero Kivinen
- Re: [IPsec] IANA ikev2 registry and FC values Tero Kivinen
- Re: [IPsec] IANA ikev2 registry and FC values Yaron Sheffer
- Re: [IPsec] IANA ikev2 registry and FC values Tero Kivinen
- Re: [IPsec] IANA ikev2 registry and FC values Yaron Sheffer
- Re: [IPsec] IANA ikev2 registry and FC values Dan Harkins