Subject: RE: [rddp] comments on draft-black-rdma-concerns-00.txt

From: [email-masked]
Date: Sat, 27 Jul 2002 17:06:44 -0400

A few comments:

> This is a local interface issue, not a protocol issue.

That doesn't rule it out of scope - if properties of the local
interface are important to the secure use of the protocol, those
properties need to be specified.  It's not necessary to specify
the local interface itself - functional requirements/constraints
on it are sufficient to get the job done.  One example can be found
in the IPsec architecture RFC - see Section 4.4 (and subsections)
of RFC 2401.

> The ULP Data Sink / Client MUST ensure that it has used
> local interfaces to enable RDDP layer memory access with
> sufficient rights to match the advertised buffers.
> 
> There is no *protocol* justification for mandating that all
> Data Sinks MUST protect the rest of their memory. The
> protocol MUST NOT *prevent* them from doing so.

The actual situation may be somewhere in between:
- It's probably appropriate to require (MUST implement) suitable
	data protection mechanisms even if their use is OPTIONAL.
	As I noted earlier, if the RDDP mechanisms are being used
	only to transfer data and not control, this overwrite
	attack can't cause application integrity problems and
	hence protecting against it may not be necessary.
- The "Security Considerations" section of the protocol
	specification(s) will need to discuss this overwrite
	possibility, when/how it poses a risk, and what to do
	about it.  At a minimum this will result in instructions
	that *if* a particular application's use of RDDP is
	vulnerable to this sort of overwrite, then suitable
	preventative measures MUST be employed, a useful
	warning for those figuring out how to use RDDP with
	other protocols.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Saturday, July 27, 2002 12:19 PM
> To: [email-masked]
> Cc: Michael Krause; [email-masked]
> Subject: Re: [rddp] comments on draft-black-rdma-concerns-00.txt 
> 
> 
> On 7/27/02, Bill Sommerfeld wrote:
> 
> 
> >The WG charter says:
> >
> > The working group will ensure that the resulting
> > technology will be secure and will not enable new attacks
> > on systems supporting RDDP.
> >
> >An overwrite race condition sounds to me like a "new attack".
> 
> This is a local interface issue, not a protocol issue.
> 
> Fundamentally, the Data Source does not need, nor should
> it have, the complete semantics of the STag that is part
> of the buffer advertisement it received.
> 
> The only knowledge it requires is the extent of permission
> given to it by the ULP. DAFS is probably typical of the
> rules most ULPs will establish:
> 
> -- the client sends a request to an anonymous buffer that
>    contains a buffer advertisement and a request for some
>    work to be done using that buffer.
>    
> -- the server performs that work.
> 
> -- the server sends a reply back to client, also to an 
>    anonymous buffer,  thereby terminating its rights to
>    the advertised buffer.
> 
> The ULP Data Sink / Client MUST ensure that it has used
> local interfaces to enable RDDP layer memory access with
> sufficient rights to match the advertised buffers.
> 
> There is no *protocol* justification for mandating that all
> Data Sinks MUST protect the rest of their memory. The
> protocol MUST NOT *prevent* them from doing so.
> 
> Nothing in any of the iWARP/ROI/RDDP proposals has ever done
> anything to prevent more precise local protection of memory.
> 
> 
> 
> 
> 
> Even if such local  mechanisms are available, it  would be
> inappropriate to make  them mandatory. There are common
> practices with RDMA Writes which are incompatible with
> deregistering the STag automatically:
> 
> -- Enabling a single large region specifically  for the 
>     client, and then advertising buffers within that STag.
>     This avoids having to create and distribute STags for
>     each interaction. This model can be very attractive
>     when the peers have long lasting connections  and
>     many interactions, such as for an RDBMS.
> -- Enabling a large buffer that is filled on an ongoing
>     basis, but with each delivery being a notified event.
>     This can be useful for delivery a series of variable
>     sized data, especially for streaming media.
>     
> So ultimately, disabling of an STag is both a ULP and local
> interface question. The question is whether to mandate a
> specific, and potentially expensive behavior to close a
> "vunerability window" between the time the message is
> received that would have automatically disabled an STag and
> when the ULP would have responded to the notification and
> disabled the STag itself.
> 
> But keep in mind that the same buffers were vunerable to
> unauthorized overwrites from the very same sources during
> the entire period *prior* to the completing message.
> 
> Now there may be some applications where additional
> complexity on the NIC is justifiable if it reduces
> vunerabilty  in *ANY* way. They would probably be better
> served by sticking with non-RDDP messages with
> authenticating signatures to every update, but conceivably
> they could decide that automatic STag release was a valuable
> feature for them. However, mandating that *all* Data Sinks
> MUST exercise the *same* data protection policies is simply
> not called for.
>  
> 
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 28 Jul 2002 12:33:36 -0400

