Subject: RE: [rddp] Error code returns for DDP tagged buffer messages

From: [email-masked]
Date: Mon, 26 Apr 2004 15:51:56 -0600

Hemal,

Your responses seem to depend on assumptions about implementation.

Depending implementation, the validity check may allow the implementation to see that the STag is valid but not associated with this stream or it may not see anything that distinguishes the two cases. Also, if the peer has tried to access an STag it shouldn't have access to, I can't think of any reason to tell the peer that the STag is possibly valid on another stream. Doing so doesn't convey any useful information to an honest peer and it potentially reveals informtion to an attacker.

Therefore, STag not associated with DDP Stream should be returned.

On the MSN errors, your answer presumes there is a fixed queue size which there may or may not be. There also isn't a value in distinguishing between these two errors. A message arrived and there was no buffer.

Also, nothing in the draft makes these distinctions between the errors. In each case the distinction is not particularly useful and I think we should consolidate to one error for STag not valid on the stream and one error for no buffer for the MSN.

Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Shah,
Hemal
Sent: Monday, April 26, 2004 12:25 PM
To: Barry Reinhold; RDDP
Subject: RE: [rddp] Error code returns for DDP tagged buffer messages

Barry,

See my comments below embedded between <hvs> and </hvs>.

Hemal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barry Reinhold
Sent: Friday, April 23, 2004 12:22 PM
To: RDDP
Subject: [rddp] Error code returns for DDP tagged buffer messages

Clause 9.2 DDP Error Numbers provides the error codes "Invalid STag" and
"STag not associated with DDP Stream", but the language of the first
paragraph is not clear enough for me to understand the expectation for
the following:

<hvs>
For an "Invalid STag" memory access is not allowed at all. "STag not
associated with DDP Stream" means that the STag is valid but is not
associated with the DDP Stream on which the DDP Segment was received. In
other words, memory access using the STag is not allowed on this DDP
Stream. 
</hvs>

Is it the intent to require that a receiver delineate between "Invalid
STag" and "STag not associated with DDP Stream"? That is, if STag 10 was
valid on stream A but not on stream B, MUST the receiver return "STag
not associated with DDP Stream?" if a DDP Segment is received on stream
B with STag 10, or is "Invalid STag" acceptable.
<hvs> No. The receiver MUST return "STag not associated with DDP Stream"
in this case. </hvs>

This question also applies to delineating between "Invalid MSN - no
buffer available", and "Invalid MSN - MSN range is not valid". However,
this is a bit more difficult conceptually as Clause 9.1, item 5 states:

       The legal range is defined as being between the MSN value
assigned to
       the first available buffer for a specific QN and the MSN value 
       assigned to the last available buffer for a specific QN.

Which appears to tie "invalid MSN pretty closely to no buffer available.
<hvs>
Let us say QN has a queue length QLEN. So, at any given point [MSN1,
MSN2] represents the MSN range of the entries of the queue. Here,
MSN2-MSN1 = QLEN-1 (in modulo arithmetic). Let us say the number of
buffers posted on the queue at any given time is N (0 <= N <= QLEN).

So, for N > 0, if a MSN is not in [MSN1,MSN1+N-1] and MSN1 <= MSN <=
MSN2, then it is the condition "Invalid MSN - no buffer available". For
N=0, if MSN is in [MSN1, MSN2], then it is the condition ""Invalid MSN -
no buffer available".

If MSN is not in [MSN1,MSN2], then it is "Invalid MSN - MSN range not
valid" condition.
</hvs>  

Barry Reinhold
Lamprey Networks
[email-masked]
(603) 868-8411

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

_______________________________________________
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: Caitlin Bestler <[email-masked]>
Date: Tue, 27 Apr 2004 07:17:23 +0300

On Apr 27, 2004, at 12:51 AM, [email-masked] wrote:
>
>
> On the MSN errors, your answer presumes there is a fixed queue size 
> which there may or may not be. There also isn't a value in 
> distinguishing between these two errors. A message arrived and there 
> was no buffer.
>
>
There is a valid distinction between "Invalid MSN: you should not have 
sent
that message" and "Oops I don't have a buffer, sorry about that."

As previously discussed while covering the implications of SRQs, for 
RDMA
based ULPs to work, there MUST be a concept of a "valid MSN". But it is
possible for an implementation using SRQs to be unaware of this 
limitation
at the DDP layer. It is also highly plausible that the DDP layer will 
not know
how many buffers are available to it, merely whether it can allocate 1 
(in
the case of arrival order allocation) or n (in case of serial order 
allocation).

But I believe this issue has already been settled in the security 
discussions.
Handling of per-stream credit violations by either the ULP or Privileged
Resource Manager implies that the implementation is only required to
detect such violations *promptly*, not synchronously.

While I remain a strong proponent of catching these violations 
synchronously,
making the existence of an SRQ transparent to the ULP peer, clearly
this will not be a protocol mandate. The only requirement is that the
deterministic response to such overruns not be forced upon all
applications that want to use SRQs. But inherently delayed detection
of the condition is legitimate.

Therefore we cannot *require* that the generated error distinguish 
between
"Invalid MSN: you should not have sent that message" and "Oops, sorry
no buffer, I'm not sure who goofed".

The question then becomes whether it is useful for implementations that
*can* distinguish (as almost any would when using a plain RQ) to
return the separate error for informative purposes.

My inclination is that this is valuable, and unlike the "Invalid STag" 
error,
provides virtually no information to an attacker. Theoretically, it 
allows
an attacker to probe how many untagged message credits a stream had,
but each probe tears down the stream. It's not terribly important 
information,
and can probably be inferred more simply by just eavesdropping.

--
Caitlin Bestler
http://asomi.com/