Re: IPsec and RDDP as a transport

To follow up on Dwight's point about well-designed ULPs with buffer use 
restrictions, here is a very short summary of how iSER deals with this 
today (and the IPS WG can choose to tighten these further once it 
hopefully takes up the RDMA work) since we seem to be on iSCSI/iSER anyway.

iSER target
- MUST cause invalidation of advertised peer STag via a
   SendInvSE message at the end of each I/O.
- MUST locally invalidate the Data Sink STags associated
   with the I/O whenever the I/O concludes abnormally
   (abort/reset etc.).
- SHOULD invalidate each Data Sink STag locally upon corresponding
   RDMA Read's conclusion.


iSER initiator
- MUST double check the auto-invalidation realized via
   SendInvSE upon each I/O conclusion.
- MUST invalidate the second STag locally upon bidirectional
   command completion.
- MUST locally invalidate the STags associated with the I/O
   whenever the I/O concludes abnormally (abort/reset etc.).
- All this MUST happen before the final I/O status is
   delivered to the iSCSI layer


BTW, I'd appreciate if someone can provide a precise description of
the scenario leading to the new "hole" with iSCSI/iSER and why the same 
cannot be encountered with iSCSI-3720 (RFC #).
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com



Barron, Dwight wrote:

> Caitlin wrote:
> 
>>>Or more generally, a buffer that the application intends to use is 
>>>still exposed to update from non-authenticated DDP packets.
>>
> David Black responded:
> 
>>The latter is the better statement of the vulnerability, as 
>>it includes man-in-the-middle traffic injection, e.g., via a 
>>connection hijack.
> 
> 
> Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, MPI)
> and ad-hoc applications in determining responsibility of implementing
> protocol behaviors that do not leave themselves vulnerable? I believe it
> is quite innoccuous and appropriate to require that IETF (or other)
> ULPs be designed in a matter that does not notify ULP consumers of
> available data while an Stag is 
> still mapped to that data. Both remote and local Stag invalidations are
> envisioned to be very 
> lightweight operations. I also believe that the vast majority of data
> movement and usage of 
> DDP will occur through these and other defined ULPs. 
> 
> Regards,
> Dwight
> 
> 
> 
> 
>>-----Original Message-----
>>From: [email protected] [mailto:[email protected]] On 
>>Behalf Of [email protected]
>>Sent: Sunday, June 06, 2004 4:36 PM
>>To: [email protected]; [email protected]
>>Subject: RE: [rddp] IPsec and RDDP as a transport
>>
>>
>>Several clarifying comments:
>>
>>
>>>To summarize, the vulnerability occurs when an application 
>>
>>trusts its 
>>
>>>remote peer to follow the upper layer protocol regarding 
>>
>>STag access 
>>
>>>rather than using the local interface to enforce compliance.
>>>
>>>Or more generally, a buffer that the application intends to use is 
>>>still exposed to update from non-authenticated DDP packets.
>>
>>The latter is the better statement of the vulnerability, as 
>>it includes man-in-the-middle traffic injection, e.g., via a 
>>connection hijack.
>>
>>
>>>David has proposed the ULP be able to rely on the availability of 
>>>IPsec authentication of DDP packets.
>>
>>Not exactly ... this was originally proposed in the RDDP 
>>security draft, although with a "SHOULD implement" 
>>requirement that would have to be changed to "MUST implement" 
>>in order to obtain IESG approval. This was discussed in 
>>Seoul, which is why the original thread on this topic carries 
>>the issue (4) tag from Seoul.
>>
>>To the extent that I've pointed out that the IESG is very 
>>serious about mandatory-to-implement security, I guess it's 
>>fair to tag me with some responsibility for this proposal, BUT ...
>>
>>... I have also posted that while IPsec is sufficient to deal 
>>with this problem, it's more than is necessary.  It should be 
>>possible to design a mechanism that only authenticates the 
>>RDDP headers via some sort of keyed cryptographic integrity 
>>check.  I would ask everyone to please stop looking for 
>>conspiracy theories about how this is somehow part of a grand 
>>plot to require IPsec everywhere.
>>
>>Despite this, I do think local functionality/interface 
>>modifications (e.g., restrict all STags to be 'one-shot' and 
>>require implementations to enforce this) are the preferred 
>>approach because they block not only the man-in-the-middle 
>>but also the misbehaved or malicious client; this is quite 
>>useful for protocols like NFS that generally cannot place 
>>complete trust in clients.  I probably should have said this 
>>more strenuously about a dozen posts ago.
>>
>>Caitlin's proposal below appears to be headed in a productive 
>>direction, but at the end of the day, we have to abide by the 
>>IESG's "if you broke it, provide tools to fix it" approach to 
>>mandatory-to-implement security
>>- if the WG wants its specifications to provide long-lived 
>>STag functionality for use by protocols that are prepared to 
>>assume the requisite high degree of trust among the 
>>communicating peers, the WG is obligated to also provide the 
>>mandatory-to-implement security that such protocols can use 
>>to prevent man-in-the-middle attacks on/via that long-lived 
>>STag functionality.  At the moment, I'm not certain whether 
>>Caitlin's proposal is sufficient in this regard.
>>
>>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 protected]        Mobile: +1 (978) 394-7754
>>----------------------------------------------------
>>
>>
>>>-----Original Message-----
>>>From: Caitlin Bestler [mailto:[email protected]]
>>>Sent: Saturday, June 05, 2004 6:59 AM
>>>To: [email protected]; RDDP
>>>Subject: Re: [rddp] IPsec and RDDP as a transport
>>>
>>>
>>>
>>>On Jun 5, 2004, at 3:56 AM, [email protected] wrote:
>>>
>>>
>>>>Dwight,
>>>>
>>>>
>>>>>Sorry to be dense, but I'm still having trouble visualizing the 
>>>>>attack that makes DDP more vulnerable. I think it has been 
>>>>>relegated to a man in the middle attack scenario, as bogus data 
>>>>>from the real peer always gets through, even with IPSEC enabled. 
>>>>>The transport layer behavior is the same with/without 
>>
>>DDP headers; 
>>
>>>>>a packet with an appropriate transport sequence number 
>>
>>gets ACKed 
>>
>>>>>and passed upstream to be placed in a buffer. The buffer 
>>
>>eventually 
>>
>>>>>gets passed to the application.
>>>>
>>>>The difference happens here.  If the STag is 'long-lived' or
>>
>>'persistent'
>>
>>>>and has not been invalidated, the buffer can still be modified 
>>>>remotely
>>>>*after* being passed to the application.  Such modification is not
>>>>possible in the absence of DDP.  If the STag is 
>>
>>'one-shot' (in whatever
>>
>>>>sense that restriction is defined), the important 
>>
>>property is that the
>>
>>>>application can rely on the data not being changed by 
>>
>>remote access
>>
>>>>after the buffer has been passed to the application.  If the WG
>>>>is prepared to restrict all STags to be 'one-shot' so 
>>
>>that at the point
>>
>>>>where the buffer is passed to the application, the STag 
>>
>>used to deliver
>>
>>>>the data MUST be invalid (and the RDDP implementation is 
>>
>>responsible
>>
>>>>for ensuring this), then it should be possible to avoid additional
>>>>security requirements in this area.
>>>
>>>To summarize, the vulnerability occurs when an application 
>>
>>trusts its 
>>
>>>remote peer to follow the upper layer protocol regarding 
>>
>>STag access 
>>
>>>rather than using the local interface to enforce compliance.
>>>
>>>Or more generally, a buffer that the application intends to use is 
>>>still exposed to update from non-authenticated DDP packets.
>>>
>>>This is indeed a new security vulnerability, the question is how to 
>>>deal with it.
>>>
>>>The current drafts take a "well we told you not to do that" 
>>
>>approach. 
>>
>>>Personally, I still find this valid. But I will concede that others 
>>>might consider this to be inadequate. But for the record I 
>>
>>will point 
>>
>>>out that the RDDP layer simply cannot prevent the ULP from doing 
>>>stupid things. Consider the fundamental rule that an 
>>
>>exposed buffer is 
>>
>>>undefined *until* the ULP infers delivery from a untagged 
>>
>>message or 
>>
>>>RDMA Read completion. An application that attempts to read smoke 
>>>signals in partially update RDMA accessible buffers based only on 
>>>tagged writes is very vulnerable not only to attack but to 
>>
>>to unstable 
>>
>>>behavior. I doubt that anyone would propose requiring the 
>>
>>RDDP layer 
>>
>>>to remove read access for the ULP on undelivered buffers 
>>
>>that it has 
>>
>>>update access to. And the vulnerability to unstable 
>>
>>behavior would be 
>>
>>>there even over IPsec.
>>>
>>>David has proposed the ULP be able to rely on the availability of 
>>>IPsec authentication of DDP packets.
>>>
>>>I believe it would be more appropriate to require the local 
>>
>>interface 
>>
>>>to provide adequate tools so that applications would 
>>
>>neither be forced 
>>
>>>to overexpose buffers, or even be prone to do so by the defaults of 
>>>the local interface. "Defaults" here would include omission 
>>
>>of extra 
>>
>>>steps that an application
>>>*should* be taking, but the local interface requires 
>>
>>additional steps 
>>
>>>to invoke.
>>>
>>>The proposed restriction to "one shot" STags would be one 
>>
>>such local 
>>
>>>interface change, but I believe it is also to extreme.
>>>
>>>I believe we can determine what local interface 
>>
>>requirements would be 
>>
>>>appropriate if we examine the current gaps:
>>>
>>>- The application can be encouraged to rely upon the remote
>>>    peer to invalidate an STag when the transaction is done.
>>>    If an expected remote invalidation is not performed, the
>>>    application is typically required to invalidate the STag
>>>    ifself. This is typically an asynchronous operation which
>>>    would require the application to add an extra state before
>>>    properly utilizing the buffer only after it had been secured.
>>>
>>>-  Some applications advertise an aggregate buffer to be
>>>    used over the span of several untagged messages. Each
>>>    untagged message would indicate what portion of the
>>>    advertised buffer had been used, and at the ULP layer
>>>    pledge not to make further writes to that portion.
>>>
>>>    Current local interfaces lack any support for enforcement
>>>    of this model. When the portion used by the remote peer
>>>    on each response is variably sized, there is no way for
>>>    the Data Sink to remove one portion of a window without
>>>    at least momentarily making the entire STag invalid.
>>>
>>>To address these problems I would propose the following
>>>local interface enhancements, which could be implemented
>>>as an alternative to authenticating DDP packets with IPsec
>>>or other equivalent transport-layer solutions:
>>>
>>>-- The local interface MUST provide an option where a posted
>>>     receive operation will complete in error unless the Send
>>>     successfully invalidated an STag.
>>>
>>>-- The local interface MUST provide an option where a posted
>>>     receive operation will not complete until after a specified
>>>     STag has been invalidated.
>>>
>>>-- The local interface MUST provide an option to rebind an
>>>     STag to a contiguous subset of its current range without
>>>     taking it through an intermediate invalid state.
>>>
>>>With these tools an application can easily ensure that the DDP 
>>>exposure of an STag matches the ULP required exposure. Given the 
>>>ability to easily remove a buffer's exposure *before* using it the 
>>>application will face *no* additional security vulnerability and 
>>>therefore would *not* require IPsec.
>>>
>>>That may also be true with a subset of the above. The last 
>>
>>one is the 
>>
>>>only requirement that cannot be implemented by a shim layer over 
>>>current verbs, and it is admittedly of the least generality.
>>>
>>>
>>>
>>>
>>>--
>>>Caitlin Bestler
>>>http://asomi.com/
>>>
>>
>>_______________________________________________
>>rddp mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/rddp
>>
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp