Re: [secdir] draft-ietf-storm-iser and IPsec version requirements

Stephen Kent <kent@bbn.com> Tue, 18 June 2013 15:51 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 78E0121F9955 for <secdir@ietfa.amsl.com>; Tue, 18 Jun 2013 08:51:00 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m+CYkI5liIT for <secdir@ietfa.amsl.com>; Tue, 18 Jun 2013 08:50:46 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB8521F9815 for <secdir@ietf.org>; Tue, 18 Jun 2013 08:50:45 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49476) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1UoyB5-000Dvc-GO; Tue, 18 Jun 2013 11:50:39 -0400
Message-ID: <51C081CF.6060208@bbn.com>
Date: Tue, 18 Jun 2013 11:50:39 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Black, David" <david.black@emc.com>
References: <507F45BE.2040900@bbn.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B01F@MX15A.corp.emc.com> <50983EB5.2010501@bbn.com> <8D3D17ACE214DC429325B2B98F3AE712980CA080@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712980CA080@MX15A.corp.emc.com>
Content-Type: multipart/alternative; boundary="------------080706070301050905020006"
Cc: "mkosjc@gmail.com" <mkosjc@gmail.com>, Mallikarjun Chadalapaka <cbm@chadalapaka.com>, "ttalpey@microsoft.com" <ttalpey@microsoft.com>, secdir <secdir@ietf.org>, "nezhinsky@gmail.com" <nezhinsky@gmail.com>, "alexandern@mellanox.com" <alexandern@mellanox.com>, "spencerdawkins.ietf@gmail.com" <spencerdawkins.ietf@gmail.com>, "martin.stiemerling@neclab.eu" <martin.stiemerling@neclab.eu>
Subject: Re: [secdir] draft-ietf-storm-iser and IPsec version requirements
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: Tue, 18 Jun 2013 15:51:00 -0000

David,

Thanks for the followup note. I've been on vacation, so I just read your 
message.
I assume everything is OK now.