> 	hence protecting against it may not be necessary.

In thinking some more about this, the "data"/"control" distinction
doesn't quite capture the risks involved with overwrites.  It's more
of a a "read once" vs "read multiple" case -- overwrites which come in
between multiple reads may cause unexpected application behavior.

So, one could conceivably write a parser for a protocol which loads
each byte at most once -- in which case, overwrites are irrelevant.

Consider anther hypothetical system where a checksum is computed by
the receiving application and stored as part of metadata.

An app is notified of rddp'ed data, computes a checksum over the data,
and then schedules the data to be written to stable store (presumably
with another DMA operation).  Thus, despite being "bulk data", each
byte is read twice -- once by whatever computes the checksum, and
again by the disk controller writing it out to stable store.

So, in parallel with this (during or after the checksum computation),
another rddp/rdma message comes in and overwrites one of the pages
being written, causing the image in stable store to not match the
checksum...

Depending on the scope of the checksum (this may be a checksum over a
batch of transactions being written to a journal), this may
effectively deny future access to more than just the data which the
peer had write access to...

Naturally, one sure-fire way to avoid overwrite complications is just
copy the data to a buffer which is out of reach of the rddp/rdma
system, but I thought the whole point of this exercise is to avoid the
cost of data copies..

Besides the Security Considerations section, I think there may also be
fodder for an applicability statements -- the cost of buffer
registration/deregistration needed to make a system or application
safe against unexpected remote overwrites may rival or exceed the cost
of the data copies avoided by use of the rddp/rdma mechanism, at which
point the added complexity makes it a net lose.

					- Bill

---

From: Caitlin Bestler <[email-masked]>
Date: Sun, 28 Jul 2002 16:47:59 -0500

On 7/28/02, Bill Sommerfeld wrote:

>In thinking some more about this, the "data"/"control"
>distinction doesn't quite capture the risks involved with
>overwrites.  It's more of a a "read once" vs "read
>multiple" case -- overwrites which come in between
>multiple reads may cause unexpected application behavior.
>
>So, one could conceivably write a parser for a protocol
>which loads each byte at most once -- in which case,
>overwrites are irrelevant.
>
>Consider anther hypothetical system where a checksum is
>computed by the receiving application and stored as part
>of metadata.
>
>An app is notified of rddp'ed data, computes a checksum
>over the data, and then schedules the data to be written
>to stable store (presumably with another DMA operation). 
>Thus, despite being "bulk data", each byte is read twice
>-- once by whatever computes the checksum, and again by
>the disk controller writing it out to stable store.
>
>So, in parallel with this (during or after the checksum
>computation), another rddp/rdma message comes in and
>overwrites one of the pages being written, causing the
>image in stable store to not match the checksum...
>
>Depending on the scope of the checksum (this may be a
>checksum over a batch of transactions being written to a
>journal), this may effectively deny future access to more
>than just the data which the peer had write access to...
>
>Naturally, one sure-fire way to avoid overwrite
>complications is just copy the data to a buffer which is
>out of reach of the rddp/rdma system, but I thought the
>whole point of this exercise is to avoid the cost of data
>copies..
>
>Besides the Security Considerations section, I think there
>may also be fodder for an applicability statements -- the
>cost of buffer registration/deregistration needed to make
>a system or application safe against unexpected remote
>overwrites may rival or exceed the cost of the data copies
>avoided by use of the rddp/rdma mechanism, at which point
>the added complexity makes it a net lose.
>

This sort of scenario is indeed the best justification for
automatic de-registration of the STag. Whether or not an
actual checksum is calculated, the notification that a reply
has been received should indicate transactional closure.

The interface I would favor would be one where the Data Sink
ULP indicated that it wanted an STag deregistered when
notification was made on receive-completion.

When the ULP gets that notification it would be ideal that
it knew that there would be no more modifications of the
advertised buffer, so that it could begin checksum
validation and processing.

I will point out that even without such a local interface it
could simply deregister the STag itself, and when *that*
completes it would have achieved the exact same set of
guaranteed behavior. This is especially true if the local
interface provides for synchronous invalidation of an STag.

It should be noted that any such semantics are not
compatible with InfiniBand R-Key semantics. I wouldn't argue
that STags matching IB R-Keys is a requirement, but I would
favor having a justification for each difference.