STag value choices

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

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------