Subject: RE: [BEHAVE] review of rfc3489bis-05

From: "Kevin Johns" <[email-masked]>
Date: Thu, 16 Nov 2006 15:35:01 -0700

Bruce,

Thanks for the response.

If folks are ok with the idea that the transaction ID number space is
sufficiently large that collisions are not an issue, then I guess I can
go along with that given that they are suppose to be random.

As for indications, I might be missing something here but given their
definition I do not see why a transaction ID is needed. There is nothing
to correlate the indication with and there is no way to have a duplicate
or re-transmission per the text. This seems to be adding additional
complexity with no usage by the protocol.

Kevin

-----Original Message-----
From: Bruce Lowekamp [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 12:44 PM
To: Kevin Johns
Cc: [email-masked]
Subject: Re: [BEHAVE] review of rfc3489bis-05

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

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.

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

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

> 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
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave
>
>
>

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Nov 2006 15:57:06 -0500

inline.

> go along with that given that they are suppose to be random.

That was the intent. This is just like how, for example, the call-id 
works in SIP. With 96 bits of transaction ID, if you assume that a 
server handles 10,000 transactions per second, and worries about 
collision within a window of 20 seconds, the probability of collision is 
roughly 2^-61, which is more than good enough.

> complexity with no usage by the protocol.

Its probably not needed for functional purposes. But its useful for 
diagnostics and logs for sure, and it also allows for uniform message 
formats for transactions and indications, which I like. Certainly, it 
does no harm.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Philip Matthews <[email-masked]>
Date: Wed, 22 Nov 2006 19:16:18 -0500

On 21-Nov-06, at 15:57 , Jonathan Rosenberg wrote:

> diagnostics and logs for sure, and it also allows for uniform  
> message formats for transactions and indications, which I like.  
> Certainly, it does no harm.
>

I was under the impression that the 96-bit transaction id is also  
used to prevent replay attacks
when STUN was run over UDP. Am I mistaken? The document is rather  
vague about this.
(Though how practical this is is a good question, since it requires  
an endpoint to remember all
previously used transaction ids).

If this is not true, and the only functional purpose is to help a  
client correlate a response
with the request that generated it, then surely we could get away  
with a much smaller transaction id?

- Philip