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

From: [email-masked]
Date: Mon, 13 Jun 2005 10:57:52 -0400

Mallikarjun,

I think this is ok, although there will probably be quibbles
with the wording  and requests for further elaboration later on.

Mike - Please make sure that the new "MUST" (essentially
"MUST complete any security negotiation before allocation
of data movement connection resources" is reflected in the
iSER draft.

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

> -----Original Message-----
> From: Mallikarjun C. [mailto:[email-masked]] 
> Sent: Wednesday, June 08, 2005 10:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ips] WG Last Call Review: DA
> 
> 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
> Networked Storage Architecture
> StorageWorks Division
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> 
> 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.
> 

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

---

From: Mike Ko <[email-masked]>
Date: Mon, 13 Jun 2005 17:06:47 -0700

David,

The essence of the 2nd paragraph from the Security Considerations section 
of the DA draft will be added in section 5.1.1 (initiator behavior during 
iSCSI/iSER connection setup) and section 5.1.2 (target behavior).  The 
"MUST" requirement on completing any security negotiation before 
allocating connection resources will remove all sentences in both sections 
that allow the allocation to occur before iSCSI login negotiations.

Mike
To:     [email-masked], [email-masked]
cc:     [email-masked] 
Subject:        RE: [Ips] WG Last Call Review: DA

Mallikarjun,

Thanks,
--David