Re: Why IPsec is needed for iSCSI but might not be needed for RDDP/iWARP

Agree with Dwight's note.  Let me add one additional comment since my 
listing of iSER MUST/SHOULD requirements earlier on a related thread wrt 
long-lived STags may have led some to believe that long-lived STags are 
not currently useful.

iSER assumes/requires the use of a single valid STag across multiple 
RDMA ops during the course of one I/O.  The # of ops (launched by the 
SCSI target) on the STag is unlimited and is a function of the target 
controller memory in most cases.  A similar design principle is applied 
in the opposite direction as well.  So from iSER's perspective, 
"long-lived" is "valid beyond one I/O", mandatory one-shot STags would 
spell serious trouble for iSER (note that iSER would be accompanied by a 
mandatory-to-implement IPSec, since it's simply an iSCSI extension).
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


Barron, Dwight wrote:

> David,
> Thanks for the effort in trying number 2 below, but several private
> conversations have convinced me that mandatory IPSEC may not be so bad
> after all. There are really three facets to the argument.  
> 
> - The first is the desire to err on the conservative side when it comes
> to security. IPSEC clearly does that. The header remedies suggested in
> your item 3, along with one-shot Stags, are attempts to deal with the
> threats as we identify them, while IPSEC effectively deals with threats
> we haven't yet identified.
> - The second is the more pragmatic thought of the iSCSI scenario
> repeating itself in the market and implementations manifest without
> IPSEC enabled.  Well designed ULPs will represent the bulk of the
> traffic and won't be exposing known holes. This is not an attempt to
> encourage this behavior, but rather to make sure are not remiss in
> anticipating it.
> - Finally, the thought of eliminating long lived Stags defeats one of
> the primary benefits of RDDP, which is to publish access to memory with
> as little CPU overhead as possible. 
> 
> Regards,
> Dwight
> 
> 
>>-----Original Message-----
>>From: [email protected] [mailto:[email protected]] On 
>>Behalf Of [email protected]
>>Sent: Tuesday, June 08, 2004 11:33 PM
>>To: [email protected]
>>Cc: [email protected]
>>Subject: RE: [rddp] Why IPsec is needed for iSCSI but might 
>>not be needed for RDDP/iWARP
>>
>>
>>John,
>>
>>
>>>Perhaps you could explain again for me and perhaps some 
>>
>>other "dense" 
>>
>>>folks why IPsec would be a MUST implement (but optional to use) for 
>>>iSCSI but we are attempting to not say similar things for 
>>
>>RDMA/iWARP.
>>
>>iSCSI is responsible for its data - there is no ULP further 
>>up the stack that is in a position to handle the security 
>>issues addressed by IPsec. In contrast, I'm prepared to 
>>advocate on behalf of the WG that RDDP is a transport used by 
>>a ULP, and as such the ULP bears the primary responsibility 
>>for specifying and meeting the security requirements of the 
>>ULP's data; we'll have to see how that fares.  I'm not 
>>promising success in getting this distinction accepted, but I 
>>think there's enough technical merit that it would be 
>>irresponsible of me to dismiss this out of hand.  Depending 
>>on the ULP, IPsec could still being required - for example, 
>>iSCSI over RDDP will probably need to require IPsec for iSCSI 
>>reasons.
>>
>>
>>>I am not pushing an agenda here, I know that if we do not 
>>
>>need IPsec 
>>
>>>for RDMA/iWARP on clusters and other such reasonably secure 
>>>environments, the requirements of IPsec as a MUST implement in all 
>>>cases will NOT be appropriate.  (And often the RNIC used for such 
>>>clustering environment is on its own Subnet and not part of 
>>
>>a general 
>>
>>>communication network.) But I also feel that when RNICs are used on 
>>>less secure environments, that the environment looks 
>>
>>similar to iSCSI.  
>>
>>>Perhaps even less secure because of the RNIC holding the placement 
>>>open to a storage location were with HW iSCSI, the direct placement 
>>>and the protocol are closely combined so that Buffers are not left 
>>>open for the intruder (at least not as much).
>>
>>IETF RFCs are written for "less secure environments" like the 
>>public Internet.  If an implementer wants to take liberties 
>>with the security requirements of an RFC for use in a 
>>"reasonably secure environment", that implementer does so 
>>without the IETF's approval, and cannot point to the IETF as 
>>justification when that insecure implementation is used in a 
>>less secure environment and is compromised by a foreseeable attack.
>>
>>
>>>So based on the above thoughts, I am not sure why it was 
>>
>>required for 
>>
>>>iSCSI to use IPsec (when iSCSI HW is more secure than 
>>
>>RNICs) and not 
>>
>>>an issue for RDMA/iWARP.
>>>
>>>I get (but do not buy) the arguments that RDMA/iWARP is 
>>
>>just using the 
>>
>>>TCP/IP (or SCTP) and as such does not need any other 
>>
>>protection that 
>>
>>>is given to that, but then so was iSCSI.
>>
>>The key issue is not what's below the protocol, but what's 
>>above it - there's no ULP above iSCSI that can protect 
>>iSCSI's data (for data transfer, the next layer up is SAM-2, 
>>which is not a protocol).  A similar line of reasoning was 
>>successful in avoiding a requirement to add inband 
>>authentication to IPS's FC protocols - that is better done at 
>>the higher FC level (and in fact T11 is working on this).
>>
>>
>>>So your thoughts about why it would be needed in one and 
>>
>>not the other 
>>
>>>would be of interest.  Since I do not see that a solution for 
>>>protecting the Buffers (single shot or what ever) changes 
>>
>>the issue of 
>>
>>>why iSCSI and not RDMA/iWARP.  If we protect the Buffers, then the 
>>>results will have a similar profile to iSCSI.  So that 
>>
>>alone can not 
>>
>>>be a full solution.
>>
>>I think there will need to be a resolution of the local 
>>interface requirements from the "single shot" discussion, as 
>>they are the only mechanism available to protect a server 
>>against a malicious client that can successfully authenticate.
>>
>>
>>>If your position is that it is needed for both regardless of the 
>>>buffer protection, and you are suggesting that we might 
>>
>>come up with 
>>
>>>something that handles "authentication" at the DDP layer via 
>>>Cryptographic approaches as a possible approach to meeting 
>>
>>the need, 
>>
>>>then I can understand the logic as far as it goes.  But you 
>>
>>have not 
>>
>>>said anything about the need for Privacy (Encryption).  I 
>>
>>thought that 
>>
>>>was also an important consideration.
>>
>>Whether it's going to be needed regardless of buffer 
>>protection remains to be seen, as I don't know how strong the 
>>eventual local interface buffer protection requirements are 
>>going to be - that discussion does not appear to have concluded.
>>
>>
>>>But you have not said anything about the need
>>>for Privacy (Encryption).  I thought that was also an important
>>
>>consideration.
>>
>>Confidentiality (e.g., via encryption) is important for 
>>RDDP's placed data. It is not clear to me that the RDDP 
>>headers require confidentiality, although we may wind up with 
>>a requirement that STags be randomly generated in some 
>>fashion  (and an optional means of providing "authentication" 
>>of the RDDP headers could meet this requirement).  Again, 
>>this depends in some fashion on the buffer protection 
>>discussion outcome.
>>
>>
>>>Anyway, perhaps you could address the above, and help clarify the 
>>>issues for some of us.
>>
>>Here's an attempt to summarize my current view of this:
>>
>>(1) Something needs to be done in the area of buffer protection
>>	requirements, because:
>>	- Support for long-lived STags makes it too easy to expose
>>		received data to further modification after delivery
>>		to the ULP.
>>	- Unlike cryptographic mechanisms (including IPsec), buffer
>>		protection can protect against a malicious client that
>>		can successfully authenticate.
>>	I don't think strict single-shot (each RDDP operation always
>>	invalidates the associated STag) is necessary, but the
>>	strength of what is done here may affect what is necessary
>>	elsewhere - see (3).
>>(2) The "RDDP is a transport" approach that makes ULPs responsible
>>	for specifying security requirements for ULP data appears to
>>	be worth pursuing.  I can't promise success, but I would be
>>	remiss in not trying.  If this approach fails, "MUST implement
>>	IPsec" is the most likely result.
>>(3) If the "RDDP is a transport" approach is accepted, then RDDP is
>>	responsible for preventing misuse of the RDDP headers.  There
>>	are several possibilities here:
>>	- The buffer protection requirements from (1) could be strong
>>		enough to reduce any possible misuse to that which can
>>		be attempted against a transport like SCTP.  
>>This could be
>>		accompanied by a requirement for randomly generate STag
>>		values.
>>	- A "MUST implement" RDDP security header could be defined to
>>		block replay, connection hijacking, and other 
>>man-in-the-
>>		middle attacks.
>>	- "MUST implement IPsec" is sufficient, but probably more
>>		mechanism than is necessary in this situation.
>>
>>At the moment, I think I see WG rough consensus to try (2), 
>>although anyone is welcome to try to convince me otherwise.  
>>OTOH, the WG should consider itself instructed to do 
>>something about (1) [local interface requirements for buffer 
>>protection].  In addition to the above, another reason for 
>>this is in response to something Dwight asked earlier:
>>
>>
>>>Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, 
>>>MPI) and ad-hoc applications in determining responsibility of 
>>>implementing protocol behaviors that do not leave themselves 
>>>vulnerable? I believe it is quite innoccuous and appropriate to 
>>>require that IETF (or other) ULPs be designed in a matter that does 
>>>not notify ULP consumers of available data while an Stag is still 
>>>mapped to that data.
>>
>>The distinction that concerns me is that the defined ULPs are 
>>being specified by very talented RDDP experts.  If it takes 
>>that level of expertise to get STag invalidation right in 
>>order to avoid memory exposure security holes, RDDP will not 
>>be a mechanism that will be generally usable in a safe 
>>fashion.  In essence, I am not convinced of Dwight's 
>>"innocuous and appropriate" statement above, because I worry 
>>that meeting the requirement requires application of an 
>>unusual level of talent/expertise in the absence of doing 
>>something better in the area of "buffer protection", although 
>>I'm sure Dwight has that level of talent/expertise.
>>
>>Returning to John's final point:
>>
>>
>>>Also as a second point, does it make since to attempt to define
>>
>>environments
>>
>>>where RDMA/iWARP would be approprate without the additional 
>>>Cryptographic
>>
>>or
>>
>>>IPsec implementations (such as within clusters on their own physical
>>
>>subnets,
>>
>>>etc.), and then require IPsec in other less secure environments?
>>
>>** NO ** !!!  This was tried for one of the IPS protocols at 
>>the London IESG plenary not too long ago and it went down in 
>>flames ... 
>>
>>Thanks,
>>--David
>>----------------------------------------------------
>>David L. Black, Senior Technologist
>>EMC Corporation, 176 South St., Hopkinton, MA  01748
>>+1 (508) 293-7953             FAX: +1 (508) 293-7786
>>[email protected]        Mobile: +1 (978) 394-7754
>>----------------------------------------------------
>>
>>_______________________________________________
>>rddp mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/rddp
>>
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp