RE: Relation between iSCSI session and IPSec SAs

[Black_David@emc.com]

Yes, the wording that implies a new IKE phase 1 for each iSCSI session
needs to be changed.  I believe that to be an oversight.  --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: Christina Helbig [mailto:cbh@zyfer.com]
> Sent: Monday, May 06, 2002 4:37 PM
> To: 'Srinivasa Addepalli'; Bernard Aboba; 'kukkonen@ssh.com';
> 'black_david@emc.com'
> Cc: ips@ece.cmu.edu
> Subject: RE: Relation between iSCSI session and IPSec SAs
> 
> 
> Hi, thank you for your answers!
> May be I have mixed something before I came out with my question. I
> understand that it is possible and reasonable to secure all 
> tcp connections
> with the same IKE phase 2 SA if the tcp connections have following
> properties:
> - belong to the same iSCSI session
> - are between the same IP address pair.
> If this is the security policy then the tcp ports could be 
> eliminated as
> selectors for the out-bound traffic to reduce the complexity 
> of realization.
> The consequence of this reduction would be that you can't 
> separate out-bound
> packets from multiple iSCSI sessions between the same IP 
> address pair and
> there is also currently no requirement to do this (David). In 
> this case it
> makes no sense to fulfill following demand of 
> draft-ips-security-11 for a
> new multiple iSCSI session if there is already an IKE phase 1 
> SA for an
> existing multiple iSCSI session between the same IP address pair:
> "In order to create a new iSCSI Session, an Initiator 
> implementing iSCSI
> security first establishes an IKE Phase 1 SA.  Subsequent 
> iSCSI connections
> established within the iSCSI session will typically be 
> protected by IKE
> Phase 2 SAs derived from that IKE Phase 1 SA, although 
> additional IKE Phase
> 1 SAs can also be brought up."
> It is possible to change this formulation for multiple iSCSI sessions
> between a given IP address pair?
> Greetings
> Christina
> 
> 
> > -----Original Message-----
> > From: Srinivasa Addepalli [mailto:srao@intotoinc.com]
> > Sent: Friday, May 03, 2002 1:04 PM
> > To: Bernard Aboba
> > Cc: Christina Helbig; ips@ece.cmu.edu
> > Subject: Re: Relation between iSCSI session and IPSec SAs
> > 
> > 
> > 
> > Security Policy Database, as defined by RFC2401 (Section 4.4.1) is
> > flexibile enough to create security associations for individual
> > TCP connections and for set of TCP/IP connections. For clarity, I am
> > listing down the portion of the RFC here:
> >  "   For each selector, the policy entry specifies how
> >    to derive the corresponding values for a new Security Association
> >    Database (SAD, see Section 4.4.3) entry from those in the 
> > SPD and the
> >    packet (Note that at present, ranges are only supported for IP
> >    addresses; but wildcarding can be expressed for all selectors):
> > 
> >            a. use the value in the packet itself -- This will 
> > limit use
> >               of the SA to those packets which have this 
> > packet's value
> >               for the selector even if the selector for the 
> > policy entry
> >               has a range of allowed values or a wildcard for this
> >               selector.
> >            b. use the value associated with the policy entry 
> > -- If this
> >               were to be just a single value, then there would be no
> >               difference between (b) and (a).  However, if 
> the allowed
> >               values for the selector are a range (for IP 
> > addresses) or
> > 
> >               wildcard, then in the case of a range,(b) would 
> > enable use
> >               of the SA by any packet with a selector value 
> within the
> >               range not just by packets with the selector 
> value of the
> >               packet that triggered the creation of the SA.  
> > In the case
> >               of a wildcard, (b) would allow use of the SA 
> by packets
> >               with any value for this selector. "
> > 
> > If security association is required for each TCP connection between
> > iSCSI initiator and target, then Security policy can be configured
> > to create security associations based on packet values for sourceIP,
> > destination IP, protocol, SP and DP.
> >  
> > If Security association is required for all connections between a
> > iSCSI initiator and target, then security policy can be configured
> > to depend on packet values for Source IP and destination IP 
> and policy
> > values for others.
> > 
> > Since, SPD itself provides this granularity, I think, there 
> > is no need for
> > any communication/relation between iSCSI layer and IPSEC layer.
> > 
> > 
> > Srini
> > On Fri, 3 May 2002, Bernard Aboba wrote:
> > 
> > > >From the minutes of Minneapolis:
> > > >"...a single IPSec Phase 2 SA per TCP connection ...had no 
> > security 
> > > > >value."
> > > >I agree and like to extend this:
> > > 
> > > >"...a single IKE negotiation per multiple iSCSI session 
> > (between the >same 
> > > >IP addresses of initiator and target) ...had no security value."
> > > 
> > > If you are saying that it it doesn't matter how many IKE 
> > phase 2 SAs 
> > > correspond to a given IKE Phase 1 SA, then I would agree. 
> > Is this what you 
> > > meant?
> > > 
> > > >Must we negotiate per multiple session (and evaluate 
> > packets >additional 
> > > >for a session identifier) or must we not?
> > > 
> > > I think that the bottom line is that an iSCSI session needs 
> > to be protected 
> > > by an IKE phase 2 SA. You can have multiple iSCSI sessions 
> > per phase 2 SA. 
> > > You can have multiple phase 2 SAs per phase 1 SA. Those are 
> > implementation 
> > > decisions that generally don't influence the security 
> > properties, except in 
> > > a few exceptional conditions (e.g. QoS marking, desire to 
> > protect iSCSI 
> > > sessions with different transforms).
> > > 
> > > _________________________________________________________________
> > > Join the world's largest e-mail service with MSN Hotmail. 
> > > http://www.hotmail.com
> > > 
> > 
> > -- 
> > Srinivasa Rao Addepalli
> > Intoto Inc.
> > 3160, De La Cruz Blvd #100
> > Santa Clara, CA
> > USA
> > Ph: 408-844-0480 x317
> > 
>