RE: Relation between iSCSI session and IPSec SAs

[Srinivasa Addepalli <srao@intotoinc.com>]

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

On Mon, 6 May 2002, Bill Studenmund wrote:

> On Mon, 6 May 2002, Christina Helbig wrote:
> 
> > 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.
> 
> 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).
> 
> > 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.
> 
> While you can do whatever you want internally, it has to look to the
> outside world like you are using port numbers for selecting.
> 
> > 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."
> 
> 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.
> 
> > It is possible to change this formulation for multiple iSCSI sessions
> > 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
> 

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