[IPsec] Question on IPSEC Identification Type" registry

Tero Kivinen <kivinen@iki.fi> Mon, 07 April 2014 12:20 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242C1A03DB for <ipsec@ietfa.amsl.com>; Mon, 7 Apr 2014 05:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osQxcHLTaen5 for <ipsec@ietfa.amsl.com>; Mon, 7 Apr 2014 05:20:37 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1961A03D4 for <ipsec@ietf.org>; Mon, 7 Apr 2014 05:20:36 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s37CKLwv029857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Apr 2014 15:20:21 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s37CKLZ8010161; Mon, 7 Apr 2014 15:20:21 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21314.38916.998882.266783@fireball.kivinen.iki.fi>
Date: Mon, 7 Apr 2014 15:20:20 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@cypherpunks.ca>
In-Reply-To: <alpine.LFD.2.10.1404041732520.16687@bofh.nohats.ca>
References: <alpine.LFD.2.10.1404041732520.16687@bofh.nohats.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 17 min
X-Total-Time: 18 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lVjpgM-hziqW9Kot0GHqK0uTAb0
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: [IPsec] Question on IPSEC Identification Type" registry
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 07 Apr 2014 12:20:43 -0000

Paul Wouters writes:
> 
> According to RFC 3554 (SCTP with IPsec):
> 
>  	IANA has assigned number 12 for ID_LIST (defined in Section 3) in the
>  	"IPSEC Identification Type" registry
> 
> which matches:
>
> http://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml#isakmp-registry-31

Yes, RFC 3554 is only for IKEv1. 

> But for IKEv2 we have:
> 
> http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-10
> 
> 12 	ID_FC_NAME 	[RFC4595]  (IKEv2 values for Fibre Channel)
> 
> which on top of that is  also not a real IKE value...

There is no need for ID_LIST in the IKEv2. First of all the ID_LIST is
only meant to be used as traffic selector not Identity. In the IKEv1
the ID payloads had dual role for both Identity for the authentication
(IDii, IDir) and the traffic selectors for the quick mode (IDci,
IDcr). In IKEv2 we have separated these two uses for separate
payloads, i.e. the ID payloads only act as Identity for authentication
and the traffic selectors are used to tell which traffic is protected.

Traffic selector payloads already support lists of traffic selectors,
so there is no problem. The ID payload used in the authentication
requires on identity but that usually is not a problem either, as the
peer can use FQDN or similar for their identity instead of using list
of IP addresses. 


> I guess I'm not the first to run into this. Angelos ran into this in
> 2003: http://www.vpnc.org/ietf-ipsec/03.ipsec/msg01723.html

This was way before the IKEv2 was even finished, and we did discuss it
at the time and tried to make sure the IKEv2 supports ways of doing
that. I do not know if people have actually implemented SCTP protected
over IPsec in host to host mode (this problem does not really exists
in the tunnel mode, or VPNs etc). 

> I'm not sure how one conveys ID_LIST for SCTP in IKEv2. But perhaps no
> one really cared to fix this? (I don't)

In traffic selectors just include all addresses in the traffic
selectors. In the ID payload, just use some other identity than list
of IP-addresses. 

> I guess at this point there is nothing much to do, possible add a
> warning note to the IANA registries for implementors....

Why? Those two registries are different and the other protocol is even
obsoleted... :-)

> I wish we could have kept these two registries more in sync.....

I agree that we most likely should have marked ID 12 as reserved as we
did for all other IKEv1 ID payloads which are not applicable for
IKEv2. 

> Paul, off to split v1 and v2 versions of this now

You should have done that earlier already... the registries are
different and there are other differences too. Also there is
differences between the ipsec-registry and isakmp-registry too (for
example the encryption algorithm of 8 is either CAMELLIA-CBC, or
ESP_3IDEA).
-- 
kivinen@iki.fi