Re: Re: STag value choices

At 09:44 AM 2/21/2004 -0600, Caitlin Bestler wrote:

>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.

The size of the RDMA Writes may vary between 1 and 4GB but I don't see that 
as having any real bearing on the discussion.  The STag has a ULP-defined / 
application instance scope and is intended to act as a key to enable fast 
memory translation possible.  It isn't there to provide any sense of 
protection.

>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.

Correct. If the fabric is open to a sniffer then they can see the 
information assuming they knew how to parse the packets to determine where 
the headers are in a given byte stream / message chunk.  If there is 
concern that this can exist, then use something like IP Security to protect 
the stream and avoid the exposure.

>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.

Correct.  Since a STag is not used for security, its size was kept 
reasonably small to allow implementations to encode the STag to optimize 
their solutions to  meet their particular design - simplicity, performance, 
scalability, etc.

>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.

These can be done without requiring anything new within the specification 
as STags are an opaque handle used to optimize the implementation by 
passing the handle between the communicating endnodes.

Mike