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

I have to agree with Dwight's note as well. Particularly in light of (3)
below. There is significant pile of work which we can leverage if we go
down the IPSec path but have to re-invent if we make it native to the
RDDP protocol (for example, replay attack prevention is non-trivial).


Jim




> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
Of
> Mallikarjun C.
> Sent: Thursday, June 10, 2004 5:06 PM
> To: [email protected]
> Subject: Re: [rddp] Why IPsec is needed for iSCSI but might not be
> neededfor 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
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp