ISCSI why an SC and a VMK ?

[Spiker]

Hi All

I know that ESX needs 2 connections for ISCSI if using authentication - 1 for the transfer (VMK) and 1 for the authentication (SC)

Talking to a colleague today we were discussing how once authenticated on 1 ip address ( the SC) this must be then passed over to the VMK on a DIFFERENT ip address

Seemed to us a little odd - surely to keep things secure this should be being done on an end to end communication that does not require a change of ip.

Aside from the fact that the SC is needed for chap, I understand that! , BUT what was the logic behind this ?

Anyone know ?

[virtualdud3]

The reason is that the iSCSI daemon (vmkiscsid) runs in the service console. This iscsi daemon is what initiates the session, and what provides the login and authentication.

Then, once the data passes directly to the VMkernel.

So, the service console and VMkernel NICs both need to talk to the iSCSI storage.

[Spiker]

Thanks for the reply

I am already fully aware of the relationship of both the SC and vmk during the ISCSI process as I said in my post - the daemon runs in the SC - SURE where else can it run !

That was not my question - but I appreciate you are trying to help so thankyou

My question relates to the fact that the destination seems perfectly happy to continue the ISCSI transfer from a different source ip to the one that was used to make the initiall connection and authentication - it just seems to add an extra attack surface to the process and potentially weaken the security.

Follow me ?

[virtualdud3]

Ahhh...

Well, I imagine that having the iSCSI traffic proceed through the service console interface would not only cause a LOT of overhead.

Regarding attack surface, keep in mind that,when implemented properly, the iSCSI network should be on its own PHYSICAL network. Or, at the very least, on its own VLAN.

If only a single "connection" were used (the service console), then anyone with network connectivity to the service console network/subnet would also have network connectivity to the iSCSI data. Of course, if you are really concerned about security you should also have the service console on its own network/VLAN as well.

My guess is that the iSCSI initiator (which as you likely know is based on the Cisco iSCSI Initiator Command Reference) was easier to port to the RHEL 3.-based service console as opposed to the VMkernel. Plus, leaving the session initiation/authentication/login to the service console allows the VMkernel to stay as small/lean as possible.

Maybe someone else has something to add...

[Spiker]

Thanks

I dont think that my question is nailed yet

Thanks again for your thoughts - I appreciate them - you've given me something else to ponder

Cheers

[Chris_S_UK]

But presumably your iSCSI target, whatever device it is, has to specifically configured with the IPs of your SC/VMK interfaces, thereby reducing the security implication?

Chris

[Spiker]

HI Chris

It is my understanding that the ISCSI target be aware of the VMK port as that is the source ip

This is exactly my point - it authenticates using 1 ip and then offloads the transfer to another

why is it done this way ( apart from what we have already discussed) - just seems odd