[secdir] secdir review of draft-ietf-storm-iser-12.txt

Stephen Kent <kent@bbn.com> Wed, 17 October 2012 23:57 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7321F8691 for <secdir@ietfa.amsl.com>; Wed, 17 Oct 2012 16:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDvu6WdTyXUI for <secdir@ietfa.amsl.com>; Wed, 17 Oct 2012 16:57:00 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8796021F8686 for <secdir@ietf.org>; Wed, 17 Oct 2012 16:56:56 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:37646 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1TOdTj-000D6s-8V; Wed, 17 Oct 2012 19:56:47 -0400
Message-ID: <507F45BE.2040900@bbn.com>
Date: Wed, 17 Oct 2012 19:56:46 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121005 Thunderbird/16.0
MIME-Version: 1.0
To: mkosjc@gmail.com, alexandern@mellanox.com, nezhinsky@gmail.com, secdir <secdir@ietf.org>, wes@mti-systems.com, martin.stiemerling@neclab.eu, black_david@emc.com, ttalpey@microsoft.com
Content-Type: multipart/alternative; boundary="------------060307030700040502040303"
Subject: [secdir] secdir review of draft-ietf-storm-iser-12.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2012 23:57:03 -0000

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.