Subject: [rddp] Normative references to RDDP security document
From: "Jim Pinkerton" <[email-masked]>
To: <[email-masked]>
Date: Thu, 5 Aug 2004 09:24:43 -0700
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>

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

To: "Talpey, Thomas" <[email-masked]>, <[email-masked]>
Subject: [rddp] RE: Comments on draft-ietf-rddp-security-01
From: "Jim Pinkerton" <[email-masked]>
Date: Wed, 4 Aug 2004 21:17:28 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcQAEnFKYlLjNOowTBCTlEk4QlYcax6XmG+A
Thread-topic: Comments on draft-ietf-rddp-security-01

Title: Comments on draft-ietf-rddp-security-01

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:[email-masked]]
Sent: Monday, March 01, 2004 8:54 PM
To: Jim Pinkerton; [email-masked]
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

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-03.txt
From: [email-masked]
Date: Mon, 09 Aug 2004 15:26:43 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-security-03.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>
Subject: RE: [rddp] I-D ACTION:draft-ietf-rddp-security-03.txt
From: "Jim Pinkerton" <[email-masked]>
Date: Tue, 10 Aug 2004 10:22:43 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcR+UHCO1wiGY513QGSrYUUxUNc7vQAjcfMw
Thread-topic: [rddp] I-D ACTION:draft-ietf-rddp-security-03.txt

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.

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] DRAFT San Diego minutes
From: [email-masked]
Date: Wed, 11 Aug 2004 01:59:40 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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.

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>
Subject: [rddp] MPA CRC check issue from San Diego
From: "Culley, Paul" <[email-masked]>
Date: Wed, 11 Aug 2004 08:12:27 -0500
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcR/pNnVoALO6+8CRgG1CaD9SkitKQ==
Thread-topic: MPA CRC check issue from San Diego

>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

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>
Subject: RE: [rddp] DRAFT San Diego minutes
From: [email-masked]
Date: Wed, 11 Aug 2004 10:48:43 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcR/aY+jYAZFpoBzTf2SnkmfuUE7jwAQxqmA
Thread-topic: [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

To: [email-masked]
Subject: RE: [rddp] DRAFT San Diego minutes
From: Julian Satran <[email-masked]>
Date: Thu, 12 Aug 2004 16:57:46 +0300
Cc: rddp at ietf.org
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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.org

11/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

To: "Julian Satran" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] DRAFT San Diego minutes
From: "Somesh Gupta" <[email-masked]>
Date: Thu, 12 Aug 2004 12:28:21 -0700
Cc: rddp at ietf.org
Importance: Normal
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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.org

    11/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

To: "Somesh Gupta" <[email-masked]>, "Julian Satran" <[email-masked]>, <[email-masked]>
Subject: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)
From: "Jim Pinkerton" <[email-masked]>
Date: Thu, 12 Aug 2004 14:52:51 -0700
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSAqlTVn2IwVtytSCqAXzsYV27I3QAB2umQ
Thread-topic: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

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: [email-masked] [mailto:[email-masked]] On Behalf Of Somesh Gupta
Sent: Thursday, August 12, 2004 12:28 PM
To: Julian Satran; [email-masked]
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.org

    11/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

To: <[email-masked]>
Subject: RE: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)
From: "Carrier, John" <[email-masked]>
Date: Thu, 12 Aug 2004 15:49:05 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSAqlTVn2IwVtytSCqAXzsYV27I3QAB2umQAAMS6eA=
Thread-topic: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

The original intent of using CRC32C with MPA was to ensure that DDP/RDMAP had the same level of data integrity from TCP as it had from SCTP. 
 
I don't object to Jim's proposed wording and agree that MPA should have CRC enabled by default.
 
--jc

 -----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Jim Pinkerton
Sent: Thursday, August 12, 2004 2:53 PM
To: Somesh Gupta; Julian Satran; [email-masked]
Cc: rddp at ietf.org
Subject: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

    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.org

        11/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

To: <[email-masked]>
Subject: [rddp] Con-call to review the Security draft's normative statements
From: "Jim Pinkerton" <[email-masked]>
Date: Thu, 12 Aug 2004 16:03:44 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSAwJ4aRC2b1VsVRlKXEZu+vty1Sg==
Thread-topic: Con-call to review the Security draft's normative statements

As was discussed last week at the IETF RDDP WG meeting, the latest security draft revision (http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-03.txt) has changed many of the mitigations in the draft to be normative statements. In the interest of quickly iterating to a consensus on these changes, it might be worthwhile doing the first round of iteration on a con-call.

Thus I’ve set up a conference call on August 26th, 10am-noon PDT, noon-2pm CDT, 1-3pm EDT, to review any comments people have specifically around the normative statements made in the spec. There is about zero normative text before section 7.2.4 (one additional one in section 4.1). From there, the general format is explain attack, create normative counter-measures. If you're short on time, you can just read the normative counter-measure part. I would propose this meeting *only* review normative text, to keep it to a tractable amount of time. If you have other feedback, please either contact the authors directly or send it to the reflector. If you have feedback on the normative text, if possible please come with suggested text on how it should be changed.  This will make the call go a lot faster.

If you’d like to attend, please send me mail for the conference-call information. All comers are welcome. Note that this call will not be used to achieve formal work group consensus – that can only be done by the chair, on the reflector. Thus not attending (or attending!) the call does not in any way restrict what you want to bring up on the reflector.

 

Jim Pinkerton

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: "Jim Pinkerton" <[email-masked]>, "Julian Satran" <[email-masked]>, <[email-masked]>
Subject: RE: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)
From: "Somesh Gupta" <[email-masked]>
Date: Thu, 12 Aug 2004 16:30:43 -0700
Cc: rddp at ietf.org
Importance: Normal
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Jim,
 
I think it is a mix of the application and the administrative requirements.
 
I think an application so paranoid about its data integrity as to insert an
end-to-end CRC or redundany (and I hope my banking app does that) will benefit from
not having any other layer in the middle provide performance reducing
integrity from which it does not benefit.
 
