SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI IPsec-Related Algorithm Proposal



    
    Points on the hairball/tarball noted - things are sticky enough already.
    
    For the IKE subteam - Sure, sign me up.
    
    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Monday, July 02, 2001 11:44 AM
    To: howard.c.herbert@intel.com; ips@ece.cmu.edu
    Subject: RE: iSCSI IPsec-Related Algorithm Proposal
    
    
    Howard,
    
    > 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.
    
    Thank you.
    
    > 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).
    
    True, BUT ... it does change the data over which the authentication (MAC)
    algorithm is run (two bullets above on the same slide) - the 16 bits that
    aren't
    on the wire are included in the authentication/integrity check.  Before
    anyone
    draws the wrong conclusion, Steve also proposed that this behavior be
    negotiable on a per-SA basis for backwards compatibility.  This change
    really
    needs to be made via a modification to RFC 2406 (the basic ESP RFC), hence
    the concern about the security document hairball/tarball.  OTOH, I was just
    involved in the new ECN RFC (coming soon from the RFC Editor) which
    managed to "update" RFC 2401 (IPsec architecture) without getting hung
    up, so this sort of modification isn't completely out of the question.
    
    > 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?
    
    It's up to the WG, but I have no fundamental problem with
    an IKE subset ... and I've been independently pursuing a
    set of volunteers to work on such a subset - want to join
    the party?
    
    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
    ---------------------------------------------------
    
    
    


Home

Last updated: Tue Sep 04 01:04:21 2001
6315 messages in chronological order