Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security
draft-ietf-rddp-security-10

Both documents depend on several normative references from the rddp wg. Specifically the Internet-Drafts defining DDP and RDMAP did not yet go through IESGLC. I am wondering if as result of the broader community review there is a chance that changes will happen to influence the security aspects and applicability statements related to DDP and RDMAP. The timing of approving these two documents before the protocols having even gone through Last Call seems questionable.

Nits on the applicability document

s/existince/existence/
s/imbedded/embedded/
s/signifigant/significant/

Normative references that are not used:

  - Unused Reference: [1] is defined on line 909, but not referenced
  - Unused Reference: [2] is defined on line 912, but not referenced
  - Unused Reference: [3] is defined on line 915, but not referenced
  - Unused Reference: [4] is defined on line 918, but not referenced
  - Unused Reference: [5] is defined on line 923, but not referenced
  - Unused Reference: [9] is defined on line 937, but not referenced

These are all about draft-ietf-rddp-applicability-06.txt.

Overall:
	Cites RFC2119, doesn't have the boilerplate text, uses the terms
	in only a few subsections. Does this AS actually _need_ to use RFC2119
	terms?

	Needs to be idnits-, grammar- and spell-checked.

Section 1., para. 0:

1.  Introduction

        draft-ietf-rddp-security-09.txt has a much more readable introductory
        overview of the RDDP protocols and the ideas behind it. Since the security
        document is not the     most obvious place for people to look for that sort of
        thing, it may therefore be worth pointing at it in this section.

Section 2., para. 0:

2.  Definitions

        Given that all six RDDP documents (the two in this ballot and the
        four others on their way to the IESG) duplicate subsets of the same
        terminology more or sometimes less consistently, it may make sense to
        consolidate the RDDP terminology in _one_ draft - this one? - and put
        a normative reference on it in the others.

Section 3.2., para. 0:

>    Content access applications are primary examples of applications with
>    both high bandwidth and high content to required ULP interaction
>    ratios.  These applications include file access protocols (NAS),
>    storage access (SAN), database access and other application specific
>    forms of content access such as HTTP, XML and email.

        Can't parse the first sentence of this paragraph.

3.2.  Direct Placement using only the LLP

        May make sense to swap sections 3.1 and 3.2 for readability reasons.

Section 3.2., para. 2:

>    An application that could predict incoming messages and required
>    nothing more than direct placement into buffers might be able to do
>    so with a properly designed local interface to SCTP or TCP.  Doing so
>    for TCP requires making predictions at a byte level rather than a
>    message level.

        What does "requires making predictions at a byte level" mean?

Section 4., para. 4:

>    Some examples of data that typically belongs in the untagged message
>    would include short fixed size control data that is inherently part
>    of the control message almost always should be included in the
>    untagged message, relatively short payload that is almost always
>    needed (especially when it would eliminate a round-trip to fetch the
>    data.  For example, the initial data on a write request, and of
>    course advertising tagged buffers that specify the location of data
>    not in the untagged message.

        I can't parse this paragraph.

Section 4.3., para. 2:

>    A ULP where all exchanges would naturally be only the untagged
>    message would derive virtually no benefit from the use of RDMAP/DDP
>    as opposed to SCTP.  But while tagged buffers are the justification
>    for RDMAP/DDP, untagged buffers are still necessary.  Without
>    untagged buffers the only method to exchange buffer advertisements
>    would involve out-of-band communications and/or sharing of compile
>    time constants.  Most RDMA-aware ULPs use untagged buffers for
>    requests and responses.  Buffer advertisements are typically done
>    within these untagged messages.

        Can't parse the first sentence.
        What does "sharing of compile-time constants" mean?

Section 6.9.1., para. 4:

>    With SCTP, a pair of SCTP streams can be used for sequential
>    sessions.  With MPA/TCP each connection can be used for at most one
>    session.  However, the same source/destination pair of ports can be
>    re-used sequentially subject to normal TCP rules.

        What are "sequential" sessions, do you mean recurring?

Section 9.1., para. 0:

9.  Security considerations

        How does this relate to draft-ietf-rddp-security-09.txt? There seems
        to be some duplication of content. Is it maybe sufficient to point at
        draft-ietf-rddp-security-09.txt here?

Section 10.1., para. 0:

10.1.  Normative references

        These normative references are not cited anywhere, which seems odd:
        [1], [2], [3], [4], [5], [9]

  draft-ietf-rddp-applicability-07:

  Section 6.6 says:
  >
  > A ULP that requires a greater degree of protection may add it own.
  >
  s/own/own integrity check/

  Section 9.3 contains sentence fragments.  I would prefer a slight
  reorganization, so that TLS, DTLS, and IPsec are each discussed in
  their own paragraphs.

The discussion of TLS in section 5.4 of the security draft does not
make sense to me.  How is the record length of 2**14 bytes any worse
than MTUs over common links?  Also, Russ is right; you should analyze
DTLS as well.

The advice in section 5.4 implies that data source authentication is
sufficient to defeat MITM without per-packet integrity.  I don't
understand how authentication of the source of a packet is meaningful
without authenticating that the contents are unmodified.