And then there is security and reliability that one wants at the infrastructure level.
That is best provided by administrative policy.
 
Is iSER an application or an infrastructure component?
 
Somesh

    -----Original Message-----
    From: Jim Pinkerton [mailto:jpink at windows.microsoft.com]
    Sent: Thursday, August 12, 2004 2:53 PM
    To: Somesh Gupta; Julian Satran; Jim.Williams at Emulex.Com
    Cc: rddp at ietf.org
    Subject: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

    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.org

        11/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

To: "Somesh Gupta" <[email-masked]>, "Julian Satran" <[email-masked]>, <[email-masked]>
Subject: RE: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)
From: "Jim Pinkerton" <[email-masked]>
Date: Thu, 12 Aug 2004 17:42:35 -0700
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSAxL1ZUwh8hi1VSBaHUyP217ppYAAAKPbw
Thread-topic: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

You say potahto, I say potato...

In other words, both, neither, and possibly anything in between.

In re-reading the spec, it would appear as though the specified behavior is:

            An implementation MUST support CRCs

            An implementation MUST default to CRCs enabled (i.e. set the C bit in the MPA Request/Reply)

            An implementation MAY disable CRCs if the system administrator tells it to (but the implementation can ignore the administrator).

            The process of override of the default MUST be invisible to the ULP.

Thus we don’t have a specific escape clause if a specific Stream has IPSec enabled – but IPsec is generally enabled administratively, so to get the same effective result with the above statements, the administrator just has to take one additional step (enable IPSec, disable MPA CRC).

So what’s missing? iSER has no guarantee that the administrator has not turned off CRC (and not enabled IPsec). And it has no guaranteed way of turning off CRC if IPsec is enabled, unless it calls itself a “system administrator” rather than an application. Again, you say potahto, I say potato.

I’m not sure this is broken folks...

 

Jim

 

From: Somesh Gupta [mailto:[email-masked]]
Sent: Thursday, August 12, 2004 4:31 PM
To: Jim Pinkerton; Julian Satran; [email-masked]
Cc: rddp at ietf.org
Subject: RE: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

Jim,

I think it is a mix of the application and the administrative requirements.

I think an application so paranoid about its data integrity as to insert an

end-to-end CRC or redundany (and I hope my banking app does that) will benefit from

not having any other layer in the middle provide performance reducing

integrity from which it does not benefit.

And then there is security and reliability that one wants at the infrastructure level.

That is best provided by administrative policy.

Is iSER an application or an infrastructure component?

Somesh

    -----Original Message-----
    From: Jim Pinkerton [mailto:jpink at windows.microsoft.com]
    Sent: Thursday, August 12, 2004 2:53 PM
    To: Somesh Gupta; Julian Satran; Jim.Williams at Emulex.Com
    Cc: rddp at ietf.org
    Subject: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

    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.org

        11/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

To: [email-masked]
Subject: Re: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)
From: "Mallikarjun C." <[email-masked]>
Date: Thu, 12 Aug 2004 19:18:10 -0700
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
References: <[email-masked]>
Sender: [email-masked]
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

I'm not sure I am seeing a real disagreement here per se. I think everyone is agreeing that, a) iSCSI's CRC need (if negotiated to Yes) cannot be met by the iSCSI/iSER stack [or _any_ ULP stack in a similar position] without requiring the same from MPA, b) stay away from options/profiles if possible, c) MPA CRC should allow being turned off if there's IPSec/similar protection underneath.

If someone doesn't agree with the above, I'd of course like to know where the disagreement is.

Paul Culley's proposed text in his email on 8/11/2004 fixes section 1.1, which was originally somewhat out of sync with the strength of language in 5.2. I think the proposed text syncs up the two sections and meets the first-order concern expressed by the iSER folks, though some finer wordsmithing may be possible.
--
Mallikarjun

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

Jim Pinkerton wrote:

You say potahto, I say potato...

In other words, both, neither, and possibly anything in between.

In re-reading the spec, it would appear as though the specified behavior is:

            An implementation MUST support CRCs

    An implementation MUST default to CRCs enabled (i.e. set the C bit in the MPA Request/Reply)

    An implementation MAY disable CRCs if the system administrator tells it to (but the implementation can ignore the administrator).

    The process of override of the default MUST be invisible to the ULP.

    Thus we don’t have a specific escape clause if a specific Stream has IPSec enabled – but IPsec is generally enabled administratively, so to get the same effective result with the above statements, the administrator just has to take one additional step (enable IPSec, disable MPA CRC).

    So what’s missing? iSER has no guarantee that the administrator has not turned off CRC (and not enabled IPsec). And it has no guaranteed way of turning off CRC if IPsec is enabled, unless it calls itself a “system administrator” rather than an application. Again, you say potahto, I say potato.

I’m not sure this is broken folks...

Jim

------------------------------------------------------------------------

*From:* Somesh Gupta [mailto:somesh_gupta at silverbacksystems.com]
*Sent:* Thursday, August 12, 2004 4:31 PM
*To:* Jim Pinkerton; Julian Satran; Jim.Williams at Emulex.Com
*Cc:* rddp at ietf.org
*Subject:* RE: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

Jim,

I think it is a mix of the application and the administrative requirements.

I think an application so paranoid about its data integrity as to insert an

    end-to-end CRC or redundany (and I hope my banking app does that) will benefit from

not having any other layer in the middle provide performance reducing

integrity from which it does not benefit.

    And then there is security and reliability that one wants at the infrastructure level.

That is best provided by administrative policy.

Is iSER an application or an infrastructure component?

Somesh

    -----Original Message-----
    *From:* Jim Pinkerton [mailto:jpink at windows.microsoft.com]
    *Sent:* Thursday, August 12, 2004 2:53 PM
    *To:* Somesh Gupta; Julian Satran; Jim.Williams at Emulex.Com
    *Cc:* rddp at ietf.org
    *Subject:* MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

    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.org

        11/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

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: "Jim Pinkerton" <[email-masked]>
Subject: Re: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)
From: Caitlin Bestler <[email-masked]>
Date: Fri, 13 Aug 2004 08:38:14 +0300
Cc: Jim.Williams at Emulex.Com, Somesh Gupta <somesh_gupta at silverbacksystems.com>, Julian Satran <Julian_Satran at il.ibm.com>, rddp at ietf.org
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
References: <[email-masked]>
Sender: [email-masked]

