RE: does iSCSI layer need to check IPsec policy? I hope not.

[Black_David@emc.com]

Vince,

> I have some difficulty understanding the intent in section 8.3.3.
> 
> Section 8.3.3, Policy, Security Associations, and 
> Cryptographic Key Management says "The method used by the 
> initiator to determine whether the target should be connected 
> using IPsec is regarded as an issue of IPsec policy 
> administration, and thus not defined in the iSCSI standard. 
> If an iSCSI target is discovered via a SendTargets request in 
> a *discovery* session not using IPsec, the initiator should 
> assume that it does not need IPsec to establish a [normal or 
> operational] session to that target. If an iSCSI target is 
> discovered using a discovery session that does use IPsec, the 
> initiator SHOULD use IPsec when establishing a [normal] 
> session to that target."
>
> How does the iSCSI layer know that the session is protected 
> by IPsec? This is not addressed in the iSCSI spec. In theory 
> only the management application that configured the policy 
> for this machine should care about IPsec. Why does iSCSI need 
> to know?

This can be viewed as advice to a security administrator in setting
up appropriate security policy for use of IPsec with iSCSI.  The
iSCSI spec describes a protocol that is iSCSI + IPsec - how
those two are divided into layers and coordinated is up to the
implementation.  This is related to the security gateway
discussion - recall that iSCSI RFC conformance for a two-box
solution (iSCSI box connected to an IPsec security gateway)
can only be claimed on the secure side of the gateway (so
the link from the private side of the gateway to the iSCSI
box is internal to this implementation).

> How *does* an initiator use IPsec when establishing 
> a session - either discovery or operational? If the discovery 
> session was protected by IPsec (because the policy on the 
> machine was configured to protect a certain category of 
> traffic which encompasses the discovery session) then it is 
> the responsibility of the initiator to make sure the policy 
> is such that the operational session is also protected by 
> IPsec? This seems very strange to me. It seems that the 
> initiator has to make sure the policy was defined consistently???

Somebody needs to make sure that the security policy was defined
consistently, else the use of IPsec is probably a waste of time.
If one takes the above paragraph and substitute "iSCSI + IPsec"
for "initiator", it may start to make a lot more sense.

> To summarize, my basic conceptual problem is this:
> 
> Policy is what determines the traffic that is protected by 
> IPsec. Policy is configured outside of iSCSI. Does iSCSI have 
> the responsibility to check that the policy is correct?

No, but the fact that a target was discovered on a discovery
session that used IPsec may be useful input to an IPsec subsystem
that can dynamically set/modify its security policy.  If one wanted
to be very careful about the SHOULD, and the IPsec subsystem policy
is queryable in a reasonable fashion, one could query whether the other
end of the discovery session and the target discovered are covered
by the same level of security (both IPsec or both not - the more
paranoid can make finer grain distinctions), and use that as part
of deciding whether or not to attempt to connect to the discovered
target.  There is no requirement that an iSCSI initiator MUST
connect to all discovered targets, and no limits to the information
that can be used to make that policy decision about which targets
to connect to.

> If such is not the case then I don't think iSCSI needs to even 
> be aware that some or all of its traffic is being protected 
> by IPsec. Both the iSCSI spec and the IPS-Security draft seem 
> vague in this matter.

And deliberately so, as the interaction between iSCSI and IPsec
within an implementation is an internal matter for that implementation.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------