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

Concur.  Perhaps we can move towards getting consensus on this point so 
that the security draft can be updated and a final review done prior to the 
upcoming IETF meeting.

Mike


At 06:14 AM 6/22/2004, Jim Pinkerton wrote:

>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
>
>_______________________________________________
>rddp mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rddp