Re: IPS: Schedule and Security Update

[Bernard Aboba <aboba@internaut.com>]

> Given the newly being-proposed rekeying solutions, how does 
> "mandatory to implement" translate in terms of the iSCSI 
> clients (initiators), where the same box might have some
> or all of the following :
> (a) a host OS with IPSec stack from vendor A
> (b) an iSCSI HBA from vendor B
> (c) an IPsec accelerator from vendor C
> 

How this will work depends on how the iSCSI HBA is configured within the
system. In some cases it may be configured as a disk driver, and therefore
will not act as an interface withint he system. In this case it  will not
be able to utilize the IPsec stack on the host, or the IPsec accelerator
hardware installed on another NIC. Such HBAs would need to have their own
IPsec and IKE implementations. 

However, it is also possible to have a NIC capable of handling TCP & IPsec
offload, as well as iSCSI. Such a NIC could utilize the IKE residing on
the host for keying, while accelerating cryptographic operations and
calculations such as the TCP checksum and iSCSI CRC. This effectively
merges categories b and c above.


> Second question : how would we run iSCSI over NAT if we are
> to use transport mode ESP, given all the problems 
> pointed out by Aboba in 
> http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-00.txt
> 

The solution is either the IPsec/NAT functionality (in the general case
where you have more than one initiator behind a NAT), or IPsec tunnel mode
(which can work if there is only one initiator behind the NAT). IPsec/NAT
compatibility is now an IPsec WG work item.