Re: IPS: Schedule and Security Update
Bernard Aboba <aboba@internaut.com> Wed, 15 August 2001 18:33 UTC
Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28686 for <ips-archive@odin.ietf.org>; Wed, 15 Aug 2001 14:33:28 -0400 (EDT)
Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f7FHRGM04599 for ips-outgoing; Wed, 15 Aug 2001 13:27:16 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from internaut.com ([64.38.134.99]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f7FHREe04594 for <ips@ece.cmu.edu>; Wed, 15 Aug 2001 13:27:14 -0400 (EDT)
Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA06622; Wed, 15 Aug 2001 10:18:44 -0700 (PDT) (envelope-from aboba@internaut.com)
Date: Wed, 15 Aug 2001 10:18:44 -0700
From: Bernard Aboba <aboba@internaut.com>
To: Sandeep Joshi <sandeepj@research.bell-labs.com>
cc: Black_David@emc.com, ips@ece.cmu.edu
Subject: Re: IPS: Schedule and Security Update
In-Reply-To: <3B7A9372.388A60B1@research.bell-labs.com>
Message-ID: <Pine.BSF.4.21.0108151011280.6615-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
> 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.
- Re: IPS: Schedule and Security Update Bernard Aboba
- Re: IPS: Schedule and Security Update Sandeep Joshi
- Re: IPS: Schedule and Security Update Sandeep Joshi
- Re: IPS: Schedule and Security Update Bernard Aboba
- IPS: Schedule and Security Update Black_David