SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    
    Paul and Bernard,
     
    Comments inline.
    
    -Shridhar Mukund
    
    > -----Original Message-----
    > From: Paul Koning [mailto:pkoning@equallogic.com]
    
    >  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
    
    
    


Home

Last updated: Wed Dec 05 21:17:54 2001
7999 messages in chronological order