RE: Relation between iSCSI session and IPSec SAs

[Bill Studenmund <wrstuden@wasabisystems.com>]

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