[Swan-dev] [IPsec] Question on IPSEC Identification Type" registry (fwd)

[Paul Wouters]

FYI. I have to double check Tero's last remark.

---------- Forwarded message ----------
Date: Mon, 7 Apr 2014 08:20:20
From: Tero Kivinen <kivinen at iki.fi>
Cc: "ipsec at ietf.org WG" <ipsec at ietf.org>
To: Paul Wouters <paul at cypherpunks.ca>
Subject: [IPsec] Question on IPSEC Identification Type" registry

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 at iki.fi