Re: Relation between iSCSI session and IPSec SAs

[Srinivasa Addepalli <srao@intotoinc.com>]

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