RE: Relation between iSCSI session and IPSec SAs

[Christina Helbig <cbh@zyfer.com>]

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
>