Subject: RE: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 3DES-CBC-I

From: "Mukund, Shridhar" <[email-masked]>
Date: Tue, 4 Dec 2001 16:06:03 -0800

Paul and Bernard,
 
Comments inline.

-Shridhar Mukund

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]

>  Bernard> ...Given that 3DES-CBC-I has already been 
>  Bernard> standardized by ANSI,
>  Bernard> it may be feasible to get an IPsec transform document
>  Bernard> written and adopted as a work item by IPsec WG. If this can
>  Bernard> happen, then it would be possible to argue the merits of
>  Bernard> this algorithm versus the other ones under
>  Bernard> consideration. Given the prevalence of 3DES-CBC however, I
>  Bernard> suspect that the argument would be over whether 3DES-CBC-I
>  Bernard> would become a MAY or a SHOULD implement, rather than a
>  Bernard> MUST.
> 
> CBC-I is no less a hardware change than any other new mode.  So it's
> not clear why it would be useful to work on that rather than on other
> new modes.  Perhaps if there aren't IP issues with it?
> 

I agree, this issue needs to be worked in thru the IPSec WG(and saag?)
I have nothing against other new modes, assuming: When AES-CTR is 
approved, AES-CTR becomes MUST and 3DES-CBC is demoted to MAY. On the
other hand, if both are MUST, then there is a problem. There are no IP
issues with CBC-I.

> Given that IPSec acts at the datagram level, you can do interleaving
> on a packet basis.  In a high speed implementation, it is reasonable
> to expect that there are several packets awaiting processing at a
> time.  If so, they can each be run through separate processing
> elements.  So the CBC bottleneck applies within a packet but not
> across packets.  That's not to say that new modes aren't interesting
> -- but it says that you can continue to improve performance in the
> meantime. 
> 

Paul, it is difficult to argue the above issue without getting into
more detail. I do insist that the "additional" and "otherwise 
unnecessary" cost of interleaving on a packet basis is "significant" 
at say 2G thru 10G. Let us take this off-line and follow-up on the IPSec 
reflector. 

-Shridhar Mukund

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 05 Dec 2001 17:14:21 -0800

>When AES-CTR is
>approved, AES-CTR becomes MUST and 3DES-CBC is demoted to MAY.

Doing that will create a problem in interoperation between iSCSI HBAs (which 
might have AES support) and software-only implementations, all of which now 
support 3DES-CBC. So it seems like 3DES-CBC has to be a MUST.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

From: "Mukund, Shridhar" <[email-masked]>
Date: Thu, 6 Dec 2001 18:29:47 -0800

Bernard,

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 5:14 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 
> 3DES-CBC-I
> 
> 
> >When AES-CTR is

>>> Yes, if we do not prep appropriatly we are inviting 
>>> trouble down the road. But then, we do agree that it is the
>>> charter of the IPS WG to enable low-cost iSCSI solutions from >>> today
all the way up to 10G.

>>> The IPSec implementation(hence interop) complexity is really 
>>> around yIKEs! Given that we leave the mathematically inclined
>>> folks to invent(and standardize) ESP/AH algorithms, software
>>> implementation of these algorithms is the easy part. 

>>> One of the important motivations behind AES is to simplify
>>> s/w implementation. Since 3DES is compute intensive, 
>>> s/w implementations will transition rapidly. Even today
>>> several implementations taut AES.

>>> On a lighter note, those who resist small s/w changes that 
>>> bring significant value are not in this audience. iSCSI
>>> is about change.

-Shridhar Mukund