Subject: Non-ipsec IANA allocations for IKEv2 needed

From: [email-masked]
Date: Fri, 6 Feb 2004 02:05:26 -0500

About a month ago, Tero Kivinen wrote:

> >   IKEv2 Security Protocol Identifiers may be allocated by Standards
Action.

> Again same as with proposal substructure protocol-IDs, I think
> specification required would be enough. I can see that someone might
> want to use IKE as a key exchange method for non-ipsec cases, where
> the easiest way would be to use new protocol number for that, and if
> it is not IP related protocol, then its documents might not be
> standard track documents, or RFCs at all. Preventing duplicate numbers
> in those cases might still be usefull, in case someone sometime define
> way to transport that stuff on the internet too...

In fact someone does want to use IKEv2 for a non-ipsec case - Technical
Committee T11 (www.t11.org) is planning to use IKEv2 as the key exchange
and SA-setup protocol for Fibre Channel (FC).  Since IP runs over Fibre
Channel (RFC 2625) and Fibre Channel runs over IP (RFC 3643 + additional
IPS WG drafts in the RFC Editor's queue), there is ample opportunity
for confusion, and hence preventing duplicate numbers is highly desirable.

Fibre Channel will want new IKEv2 values for the following:
- IKEv2 Security Protocol Identifiers.  There's at least one existing
	FC security encapsulation that is neither ESP nor AH.
- IKEv2 Integrity Algorithm Transform IDs.  The existing FC security
	encapsulation uses HMACs without truncation instead of the 96-bit
	truncated HMACs used by ESP and AH.
- IKEv2 Identification Payload ID Types.  Needless to say, in the absence
	of IP addresses, FC needs to use other sorts of addresses for
	identification.
- IKEv2 Traffic Selector Types.  Since FC native traffic doesn't have an
	IP header, different traffic selectors are needed.

There should be no problem in principle with producing specifications for
these and publishing them as RFCs (probably informational), so Expert
Review an Specification Required allocation processes are fine.  This
does raise a couple of concerns:

- There are no private use values defined for either security protocol
	IDs or traffic selector types, making it difficult to experiment
	with  implementations prior to allocation of values.
- My reading of the list discussion is that the security protocol
	identifiers should only be allocated by standards action, whereas
	Specification Required or Expert Review is ok for the traffic
	selector types.  This makes it difficult to allocate a security
	protocol ID.

The upshot is that in order to get a security protocol ID for non-ipsec
usage, one has to publish a standards track RFC defining a security
encapsulation that MUST NOT be used for ipsec.  That doesn't sound
right due to both the "standards track" requirement (informational
RFC would be ok), and the inability to legitimately use any value in
a non-ipsec context prior to the RFC publication.  This echoes Tero's
concern from above.

As an alternative, could we set aside a range of Security Protocol IDs
in IKEv2 that MUST NOT be used with IPsec for IP traffic, and allow
allocation of IDs for non-IPsec usage via Specification Required (or even
an Informational RFC)?  Security Protocol ID is a 1 byte field (256
values) of which only 3 (IKE, AH, ESP) are used now.  Reserving the
largest 32 or 64 values for non-ipsec usage shouldn't cause any problems
for future IPsec security protocols, although IANA should be instructed
to hand out new IPsec protocol IDs in ascending order after the existing
values to retain flexibility in the future.  This approach could also allow
creation of non-IPsec Private Use values (e.g., split the 64 non-IPsec
values into 32 Private Use and 32 to be allocated by IANA).

We should also consider setting aside private use traffic selector
values, with the possible restriction that they are for non-ipsec
usage only.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------