Re: Relation between iSCSI session and IPSec SAs

["Bernard Aboba" <bernard_aboba@hotmail.com>]

>Is there any benefit in being able to identify iSCSI
>TCP session based on the IPSec SA (SPI) alone?

In general, I do not think there is a benefit. Most implementions won't do 
this by default (e.g. most existing ones), so I suspect that you'd need to 
add the conventional logic anyway. And requiring an SA per connection will 
require a more memory to save the resulting state; the number of active SAs 
that can be handled at a time is limited.

>Does it make iSCSI TCP offloading easier when
>you can associate inbound datagrams to correct
>session using only single lookup based on the SPI?
>(or destination address + SPI + protocol, to be exact)
>
>You still need post-IPSec policy enforcement, but this
>is only a comparison against known values, not a lookup.

I think one must balance this against the extra state (and resulting memory) 
that must be kept for the additional Phase 2 SAs that are created. My sense 
is that this is not a good tradeoff.

>Also, does this "SA per TCP session" model make
>load balancing & high availability somehow easier?

I do not think so, because the state to track (IPsec + TCP + iSCSI) is not 
affected substantially.

>I would like to understand what is the usual justification
>for separating individual TCP sessions to different SAs.
>(and also whether people are doing this or not in iSCSI)

The most commonly cited justifications are when it is desired to apply 
different QoS to the sessions, or protect them with different transforms. 
However, I think these cases will be exceptions rather than being common, 
particularly since APIs are not typically available with which to easily set 
more granular, dynamic policies for iSCSI sessions. It is far easier to use 
a generic policy "from me to any, dest port iSCSI" than to attempt to plumb 
more granular and dynamic policies.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.