Steve
----
On 6/6/13 7:03 PM, Black, David wrote:
>
> Steve,
>
> This is a much delayed follow-up on the IPsec version concern noted
>
> in the secdir review of draft-ietf-storm-iser found.  After further
>
> investigation, it turns out that the iSER draft implicitly used
>
> different sets of IPsec requirements for the iSCSI vs. RDMA layers
>
> of the iSER protocol stack.  That was not a good approach, as the
>
> protocol stack is iSER/RDMA/TCP/IP, so a single common IPsec
>
> implementation is likely to be used for both iSER and RDMA, but
>
> doing the proverbial "right thing" has taken a while.
>
> Getting to a single common set of IPsec requirements required a new
>
> draft. That new storm WG draft has just been posted; it updates
>
> RFC 3723's IPsec requirements to encompass IPsec v3 (4301 series RFCs).
>
> That update covers iSCSI, iSER, the iWARP RDMA protocols, and all other
>
> protocols that use the IPsec requirements for IP Storage in RFC 3723:
>
> http://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update/
>
> Yaron Sheffer's prompt review of that draft (thank you!) found a
>
> few minor problems, which will be addressed in a -01 version to be
>
> posted in the next few days.
>
> The just-posted -14 version of the iSER draft contains a normative
>
> reference to that ipsec-ips-update draft, with the result that the IPsec
>
> requirements are now consistent and include IPsec v3 (4301 series RFCs).
>
> Everything else noted in the secdir review has been addressed in that
>
> new -14 version.
>
> Thanks,
> --David
>
> *From:*Stephen Kent [mailto:kent@bbn.com]
> *Sent:* Monday, November 05, 2012 5:33 PM
> *To:* Black, David
> *Cc:* mkosjc@gmail.com; alexandern@mellanox.com; nezhinsky@gmail.com; 
> secdir; wes@mti-systems.com; martin.stiemerling@neclab.eu; 
> ttalpey@microsoft.com; Mallikarjun Chadalapaka; Steve Kent
> *Subject:* Re: secdir review of draft-ietf-storm-iser-12.txt
>
> David,
>
>
> Steve,
>
> Thank you for this review.
>
> > RFC 5042 analyzes security issues 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
>
> > RFCs were cited. (OK, time to fess up, which SECDIR member reviewed 5042?)
>
> A conscious and deliberate decision was made at that time to continue 
> to use
>
> the IP Storage profile of the older IPsec RFCs (2401 series) as 
> specified in
>
> RFC 3723 for consistency.  While that decision was apparently not recorded
>
> in RFC 5042, another RFC in that series, RFC 5040 does have this to say in
>
> its Security Considerations (Section 8):
>
>    The IPsec requirements for RDDP are based on the version of IPsec
>
>    specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC
>
>    3723 [RFC3723], despite the existence of a newer version of IPsec
>
>    specified in RFC 4301 [RFC4301] and related RFCs [RFC4303],
>
>    [RFC4306], [RFC4835].  One of the important early applications of the
>
>    RDDP protocols is their use with iSCSI [iSER]; RDDP's IPsec
>
>    requirements follow those of IPsec in order to facilitate that usage
>
>    by allowing a common profile of IPsec to be used with iSCSI and the
>
>    RDDP protocols.  In the future, RFC 3723 may be updated to the newer
>
>    version of IPsec, and the IPsec security requirements of any such
>
>    update should apply uniformly to iSCSI and the RDDP protocols.
>
> So, I think the (anonymous) SECDIR reviewer is off the hook on this one,
>
> which is just as well as (IIRC), at least one of the SEC ADs at the time
>
> was also involved :-).
>
> The consolidated iSCSI draft updates RFC 3723 to extend that IPsec profile
>
> to the 4301 series RFCs (as well as to the current IKEv2 specification,
>
> RFC 5996), although the 2401 series RFCs are still the "MUST implement"
>
> requirements based on what has been widely implemented.  I will check with
>
> the current security ADs (both of whom just happen to be holding Discuss
>
> positions on that iSCSI draft for good reasons) about whether to go ahead
>
> and use that iSCSI draft to update the 5040 series RFCs - I think that
>
> should probably be done.
>
> Thanks for the explanation. If the WG and ADs choose to stick with the 
> 3401 series,
> I think it would be useful to readers to note the rationale for this 
> in the SC section.
>
> > 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.)
>
> You could have just called that an editorial nit :-) - we'll fix it, 
> regardless.
>
> Too often I review docs where the authors don't know the difference, 
> which is why
> I flag issues like this. but, in your case I'll chalk it up as a typo :-).
>
> > 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.
>
> Not exactly ;-).  The IPsec requirements are consistently "MUST implement,
>
> MAY use".
>
> Right. sorry for my sloppy characterization.
>
> > 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.
>
> Will edit and clarify as suggested.
>
> Thanks.
>
> > The Security Considerations section concludes with a paragraph that is
>
> > a bit mysterious.
>
> What's Halloween time without a good mystery :-) :-) ?
>
> good timing!
>
> > 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.
>
> We'll provide a better explanation in the Security Considerations section.
>
> What happened here is that  the original specification of iSER (RFC 5046)
>
> required (MUST) use of a Send with Invalidate RCaP primitive in some 
> cases.
>
> That primitive has the side effect of invalidating a buffer identifier,
>
> preventing future use (as the buffer identifier enables remote direct 
> access
>
> to memory), and that requirement allowed the implementation on the 
> receiving
>
> end to rely on use of that primitive to invalidate the buffer identifier.
>
> This draft allows use of a Send RCaP primitive that does not 
> invalidate the
>
> buffer identifier in all cases, and that exposes the buffer identifier to
>
> future use, thereby creating a potential security issue if the identifier
>
> was supposed to be invalidated.  Hence when invalidation of the buffer
>
> identifier is intended or required (e.g., it's not being cached for future
>
> reuse), an iSER implementation can no longer rely on the underlying use of
>
> an RCaP Send with Invalidate primitive, but has to instead explicitly 
> check
>
> the state of the buffer identifier and/or perform a local invalidation 
> if the
>
> identifier is still valid.
>
> Thanks for the explanation. I;m confident that your revision will make 
> this OK.
>
> No need for me to re-review.
>
> Steve
>