Subject: RE: Relation between iSCSI session and IPSec SAs

From: Christina Helbig <[email-masked]>
Date: Mon, 6 May 2002 13:36:42 -0700

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: Bill Studenmund <[email-masked]>
Date: Mon, 6 May 2002 16:57:33 -0700 (PDT)

> - are between the same IP address pair.

I don't think so. I don't think that iSCSI session is a reasonable
selector for negotiating IPsec SAs. Mainly as you have to negotiate IPsec
SAs before the iSCSI login starts, and it is only during iSCSI login that
the target determines what session the initiator wants to talk to.

The IPsec standards list IP address, protocol, and (for ones where it
makes sense) port number as valid selectors for negotiating SAs. So how
would we negotiate session (but not tcp port) specific SAs? The initiator
doesn't know what tcp port a given session involves until it sets up the
tcp connection. The target doesn't know the tcp ports involved in a
connection _for_a_session_ until after its negotiated login (which as
above is way too late).

> selectors for the out-bound traffic to reduce the complexity of realization.

While you can do whatever you want internally, it has to look to the
outside world like you are using port numbers for selecting.

> 1 SAs can also be brought up."

I agree that it makes no sense to satisfy that requirement if you already
have a valid IKE Phase 1 SA. That text should be modified. When I quoted
the text to a number of IPsec implementors (different IPsec stacks), they
said, "that's just so wrong." :-)

I expect (from the quote) that that text is trying to describe what you
need to do when setting up the very first session between an initiator and
a target; you have to do the IPsec negotiation first, which starts with a
phase 1 SA.

> between a given IP address pair?

I think we need more than that. :-) Consider the case where we are using
IPsec between the initiator and the target. The initiator sets up a
discovery session, and as part of that, we negotiate both a phase 1 and
phase 2 SA. Then the initiator logs into one of the targets it just found.
It's more than likely that those SA negotiations are still valid. :-) For
iSCSI to require renegotiation would be, "less than desirable."  :-)

Take care,

Bill

---

From: Srinivasa Addepalli <[email-masked]>
Date: Mon, 6 May 2002 18:12:34 -0700 (PDT)

Hi,
   Securing iSCSI using IPSEC is now can be treated as two
   independent entities. iSCSI is just one more application on
   top of IPSEC. I see only one relation ( which is optional), that
   is, iSCSI layer can omit iSCSI CRC, if IPSEC is employed. Ofcourse,
   this is possible if both layers exist in the same machine.

   Are there any more dependencies?

Srini

-- 
Srinivasa Rao Addepalli
Intoto Inc. (Enabling Security Infrastructure)
3160, De La Cruz Blvd #100
Santa Clara, CA
USA