Subject: RE: Relation between iSCSI session and IPSec SAs

From: [email-masked]
Date: Thu, 2 May 2002 10:57:01 -0400

> I found a similar statement in the mailing list from February but no
> discussion about this issue:
> "If an implementor wants to put all their iSCSI sessions on the same IPSec
> SA, I think they should have that liberty."
>
> So the question is, what is the situation? Must we negotiate per multiple
> session (and evaluate packets additional for a session identifier) or must
> we not?

The current situation is that there are no IP Storage requirements in
this space; one manage both phase 1 and phase 2 SAs in whatever fashion
makes sense.

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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 03 May 2002 10:52:34 -0700

>I would like to understand what is the usual justification
>for separating individual TCP sessions to different SAs.
>(and also whether people are doing this or not in iSCSI)

The most likely reasons seemed to have to do with the desire to provide 
different QoS for the sessions, or to use different transforms to protect 
the sessions. Personally, I don't think either of those reasons is 
compelling, but your

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: [email-masked]
Date: Mon, 6 May 2002 17:55:39 -0400

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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Christina Helbig [mailto:[email-masked]]
> Sent: Monday, May 06, 2002 4:37 PM
> To: 'Srinivasa Addepalli'; Bernard Aboba; [email-masked]';
> [email-masked]'
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: Friday, May 03, 2002 1:04 PM
> > To: Bernard Aboba
> > Cc: Christina Helbig; [email-masked]
> > 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
> > 
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 18 May 2002 00:52:31 -0700

>Is there any benefit in being able to identify iSCSI
>TCP session based on the IPSec SA (SPI) alone?

In general, I do not think there is a benefit. Most implementions won't do 
this by default (e.g. most existing ones), so I suspect that you'd need to 
add the conventional logic anyway. And requiring an SA per connection will 
require a more memory to save the resulting state; the number of active SAs 
that can be handled at a time is limited.

>Does it make iSCSI TCP offloading easier when
>you can associate inbound datagrams to correct
>session using only single lookup based on the SPI?
>(or destination address + SPI + protocol, to be exact)
>
>You still need post-IPSec policy enforcement, but this
>is only a comparison against known values, not a lookup.

I think one must balance this against the extra state (and resulting memory) 
that must be kept for the additional Phase 2 SAs that are created. My sense 
is that this is not a good tradeoff.

>Also, does this "SA per TCP session" model make
>load balancing & high availability somehow easier?

I do not think so, because the state to track (IPsec + TCP + iSCSI) is not 
affected substantially.

>(and also whether people are doing this or not in iSCSI)

The most commonly cited justifications are when it is desired to apply 
different QoS to the sessions, or protect them with different transforms. 
However, I think these cases will be exceptions rather than being common, 
particularly since APIs are not typically available with which to easily set 
more granular, dynamic policies for iSCSI sessions. It is far easier to use 
a generic policy "from me to any, dest port iSCSI" than to attempt to plumb 
more granular and dynamic policies.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.