On Aug 13, 2004, at 3:42 AM, Jim Pinkerton wrote:

    <x-tad-bigger> </x-tad-bigger>

    <x-tad-bigger>You say potahto, I say potato...</x-tad-bigger>

    <x-tad-bigger>  </x-tad-bigger>

    <x-tad-bigger>In other words, both, neither, and possibly anything in between.</x-tad-bigger>

    <x-tad-bigger> </x-tad-bigger>

    <x-tad-bigger>In re-reading the spec, it would appear as though the specified behavior is:</x-tad-bigger>

    <x-tad-bigger> </x-tad-bigger>

    <x-tad-bigger>            An implementation MUST support CRCs</x-tad-bigger>

    <x-tad-bigger>            An implementation MUST default to CRCs enabled (i.e. set the C bit in the MPA Request/Reply)</x-tad-bigger>

    <x-tad-bigger>            An implementation MAY disable CRCs if the system administrator tells it to (but the implementation can ignore the administrator).</x-tad-bigger>

    <x-tad-bigger>            The process of override of the default MUST be invisible to the ULP.</x-tad-bigger>

    <x-tad-bigger> </x-tad-bigger>

    <x-tad-bigger>Thus we don’t have a specific escape clause if a specific Stream has IPSec enabled – but IPsec is generally enabled administratively, so to get the same effective result with the above statements, the administrator just has to take one additional step (enable IPSec, disable MPA CRC).</x-tad-bigger>

    <x-tad-bigger>  </x-tad-bigger>

    <x-tad-bigger>So what’s missing? iSER has no guarantee that the administrator has not turned off CRC (and not enabled IPsec). And it has no guaranteed way of turning off CRC if IPsec is enabled, unless it calls itself a “system administrator” rather than an application. Again, you say potahto, I say potato.</x-tad-bigger>

    <x-tad-bigger> </x-tad-bigger>

    <x-tad-bigger>I’m not sure this is broken folks...</x-tad-bigger>

The key point that was somehow missed is this:

ULP designers MUST NOT be concerned that they might be receiving less than CRC-32C
protection on an end-to-end basis.

I thought that this was clear.

There seems to be some concern that the ULP should even protect itself against the
possibility of the system administrators setting the network configuration up incorrectly.
Frankly, in an IP network that is impossible.

Should the ULP also explicitly require the system administrator to set up routing tables
correctly? And DNS? What about "the system administator MUST allow all required
traffic to be passed by intermediate firewalls."

The intent is that the LLP MUST provide a level of end-to-end error protection that
is at least as good as CRC-32c.

Jim is absolutely correct that this requirement SHOULD be stated as a performance
goals, with a note that CRC-32c and IPsec are known to be safe. I believe a
cross-over Ethernet cable would also qualify.

Another obvious destination that could suppress CRCs would be 127.0.0.1.

In any event, this would hardly be the first time that a requirement was stated
in terms of an acceptable solution. Building codes routinely require a certain
type of wood be used for floors, and occassionally state 'must support X pounds
per square foot"

If it really bothers anyone that much, they should simply submit the more formal
statement of the requirement. Just be sure to explicitly state that CRC-32C and
IPsec both qualify.

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: "Somesh Gupta" <[email-masked]>
Subject: RE: [rddp] DRAFT San Diego minutes
From: Julian Satran <[email-masked]>
Date: Fri, 13 Aug 2004 10:31:40 +0300
Cc: Jim.Williams at Emulex.Com, rddp at ietf.org
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Somesh,

It is not a question of basic principles but rather one of wording.
BTW IPsec suffers from a similar problem - no appliaction above has any way of knowing if it running on IPsec or not and I understand that for a large class of applications that is unacceptable and that is why TLS is so popular. IPsec going to fix this (I hear) through some channel binding mechanism. In the absence of such a mechanism the best iSER/MPA could do is strengthen wording as was suggested (and perhaps allow for some later fix if bonding becomes standardized - bonding involving API's).
And yes it is an administrative issue - but the administrator must have its tools (i.e., the mandatory to implement stuff).

Julo

"Somesh Gupta" <somesh_gupta at silverbacksystems.com>

12/08/04 22:28
To
Julian Satran/Haifa/IBM at IBMIL, <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: [email-masked] [mailto:[email-masked]]On Behalf Of Julian Satran
Sent: Thursday, August 12, 2004 6:58 AM
To: [email-masked]
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.org

11/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

To: [email-masked]
Subject: [rddp] RDDP Mandatory Security (IPsec)
From: [email-masked]
Date: Tue, 17 Aug 2004 20:58:44 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

This email is bringing the first major issue from San
Diego in hopes of confirming the conclusions reached
in the meeting.  The draft minutes say:

  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.

NB: The sense of "no restrictions" is with respect to native
vs. Bump-in-the-stack vs. Bump-in-the-wire.  See Section 3.3
of RFC 2401

  (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.

This is an opportunity for anyone who objects to these
"sense of the room" conclusions to do so, but please read
the entire San Diego minutes on this topic before doing so.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] Discouraging use of network-writable data
From: [email-masked]
Date: Tue, 17 Aug 2004 21:06:04 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

This email is about the second major issue discussed in San Diego.
Here's the summary of the potential attack from the draft minutes:

  Issue is around having data sink buffer contents getting changed
  before the buffer [STag] 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.

Requiring all Stags to be One-Shot (single RDMA operation) has
been discussed and rejected on the list.  Discussion in San Diego
reinforced that rejection.  I believe that rejection is the
rough consensus of the RDDP Working Group.

Two approaches beyond stiff warnings to ULP implementers were
discussed in San Diego.  This is slightly summarized from the
minutes:

  a) Receive and Invalidate.

  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:

  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.

