Subject: RE: [Ips] WG Last Call Review: DA

From: [email-masked]
Date: Tue, 7 Jun 2005 17:36:20 -0400

Mallikarjun,

> Thanks for the review.
> 
> In clear hindsight, I think not referencing RFC 3723 in this 
> section is a mistake.  I will put that in.
> 
>  > - Control/Data separation.  The mechanisms for transmission
>  > 	of iSCSI control vs. data are deliberately split by
>  > 	DA, and there is no requirement that they even use
>  > 	the same transport medium.
> 
> RFC 3720 defines several MUST requirements on ordering relationships 
> across control & data for a given task besides a mandatory deterministic 
> task allegiance model - DA is not changing any of that (DA has a 
> normative reference on RFC 3720), nor allowing any additional 
> flexibility in compliance here.
> 
> Sending bulk data transfers (prompted by Put/Get_Data Primitives) on a 
> different transport medium would be as ill-advised as sending just the 
> iSCSI-3720 Data-out/Data-in PDUs on a different TCP connection in 
> traditional iSCSI implementations.

Both of the above paragraphs are probably good content to add to the
DA draft.  If memory serves, the people working on iSER for InfiniBand
are doing more separation of control/data transfers than realized via
iSER/RDDP.  The point I'm looking to convey here is that the control/
data separation in DA may provide an attacker more leverage by making
it easier to isolate/view/modify one without getting involved in the
other.  Any use of DA will need to address this in some fashion.

>  >DA introduces
>  > 	explicit management of resources at the DI interface,
>  > 	including data buffers and Datamover connection resources.
>  > 	The latter in particular is likely to be a limited class
>  > 	of resource in some anticipated implementations.
> 
> By "Datamover connection resources", I assume you mean the logical 
> equivalent of posted receive buffers.  The potential for DoS attack, 
> IMHO, is qualitatively not different from the iSCSI-3720 case, and so 
> appealing to RFC 3723 should address this basic concern.  
> Would you agree?

For resources that already exist in iSCSI in the absence of DA/iSER and
are managed in the same way, RFC 3723 should be fine.  What's bothering
me is the Allocate_Connection_Resources primitive which is intended
to deal with resources that either don't exist, or aren't managed
in the same pre-allocation fashion in traditional/vanilla iSCSI ...

> Another option is to informationally reference the RDDP security draft 
> to direct the reader's attention to suitable remedies for the case of 
> RDDP-based Datamovers.

How about referencing that draft as an example *and* generalizing to
non-RDDP Datamovers, using that draft as an example of the analysis of
resource exhaustion and application of countermeasures that needs to
be done?

Thanks,
--David

> Thanks.
> 
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> StorageWorks Division
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> [email-masked] wrote:
> > I have reviewed the DA draft, draft-ietf-ips-iwarp-da-02.txt,
> > and in addition to a number of editorial comments that I will
> > send to Mallikarjun, I have one important technical comment -
> > 
> > The Security Considerations section essentially says "there
> > are no new security considerations because DA does not define
> > a wire protocol."  That is not correct because DA introduces
> > at least two architectural concepts to iSCSI that do have
> > security implications:
> > - Control/Data separation.  The mechanisms for transmission
> > 	of iSCSI control vs. data are deliberately split by
> > 	DA, and there is no requirement that they even use
> > 	the same transport medium.  This introduces new
> > 	opportunities for an attacker to fiddle with things,
> > 	and may place additional security responsibility on
> > 	an iSCSI-DA implementation over and above an iSCSI
> > 	implementation.
> > - Explicit resource management/control.  DA introduces
> > 	explicit management of resources at the DI interface,
> > 	including data buffers and Datamover connection resources.
> > 	The latter in particular is likely to be a limited class
> > 	of resource in some anticipated implementations.  Some
> > 	discussion is needed on the possibility of a denial-of-
> > 	service attack via resource exhaustion and the functional
> > 	responsibility of an iSCSI-DA implementation to defend
> > 	against this.
> > A new Security Considerations section will be needed to address
> > at least these areas.
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 08 Jun 2005 19:15:44 -0700

David,

Here is the security re-write for the next rev of DA.  Please 
review/comment.

Note the new MUST requirement around iSCSI SecurityNegotiation stage wrt 
resource allocation.  I do not believe it requires any changes to the 
iSER draft, but other co-authors may want to check me on that.

Thanks.

Mallikarjun

Mallikarjun Chadalapaka

12	Security Considerations
12.1	Architectural Considerations
DA enables compliant iSCSI implementations to realize a control and data 
separation in the way they interact with their Datamover protocols. 
Note however that this separation does not imply a separation in 
transport mediums between control traffic and data traffic - basic iSCSI 
architecture with respect to tasks and PDU relationships to tasks 
remains unchanged.  [RFC3720] defines several MUST requirements on 
ordering relationships across control and data for a given task besides 
a mandatory deterministic task allegiance model - DA does not change 
this basic architecture (DA has a normative reference on [RFC3720]) nor 
allow any additional flexibility in compliance in this area.  To 
summarize, sending bulk data transfers (prompted by Put_Data and 
Get_Data Primitive invocations) on a different transport medium would be 
as ill-advised as sending just the Data-out/Data-in PDUs on a different 
TCP connection in RFC 3720-based iSCSI implementations.  Consequently, 
all the iSCSI-related security text in [RFC3723] is directly applicable 
to a DA-enabled iSCSI implementation.

Another area with security implications is the Datamover connection 
resource management model which DA defines – particularly the 
Allocate_Connection_Resources Primitive.  An inadvertent realization of 
this model could leave an iSCSI implementation exposed to denial of 
service attacks.  As Figure 2 and Figure 3 in section 17.2 illustrate, 
the most effective countermeasure to this potential attack consists of 
performing the Datamover resource allocation when the iSCSI layer is 
sufficiently far along in the iSCSI Login Phase that it is reasonably 
certain that the peer side is not an attacker.  In particular, if the 
Login Phase includes a SecurityNegotiation stage, an iSCSI end node MUST 
defer the Datamover connection resource allocation (i.e. invoking the 
Allocate_Connection_Resources Primitive) to the 
LoginOperationalNegotiation stage ([RFC3720]) so that the resource 
allocation happens post-authentication.  This considerably minimizes the 
potential for a denial of service attack.

12.2	Wire Protocol Considerations
In view of the fact that the DA architecture itself does not define any 
new wire protocol nor propose modifications to the existing protocols, 
there are no additional wire protocol security considerations in 
employing DA itself.  However, a DA-compliant iSCSI implementation MUST 
comply with all the iSCSI-related requirements stipulated in [RFC3723] 
and [RFC3720].  Note further that in realizing DA, each Datamover 
protocol must define and elaborate as appropriate on any additional 
security considerations resulting from the use of that Datamover protocol.

All Datamover protocol designers are strongly recommended to refer to 
[RDDPSEC] for the types of security issues to consider.  While [RDDPSEC] 
elaborates on the security considerations applicable to an RDDP-based 
Datamover ([iSER]), the document is representative of the type of 
analysis of resource exhaustion and the application of countermeasures 
that needs to be done for any Datamover protocol.