RE: iSCSI IPsec-Related Algorithm Proposal

["Herbert, Howard C" <howard.c.herbert@intel.com>]

David:

I will find out if anyone is writing a AES CBC MAC draft over in the IPsec
WG.  If no one has started, then I will sign up to producing one.

Also, Steve Kent's sequence number proposal DID NOT change the format on the
wire (at least that is what he says on slide #3).

I think we are going to have to come to terms with folks who want to use IKE
in this application.  The functionality already exists in the major host OSs
and HBA vendors are going to want to take advantage of that fact (one less
thing to add).  Maybe the trick here is to define a subset of the IKE
functionality that limits the impact to target vendors.  If we can do so,
would you consider making IKE mandatory to implement?

Howard

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Monday, July 02, 2001 10:56 AM
To: howard.c.herbert@intel.com; ips@ece.cmu.edu
Subject: RE: iSCSI IPsec-Related Algorithm Proposal


> CBC MAC has been standardized for years (see FIPS PUB 113 or ANSI X9.17).
> These standards used DES as the algorithm.  We just need to substitute AES
> for DES.  Another excellent reference can be found in section 9.5.1 in
> "Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone.
> Use of any other algorithms (e.g., one of the new SHAs) raises concerns
> about being able to scale to 1Gbit/sec.

I'd suggest writing a draft on the use of the AES CBC MAC
with ESP and starting it through the IPsec WG, as I think
that would have to come out as an RFC at the same time as
iSCSI in order for iSCSI to use it.  Such a draft will also
be necessary to get an ISAKMP value allocated for the MAC,
which will be needed independent of whether iSCSI uses IKE.

Absent such a draft, we may be left with no choice but to use
one of the SHAs (or MD5).  FWIW, there are chip vendors who
are claiming the ability to do SHA-1 at multi-gigabit speeds,
so I don't think scaling to 1Gbit/sec is a showstopper.  OTOH
I would agree that whether any of the SHA algorithms can be
effectively scaled to 10 Gbit/sec in the near future is
an open issue.

> On the second issue, even if you specify a re-keying algorithm that does
not
> solve your problem.  You must also extend the size of the sequence number
> field itself so that you are not having to re-key as often.  At the
December
> 2000 IETF meeting, Steve Kent of the IPsec WG presented proposals covering
> AES CBC MAC and sequence number rollover (see attached presentation).

I'm familiar with Steve's presentation, as I was in the
room in San Diego when he gave it.  What he described
is a worthy goal, but is not compatible on the wire with
current ESP.  If iSCSI were to depend on this, iSCSI would be
likely to get caught in a security document hairball/tarball
behind a whole pile of potentially pending revisions to
IPsec (e.g., iSCSI will depend on an ESP rev that depends
on "son of IKE").  I don't recommend this if the goal is
to get a stable iSCSI document completed in a timely fashion.

> I would expect that we could achieve quick alignment with the IPsec WG on
> these issues, have the IPsec WG generate any missing RFCs (if they are not
> already doing so), and reference them in our specification.

Writing drafts that will become the "missing RFCs" is a
better approach, and (as indicated above) I would stay
away from any basic revisions to ESP.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------