SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Last call comments



    
    I think either of the possible wordings suggested by David, Julian,
    or John would work fine.  However, John brings up a valid point
    in that it's the _interface_ not the target or initiator, that can
    be compliant or not, since the target or initiator is really a SCSI-
    level thing.  I'm not sure whether we have to specify the use of an
    enclosure or not, since one could integrate the iSCSI and IPsec
    implementations either within an enclosure, or in separate enclosures,
    and still be OK.  The enclosure is a good example, though.
    
    How about the following modification:
    
    An iSCSI initiator or target interface may provide the required IPsec
    support either fully integrated or in conjunction with an IPsec
    front-end device.  In the latter case the term iSCSI target interface
    refers to the target and IPsec front-end and compliance requirements
    apply to the "combined device".  For example, an enclosure containing
    separate implementations of iSCSI and IPsec may claim compliance only
    on those interfaces leaving the enclosure that support IPsec.
    
    --
    Mark
    
    John Hufferd wrote:
    > 
    > Julian,
    > As you know we talked about this a lot a long time ago.  Many folks wanted
    > to count the fact that a Firewall device within the installation could be
    > used with their iSCSI Initiator or Target, and therefore their device
    > should count as compliant with the specification.  The understanding that
    > was reached after much debate was that  ... if you want to claim compliance
    > for the interface that leaves an enclosure, IPsec is required ....  I
    > believe that if you include the words you are suggesting, that you should
    > add that statement to the spec also.
    > 
    > I suggest the following wordage:
    > 
    > "An iSCSI initiator or target may provide the required IPsec support either
    > fully integrated or in conjunction with an IPsec front-end device.  In the
    > later  case, the compliance requirements apply to the "combined device".
    > Claims of compliance for the interface that leaves an enclosure, is valid
    > only if IPsec is supported on that interface from within the enclosure."
    > 
    > The above would permit a Rack Enclosure, which had a Firewall included
    > within that Rack Enclosure, to validly claim compliance for the interfaces
    > that left the Rack.  Likewise, for any other enclosure.  If the HBA , blade
    > or motherboard had a fronting IPsec chip, that would also permit compliance
    > at the external interfaces of the HBA, blade or motherboard.
    > 
    > .
    > .
    > .
    > John L. Hufferd
    > Senior Technical Staff Member (STSM)
    > IBM/SSG San Jose Ca
    > Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    > Home Office (408) 997-6136, Cell: (408) 499-9702
    > Internet address: hufferd@us.ibm.com
    > 
    > "Julian Satran \(Actcom\)" <Julian_Satran@actcom.net.il>@ece.cmu.edu on
    > 07/05/2002 01:56:09 AM
    > 
    > Sent by:    owner-ips@ece.cmu.edu
    > 
    > To:    "Michael Smith" <msmith@corp.iready.com>, <Black_David@emc.com>,
    >        <ips@ece.cmu.edu>
    > cc:    "Michael Smith" <msmith@corp.iready.com>
    > Subject:    Re: iSCSI: Last call comments
    > 
    > I would suggest the following text for  7.3
    > 
    > An iSCSI initiator or target may provide the required IPsec support either
    > fully integrated or in conjunction with an IPsec front-end device. In the
    > later  case the term iSCSI target reffers to the target and IPsec front-end
    > and  compliance requirements apply to the "combined device".
    > 
    > Julo
    > ----- Original Message -----
    > From:  Michael  Smith
    > To: 'Black_David@emc.com' ; 'ips@ece.cmu.edu'
    > Cc: Michael Smith
    > Sent: Thursday, July 04, 2002 2:52  AM
    > Subject: RE: iSCSI: Last call  comments
    > 
    > I support David's suggested clarification and his suggested  wording. I
    > struggled for a while understanding this issue and the suggested  changes
    > make things much clearer.
    > 
    > Mike Smith
    > CTO, iReady
    > 
    > -----Original Message-----
    > From: Black_David@emc.com [mailto:Black_David@emc.com]
    > Sent: Wednesday, July 03, 2002 2:54 PM
    > To: mbakke@cisco.com; ips@ece.cmu.edu
    > Subject: RE: iSCSI: Last call comments
    > 
    > Mark,
    > 
    > > There are a few sections in iSCSI (and ips-security) that  discuss
    > > IPsec requirements for  "compliant/conformant implementations".  I
    > >  recall that this meant a target implementation could either be a
    > > single device with both iSCSI and IPsec, or a  combination of two
    > > devices, one that handles  iSCSI; the other handling IPsec.
    > 
    > In the two device combination, only the combination is  compliant,
    > and only at the interface(s) that  provide(s) both iSCSI and IPsec.
    > The iSCSI device in  the combination is not compliant by itself
    > because it  does not provide IPsec.
    > 
    > > As there are many cases where it makes a lot of sense to  provide
    > > the solution in two pieces (iSCSI in one  or more devices, with one or
    > > more IPsec front-end  devices, I'd like to clarify this.
    > >
    > > How about (somewhere in section 7) adding  something like:
    > >
    > >    An iSCSI compliant initiator or target may  provide the required
    > >    IPsec  support either by itself, or in conjunction with an IPsec
    > >    front-end device.
    > >
    > > Any thoughts?
    > 
    > It would need to have the word "compliant" removed and a  sentence
    > added to spell out what is compliant, along  the lines of:
    > 
    >     An iSCSI initiator or target may provide  the required
    >     IPsec support either  by itself, or in conjunction with an IPsec
    >     front-end device.  In the latter case only the  combination
    >     complies with the  requirements of this specification; the
    >     individual iSCSI initiator or target would not  comply with
    >     the requirements of  this specification due to the lack of IPsec
    >     support.
    > 
    > It's probably a good idea to put this in.
    > 
    > Thanks,
    > --David
    > ---------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC  Corporation, 42 South St., Hopkinton, MA  01748
    > +1 (508)  249-6449             FAX: +1 (508) 497-8018
    > black_david@emc.com       Mobile: +1  (978) 394-7754
    > ---------------------------------------------------
    > 
    > > -----Original Message-----
    > >  From: Mark Bakke [mailto:mbakke@cisco.com]
    > > Sent: Wednesday, July 03, 2002 5:48 PM
    > > To: IPS
    > > Subject: iSCSI: Last call  comments
    > >
    > >
    > >
    > > The iSCSI draft is  looking pretty good.  I only have one last-call
    > > comment left:
    > >
    > > There are a few sections in iSCSI (and ips-security) that  discuss
    > > IPsec requirements for  "compliant/conformant implementations".  I
    > >  recall that this meant a target implementation could either be a
    > > single device with both iSCSI and IPsec, or a  combination of two
    > > devices, one that handles  iSCSI; the other handling IPsec.  However,
    > > I  couldn't find anywhere in the spec that spells this out either
    > > way, other than a hint at it in item [3] on page 31 of
    > > ips-security-13:
    > >
    > > > [3]  IPsec is provided by a device  external to the actual
    > > iSCSI device.
    > > >      Here the iSCSI header  and data CRCs can be kept across
    > > the part  of
    > > >      the  connection that is not protected by IPsec. For
    > >  instance, the
    > > >       iSCSI connection could traverse an extra bus, interface card,
    > > >      network, interface card, and  bus between the iSCSI
    > > device and the
    > > >      device providing  IPsec. In this case, the iSCSI CRC is
    > >  desirable,
    > > >      and  the iSCSI implementation behind the IPsec device
    > >  may request
    > > >       it.
    > >
    > > As there are  many cases where it makes a lot of sense to provide
    > > the solution in two pieces (iSCSI in one or more devices, with one  or
    > > more IPsec front-end devices, I'd like to  clarify this.
    > >
    > > How  about (somewhere in section 7) adding something like:
    > >
    > >    An iSCSI compliant  initiator or target may provide the required
    > >    IPsec support either by itself, or in  conjunction with an IPsec
    > >     front-end device.
    > >
    > >  Any thoughts?
    > >
    > >  --
    > > Mark
    > >
    > >
    > > For reference, here  are a few of the statements that would be
    > > helped  out by the above.
    > >
    > >  iscsi-14 Section 7.3.1:
    > >
    > >    An iSCSI compliant initiator or target MUST  provide data integrity
    > >    and  authentication by implementing IPsec [RFC2401] with
    > > ESP [RFC2406]
    > >    in  tunnel mode and MAY provide data integrity and
    > >  authentication by
    > >    implementing  IPsec with ESP in transport mode. The IPsec
    > >  implementa-
    > >    tion MUST fulfill  the following iSCSI specific requirements:
    > >
    > > iscsi-14 Section 7.3.2:
    > >
    > >    An iSCSI compliant  initiator or target MUST provide
    > > confidentiality
    > >    by implementing IPsec [RFC2401]  with ESP [RFC2406] in
    > > tunnel mode and
    > >    MAY provide confidentiality by  implementing IPsec with ESP
    > > in trans-
    > >    port mode. with the following iSCSI  specific requirements:
    > >
    > > iscsi-14 Section 7.3.3:
    > >
    > >      - Conformant iSCSI  implementations MUST support IKE Main Mode
    > >             and SHOULD support Aggressive Mode.
    > >
    > > ---
    > > ips-security-13  Section 2.3.1:
    > >
    > > All  IP block storage security compliant implementations MUST support
    > > IPsec ESP [RFC2406] to provide security for both control  packets and
    > > data packets, as well as the replay  protection mechanisms of IPsec.
    > > When ESP is  utilized, per-packet data origin authentication, integrity
    > > and replay protection MUST be used.
    > >
    > >
    > > --
    > > Mark A. Bakke
    > > Cisco Systems
    > > mbakke@cisco.com
    > >  763.398.1054
    > >
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    


Home

Last updated: Tue Jul 09 19:18:48 2002
11218 messages in chronological order