Authors of RDMAP, DDP, and MPA,
Looks like the IDs need to be updated to change the informative reference to the RDDP security draft to be normative.
Jim
_______________________________________________ rddp mailing list rddp <at> ietf.org https://www1.ietf.org/mailman/listinfo/rddp
Sorry for the late reply. Comments in line. Really appreciate the thorough review. To get this out quickly, a few questions have TBD answers (only 4).
Jim
From: Talpey, Thomas
[mailto:Thomas.Talpey <at> netapp.com]
Sent: Monday, March 01, 2004 8:54
PM
To: Jim Pinkerton; rddp <at> ietf.org
Subject: Comments on
draft-ietf-rddp-security-01
I have
reviewed the recent RDDP Security draft
(http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-01.txt)
and have some comments in advance
of tomorrow's
working group meeting.
I'd like
to open by complimenting the authors on an excellent
second revision. This is a
difficult document, but an important
one.
I don't
have many high-level comments. The draft seems
well put-together.
One style
thing to mention though - there are many, many
references to "later" or
other sections, especially in the earlier
ones. I suggest direct section
references.
[<jim>] The current draft has one reference to “later”. This is now fixed.
Apostophes
and em-dashes seem to have a different ascii
encoding, which appear strangely
with certain text tools.
Suggest conventional ascii.
[<jim>] Ouch. Fixed 4 quotes, 10 dashes.
How
specifically do we define "Partial Mutual Trust", which
appears relatively early? One way
the reader may take it,
is as an authentication guarantee,
for both the local application
and remote peer. But who decides
"partial", for instance? Is
the motivation primarily to clarify
the use of shared resources,
such as the SRQ?
[<jim>] The definition is in the introduction in the -02 version of the draft. I have refined the introductory text a bit in the upcoming -03 draft though. Main issue is the intro implies that anytime you share resources you better only do it if there is Partial Mutual Trust. That is not true – many types of resources can be shared safely, and are fully examined in the existing text. However, there are some conditions where sharing of a specific type of resource has unmitigated attacks, thus the only time the specific resource should be shared is if a condition of Partial Mutual Trust exists.
In the
introduction, it seems critical to describe the scope of
possible damage if the trust is
violated. I believe it is very
different depending on the resource
which is the subject of
the trust. System-level damage
should be described differently
from damage which merely 
damages the application. This is
not a very specific recommendation,
I know.
I think
there are differences between the trust model as described
here, and a
privileged/nonprivileged application (at the end of
the Introduction). It might be
worthwhile to bring these out.
For example, the trust model seems
primarily oriented at wire-based
attacks, while the
privileged/nonprivileged application is a local
matter? What interaction do these
have?
[<jim>] I’d appreciate specific recommendations on what to change here.
Sect 4
pargraph 1 last sentence - "should be preserved when
under attack", just delete
"when under attack" and say "should
be preserved". Maybe even
"must".
[<jim>] done.
4.2.1
refers to a FIFO list of buffers - maybe not FIFO in the
case of SRQs. Perhaps just
"list of buffers" here - but also see
comment on 4.2.10.
[<jim>] Even a Shared-RQ is first-in, first-out – i.e. they are taken off of the queue in the order they were put on. As to when the actual completion occurs is an entirely separate issue. That said, I don’t think the FIFO statement actually adds anything, so will remove it.
4.2.2 buffer exposed to "the Internet"? This is vague.
[<jim>] Replaced with “network”.
4.2.2 a
general comment - this refers to the RI, while I think
it means the Privileged Resource
Manager? Overall, I think the
"RI" term is loosely
used, for example it's defined only in Figure 1,
and about 2/3 of the time seems to
mean the PRM instead of
the RNIC's programmatic interface.
In fact, in 7.5.5 it's used to
mean "Remote
Invalidation"!
[<jim>] Good catch. I had abreviated Remote Invalidate to make it fit in the table at the end of the document, but that table is gone, so it is no longer an issue. For clarity, I have removed all referenced to “RI” and instead used either RNIC Interface, RNIC (some of the references were not to an interface, but to the entire RNIC), or Remote Invalidate .
4.2.3
describes page translation tables. Is it worth bringing out
the possibility they are
multi-level and therefore possibly shared?
[<jim>] I’d prefer not. There are a ton of different implementation techniques within the RNIC. Going to the gory details can be endless, and I don’t think terribly useful. The document already assumes the Page Translation Tables can be shared, so I have added a note in this section to that effect. Section 4.2.9 states:
“The exact resource allocation algorithm for the Page Translation Table is outside the scope of this specification. It may be allocated for a specific Data Buffer, or be allocated as a pooled resource to be consumed by potentially multiple Data Buffers, or be managed in some other way. This paper attempts to abstract implementation dependent issues, and focus on higher level security issues such as resource starvation and sharing of resources between Streams.”
4.2.4 I
suggest merging Mike Krause's comment/observation that
the STag does not in itself provide
protection, and in fact should
provide efficiency. This is
important to understanding that protection
comes from other facilities.
[<jim>] I’d appreciate specific text suggestions here.
4.2.5
mention that Completion Queues are of bounded size (like
4.2.6) and so the size can be
attacked. CQ attack is much more
likely than AEQ attack, in fact.
[<jim>] So? Likely or not, they are attackable. Is there a suggested text change?
4.2.8 clarify the RRQ is inbound.
[<jim>] ??? What is the RRQ?
After (or
in) 4.2.8, should add the outbound RRQ as well. It's not
easily attacked, but this queue has
interesting flow control interactions
with sends. If the queue overflows,
a head-of-line blocking behavior
could be encountered, which is very
different from "normal" operation.
[<jim>] ?? Again, what is the RRQ? Are you talking about the Send Queue? If so, the discussion you outlined above has no security issues, so why go into it? This isn’t a document focused on the application developer...
4.2.8.2
it's very important to mention that RDMA Read exposes a
buffer for RDMA Write as well. And
describe the possible protection.
[<jim>] <TBD>
4.2.8.2
last paragraph, has a vague use of the phrase "data transmission
or reception". For example,
RDMA Writes don't yield a completion at
the data sink, counter to the
sentence.
[<jim>] <TBD>
4.2.9
refers to an STag which has only local scope that "may not
be visible from the wire". (pp
starting "The next issue"). => This "may"
must be a "must" in order
for the statement to be true! In fact, if it's
a "may" then a security
hole is open.
[<jim>] I’ve rewritten the sentence to be clearer.
“The next issue is how an STag name is associated with a Data Buffer. For the case of an Untagged Data Buffer, there is no wire visible mapping between an STag and the Data Buffer. Note that there may, in fact, be an STag which represents the buffer. However, because the STag by definition is not visible on the wire, this is a local host specific issue which should be analyzed in the context of local host implementation specific security analysis, and thus is outside the scope of this paper.”
4.2.10
"send" and "receive" operations - these do not mean
"Send" so
are somewhat confusing.
[<jim>] To me this is a knit. I’ve finessed the text a little to try to make things clearer though. We were trying to avoid the keywords Send Queue and Receive Queue, since they are reserved words in other specifications. I’ve bailed on not using Receive Queue and Send Queue though - I think it makes things a bit clearer (also defined it in the appropriate place).
4.2.10 -
FIFO order? Perhaps "sequential", in the face of SRQ. The
paragraph goes on to describe this,
but not very clearly. I suggest
not using "FIFO" in any
case.
[<jim>] Done.
Section 5
first paragraph describes when/if the "Local peer" is untrusted.
I noticed here that "local
peer" isn't defined, and in fact I think it means
the local application or ULP? I
think it would be worth a pass through the
document to be sure all use of the
term is consistent. And of course,
defining the term.
[<jim>] TBD
Section 6
- it's not clear to me what's an attacker with send-only
capabilities?
[<jim>] In re-reading this, it really doesn’t convey the intent at all. Here’s the proposed re-wording:
“An attacker’s capabilities delimit the types of attacks that attacker is able to launch. RDMAP and DDP require that the initial LLP Stream (and connection) be set up prior to transferring RDMAP/DDP Messages. Attackers with send only capabilities must first guess the current LLP Stream parameters before they can attack RNIC resources (e.g. TCP sequence number). Attackers with both send and receive capabilities have presumably setup a valid LLP Stream, and thus have a wider ability to attack RNIC resources.”
Is this any clearer? If not, can you propose something?
Section 7
paragraph 2 - I disagree that connection setup in stream mode
has no new attacks. This is where
ULPs may exchange information. If
the information is bad, significant
resource issues can clearly result. It's
true however that such exchanges
are outside the scope of the document,
I just think the document should
not state that there are no new attacks.
[<jim>] I added this point to the paragraph.
7.1.1
should perhaps introduce the PD more directly. The PD is described
in draft-hilland which is not
normative.
[<jim>] Draft-hilland isn’t even informative – it’s not a work group draft. Thus it seems inappropriate to bring it into this context. We’ve intentionally tried to abstract above a verbs implementation to not bog us down on whether the security analysis implies that we’ve also signed up for verbs being the “one true way”. That said, it was the intent that the security analysis completely covers all wire visible security issues embodied in verbs.
7.1.1
goes on to say "should" associate a QP to unique PDs, or shared,
I find this discussion to not be
clear. Also I'd suggest incorporating Caitlin's
"remote PD" concept,
which helps to define the PD and STag scope to a
remote peer.
[<jim>] Sorry, I don’t understand your issue. To me the text is clear. Please suggest specific text.
7.1.2
mentions "allocating STags in an unpredictable way". I want to point
out that it is also possible for
the application to "advertise" STags in such
a way, if it manages its own pool.
In fact, this can be much more efficient
since STag allocation is not
appropriate for the performance path.
[<jim>] Changed text to say “Allocating and/or advertising STags numbers in an unpredictable way.”
7.2.3
MITM attack discussion first says "the only countermeasure" (pp 1)
then says "the best
countermeasure" (pp 2). Eh?
[<jim>] I don’t see the the issue. Pp1 states two ways. Pp2 states the best way is the first way (i.e. IPSec, rather then local link security).
I think
the summary of 7.2.3 is that MITM attacks should be protected in
the usual way by LLP facilities,
and not in DDP/RDMAP. However it may be
worth mentioning that the MPA layer
injects a CRC, making this nontrivial
(though no more secure).
[<jim>] I don’t understand the point.
In 7.4.2,
to me, the most usual exposure of a buffer for RDMA Read is to
provide access to NON-stale data -
i.e. an actual transfer such as client
"writing" data by
advertising it for pull. Thus the zeroing memory comment
only applies in certain (rare, IMO)
cases. The text only generally mentions
this by saying "combination of
read and write", and could be clearer. Maybe
giving a specific example?
[<jim>]I don’t understand the ambiguity. I walk through a specific example (i.e. “the Remote Peer may be able to examine the contents of the buffer before they are initialized with the correct data.”).
7.4.5
great place to mention the (more difficult) flip side - RDMA Write into
RDMA Read buffer. This is a
definite issue, see my 4.2.8.2 comment.
[<jim>] TBD
7.4.6
suggest using the term "aliasing" to help describe the multiple STag
situation.
[<jim>] I like it.
7.4.9
"eaves dropping" is one word. Worth referring to MITM discussion here
as well?
[<jim>] done.
7.5.1
define "scarce"? Why wouldn't all resources be under the control of
the PRM?
[<jim>] This seems like a knit. The dictionary definition is used. I did change the text to say “... scarce (i.e. bounded)...”. Does this scratch your itch?
7.5.2.1
mention that if the stream is torn down, then this additionally has
the benefit that RNIC resources are
released. For example, it cuts off a
misbehaving peer drawing from a
Shared RQ.
[<jim>] done.
7.5.2.3 after
"The local Peer can protect itself", first bullet mentions resize.
Really doesn't it just mean
"size"? Also give a hint that safe size is >= sum
of all queues, etc. as described
immediately following.
[<jim>] I meant resize. I’ve reworded it to make this more clear.
“Size the CQ to the appropriate level, as specified below (note that if the CQ currently exists, and it needs to be resized, resizing the CQ can fail, so the CQ resize should be done before sizing the Send Queue and Receive Queue on the Stream), OR”
7.5.2.3
some of the math examples are confusing - "S-RQ" looks like a minus
sign but isn't? Also
MaxPosted*OnEach*Q is not clear.
[<jim>] Changed name of “S-RQ” to “SRQ”. Added formal definitions of each variable.
7.5.2.4
describes the situation "If the issue is a bug in the Remote Peer's
implementation, and not a malicious
attack..." - so tell me, how does the
local peer know?
[<jim>] Hopefully you’re joking (??) Each of the attacks has a specific counter measure identified, with appropriate normative statements. So the local peer can differentiate, and it doesn’t matter.
7.5.5 has
a funny title: "RI an STag Shared on Multiple Streams". Here
"RI"
has a very different meaning -
Remote Invalidate. Even when spelled out,
the title is awkward.
[<jim>] Done.
8.1 it's
not clear how to protect against replay attacks at the RDDP "session"
level. (BTW, session is an
undefined term.) Is reply protection purely a
function of transport? This doesn't
sound right. By the way, this is only
the second mention of
"replay" in the draft.
[<jim>] There are four references to replay in the doc. Replay is a generic term, but specifically in this draft it is packet sequencing replay. Within IPSec, there are specific features defined to detect replays.
On session, I agree that it is confusing. I’ve swept the document to replace “session” with “Stream” where appropriate. In some cases (e.g. IPSec session keys), session is still appropriate. Also when stated “Stream and/or session level authentication”. I think with reduced scope of the term “session” we don’t have to define it.
I note
that 8.1.3 mentions NFS and its provision of security - presumably
referring to RPC's GSSAPI support.
This is a good topic to discuss in the
NFSv4 working group, but I'm not
sure what needs to be mentioned here.
What do the authors have in mind?
[<jim>] We went over this during today’s meeting, so I won’t go into this here.
I note
that section 8.2 is entitled "Recommendations" and describes itself
as being geared toward iSCSI
requirements. But it has many MUSTs and
the sections seems somewhat more
relevant for an iSCSI over RDMA
document, or perhaps a specific
RDDP/IPSec layering, rather than a
general RDMA one. Is a second document
appropriate?
[<jim>] Section 8.2 is completely rewritten to now just cross reference the IP Storage security draft.
I have not yet reviewed the appendices.
Again, good job!
Tom.
_______________________________________________ rddp mailing list rddp <at> ietf.org https://www1.ietf.org/mailman/listinfo/rddp
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : DDP/RDMAP Security Author(s) : J. Pinkerton, et al. Filename : draft-ietf-rddp-security-03.txt,.pdf Pages : 52 Date : 2004-8-9 This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into spoofing, tampering, information disclosure, denial of service, and elevation of privilege. Finally, the document concludes with a summary of security services for RDDP, such as IPSec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-security-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv <at> ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-security-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
_______________________________________________ rddp mailing list rddp <at> ietf.org https://www1.ietf.org/mailman/listinfo/rddp
This draft is intended to resolve all of the outstanding issues that were identified either on the reflector or at the IETF work group meeting last week, except: - The TBDs I left in the reply to Tom Talpey's feedback (4 of 'em) - Cleanup of the appendix focused on client/server implementations and how the normative statements in the documents are interpreted in a client/server environment. Specifically the text changed the document to be standards track, and changes what used to be RECOMMENDations (i.e. SHOULDs) into MUST, SHOULD, MAY, recommended (i.e. lower case recommends that are not implementation requirements), etc. As we discussed in the work group meeting, I'll send out a note in about a week to try to work out a conference call time that anyone interested can attend to specifically review the MUST/SHOULD/MAY statements, in the hopes that we can more quickly converge on consensus this way. Note that as David Black mentioned at the workgroup meeting, not being able to attend the meeting in no way restricts your ability to give feedback either directly to the authors or to this reflector. To aid in review, I've got the original MS word document with changebars turned on. Unfortunately I am not able to output a pdf document and preserve the changebars though. If you would like the changebar version, please send me mail directly. Jim Pinkerton > -----Original Message----- > From: rddp-bounces <at> ietf.org [mailto:rddp-bounces <at> ietf.org] On Behalf Of > Internet-Drafts <at> ietf.org > Sent: Monday, August 09, 2004 12:27 PM > To: i-d-announce <at> ietf.org > Cc: rddp <at> ietf.org > Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Remote Direct Data Placement Working > Group of the IETF. > > Title : DDP/RDMAP Security > Author(s) : J. Pinkerton, et al. > Filename : draft-ietf-rddp-security-03.txt,.pdf > Pages : 52 > Date : 2004-8-9 > > This document analyzes security issues around implementation and > use of the Direct Data Placement Protocol(DDP) and Remote Direct > Memory Access Protocol (RDMAP). It first defines an architectural > model for an RDMA Network Interface Card (RNIC), which can > implement DDP or RDMAP and DDP. The document reviews various > attacks against the resources defined in the architectural model > and the countermeasures that can be used to protect the system. > Attacks are grouped into spoofing, tampering, information > disclosure, denial of service, and elevation of privilege. > Finally, the document concludes with a summary of security > services for RDDP, such as IPSec. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-rddp-security-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv <at> ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-rddp-security-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft.
Send corrections to me, optionally cc: the list. Except for the two major security issues: - #1 IPsec-related requirements - #2 Discouraging use of network-writable data please post objections to any decisions made in the meeting to the list. I plan to start separate email threads on those two issues due to their importance. Absence of objection to other decisions will be taken as a sign of approval of those decisions. Thanks, --David RDDP WG Minutes - DRAFT 60th IETF Meeting, San Diego Wednesday, August 4, 0900-1130 ------------------------------ Many thanks to Hemal Shah for taking the raw minutes. Letter in square brackets (e.g., [A]) is first letter in file name containing slides for that portion of the meeting. -- Agenda Bashing and Administrivia - David Black, WG Chair [A] - Blue Sheets - NOTE WELL The agenda was bashed prior to the meeting to include the MPA CRC issue that came up in the IPS meeting on Monday. -- Status of drafts - David Black, WG Chair [no slides] Problem statement draft needs some minor revisions, and then should be ready for IESG approval. Architecture draft is held up by a security issue related to determining the mandatory to implement security mechanism(s). RDMAP draft was sent in for posting but didn't make it. Both it and the DDP draft will have boilerplate and security updates applied and be resubmitted. Applicability statement and SCTP mapping are missing from the Internet-Draft servers. They will be resubmitted with updated boilerplate. Broadcom needs to update their IPR notice to comply with RFC 3668 soon in order to avoid it causing delays. MPA draft status (informational vs. standards track) will be determined by WG chair in consultation with ADs after WG last call. WG chair understands that WG would prefer it to be standards track. -- MPA CRC issue (David Black, WG Chair, slide extracted from Mike Ko's iSER presentation to the IPS WG on Monday) [B] iSER is a protocol that uses MPA (RDDP mapping to TCP) for iSCSI. The iSER draft authors have found MPA's current CRC requirements text to be insufficient for iSER usage of MPA, and hence currently impose stronger requirements. iSER requires that RDDP provide at least CRC32-class integrity, but the current MPA draft text allows CRC32C to be disabled in situations where that would not be the result. The RDDP WG's rough consensus has been that ULPs can assume at least CRC-class integrity from RDDP. Hence the sense of the room is that the MPA draft text needs to be tightened to do this and remove the need for iSER to add requirements to MPA. ACTION: MPA draft authors to propose specific new text on reflector. -- Security Draft (draft-ietf-rddp-security-02.txt) - Jim Pinkerton [C] Two Important issues: - Mandatory to implement security requirements. - How to strongly discourage use of data while write-accessible from network. -02 draft is not significantly different from -01, mostly a boilerplate update There are 34 RECOMMENDED clauses and 8 MUSTs in the current draft split among RNIC protocol implementation and application implementation requirements. It's not clear that the "RECOMMENDED"s and "MUST"s are all correct. Jim will post a new security draft to the reflector and schedule a conference call to provide a recommendation to the WG on which requirement level should be used for which clause. See RFC 2119 for the definitions of MUST and RECOMMENDED. SHOULD is a synonym for RECOMMENDED, but lower-case should has it's ordinary meaning which is weaker than an RFC 2119 SHOULD. --> Important Security Issue #1: IPsec - required or optional? A lengthy discussion ensued on this topic. Important points: - For optional: IPsec can involve significant hardware complexity. - For mandatory: Some attacks can only be mitigated by IPsec (WG has little interest in designing its own security mechanism), and they will be of concern in some deployment environments. IP Storage (RFC 3723) enables IPsec to be implemented separately from the protected protocol - when this is done correctly for end-to-end security, the resulting architecture is "bump in the stack (BITS)" as opposed to "bump in the wire (BITW)" - see RFC 2401 for more on this. The security draft needs to be clear that the security requirements are intended to enable end-to-end security. Making IPsec mandatory does *not* force it to be implemented in hardware. IETF RFCs impose functional requirements for security, not performance, so a potentially slow software implementation can be used to meet those requirements. Since iSER is using RDDP with iSCSI, reusing the IP Storage IPsec requirements (RFC 3723) for iSCSI will avoid adding complexity in that situation, as the iSCSI requirements will not be removed by iSER. The data rates expected for some uses of RDDP require that a key exchange protocol be mandated (i.e., only manual keying is unacceptable). The issue at hand has two parts: (1) Should IPsec be required or optional? Sense of room: it should be required, but without any restrictions on how it is implemented. (2) Should the IPsec requirements be based on the existing RFCs (e.g., use IKEv1) or the new drafts coming from the ipsec WG (e.g., use IKEv2). Sense of room: Base them on the existing RFCs by referencing the IP Storage IPsec requirements in RFC 3723. Two UPDATEs from after the meeting: - Making IPsec required clears the IESG security issue blocking the rddp architecture draft. - Based on the saag meeting on Thursday, the IETF Security Area has no problem with mandating use of IKEv1 in a new RFC, even though IKEv2 will be an RFC in the near future. --> Additional issues from Jim's slides. - Abortive termination on error Current protocol drafts drop connection if bad STag is received Proposal: No change (ok with room) - Should STags be random? Small security advantage to doing so, IPsec is the real solution. HW implementations prefer to control tags for linear lookup Recommendation: No change (ok with room). UPDATE: Also ok with Security AD whose DISCUSS on this issue is blocking the rddp architecture draft at the IESG - MUST implement IPsec is more than sufficient. - Shared Receive Queue attacks This issue involved some detailed text editing - do it on the reflector. --> Important Security Issue #2: How to strongly discourage allowing network write access to data in use by a ULP or application. This includes slides from John Carrier [D] (many thanks to John for preparing these detailed slides on *very* short notice). This issue has misleadingly been called "One-shot STags". Issue is around having data sink buffer contents getting changed before the buffer is invalidated. If protocol or application logic depends on the contents not changing, this may open up attacks on the protocol. IPsec doesn't help because one has to protect against a less than fully trusted peer who can authenticate and use IPsec if required. One-shot STags are a "heavy hammer" approach to this problem - completion of an RDMA write always invalidates the associated STag. The problem is that this is too heavy - both NFS/RDMA and iSER need multi-shot STags for resource management and optimization reasons, and cannot live with a restriction that all STags be single-shot. One consequence is that the receiver MUST check for STag invalidation before using the data, even when Send with Invalidate was used (have to make sure right STag was invalidated). There are a couple of additional possibilities: a) Receive and Invalidate. If one knows which untagged receive buffer will be used for the ULP operation that signals completion of the data transfer, one can pre-mark that receive buffer to force invalidation of the STag when the transfer completes. Problem: This won't work when data transfers can complete in non-deterministic order, because the exact sequence of completion has to be known in advance. Both iSCSI and NFS exhibit this non-deterministic order behavior. Sense of room: Not worth pursuing further due to limited applicability. b) RDMA Write & Invalidate: Define an RDMA Write primitive that also invalidates the STag that it uses. Having every RDMA Write invalidate the associated STag is an implementation of One-shot STags, and hence won't work. Defining RDMA Writes that do and don't invalidate the appropriate STag still requires a receiver check for invalidation and hence provides no leverage. Sense of room: Not worth pursuing. Conclusion of issue: Need to make sure security and protocol drafts contain stiff warnings about the need for any ULP using RDDP to invalidate receive STags prior to using data they cover. Architecture draft will incorporate this warning also. Need to specifically call attention to situations in which protocol logic path depends on contents of received buffer. --> Things to be done to security draft: - Guidance for application protocols like NFS which implement security, including informative reference to channel bindings draft (Nicolas Williams to provide this ref, David Black to send him email reminding him to provide it). - Finish summary table of attacks/trust models - Finish Tom Talpey's comments posted to the reflector -- Next steps - Revise security draft. - Add appropriate security requirements in DDP, RDMAP, and architecture draft. - Good chance to move DDP, RDMAP, and security drafts to WG Last Call by mid-September. - WG Last Call on transport mappings drafts (MPA, SCTP mapping) and applicability statement will be later.
>From the San Diego Workgroup minutes: iSER is a protocol that uses MPA (RDDP mapping to TCP) for iSCSI. The iSER draft authors have found MPA's current CRC requirements text to be insufficient for iSER usage of MPA, and hence currently impose stronger requirements. iSER requires that RDDP provide at least CRC32-class integrity, but the current MPA draft text allows CRC32C to be disabled in situations where that would not be the result. The RDDP WG's rough consensus has been that ULPs can assume at least CRC-class integrity from RDDP. Hence the sense of the room is that the MPA draft text needs to be tightened to do this and remove the need for iSER to add requirements to MPA. ACTION: MPA draft authors to propose specific new text on reflector. Current text (section 1.1): "MPA includes a CRC check to increase the ULPDU data integrity to the level provided by other modern protocols, such as SCTP [RFC2960]. This check may be disabled with agreement by providers and administrators at both ends of a connection. This disabling of CRCs should only be done when it is clear that the connection through the network has data integrity at least as good as a CRC (for example when IPSEC is implemented end to end). DDP's ULP expects this level of data integrity and therefore the ULP SHOULD NOT have to provide its own duplicate data integrity and error recovery for lost data." Also section 5.2: "An MPA implementation MUST implement CRC support and MUST either: (1) always use CRCs or (2) only negotiate the non-use of CRC on the explicit request of the system administrator, via an interface not defined in this spec. The default configuration for a connection MUST be to use CRCs. (3) The MPA provider at either peer MAY ignore its administrator's request that CRCs not be used. The decision for one host to request CRC suppression MAY be made on an administrative basis for any path that provides equivalent protection from undetected errors as an end-to-end CRC32c." Section 5.2 appears to be sufficiently strong to deal with the iSER issue. The proposal is to modify the section 1.1 text as follows: "MPA includes a CRC check to increase the ULPDU data integrity to the level provided by other modern protocols, such as SCTP [RFC2960]. It is possible to disable this CRC check, however CRCs MUST be enabled unless it is clear that the end to end connection through the network has data integrity at least as good as a MPA with CRC enabled (for example when IPSEC is implemented end to end). DDP's ULP expects this level of data integrity and therefore the ULP does not have to provide its own duplicate data integrity and error recovery for lost data." Paul R. Culley HP Fellow 281-514-5543
> iSER is a protocol that uses MPA (RDDP mapping to TCP) for iSCSI. > The iSER draft authors have found MPA's current CRC requirements text > to be insufficient for iSER usage of MPA, and hence currently impose > stronger requirements. iSER requires that RDDP provide at least > CRC32-class integrity, but the current MPA draft text allows CRC32C > to be disabled in situations where that would not be the result. > > The RDDP WG's rough consensus has been that ULPs can assume at least > CRC-class integrity from RDDP. Hence the sense of the room is that the > MPA draft text needs to be tightened to do this and remove the need > for iSER to add requirements to MPA. This smells like a red herring. CRC32 is not a class of integrity, it is a mechanism for providing integrity. Quantifying integrity should be done with metrics like mean time between undetected failure or mean GB of data transferred between undetected failure, not bits of CRC. RDDP should provide the ULP with a guaranteed level of integrity, not guarantee a mechanism for providing it. The case that iSER requires a higher level of reliability that iSCSI or NFS seems like a difficult case to make (but since I wasn't at the meeting, perhaps it was made effectively). iSCSI and NFS do not require mandatory CRC. I suspect that the real reason is that all planned implementations provide CRC for free, and options are a pain. However this it not a bad argument, so I am not troubled by the conclusion. > --> Important Security Issue #1: IPsec - required or optional? > > A lengthy discussion ensued on this topic. Important points: > - For optional: IPsec can involve significant hardware complexity. > - For mandatory: Some attacks can only be mitigated by IPsec (WG has > little interest in designing its own security mechanism), and > they will be of concern in some deployment environments. OK, I'll be politically incorrect. Running RDMA over IPsec is sufficiently stupid that NOBODY will implement IPsec regardless of how mandatory it is. Just make it mandatory and quit worrying.
| Jim.Williams <at> Emulex.Com
Sent by: rddp-bounces <at> ietf.org 11/08/04 17:48 |
|
_______________________________________________ rddp mailing list rddp <at> ietf.org https://www1.ietf.org/mailman/listinfo/rddp
-----Original Message-----
From: rddp-bounces <at> ietf.org [mailto:rddp-bounces <at> ietf.org]On Behalf Of Julian Satran
Sent: Thursday, August 12, 2004 6:58 AM
To: Jim.Williams <at> Emulex.Com
Cc: rddp <at> ietf.org
Subject: RE: [rddp] DRAFT San Diego minutes
The reasoning behind this requirement was that an I_T pair may want to negotiate CRC (or equivalent) as an e2e guarantee but have no way of doing that if they use iSER.
Does it still look (or smell) as a red herring?
Julo
Jim.Williams <at> Emulex.Com
Sent by: rddp-bounces <at> ietf.org11/08/04 17:48
<rddp <at> ietf.org> RE: [rddp] DRAFT San Diego minutes
> iSER is a protocol that uses MPA (RDDP mapping to TCP) for iSCSI.
> The iSER draft authors have found MPA's current CRC requirements text
> to be insufficient for iSER usage of MPA, and hence currently impose
> stronger requirements. iSER requires that RDDP provide at least
> CRC32-class integrity, but the current MPA draft text allows CRC32C
> to be disabled in situations where that would not be the result.
>
> The RDDP WG's rough consensus has been that ULPs can assume at least
> CRC-class integrity from RDDP. Hence the sense of the room is that the
> MPA draft text needs to be tightened to do this and remove the need
> for iSER to add requirements to MPA.
This smells like a red herring. CRC32 is not a class of integrity,
it is a mechanism for providing integrity. Quantifying integrity
should be done with metrics like mean time between undetected
failure or mean GB of data transferred between undetected failure,
not bits of CRC. RDDP should provide the ULP with a guaranteed
level of integrity, not guarantee a mechanism for providing it.
The case that iSER requires a higher level of reliability that
iSCSI or NFS seems like a difficult case to make (but since I
wasn't at the meeting, perhaps it was made effectively). iSCSI
and NFS do not require mandatory CRC.
I suspect that the real reason is that all planned implementations
provide CRC for free, and options are a pain. However this it
not a bad argument, so I am not troubled by the conclusion.
> --> Important Security Issue #1: IPsec - required or optional?
>
> A lengthy discussion ensued on this topic. Important points:
> - For optional: IPsec can involve significant hardware complexity.
> - For mandatory: Some attacks can only be mitigated by IPsec (WG has
> little interest in designing its own security mechanism), and
> they will be of concern in some deployment environments.
OK, I'll be politically incorrect. Running RDMA over IPsec is
sufficiently stupid that NOBODY will implement IPsec regardless of
how mandatory it is. Just make it mandatory and quit worrying.
_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
_______________________________________________ rddp mailing list rddp <at> ietf.org https://www1.ietf.org/mailman/listinfo/rddp
Renaming the subject line.
To me Somesh’s point devolves into the classic argument of who owns this issue – the application or the administrator? Personally, I don’t see why we should decide here. Saying the administrator has the unique ability to dictate levels of error detection robustness when we have a diverse set of protocols running on the system (SCTP, TCP, UDP, RDMAP, etc) seems odd.
Another way of thinking about it is some applications are so paranoid about error detection that they embed a data check in their data – and take a perf hit because of it. Some applications that sit on top of storage embed this all the way to the disk. They are perfectly fine with trading off performance for the additional level of error detection. To me this is a perfectly reasonable level of flexibility, which the administrator doesn’t necessarily want to get in the middle of.
Back to Jim William’s points. I think Jim was primarily making two points:
1) How to state the requirement? In David’s original email, he stated “at least
CRC32-class integrity” be used. And in Jim Williams email, he stated “CRC32 is not a class of integrity, it is a mechanism for providing integrity.”
I’d prefer that we don’t resurrect the exact CRC-32C technical requirements – seems like it is over specifying the interface (i.e. XX sequential bit errors 100% detectable, up to YY non-sequential bit errors 100% detected, etc, etc). What value does it add? And we aren’t the experts in any case. We know what MPA/SCTP gives us. Let’s keep it simple. Possibly something like “at least the same level of data integrity verification as CRC32C”?
2) Why are we stating this as a requirement? I suspect there is some truth in his argument. Options are bad, basic assumptions are good. Look how UDP checksums evolved. In the early days, the checksum was optional. That was changed to mandatory to implement, on by default, because everyone wanted to know they had a data integrity check. I think the same argument can be applied here. In the world of high-speed networking and large data movement, checksum silent escapes are much more probable. Thus the need for CRC32C level of integrity check verses checksum. It’s a lot tougher argument to make if telnet is the primary application. But I don’t see telnet as being the application that is motivating the creation of a completely new transport protocol (RDMAP/DDP). For similar reasons that UDP apps motivated UDP implementations to turn checksums on by default (and it was an ugly migration, if memory serves me correctly, between 1980’s RFC768 and 1989’s RFC1122), let’s skip the ugly migration path and turn on CRC32C or equivalent data checking by default.
Jim
From:
rddp-bounces <at> ietf.org [mailto:rddp-bounces <at> ietf.org] On Behalf Of Somesh Gupta
Sent: Thursday, August 12, 2004
12:28 PM
To: Julian Satran;
Jim.Williams <at> Emulex.Com
Cc: rddp <at> ietf.org
Subject: RE: [rddp] DRAFT San Diego minutes
Julian,
I think there is some validity to Jim's point. Maybe the application is
satisfied if there is end-to-end IPSec instead. And although there is
a point of how does the application know, it is really the administrative
policy that determines what level of reliability is good enough or not.
Somesh
-----Original Message-----
From: rddp-bounces <at> ietf.org [mailto:rddp-bounces <at> ietf.org]On Behalf Of Julian Satran
Sent: Thursday, August 12, 2004 6:58 AM
To: Jim.Williams <at> Emulex.Com
Cc: rddp <at> ietf.org
Subject: RE: [rddp] DRAFT San Diego minutes
The reasoning behind this requirement was that an I_T pair may want to negotiate CRC (or equivalent) as an e2e guarantee but have no way of doing that if they use iSER.
Does it still look (or smell) as a red herring?
Julo
Jim.Williams <at> Emulex.Com
Sent by: rddp-bounces <at> ietf.org11/08/04 17:48
To
<rddp <at> ietf.org>
cc
Subject
RE: [rddp] DRAFT San Diego minutes
> iSER is a protocol that uses MPA (RDDP mapping to TCP) for iSCSI.
> The iSER draft authors have found MPA's current CRC requirements text
> to be insufficient for iSER usage of MPA, and hence currently impose
> stronger requirements. iSER requires that RDDP provide at least
> CRC32-class integrity, but the current MPA draft text allows CRC32C
> to be disabled in situations where that would not be the result.
>
> The RDDP WG's rough consensus has been that ULPs can assume at least
> CRC-class integrity from RDDP. Hence the sense of the room is that the
> MPA draft text needs to be tightened to do this and remove the need
> for iSER to add requirements to MPA.
This smells like a red herring. CRC32 is not a class of integrity,
it is a mechanism for providing integrity. Quantifying integrity
should be done with metrics like mean time between undetected
failure or mean GB of data transferred between undetected failure,
not bits of CRC. RDDP should provide the ULP with a guaranteed
level of integrity, not guarantee a mechanism for providing it.
The case that iSER requires a higher level of reliability that
iSCSI or NFS seems like a difficult case to make (but since I
wasn't at the meeting, perhaps it was made effectively). iSCSI
and NFS do not require mandatory CRC.
I suspect that the real reason is that all planned implementations
provide CRC for free, and options are a pain. However this it
not a bad argument, so I am not troubled by the conclusion.
> --> Important Security Issue #1: IPsec - required or optional?
>
> A lengthy discussion ensued on this topic. Important points:
> - For optional: IPsec can involve significant hardware complexity.
> - For mandatory: Some attacks can only be mitigated by IPsec (WG has
> little interest in designing its own security mechanism), and
> they will be of concern in some deployment environments.
OK, I'll be politically incorrect. Running RDMA over IPsec is
sufficiently stupid that NOBODY will implement IPsec regardless of
how mandatory it is. Just make it mandatory and quit worrying.
_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
_______________________________________________ rddp mailing list rddp <at> ietf.org https://www1.ietf.org/mailman/listinfo/rddp
RSS Feed2 | |
|---|---|
8 | |
3 | |
3 | |
25 | |
7 | |
4 | |
10 | |
1 | |
1 | |
2 | |
7 | |
3 | |
2 | |
7 | |
1 | |
8 | |
5 | |
6 | |
4 | |
6 | |
31 | |
7 | |
18 | |
6 | |
1 | |
1 | |
3 | |
3 | |
12 | |
11 | |
8 | |
2 | |
2 | |
5 | |
12 | |
32 | |
12 | |
10 | |
29 | |
36 | |
39 | |
22 | |
37 | |
19 | |
60 | |
32 | |
59 | |
26 | |
31 | |
59 | |
4 | |
22 | |
34 | |
7 | |
22 | |
121 | |
97 | |
133 | |
98 | |
15 | |
122 | |
58 | |
233 | |
151 | |
91 | |
50 | |
5 | |
20 |
