Re: IPS: Schedule and Security Update

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

Bernard,

Ok..so whoever claims compliance with iSCSI must provide the
new rekeying method as part of their iSCSI implementation.
Its possible that more than one such IPsec implementations 
(from different vendors) could co-exist on a given host/client.

As to the 2nd question, it was raised since the new rekeying 
schemes seem to be veering towards using transport mode 
(end-to-end security preferred) rather than tunnel mode.

David's email states:
> The SRP approach
> generates the keys outside the gateway, and there's no 
> standard protocol to insert the keys into the gateway, and 
> the IKE draft wants to use transport mode ESP instead of 
> tunnel mode (gateways generally use tunnel mode).
  
So does your answer imply that the iSCSI RFC status will depend 
on the result of the IPSec-NAT work item in the IPSec WG ?

thanks
-Sandeep

Bernard Aboba wrote:
> 
> > 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.