Subject: [rddp] Freeing QN=1 State

From: "Michael C. Cambria" <[email-masked]>
Date: Fri, 10 Dec 2004 12:50:10 -0500

When does draft-ietf-rddp-rdmap-02.txt consider an inbound RDMA Read 
Request Message finished such that the state associated with QN=1 (the 
IRRQ) for the RDMA Read Request can be freed?

Put another way, if IRRQ is 1 (for simplicity), when is it legal for a 
new RDMA Read Request to be received?  Is it:

a) Once the RDMA Read Response Message has been given to DDP?
b) Once the RDMA Read Response Message has been "acked" by the data sink?
c) up to the implementation?
d) specified somewhere that I just missed?

Using (a) as a solution I ran into a DoS problem.  The data sink keeps 
issuing RDMA Read Requests but the LLP window advertised by the data 
sink is so small (or closed) that the resources I believe the IRD 
negotiation was meant to protect actually get depleted.

A compliant sender should not send the next RDMA Read Request until a 
prior one has completed.  However, is the draft assuming a non malicious 
sender?  Personally, I prefer to protect my resources regardless.

I can't find supporting text in the draft for (b).   Doing (c) allows 
for (a) so is the same problem IMHO.

Thanks,
MikeC

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 10 Dec 2004 16:29:07 -0800

Well an implementation is free to lose track of its resources totally.

The key is that you cannot receive the RDMA Read Request that your
RDMA Read Response enabled sooner than you *could* have released
all resources associated with the RDMA Read.

---

From: "Jim Pinkerton" <[email-masked]>
Date: Mon, 20 Dec 2004 11:42:20 -0800

Note that the security draft, section 7.5.2.4, walks through DoS attacks
on the RDMA Read Request Queue. Technically, the attack described on
this thread is not a DoS attack unless the RDMA Read Request Queue is
shared by multiple connections (the security draft walks through
normative mitigations to solve this). If it is a single connection, the
only person you're hurting is yourself - thus this isn't DoS - but it is
a bug.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Caitlin Bestler
> Sent: Friday, December 10, 2004 4:29 PM
> To: Michael C. Cambria; [email-masked]
> Subject: RE: [rddp] Freeing QN=1 State
>