This is an opportunity for anyone on the list to object to
the conclusions from the San Diego meeting, but please read
the entire San Diego minutes on this topic before objecting.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>
Subject: RE: [rddp] DRAFT San Diego minutes
From: [email-masked]
Date: Wed, 18 Aug 2004 12:57:14 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSAdF8nfch48s41QRebNbgXpsUqpQEzKvdg
Thread-topic: [rddp] DRAFT San Diego minutes

I don't want to be argumentative here since I think
where you ended up is fine.  A few thoughts follow.

Julian Satran wrote:
> 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.

The conclusion does seem to follow from the premise.
The question is why the I_T pair negotiates the CRC.
ULPs are not allowed to negotiate use of IPsec or
negotiate with IP layer as to which routes are 
acceptable.  There is an argument to be made
for a layered architecture in which each layer
is responsible for making the critical decisions
in its own "area of expertise".

Caitlin Bestler wrote:
> In any event, this would hardly be the first time
> that a requirement was stated in terms of an
> acceptable solution. Building codes routinely
> require a certain type of wood be used for floors,
> and occasionally state 'must support X pounds 
> per square foot

This is a nice analogy and makes sense.  The only
thing that give me a little pause is that for 
typical installations where the links are already
CRC protected, and networking equipment is well
designed with internal data paths parity protected,
TCP checksum escapes are probably not the weak
link in end to end data integrity, so adding a
CRC will not improve data integrity in this case.
This case may well turn out to be the majority
of installations.  However the added CRC certainly
does no harm.

Mallikarjun C. wrote:
> MPA CRC should allow being turned off 
> if there's IPSec/similar protection underneath.

I have seen this idea before and cringe every time.
I fear that the IPSec encryption/decryption layer
is an order of magnitude more likely to cause
data corruption than everything else in the end
to end data path combined.  There is not even
a practical method to parity protect this logic.
The IPSec design team decided to order encryption
and authentication such that the encryption/decryption
logic is totally unprotected by the authentication
layer.

To me, IPSec seems like a good argument to turn
the CRC on, and not a very reassuring argument
to turn it off.

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: "Caitlin Bestler" <[email-masked]>
Subject: RE: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)
From: "Jim Pinkerton" <[email-masked]>
Date: Wed, 18 Aug 2004 11:15:48 -0700
Cc: Jim.Williams at Emulex.Com, Somesh Gupta <somesh_gupta at silverbacksystems.com>, Julian Satran <Julian_Satran at il.ibm.com>, rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSA97kobku6Le/XR6SP+x+a3svmXQEUANzA
Thread-topic: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

Trying to get resolution on this topic.

Here’s what we currently have (ignoring the informative text):

Section 1.2 Protocol Overview

   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.

Section 5.2 CRC Calculation

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.

   The process MUST be invisible to the ULP.

 

My comments on the above:

-          Section 1.2. Stating normatively what the ULP SHOULD NOT do doesn’t seem appropriate. This should be lower-case text, not upper case

-          Section 5.2: Possibly remove all of the above text and replace it with the following. Note I’ve also removed the MUST be invisible to the ULP text. It seems strange to me to mandate that the ULP can’t see it – why shouldn’t this be left to the implementation?

o        An MPA implementation MUST implement CRC support. The MPA implementation MUST request CRCs be enabled during the MPA Startup Phase unless there is a CRC32C equivalent level of end-to-end data integrity verification (such as IPsec).

 

Jim

 

From: Caitlin Bestler [mailto:[email-masked]]
Sent: Thursday, August 12, 2004 10:38 PM
To: Jim Pinkerton
Cc: Julian Satran; rddp at ietf.org; Jim.Williams at Emulex.Com; Somesh Gupta
Subject: Re: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

 

On Aug 13, 2004, at 3:42 AM, Jim Pinkerton wrote:

     

    You say potahto, I say potato...

     

    In other words, both, neither, and possibly anything in between.

     

    In re-reading the spec, it would appear as though the specified behavior is:

     

                An implementation MUST support CRCs

                An implementation MUST default to CRCs enabled (i.e. set the C bit in the MPA Request/Reply)

                An implementation MAY disable CRCs if the system administrator tells it to (but the implementation can ignore the administrator).

                The process of override of the default MUST be invisible to the ULP.

     

    Thus we don’t have a specific escape clause if a specific Stream has IPSec enabled – but IPsec is generally enabled administratively, so to get the same effective result with the above statements, the administrator just has to take one additional step (enable IPSec, disable MPA CRC).

     

    So what’s missing? iSER has no guarantee that the administrator has not turned off CRC (and not enabled IPsec). And it has no guaranteed way of turning off CRC if IPsec is enabled, unless it calls itself a “system administrator” rather than an application. Again, you say potahto, I say potato.

     

    I’m not sure this is broken folks...

 

The key point that was somehow missed is this:

ULP designers MUST NOT be concerned that they might be receiving less than CRC-32C

protection on an end-to-end basis.

I thought that this was clear.

There seems to be some concern that the ULP should even protect itself against the

possibility of the system administrators setting the network configuration up incorrectly.

Frankly, in an IP network that is impossible.

Should the ULP also explicitly require the system administrator to set up routing tables

correctly? And DNS? What about "the system administator MUST allow all required

traffic to be passed by intermediate firewalls."

The intent is that the LLP MUST provide a level of end-to-end error protection that

is at least as good as CRC-32c.

Jim is absolutely correct that this requirement SHOULD be stated as a performance

goals, with a note that CRC-32c and IPsec are known to be safe. I believe a

cross-over Ethernet cable would also qualify.

Another obvious destination that could suppress CRCs would be 127.0.0.1.

In any event, this would hardly be the first time that a requirement was stated

in terms of an acceptable solution. Building codes routinely require a certain

type of wood be used for floors, and occassionally state 'must support X pounds

per square foot"

