[Ballot comment]
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

[Ballot comment]
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.

[Ballot discuss]
The following text in section 2 of the security draft is not
referenced in the normative requirements in section 12:

>  In any event, it is the responsibility of the Privileged Resource
>  Manager to ensure that no STag can be created that exposes memory
>  that the consumer had no authority to expose.


It seems clear that some normative requirement regarding this issue is
needed.  If the text in section 2 is not intended to be normative add
some text and point to it from section 12.  If the text in section 2
is intended to be normative point to it from section 12.

[Ballot comment]
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.

[Ballot comment]
The discussion of TLS in section 5.4 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.

[Ballot discuss]
The following text in section 2 is not referenced in the normative
requirements in section 12:

>  In any event, it is the responsibility of the Privileged Resource
>  Manager to ensure that no STag can be created that exposes memory
>  that the consumer had no authority to expose.


It seems clear that some normative requirement regarding this issue is
needed.  If the text in section 2 is not intended to be normative add
some text and point to it from section 12.  If the text in section 2
is intended to be normative point to it from section 12.

[Ballot discuss]
draft-ietf-rddp-security-09:

  The discussion in section 5.4.2 should consider DTLS (RFC 4347).
  It might be best handled as a separate section.

  draft-ietf-rddp-applicability-06:
 
  Section 6.6 says:
  >
  > A ULP that requires data integrity checking more thorough than an
  > end-to-end CRC32c should first invalidate all STags that reference
  > a buffer before applying their own integrity check.
  >
  Explanation is needed here.  The next paragraph (which is repeated
  below) suggests the use of IPsec for this greater integrity
  protection.  Why "invalidate all STags that reference a buffer"
  prior to IPsec encapsulation?

  Section 6.6 goes on to say:
  >
  > CRC32c only provides protection against random corruption.  To
  > protect against unauthorized alteration or forging of data packets,
  > security methods must be applied.  IPsec is supported for both SCTP
  > and MPA/TCP.
  >
  A bit more needs to be said about the use of IPsec.  Please see
  draft-bellovin-useipsec-04.txt.  At a minimum, the discussion of IPsec
  needs to say which IPsec protocol is to be used (AH or ESP) and say
  which mode is to be employed (transport mode or tunnel mode).  Also,
  in this situation, the cryptography needs to provide integrity.  Some
  encryption techniques provide confidentiality without providing
  integrity.  I pointer to parts of RFC 3723 might resolve this concern.

  The discussion in section 9.3 should consider DTLS (RFC 4347).

[Ballot discuss]
draft-ietf-rddp-security-09:

  The discussion in section 5.4.2 should consider DTLS (RFC 4347).
  It might be best handled as a separate section.

  draft-ietf-rddp-applicability-06:
 
  Section 6.6 says:
  >
  > A ULP that requires data integrity checking more thorough than an
  > end-to-end CRC32c should first invalidate all STags that reference
  > a buffer before applying their own integrity check.
  >
  Explanation is needed here.  The next paragraph (which is repeated
  below) suggests the use of IPsec for this greater integrity
  protection.  Why "invalidate all STags that reference a buffer"
  prior to IPsec encapsulation?

  Section 6.6 goes on to say:
  >
  > CRC32c only provides protection against random corruption.  To
  > protect against unauthorized alteration or forging of data packets,
  > security methods must be applied.  IPsec is supported for both SCTP
  > and MPA/TCP.
  >
  A bit more needs to be said about the use of IPsec.  Please see
  draft-bellovin-useipsec-04.txt.  At a minimum, the discussion of IPsec
  needs to say which IPsec protocol is to be used (AH or ESP) and say
  which mode is to be employed (transport mode or tunnel mode).  Also,
  in this situation, the cryptography needs to provide integrity.  Some
  encryption techniques provide confidentiality without providing
  integrity.  I pointer to parts of RFC 3723 might resolve this concern.

  The discussion in section 9.3 should consider DTLS (RFC 4347).

[Ballot comment]
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]

PROTO writeup:
                  DDP/RDMAP Security
                  draft-ietf-rddp-security-07.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (RDDP WG Chair)
------------------------------------------------------------------------

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, primarily from WG members.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has had limited review outside the WG.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

This is a security analysis document.  The Security Area should be
asked to review it sooner rather than later.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

Security expertise and interest exists in a limited portion of the WG.
In general, WG members with scurity expertise or interest understand
and agree with this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The ID nits checker says everything is ok.

  1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

There are two normative references to Internet-Drafts:

o draft-ietf-rddp-ddp - Publication has been requested along with
this draft.
o draft-ietf-rddp-rdmap - Publication has been requested along with
this draft.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

-- Technical Summary

  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 DDP and RDMAP, such as IPsec.

-- Working Group Summary

  Serious security analysis takes time - this document is no exception.
  There has been extensive review of this document in the WG.  The need
  for the Privileged Resource Manager was initially controversial, but
  the WG now has strong consensus for its necessity.

-- Protocol Quality

  The protocol has been reviewed for the rddp WG by David L. Black.