Re: [IPsec] iSCSI: IPsec requirements

Michael Richardson <mcr@sandelman.ca> Wed, 12 October 2011 01:40 UTC

Return-Path: <mcr@sandelman.ca>
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 070D921F8B66 for <ipsec@ietfa.amsl.com>; Tue, 11 Oct 2011 18:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level:
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo1PtS2TabV9 for <ipsec@ietfa.amsl.com>; Tue, 11 Oct 2011 18:40:53 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB2321F8B3D for <ipsec@ietf.org>; Tue, 11 Oct 2011 18:40:53 -0700 (PDT)
Received: from marajade.sandelman.ca (wlan204.sandelman.ca [209.87.252.204]) by relay.sandelman.ca (Postfix) with ESMTPS id 4A7F2343A2; Tue, 11 Oct 2011 21:39:47 -0400 (EDT)
Received: by marajade.sandelman.ca (Postfix, from userid 179) id 14FE498C90; Tue, 11 Oct 2011 21:41:43 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0E64298B2E; Tue, 11 Oct 2011 21:41:43 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: david.black@emc.com
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058CFE5BAC@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E058CFE5BAC@MX14A.corp.emc.com>
X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 11 Oct 2011 21:41:43 -0400
Message-ID: <26551.1318383703@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Cc: ipsec@ietf.org
Subject: Re: [IPsec] iSCSI: IPsec requirements
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: Wed, 12 Oct 2011 01:40:54 -0000

>>>>> "david" == david black <david.black@emc.com> 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[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.