SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: IKE normative guidelines



    Paul,
    
    > > Yes, these guidelines differ from those RFCs in a number of
    > > ways, based on things learned since those RFCs were written.
    > > Many of these are things that would go into revised versions
    > > of the IPsec RFCs, but revising the IPsec RFCs turns out to
    > > be intractable to the point of near-impossibility for the
    > > security folks - you'll have to ask them why.  See the IPS
    > > security draft for some further explanation of these changes.
    > 
    > That's all well and good, but I see a major process problem with WG
    > XYZ overriding the requirements created in another protocol that
    > belongs to WG ABC on the grounds that WG ABC can't get the work done
    > itself.
    
    Please take this up with the Security ADs, as opposed to pursuing it
    here.  AFAIK, both the IPsec WG and the IETF Security area (e.g.,
    saag meeting in London) are aware of the approach that the ips WG
    is taking here and do not have a problem with it.  We (including
    yours truly) are tracking what goes on in the security area and
    trying not to get ahead of it, but the fact that DES is the only
    REQUIRED cipher in the current documents is embarrassing.
    
    > If that's what we want to do, we should be clear about it and not call
    > the lower layer protocol we're relying on "IPSec" but rather something
    > like "IPS-sec" to make it clear we're defining an IPS specific variant
    > forked from the original standard.
    
    I have no problem with the use of "IPsec" along with a word like "subset".
    The fact that we are taking this subset approach does need to be crystal
    clear in our drafts.  FWIW, the "forking" is primarily in the area of
    deletion - we are not (and do not have the license to) extend the protocols
    in any fashion.  The approach is to remove requirements for things like AH
    and DES and strengthen requirements for things that replace them where
    replacements are needed (e.g., 3DES).
    
    > Perhaps IKE is less problematic than, say, not yet settled on modes
    > such as XCBC, but the same principle applies in both places.
    
    Any reference to XCBC will be a normative reference to an RFC that
    goes via the IPsec WG.  We cannot do work on XCBC here.  If the IPsec
    WG does not approve XCBC, we'll have to drop it.
    
    > > Main mode is not "at least as good" as aggressive mode when
    > > group pre-shared keys are used; see the security draft and
    > > the ipsec WG "improveike" draft for details.  Group pre-
    > > shared keys are often used in practice because they
    > > greatly simplify key management.
    > 
    > Yes, that's covered by text I supplied a while back.  That case
    > applies to dynamic IP addresses, which is an obscure corner case at
    > best for IPS.  With static addresses, group keys are not needed and
    > are very much not normal practice.
    
    At least for iSCSI, I definitely disagree with the "obscure corner
    case" characterization.  I'm less certain about FCIP and iFCP.  
    
    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: Mon Nov 12 15:17:44 2001
7764 messages in chronological order