SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: IPsec Usage Question



    IMHO, both Ofer and Paul appear to be right, so let me
    attempt to explain ...
    
    We cannot place general constraints on the extent of an IPsec
    implementation that happens to be used for IP Storage -
    if someone wants to implement full IPsec (e.g., additional
    ciphersuites, IKE ID payloads) and use that functionality to
    talk to security gateways that are not part of IP Storage
    implementations, there's nothing we can do to stop this ...
    and we probably should encourage this sort of thing.
    
    The upshot is that the implementation requirements and
    usage requirements/restrictions being placed on IPsec for
    securing IP Storage protocols apply only to SAs that have
    an IP Storage system (e.g., a security gateway that is
    part of an IP Storage system) at both ends.  I don't
    believe that either of Paul's examples fall into this category
    as he described them, hence neither would be prohibited by what
    we do here, and I agree with Ofer that at least Paul's VPN
    scenario should not be used to motivate iSCSI security
    requirements.
    
    OTOH, Paul's second example could fall into this category if
    one considered an iSCSI system consisting of multiple initiators
    bundled with a security gateway, and based on that example,
    I'm inclined to agree with Paul's contention that requiring
    inner IP addresses to match outer IP addresses would be a
    mistake.
    
    The fact that IPS usage requirements/restrictions for IPsec
    only apply to SAs that have IPsec implementations that are
    part of IP Storage systems at both ends probably needs to be
    stated somewhere for clarity to avoid others jumping to the
    conclusion that an IPsec implementation used for IP Storage
    cannot use additional features when talking to a peer that
    is not an IP Storage system.
    
    Thanks,
    --David
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    black_david@emc.com         Cell: +1 (978) 394-7754
    ---------------------------------------------------
    
    > -----Original Message-----
    > From: Ofer Biran [mailto:BIRAN@il.ibm.com]
    > Sent: Tuesday, February 05, 2002 4:12 PM
    > To: Paul Koning
    > Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu
    > Subject: RE: IPsec Usage Question
    > 
    > 
    > 
    > Paul,
    > 
    > I only meant that the 2-site tunnel scenario has nothing to 
    > do with the
    > IPsec protection mandated to be implemented (yes, implemented,
    > not used) by iSCSI.  So I would not use this scenario at all 
    > to conclude
    > about iSCSI security requirements (outer=inner etc.).
    > 
    >   Regards,
    >       Ofer
    > 
    > 
    > Ofer Biran
    > Storage and Systems Technology
    > IBM Research Lab in Haifa
    > biran@il.ibm.com  972-4-8296253
    > 
    > 
    > Paul Koning <ni1d@arrl.net>@ece.cmu.edu on 05/02/2002 18:52:28
    > 
    > Sent by:  owner-ips@ece.cmu.edu
    > 
    > 
    > To:   Ofer Biran/Haifa/IBM@IBMIL
    > cc:   Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu
    > Subject:  RE: IPsec Usage Question
    > 
    > 
    > 
    > Excerpt of message (sent 5 February 2002) by Ofer Biran:
    > >
    > > Paul,
    > >
    > > >This example MUST work.  So you cannot require inner == outer
    > > >address, because that translates into saying that IP 
    > Storage cannot be
    > > >protected by a site to site IPsec tunnel.
    > >
    > > This is not Kansas any more... The iSCSI devices on both 
    > sites (assuming
    > > that's their only IPsec protection) are not iSCSI compliant. This
    > > definitely
    > > doesn't cover the IPsec protection mandated by iSCSI.
    > 
    > No, you're mistaken.
    > 
    > I said nothing about what the iSCSI devices IMPLEMENT.  I only talked
    > about what was IN USE by the customer.  In the example, the customer
    > chose to USE a different security mechanism for reasons of cost,
    > convenience, site policy, or whatever.
    > 
    > Remember that the proposed requirement is "required to implement" and
    > NOT "required to use".
    > 
    > My interpretation of having "use" be optional is that you also have
    > the option of securing your traffic via other means.
    > 
    > Am I right?  Or is it the intent of the WG to say that no other
    > security mechanisms are allowed -- if you want security you MUST use
    > the one that is mandated in iSCSI nodes?  If so, for what reason?
    > 
    >     paul
    > 
    > 
    > 
    > 
    


Home

Last updated: Mon Feb 11 16:18:18 2002
8726 messages in chronological order