Re: STag value choices

On Feb 20, 2004, at 9:51 PM, [email protected] wrote:

>>> 	Aside: I think that many of these issues, as well as the multiple
>>> 	receiver problem (and I do not accept the argument that requiring
>>> 	many different clients to use the same address is in any way
>>> 	comparable to any existing problem in that space), would go away
>>> 	if the steering tag sent over the wire to the receiver were not
>>> 	just opaque, but by intent a random 64- or 128-bit tag to a local
>>> 	buffer descriptor.  That permits easy local revocation of
>>> 	capabilities, as well as a defense against remote contamination
>>> 	attempts if the value were communicated previously over an
>>> 	encrypted channel.
>>>
>>> Also, if the STag values generated by an implementation are hard to
>>> predict, traffic injection by an adversary becomes more difficult.
>>
>> If the STag has cryptographic value it will be too large for
>> efficiency.
>
> There can be value in unpredictability before getting to 64 or
> 128 bit sizes.  SCTP uses a 32-bit Verification Tag for a roughly
> analogous purpose, and 32 bits is not cryptographic strength.
>
>> A statement could be added that STags SHOULD be chosen so as to 
>> minimize
>> the risk of bit-errors changing one valid STag into another valid 
>> STag.
>> But there is no way to make that a "MUST" -- how would you know how an
>> STag you have been given compares with other STags given to other
>> clients?
>
> The concern is not about an STag being bit-errored into another STag,
> but rather that if an adversary knows the algorithm being used to 
> generate
> STag values (e.g., can predict the next one that an implementation
> will generate), certain aspects of forging and injecting traffic
> become easier (e.g., more of the forged traffic can be precomputed).
>
>


There is no real need to predict STags. Even if STags are only open
for a single transfer, most RDMA Writes will be encoded as multiple
DDP Segments. Also buffers are advertised in ULP messages.

Someone in a position to overhear and inject SCTP or TCP packets will
still be able to do so.

An incoming STag is evaluated in hardware, and should be done with
only absolutely required access to context data for validation.
In a typical implementation the STag will be parsed into a fixed
portion referencing a Memory Window or Region and a variable portion
that updates with each dynamic bind. Anything that would truly make
it too hard for an eavesdropper to detect the pattern would add to
the amount of context data that must be checked to validate each
arriving STag.

A simple hash (perhaps as simple as an XOR) would be cheap and
minimize bit errors producing false matches, but would be more
effective at confusing debuggers than in confusing hackers.