Last Call Review of draft-ietf-storm-iser-
review-ietf-storm-iser-secdir-lc-kent-2012-10-18-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-storm-iser-secdir-lc-kent-2012-10-18

I reviewed this document as part of the
        security
        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.




 




This
        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
        security
        considerations text is an appropriate indirection here.




 




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




 




The
        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?)




 




This
        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
        5042.) 




 




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




 




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




 




“That
        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
        Invalidate).”




 




This sort of writing does not explain
        complex issues to a
        reader.