If it really bothers anyone that much, they should simply submit the more formal

statement of the requirement. Just be sure to explicitly state that CRC-32C and

IPsec both qualify.

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>
Subject: RE: [rddp] Con-call to review the Security draft's normative statements
From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 23 Aug 2004 11:59:43 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSAwJ4aRC2b1VsVRlKXEZu+vty1SgIge5yA
Thread-topic: [rddp] Con-call to review the Security draft's normative statements

A quick reminder that the con-call is this Thursday, 10am-noon PDT, noon-2pm CDT, 1-3pm EDT. So far 5 people have asked me for con-call information. If you’d like to attend please send me email and I’ll send you the con-call information.

Note that the call will not be a walk through of all the requirements in the document. It is hoped that the attendees will come with a list of concerns/issues against what is currently in the document, so we can quickly iterate on the issues live on the call.

I just submitted the -04 draft on Friday. The main change is that the appendix on client/server issues has been essentially rewritten from scatch, with a new direction. It is normative, and been re-focused on ULP issues when implementing a client/server model. Note that I’d appreciate input on what should go in this appendix for 7.5.2.2 (there is a TBD on that one specific section).

 

 

Jim

 

 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Pinkerton
Sent: Thursday, August 12, 2004 4:04 PM
To: [email-masked]
Subject: [rddp] Con-call to review the Security draft's normative statements

As was discussed last week at the IETF RDDP WG meeting, the latest security draft revision (http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-03.txt) has changed many of the mitigations in the draft to be normative statements. In the interest of quickly iterating to a consensus on these changes, it might be worthwhile doing the first round of iteration on a con-call.

Thus I’ve set up a conference call on August 26th, 10am-noon PDT, noon-2pm CDT, 1-3pm EDT, to review any comments people have specifically around the normative statements made in the spec. There is about zero normative text before section 7.2.4 (one additional one in section 4.1). From there, the general format is explain attack, create normative counter-measures. If you're short on time, you can just read the normative counter-measure part. I would propose this meeting *only* review normative text, to keep it to a tractable amount of time. If you have other feedback, please either contact the authors directly or send it to the reflector. If you have feedback on the normative text, if possible please come with suggested text on how it should be changed.  This will make the call go a lot faster.

If you’d like to attend, please send me mail for the conference-call information. All comers are welcome. Note that this call will not be used to achieve formal work group consensus – that can only be done by the chair, on the reflector. Thus not attending (or attending!) the call does not in any way restrict what you want to bring up on the reflector.

 

Jim Pinkerton

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-04.txt
From: [email-masked]
Date: Mon, 23 Aug 2004 15:22:08 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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-04.txt
	Pages		: 54
	Date		: 2004-8-23
	
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-04.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-04.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-04.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.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-security-04.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: RE: [rddp] MPA CRC check issue from San Diego
From: [email-masked]
Date: Wed, 25 Aug 2004 18:50:02 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Wading through all the emails on this topic, I think the
rough consensus of the RDDP WG is that Paul Culley's proposed
new text for Section 1.1 is an acceptable solution to this issue:

	"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."

Specific disagreements with this text should be posted to the list.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Culley, Paul
> Sent: Wednesday, August 11, 2004 9:12 AM
> To: rddp at ietf.org
> Subject: [rddp] MPA CRC check issue from San Diego
> 
> 
> >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
> 
> _______________________________________________
> 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

To: [email-masked]
Subject: [rddp] FINAL San Diego minutes
From: [email-masked]
Date: Wed, 25 Aug 2004 19:05:17 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Having seen no objection since the posting of the draft
minutes, the RDDP WG has rough consensus on all the
issues discussed in San Diego (see below) except for
the three issues handled in separate email threads:

- MPA CRC check requirements
- Mandatory Security (IPsec)
- Discouraging use of network-writable data

Here are the final San Diego minutes that I just sent
to the secretariat:

RDDP WG Minutes - FINAL
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 completion 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.  UPDATE: Done.)
- 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.

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>
Subject: RE: [rddp] Con-call to review the Security draft's normativestatements
From: "Jim Pinkerton" <[email-masked]>
Date: Wed, 25 Aug 2004 17:34:33 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSAwJ4aRC2b1VsVRlKXEZu+vty1SgIge5yAAHBx1ZA=
Thread-topic: [rddp] Con-call to review the Security draft's normativestatements

A reminder that tomorrow morning is the con-call to review the normative statements in the security draft. So far 11 people are planning on attending.

 

Jim

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Pinkerton
Sent: Monday, August 23, 2004 12:00 PM
To: [email-masked]
Subject: RE: [rddp] Con-call to review the Security draft's normativestatements

 

A quick reminder that the con-call is this Thursday, 10am-noon PDT, noon-2pm CDT, 1-3pm EDT. So far 5 people have asked me for con-call information. If you’d like to attend please send me email and I’ll send you the con-call information.

Note that the call will not be a walk through of all the requirements in the document. It is hoped that the attendees will come with a list of concerns/issues against what is currently in the document, so we can quickly iterate on the issues live on the call.

I just submitted the -04 draft on Friday. The main change is that the appendix on client/server issues has been essentially rewritten from scatch, with a new direction. It is normative, and been re-focused on ULP issues when implementing a client/server model. Note that I’d appreciate input on what should go in this appendix for 7.5.2.2 (there is a TBD on that one specific section).

 

 

Jim

 

 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Pinkerton
Sent: Thursday, August 12, 2004 4:04 PM
To: [email-masked]
Subject: [rddp] Con-call to review the Security draft's normative statements

As was discussed last week at the IETF RDDP WG meeting, the latest security draft revision (http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-03.txt) has changed many of the mitigations in the draft to be normative statements. In the interest of quickly iterating to a consensus on these changes, it might be worthwhile doing the first round of iteration on a con-call.

