Last Call Review of draft-ietf-storm-iser-

Request Review of draft-ietf-storm-iser
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-10-22
Requested 2012-10-11
Authors Mike Ko, Alexander Nezhinsky
Draft last updated 2012-10-18
Completed reviews Genart Last Call review of -?? by Pete McCann
Genart Telechat review of -14 by Pete McCann (diff)
Secdir Last Call review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent 
State Completed
Review review-ietf-storm-iser-secdir-lc-kent-2012-10-18
Review result Has Issues
Review completed: 2012-10-18


I reviewed this document as part of the
        directorate's ongoing effort to review all IETF documents being
        processed by
        the IESG.


These comments
        were written
        primarily for the benefit of the security area directors.


Document editors and WG
        chairs should treat
        these comments just like any other last call comments.


        is a rather hefty document, running 97 pages, including 3
        appendices. The
        document specifies extensions to iSCSI to support RDMA (remote
        direct memory
        access). Since this is an extension of iSCCI, it inherits the
        security features
        available in that context. The new, consolidated iSCSI document
        is even longer
        than this document (342 pages!), and it contains a substantial
        (12 page)
        security considerations section. So, referring to the iSCSI
        considerations text is an appropriate indirection here.


        document states that “iSER requires no changes to iSCSI
        security and text mode negotiation mechanisms.” (The wording
        here is a bit
        worrisome as suggests that the authors equate security with
        since the more general, and accurate, use of the term “security”


        security considerations section of the iSER document is less
        than a page in
        length. It begins by noting that if iSER operates above an RCaP
        (RDMA capable
        protocol) layer the security considerations are the same as for
        the RCaP layer,
        and refers to RFC 5042. RFC 5042 analyzes security issuers
        associated with
        RDMA, so it is an appropriate reference here. As an aside, I’m
        surprised to see
        that RFC 5042 refers to the old IPsec RFCs (2401 series),
        instead of the newer
        IPsec RFCs (4301 series). RFC 5042 was published in October
        2007, almost 2
        years after the later set of IPsec RFCs, so there was plenty of
        time to update
        the references! I didn’t see any rationale in 5042 for why the
        earlier IPsec
        RCCs were cited. (OK, time to fess up, which SECDIR member
        reviewed 5042?)


        section states plainly that iSER is “functionally iSCSI” and
        thus all of the
        iSCSI security considerations apply. In particular, when iSER is
        carried over
        IP networks, IPsec MUST be employed. (When iSER is not carried
        over IP nets,
        security mechanisms applicable to the RCaP layer are to be
        employed, as per RFC


        is an overly-long, single sentence paragraph discussing how to
        minimize the
        potential for DoS attacks. The wording is a bit vague, but the
        text refers to
        the discussion of initiator and target behaviors, which provide
        the relevant
        details. This is a very narrow focus on DoS, and I suggest that
        the paragraph
        in question be augmented to state that the only DoS attacks
        addressed here are
        ones that could cause resource exhaustion at a target.


        Security Considerations section concludes with a paragraph that
        is a bit
        mysterious. It seems to warn implementers of a residual
        associated with the use of a buffer identifier. However, the
        section to which
        this paragraph refers contains the following sentence:


        iSER layer MUST check that STag invalidation has occurred
        whenever receipt of a
        Send with Invalidate message is the expected means of causing an
        STag to be
        invalidated, and MUST perform the STag invalidation if the STag
        has not already
        been invalidated (e.g., because a Send message was used instead
        of Send with


This sort of writing does not explain
        complex issues to a