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
----------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.