Thus I’ve set up a conference call on August 26th, 10am-noon PDT, noon-2pm CDT, 1-3pm EDT, to review any comments people have specifically around the normative statements made in the spec. There is about zero normative text before section 7.2.4 (one additional one in section 4.1). From there, the general format is explain attack, create normative counter-measures. If you're short on time, you can just read the normative counter-measure part. I would propose this meeting *only* review normative text, to keep it to a tractable amount of time. If you have other feedback, please either contact the authors directly or send it to the reflector. If you have feedback on the normative text, if possible please come with suggested text on how it should be changed.  This will make the call go a lot faster.

If you’d like to attend, please send me mail for the conference-call information. All comers are welcome. Note that this call will not be used to achieve formal work group consensus – that can only be done by the chair, on the reflector. Thus not attending (or attending!) the call does not in any way restrict what you want to bring up on the reflector.

 

Jim Pinkerton

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>
Subject: [rddp] Next RDMAP Security con-call time
From: "Jim Pinkerton" <[email-masked]>
Date: Thu, 26 Aug 2004 15:24:12 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSLu2mrJiwkA8KwQu6TgcgM6bTZDg==
Thread-topic: Next RDMAP Security con-call time

We spent two hours going through the security draft today with seven people on the call today. The feedback was extremely worthwhile. I’m hoping to get out an updated ID (-05) by the end of today. This will include comments which enumerate the changes agreed to in the con-call (my version of minutes...). We did not get through Appendix A or B, so we agreed to review that in another con-call.

Thus for those that would like to attend, the next security draft con-call will be August 31st at 8-9am PDT, 10-11am CDT, 11-12am EDT. If you’d like to attend, please send me mail and I’ll send you the conference call information. Agenda is to specifically review the normative statements in Appendix A and B.

Note that these con-calls in no way restrict anyone’s ability to give feedback on the reflector. They are just an attempt to more quickly converge consensus.

 

 

Jim

 

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] Administrivia: Mail list housekeeping
From: [email-masked]
Date: Fri, 27 Aug 2004 11:28:05 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Everyone,

In the past few months, IETF has switched to a new
version of the mailing list manager that does a much
better job of removing dead email addresses from
the mailing list.  Unfortunately, as part of this
upgrade, the distinction between email addresses
that were automatically disabled because emails were
bouncing vs. email addresses that were manually disabled
by a list member who didn't want to receive list email
at that address (e.g., but wants to be able to post
from it) was lost.

In order to get this mailing list manager working on
weeding out long-dead addresses, I've re-enabled mail
delivery to addresses that were disabled before the
upgrade.  In most cases, the result should be email
bounces that trigger the logic that will eventually
remove addresses from the list.  The mailing list
manager is currently configured so that:
	- It takes at least 5 bounces (message delivery
		failures) before email delivery to an
		address is disabled (but can be re-enabled).
	- It takes at least two weeks of continued
		bounces before an email address is
		deleted from the list (making it necessary
		to resubscribe).  Weekly notifications
		should be sent, and deletion occurs as
		a result of these bouncing.

I apologize for the inconvenience to anyone who intended
to disable email delivery - if you're receiving this email
at an email address to which you intentionally disabled email
delivery (e.g., so you can post from it without receiving
list email), please send me a note, and I'll re-disable that
address for you.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
From: [email-masked]
Date: Fri, 27 Aug 2004 15:42:41 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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-05.txt
	Pages		: 54
	Date		: 2004-8-27
	
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-05.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-05.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-05.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.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-security-05.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
From: "Jim Pinkerton" <[email-masked]>
Date: Fri, 27 Aug 2004 15:22:45 -0700
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSMdNhG2KwGRt0VTlOWKe1NXOC42wAD3Z0Q
Thread-topic: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt

If anyone would like a version with change-bars turned on, please send
me email.

Jim

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
Of
> Internet-Drafts at ietf.org
> Sent: Friday, August 27, 2004 12:43 PM
> To: i-d-announce at ietf.org
> Cc: rddp at ietf.org
> Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.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-05.txt
> 	Pages		: 54
> 	Date		: 2004-8-27
> 
> 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-05.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-05.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-05.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

To: <[email-masked]>
Subject: [rddp] RDDP and SSL/TLS
From: "Rajiv Das" <[email-masked]>
Date: Mon, 30 Aug 2004 12:10:15 +0530
In-reply-to: <[email-masked]>
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Organization: Rajiv(Personal)
Sender: [email-masked]
Thread-index: AcSNGgoFLHNIpCLfQHiTyKPa4TeGHQBQadHA

Hi,
So far as I understand RDDP is layered over the transport layer eg TCP.
Incidentally, SSL/TLS is also layered over TCP. So what is the position of
RDDP vis-a-vis SSL/TLS on the protocol stack?

-------------------
Have a nice day,
Rajiv

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
rddp-request at ietf.org
Sent: Saturday, August 28, 2004 9:44 PM
To: [email-masked]
Subject: rddp Digest, Vol 4, Issue 15

Send rddp mailing list submissions to
	rddp at ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/rddp
or, via email, send a message with subject or body 'help' to
	rddp-request at ietf.org

You can reach the person managing the list at
	rddp-owner at ietf.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of rddp digest..."

Today's Topics:

   1. I-D ACTION:draft-ietf-rddp-security-05.txt
      (Internet-Drafts at ietf.org)
   2. RE: I-D ACTION:draft-ietf-rddp-security-05.txt (Jim Pinkerton)

----------------------------------------------------------------------

Message: 1
Date: Fri, 27 Aug 2004 15:42:41 -0400
From: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
To: [email-masked]
Cc: rddp at ietf.org
Message-ID: <200408271942.PAA29294 at ietf.org>
Content-Type: text/plain; charset="us-ascii"

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-05.txt
	Pages		: 54
	Date		: 2004-8-27
	
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-05.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-05.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-05.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.
-------------- next part --------------
Skipped content of type multipart/alternative

------------------------------

Message: 2
Date: Fri, 27 Aug 2004 15:22:45 -0700
From: "Jim Pinkerton" <[email-masked]>
Subject: RE: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
To: <[email-masked]>, <[email-masked]>
Cc: rddp at ietf.org
Message-ID:
	
