Subject: [IPsec] iSCSI: IPsec requirements

From: <[email-masked]>
Date: Tue, 11 Oct 2011 00:42:11 -0400

As a co-chair of the storm WG, I'm looking for some input on updating the IPsec
requirements for iSCSI, which is the subject of a WG Last Call comment against
the new iSCSI draft.

The history here is that as part of the original work for iSCSI (and some additional
storage protocols), a profile of the then-current version of IPsec (2400-series RFCs)
was produced (RFC 3723), and iSCSI (RFC 3720) has "MUST implement" requirements for
that version of IPsec.  By the time iSCSI was completed, the next version of IPsec
(4300-series RFCs) was imminent, but a deliberate decision was made to have both
RFC 3720 and 3723 continue to refer to the older version of IPsec.

A primary reason at the time was that iSCSI and IPsec implementations are generally
independent, and the most likely implementation path for iSCSI involved existing
older IPsec implementations.  That was back in 2004, and the IPsec world has moved
on since them.  The issue has been raised that it may not be appropriate for the new
iSCSI RFC-to-be to continue to require implementation of RFC 2400-series IPsec.

The new iSCSI draft is fully backwards compatible with the existing iSCSI RFCs (in
contrast to IPsec, where the versions of IKE deliberately don't interoperate), so
jumping straight to 4300-series IPsec does not seem like a good move unless
2400-series IPsec is extinct for all practical purposes.

Assuming 2400-series IPsec is not extinct, the appropriate requirements may be of
roughly the following form (this is a template, see RFC 3720 or 3723 for the specific
requirements to which this structure is to be applied):
	- MUST implement IPsec, 2400-series RFCs or 4300-series RFCs.
	- SHOULD implement IPsec, 4300-series RFCs.
	- I'm not inclined to also say: SHOULD NOT implement 2400-series IPsec.

OTOH, if 2400-series IPsec is extinct for all practical purposes, that all reduces to
	- MUST implement IPsec, 4300-series.

I'm interested in comments on what the right thing to do is here and why.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 21:41:43 -0400

>>>>> "david" == david black <[email-masked]> writes:
    david> Assuming 2400-series IPsec is not extinct, the appropriate requirements may be of
    david> roughly the following form (this is a template, see RFC 3720
    david> or 3723 for the specific 

Well, I'm not really sure how to answer your question.
There is certainly still lots and lots and lots of 2400-series IPsec in
use.  I'd say it was the majority in devices which can easily be
upgraded, and which aren't because IKEv1 still works well for the
solution space out there.  Certainly IKEv2 is pretty rare on
smartphones, I'd say for *VPN* connectivity.  
While at the same time, it's required for 3GPP interop (my
understanding, I never wrote that code myself)

However, we aren't talking about general purpose devices, but rather
operating systems, HBA cards, virtualization systems (iSCSI clients) and
NAS (iSCSI targets).

Presuming that none of these devices is going to want to stop claiming
conformance to RFC 3723/RFC 3720, then they will have to continue to
implement IPsec-2400 series. 

The only advantage to implementing IPsec-4300 series would be on newer
devices where code space and configuration is an issue, i.e. HBAs.  
It isn't like an IKEv2 speaking endpoint can't recognize and speak
IKEv1, particularly when it is a responder, it doesn't even cost a round
trip.

I don't know what other things you are updating in this round, so I
don't know what other things might drive an implementation to do
RFC3720bis,  but would prevent it from deploying IKEv2.

I therefore think that you should MUST implement 4300 (IKEv2), and MAY
implement 2400 series (IKEv1).  Note that the *ESP* level things, like
extended sequence numbers that appears in 4300 can be negotiated, so
it's really not that big a deal to MUST the rest of 4300 stuff in my
opinion. 

All the iSCSI devices that want to support 3723/3720 clients is going to
support IKEv1.  But, if there is a greenfield implementation of 3720bis,
then they could implement only the much simpler IKEv2.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: <[email-masked]>
Date: Wed, 12 Oct 2011 12:58:10 -0400

Michael,

Thanks for the response.

iSCSI is a rather stable protocol - existing implementations are expected to comply with this new spec with little to no change.  There is another draft in the storm WG that is making minor functional additions to iSCSI (given the number of years since RFC 3720, the amount of change needed is surprisingly small).

The new spec needs to normatively reference and update RFC 3723 (but there will be no 3723bis), so it sounds like the right approach is the following combination:

	- MUST implement IPsec, 2400-series RFCs (IPsec v2, IKEv1).
	- SHOULD implement IPsec, 4300-series RFCs (IPsec v3, IKEv2).

The MUST is for interoperability and to acknowledge what's out there; the SHOULD is to encourage implementers to move forward.  Now I need to go write the actual text to go into the draft.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 9:42 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [IPsec] iSCSI: IPsec requirements
> 
>