Subject: [BEHAVE] review of rfc3489bis-05

From: "Kevin Johns" <[email-masked]>
Date: Wed, 15 Nov 2006 11:34:38 -0700

Hi,
 
I have been reviewing rfc3489bis-05 and have two technical concerns with
the transaction ID requirements.
 
First, for the indication message. Per the text in section 6 indication
messages include a transaction id within the same number space as
requests with a requirement that the transaction ID be unique for each
unique indication.
 
The concern here is the potential for collisions with requests and
responses. If a Client is generating an indication, it is rather
straightforward to ensure that the transaction ID is unique for all
requests generated by that client. However, when a server is generating
an indication, it is much harder for the server to ensure the
transaction ID is unique as it must now store all transaction IDs for
each client it has received a STUN request from to avoid collisions with
previously sent responses.
 
Given that indication messages are unreliable and are not re-transmitted
I do not see the need in providing a unique transaction ID. Rather I
would like to suggest that the transaction ID for all indications be 0
and that the number space for requests be changed from 0 - 2**96-1 to
1-2**96-1.
 
Second, managing transaction IDs in general. Given a server will be
receiving requests from many clients the possibility for a transaction
ID collision is likely (how likely depends on a number of factors).
There does not appear to be any good method for the server to manage
this and thus will have a difficult time in determining if a request is
a re-transmission or simply a transaction ID collision. Unfortunately a
STUN request does not have any mandatory attributes which can be used in
conjunction with the transaction ID by the server to create a unique
tuple. The only way I currently see to resolve this is to require the
server to not only remember the transaction ID but also the source of
the request (source IP and Port) so that it can disambiguate between a
re-transmission (same transaction ID from a previous source) and a
transaction ID collision (same transaction ID but different source).
 
Regards,
Kevin

~~~~~~~~~~~~~~~~~~~~~~
Kevin C. Johns
Project Director - PacketCable Communications Protocols
CableLabs(r)
858 Coal Creek Circle
Louisville, CO 80027-9750
Phone:  303.661.9100
Direct: 303.661.3303
HTTP://www.CableLabs.com <http://www.cablelabs.com/>  

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 15 Nov 2006 14:43:53 -0500

thoughts inline

On 11/15/06, Kevin Johns <[email-masked]> wrote:
>
>
> Hi,
>
> I have been reviewing rfc3489bis-05 and have two technical concerns with the
> transaction ID requirements.
>
> messages include a transaction id within the same number space as requests
> with a requirement that the transaction ID be unique for each unique
> indication.
>
> straightforward to ensure that the transaction ID is unique for all requests
> generated by that client. However, when a server is generating an
> indication, it is much harder for the server to ensure the transaction ID is
> unique as it must now store all transaction IDs for each client it has
> received a STUN request from to avoid collisions with previously sent
> responses.

I don't read the text the same way.  I don't see any implication that
the IDs must be unique between each side of the connection, the text
just says that each ID that the client generates must be unique among
IDs generated by the client and that each ID the server generates must
be unique among IDs generated by the server.  Practically speaking, I
can't imagine that most implementations would do anything other than
generate a random number, maybe compare it with outstanding
transactions, and then send it.

>
> Given that indication messages are unreliable and are not re-transmitted I
> do not see the need in providing a unique transaction ID. Rather I would
> like to suggest that the transaction ID for all indications be 0 and that
> the number space for requests be changed from 0 - 2**96-1 to 1-2**96-1.
>

You have to assume that indications are idempotent.  Of course, you're
right that since indications are unreliable, whatever is generating
them would have to implement its own duplicate detection and
retransmission anyway, but in general I would rather make it easy for
an implementation to drop a duplicated indication.

Perhaps a good solution to the issue here is to explicitly require
less state by requiring the IDs not to be repeated over some interval,
rather than forever.

> receiving requests from many clients the possibility for a transaction ID
> collision is likely (how likely depends on a number of factors). There does
> not appear to be any good method for the server to manage this and thus will
> have a difficult time in determining if a request is a re-transmission or
> simply a transaction ID collision. Unfortunately a STUN request does not
> have any mandatory attributes which can be used in conjunction with the
> transaction ID by the server to create a unique tuple. The only way I
> currently see to resolve this is to require the server to not only remember
> the transaction ID but also the source of the request (source IP and Port)
> so that it can disambiguate between a re-transmission (same transaction ID
> from a previous source) and a transaction ID collision (same transaction ID
> but different source).

Given that the ID space is 96 bits, even for a server handling
thousands of clients the odds of a collision occuring seems to be
sufficiently small as to be negligible.  If a server really wants to
do this, though, it could use a NONCE to identify which client it's
dealing with.  I guess right now NONCEs can only be used when using
integrity, but that seems like it's going to be the common case for a
stand-alone STUN server, which is the only scenario that occurs
offhand where this might be a problem.

Bruce

> HTTP://www.CableLabs.com