<E6564B8F86852D46A4E98C485FB33B8F09D82416 at WIN-MSG-10.wingroup.windeploy.ntde
v.microsoft.com>
	
Content-Type: text/plain;	charset="us-ascii"

If anyone would like a version with change-bars turned on, please send
me email.

Jim

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
Of
> Internet-Drafts at ietf.org
> Sent: Friday, August 27, 2004 12:43 PM
> To: i-d-announce at ietf.org
> Cc: rddp at ietf.org
> Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.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-05.txt
> 	Pages		: 54
> 	Date		: 2004-8-27
> 
> 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-05.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-05.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-05.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

End of rddp Digest, Vol 4, Issue 15
***********************************

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: "Rajiv Das" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] RDDP and SSL/TLS
From: "Culley, Paul" <[email-masked]>
Date: Mon, 30 Aug 2004 08:07:46 -0500
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSNGgoFLHNIpCLfQHiTyKPa4TeGHQBQadHAAA1LzkA=
Thread-topic: [rddp] RDDP and SSL/TLS

Due to the desire to enable "direct placement" of RDDP packets when they
come in, including when they are out of order, SSL/TLS is not a good fit
below the DDP layer.  SSL/TLS wants the incoming data to be part of a
continuous stream of data for decoding.  So IPSEC is the recommended
method of securing RDDP connections.  I suppose it remains possible for
some layer above RDDP to use SSL/TLS, in fact it is probably going to
happen if SDP over RDDP is used to enable legacy applications.

Paul R. Culley
HP Fellow
281-514-5543

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Rajiv Das
> Sent: Monday, August 30, 2004 1:40 AM
> To: rddp at ietf.org
> Subject: [rddp] RDDP and SSL/TLS
> 
> Hi,
> So far as I understand RDDP is layered over the transport 
> layer eg TCP.
> Incidentally, SSL/TLS is also layered over TCP. So what is 
> the position of RDDP vis-a-vis SSL/TLS on the protocol stack?
> 
> 
> -------------------
> Have a nice day,
> Rajiv
> 

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

To: [email-masked], [email-masked]
Subject: RE: [rddp] RDDP and SSL/TLS
From: [email-masked]
Date: Mon, 30 Aug 2004 09:18:02 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Rajiv,

This is covered in Section 8 of the RDDP security draft: 

http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-05.txt

Thanks
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Rajiv Das
> Sent: Monday, August 30, 2004 2:40 AM
> To: rddp at ietf.org
> Subject: [rddp] RDDP and SSL/TLS
> 
> 
> Hi,
> So far as I understand RDDP is layered over the transport 
> layer eg TCP.
> Incidentally, SSL/TLS is also layered over TCP. So what is 
> the position of
> RDDP vis-a-vis SSL/TLS on the protocol stack?
> 
> 
> -------------------
> Have a nice day,
> Rajiv
> 
> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of
> rddp-request at ietf.org
> Sent: Saturday, August 28, 2004 9:44 PM
> To: rddp at ietf.org
> Subject: rddp Digest, Vol 4, Issue 15
> 
> Send rddp mailing list submissions to
> 	rddp at ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/rddp
> or, via email, send a message with subject or body 'help' to
> 	rddp-request at ietf.org
> 
> You can reach the person managing the list at
> 	rddp-owner at ietf.org
> 
> When replying, please edit your Subject line so it is more 
> specific than
> "Re: Contents of rddp digest..."
> 
> 
> Today's Topics:
> 
>    1. I-D ACTION:draft-ietf-rddp-security-05.txt
>       (Internet-Drafts at ietf.org)
>    2. RE: I-D ACTION:draft-ietf-rddp-security-05.txt (Jim Pinkerton)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 27 Aug 2004 15:42:41 -0400
> From: Internet-Drafts at ietf.org
> Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
> To: i-d-announce at ietf.org
> Cc: rddp at ietf.org
> Message-ID: <200408271942.PAA29294 at ietf.org>
> Content-Type: text/plain; charset="us-ascii"
> 
> 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-05.txt
> 	Pages		: 54
> 	Date		: 2004-8-27
> 	
> 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-05.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-05.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-05.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.
> -------------- next part --------------
> Skipped content of type multipart/alternative
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 27 Aug 2004 15:22:45 -0700
> From: "Jim Pinkerton" <jpink at windows.microsoft.com>
> Subject: RE: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
> To: <Internet-Drafts at ietf.org>, <i-d-announce at ietf.org>
> Cc: rddp at ietf.org
> Message-ID:
> 	
> <E6564B8F86852D46A4E98C485FB33B8F09D82416 at WIN-MSG-10.wingroup.
> windeploy.ntde
> v.microsoft.com>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> 
> If anyone would like a version with change-bars turned on, please send
> me email.
> 
> 
> Jim
> 
> 
> 
> 
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
> Of
> > Internet-Drafts at ietf.org
> > Sent: Friday, August 27, 2004 12:43 PM
> > To: i-d-announce at ietf.org
> > Cc: rddp at ietf.org
> > Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.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-05.txt
> > 	Pages		: 54
> > 	Date		: 2004-8-27
> > 
> > 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-05.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-05.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-05.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
> 
> 
> End of rddp Digest, Vol 4, Issue 15
> ***********************************
> 
> _______________________________________________
> 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

To: "Rajiv Das" <[email-masked]>, <[email-masked]>
Subject: RE: [rddp] RDDP and SSL/TLS
From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 30 Aug 2004 06:29:56 -0700
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]
Thread-index: AcSNGgoFLHNIpCLfQHiTyKPa4TeGHQBQadHAAA5v6k0=
Thread-topic: [rddp] RDDP and SSL/TLS

Title: [rddp] RDDP and SSL/TLS
 
Please read the security draft, specifically chapter 8 and section 8.1.2.

jim

From: [email-masked] on behalf of Rajiv Das
Sent: Sun 8/29/2004 11:40 PM
To: [email-masked]
Subject: [rddp] RDDP and SSL/TLS

