|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Security Use RequirementsHmmmm, Yes, you are right Julian. I was thinking about IPSec implementations that use only the IP address and not the TCP port as a selector. But yes, IPSec can use source & destination TCP port as a selector, in addition to IP address. If that is the case, then there can only be one iSCSI Login per IKE negotiation. Thanks! I believe that wraps up the case that IKE/IPSec and iSCSI can be completely independent of each other. If we layer iSCSI sessions on top of IKE/IPSec, there should be no loss of security. Josh > > Josh, > > The connections are disjoint allways and the IPSec context is per > connection. > There is no issue here. iSCSI does not allow 1 session to > several targets. > The target sellector is used only at connection setup and the > connections > to different targets are disjoint (even if they use the same > target port - > the initiator address+port has to be distinct in this case). > > Regards, > Julo > > Joshua Tseng <jtseng@NishanSystems.com> on 09/02/2001 21:11:54 > > Please respond to Joshua Tseng <jtseng@NishanSystems.com> > > To: Bernard Aboba <aboba@internaut.com> > cc: ips@ece.cmu.edu > Subject: RE: Security Use Requirements > > > > > > > > >I think there is a much easier way than the two methods you > > describe below. > > >If the iSCSI authentication is taking place using the SA > > negotiated by IKE, > > >then you have an implicit relationship between IKE and iSCSI > > authentication, > > >right? > > > > That would be fine if there is only one iSCSI authentication > > per IKE QM > > SA. Is that realistic? > > > > Yes, you have a point in that multiple iSCSI devices MAY > exist behind the > same IP address, and each device would be sharing the same > IKE SA if they > were talking to the same peer IP address. This would be the > case for a > storage device that had multiple WWUI's. It could also > happen if the IP > address/IKE endpoint was a security gateway, and there was a > network behind > it supporting multiple iSCSI devices. > > As I mentioned before, physical security is needed to handle > each of these > cases, to ensure a hostile entity can't use the same IP > address that was > authenticated by IKE. In the former case, physical security > is pretty much > assured, since both IKE/IPSec and the > multiple iSCSI WWUI's share not only the same physical box, > but also the > same TCP stack. In the latter, yes of course additional > measures MUST be > taken to ensure there are no hostile entities living behind a security > gateway. > > Sure, an implementation geared to the paranoid user could do what you > prescribed in your previous message (but your suggestions > only make sense > for a native iSCSI device). But I don't think these measures > should be a > MUST. Physical security is a non-negotiable requirement in > both cases, and > especially in the standalone security gateway scenario, this > is a quite > well > understood requirement in the security architecture document > RFC 2401 when > it describes tunnel mode. > > Josh > > >
Home Last updated: Tue Sep 04 01:05:32 2001 6315 messages in chronological order |