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

["Black, David" <[e-mail]>]

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:[e-mail]]
Sent: Monday, November 05, 2012 5:33 PM
To: Black, David
Cc: [e-mail]; [e-mail]; [e-mail]; secdir; [e-mail]; [e-mail]; [e-mail]; 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