Hi,
So far as I understand RDDP is layered over the transport layer eg TCP.
Incidentally, SSL/TLS is also layered over TCP. So what is the position of
RDDP vis-a-vis SSL/TLS on the protocol stack?

-------------------
Have a nice day,
Rajiv

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
rddp-request at ietf.org
Sent: Saturday, August 28, 2004 9:44 PM
To: [email-masked]
Subject: rddp Digest, Vol 4, Issue 15

Send rddp mailing list submissions to
        rddp at ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www1.ietf.org/mailman/listinfo/rddp
or, via email, send a message with subject or body 'help' to
        rddp-request at ietf.org

You can reach the person managing the list at
        rddp-owner at ietf.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of rddp digest..."

Today's Topics:

   1. I-D ACTION:draft-ietf-rddp-security-05.txt
      (Internet-Drafts at ietf.org)
   2. RE: I-D ACTION:draft-ietf-rddp-security-05.txt (Jim Pinkerton)

----------------------------------------------------------------------

Message: 1
Date: Fri, 27 Aug 2004 15:42:41 -0400
From: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
To: [email-masked]
Cc: rddp at ietf.org
Message-ID: <200408271942.PAA29294 at ietf.org>
Content-Type: text/plain; charset="us-ascii"

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-05.txt
        Pages           : 54
        Date            : 2004-8-27
       
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-05.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-05.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-05.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.
-------------- next part --------------
Skipped content of type multipart/alternative

------------------------------

Message: 2
Date: Fri, 27 Aug 2004 15:22:45 -0700
From: "Jim Pinkerton" <[email-masked]>
Subject: RE: [rddp] I-D ACTION:draft-ietf-rddp-security-05.txt
To: <[email-masked]>, <[email-masked]>
Cc: rddp at ietf.org
Message-ID:
       
<E6564B8F86852D46A4E98C485FB33B8F09D82416 at WIN-MSG-10.wingroup.windeploy.ntde
v.microsoft.com>
       
Content-Type: text/plain;       charset="us-ascii"

If anyone would like a version with change-bars turned on, please send
me email.

Jim

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf
Of
> Internet-Drafts at ietf.org
> Sent: Friday, August 27, 2004 12:43 PM
> To: i-d-announce at ietf.org
> Cc: rddp at ietf.org
> Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-05.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-05.txt
>       Pages           : 54
>       Date            : 2004-8-27
>
> 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-05.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-05.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-05.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

End of rddp Digest, Vol 4, Issue 15
***********************************

_______________________________________________
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

To: [email-masked]
Subject: RE: [rddp] Discouraging use of network-writable data
From: [email-masked]
Date: Mon, 30 Aug 2004 17:00:28 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Having seen no objections to this, the sense of the room 
in San Diego on this issue (see below) is the rough consensus
of the RDDP WG.

Thanks,
--David (RDDP WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Black_David at emc.com
> Sent: Tuesday, August 17, 2004 9:06 PM
> To: rddp at ietf.org
> Subject: [rddp] Discouraging use of network-writable data
> 
> 
> This email is about the second major issue discussed in San Diego.
> Here's the summary of the potential attack from the draft minutes:
> 
>   Issue is around having data sink buffer contents getting changed
>   before the buffer [STag] 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.
> 
> Requiring all Stags to be One-Shot (single RDMA operation) has
> been discussed and rejected on the list.  Discussion in San Diego
> reinforced that rejection.  I believe that rejection is the
> rough consensus of the RDDP Working Group.
> 
> Two approaches beyond stiff warnings to ULP implementers were
> discussed in San Diego.  This is slightly summarized from the
> minutes:
> 
>   a) Receive and Invalidate.
> 
>   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:
> 
>   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.
> 
> This is an opportunity for anyone on the list to object to
> the conclusions from the San Diego meeting, but please read
> the entire San Diego minutes on this topic before objecting.
> 
> Thanks,
> --David
> 
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> _______________________________________________
> 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

To: [email-masked]
Subject: RE: [rddp] RDDP Mandatory Security (IPsec)
From: [email-masked]
Date: Mon, 30 Aug 2004 17:00:36 -0400
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

Having seen no objections to this, the sense of the room 
in San Diego on this issue (see below) is the rough consensus
of the RDDP WG.

Thanks,
--David (RDDP WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> Behalf Of Black_David at emc.com
> Sent: Tuesday, August 17, 2004 8:59 PM
> To: rddp at ietf.org
> Subject: [rddp] RDDP Mandatory Security (IPsec)
> 
> 
> This email is bringing the first major issue from San
> Diego in hopes of confirming the conclusions reached
> in the meeting.  The draft minutes say:
> 
>   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.
> 
> NB: The sense of "no restrictions" is with respect to native
> vs. Bump-in-the-stack vs. Bump-in-the-wire.  See Section 3.3
> of RFC 2401
> 
>   (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.
> 
> This is an opportunity for anyone who objects to these
> "sense of the room" conclusions to do so, but please read
> the entire San Diego minutes on this topic before doing so.
> 
> Thanks,
> --David
> 
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> _______________________________________________
> 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

To: [email-masked]
Subject: [rddp] I-D ACTION:draft-ietf-rddp-ddp-03.txt
From: [email-masked]
Date: Tue, 31 Aug 2004 15:31:38 -0400
Cc: rddp at ietf.org
List-help: <mailto:[email-masked]?subject=help>
List-id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=subscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:[email-masked]?subject=unsubscribe>
Sender: [email-masked]

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		: Direct Data Placement over Reliable Transports
	Author(s)	: H. Shah, et al.
	Filename	: draft-ietf-rddp-ddp-03.txt
	Pages		: 37
	Date		: 2004-8-31
	
The Direct Data Placement protocol provides information to Place the 
incoming data directly into an upper layer protocol's receive buffer 
without intermediate buffers. This removes excess CPU and memory 
utilization associated with transferring data through the 
intermediate buffers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-ddp-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-ddp-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-ddp-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.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rddp-ddp-03.txt>

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp