Subject: [BEHAVE] Review of rfc3489bis-05 up to section 8

From: "Brian Stucker" <[email-masked]>
Date: Mon, 27 Nov 2006 22:35:21 -0600

Hi guys,

Mirroring Kevin's format for WGLC review comments, here's what I have up
to section 8.

I will make a very broad disclaimer that the comments may seem extensive
(especially sections 6 and 7.1), but most of them are intended to be
editorial. Now that the functionality has been settled, I have been
going back through the document as a designer having an interoperability
debate with another vendor. With that in mind, my comments are generally
trying to make the text as easy to follow (it's already better than most
specs I have read) and get rid of any points of future debate for the
folks having to write code to the spec.

Rather than give change bars on the larger chunks, I've offered
replacement text. I didn't know of a more expedient way of doing this
that was easily understandable, sorry for the length (hoping cut & paste
into the draft will work here). A lot of it is simply moving existing
text around to improve the flow. Unless otherwise noted ahead of the
change offered, the edits are intended to be editorial in nature, and
not to change the intent of the mechanism. I'll be working on getting
through the rest of the document tomorrow. Sorry I couldn't get these to
you earlier.

Cheers,
Brian

---

General nit: Aren't the document references supposed to be of the format
[RFC2988] instead of [8] now?

Page 9, third paragraph: 
		NIT: "sent over TLS [5] over TCP." May wish to change to
"sent via TLS[5] over TCP."

		NIT: capitalization of "Shared secret requests"
inconsistient within the paragraph.

Page 9, fourth paragraph: 
		NIT: Second sentence seems awkward, consider revising
first two sentences to read:

		--- Begin replacement text ---

		There are many ways in which the basic mechanisms within
the STUN protocol can be combined to accomplish a specific task. Such
combinations of STUN protocol elements are known as a 'usage' within the
protocol.

		--- End replacement text ---

Page 10, first & second paragraph:
		The text in this paragraph seems to muddle SIP outbound
concepts with STUN too heavily. The result is that the STUN mechanism
being described is not as clearly called out as it could be. Consider
clarifying to better call out the STUN mechanism being described:

		--- Begin replacement text ---

		   The binding keep-alive usage also utilizes the STUN
binding request message, but for a different purpose. Bindings allocated
by a NAT typically expire if left dorment. When this happens, the client
behind the NAT is no longer reachable by the server on the other side of
the NAT. As a result, the client must generate periodic traffic to
refresh the existing NAT binding. Rather than use potentially expensive
application layer messages, a STUN binding request is sent by the client
to the server. This binding request is sent to the exact same transport
address used by the server for the application protocol (in the case of
SIP, this would typically port 5060 or 5061). In addition to keeping the
binding on the NAT alive, the STUN binding responses have additional
effects: they inform the client that the server is still responsive, and
if the client's transport address towards the server has changed (its
reflexive transport address). If the client's transport address has
changed, it may need additional application layer protocol messaging to
update its transport address as seen by the server (i.e. the binding
keep-alive usage has used by the SIP outbound mechanism [18]). 

		   The binding discovery and keep-alive usages both
utilize the same Binding Request message, and require the same basic
processing on the server.  They differ only in where the server is (a
standalone server in the network, or embedded in an application layer
server), when the Binding Request is used and what the client does with
the mapped address that is returned.

		--- End replacement text ---

Page 10, last paragraph:
		NIT: Change "the magic cookie" to "a magic cookie".

Page 11-13, Start of section 6 to first paragraph on page 13:

		This section seemed to jump around a lot and have
duplicate information. I took the liberty to reorder the material and
clarify the text in this section of the document to make it flow better,
and be more easily understood by the reader. I modeled the flow of the
text around the format of the message.

		Essentially, I got rid of any material that was
repeated, and tried to lay out the material in the order in which it
would appear in a STUN header such that if someone were looking at a
STUN packet in a debugger, they could follow along in the text as they
looked at the binary itself.

		Also reorganized some of the parenthetical information
to help more clearly separate informative text from normative text.

		I've given my suggested updated text below. This would
replace from the start of Section 6 down to the second paragraph on page
13 where we start talking about STUN attributes.

		--- Begin replacement text ---

STUN messages are encoded using a TLV (type-length-value) format with
network ordered binary fields (most significant byte or octet first,
also commonly known as big-endian). The transmission order is described
in detail in Appendix B of RFC791 [2]. Unless otherwise noted, numeric
constants are given in decimal (base 10).

[[ New Subsection: 6.1 STUN Message Header Format ]]

All STUN messages start with a single, 20 byte, STUN header followed by
a STUN payload. The STUN header contains a STUN message type, magic
cookie, transaction ID, and total payload length. 

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0|     STUN Message Type     |         Message Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic Cookie                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            Transaction ID
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: Format of STUN Message Header

		The most significant two bits of every STUN message are
both zeroes to aid in distinguishing STUN traffic from other protocols
that may be multiplexed on the same port.

		The message type defines the message class (request,
success response, failure response, or indication) and the message
method (the primary function) of the STUN message. Although there are
four message classes, there are only two types of transactions in STUN:
request/response transactions (which utilize a request message and a
response message), and indication transactions (which utilizes a single
indication message). Response classes are differentiated to aid in
quickly processing the STUN message.

		The message type field is decomposed further into the
following structure:

		                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		                          |M|M|M|M|M|C|M|M|M|C|M|M|M|M|
		                          |1|1|9|8|7|1|6|5|4|0|3|2|1|0|
		                          |1|0| | | | | | | | | | | | |
		                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		Figure 3: Format of STUN Message Type Field

M11 through M0 represent a 12-bit encoding of the method.  C1 through C0
represent a 2 bit encoding of the class.  A class of 0 is a Request, a
class of 1 is an indication, a class of 2 is a success response, and a
class of 3 is an error response.  This specification defines two
methods: Binding and Shared Secret.  Their method values are enumerated
in Section 15.

A number of mechanisms are provided to aid in differentiating STUN
packets from other protocols that STUN may be multiplexed with on the
same port. The magic cookie is a fixed value, 0x2112A442.  In the
previous version of this specification [15] this field was part of the
transaction ID.  This fixed value is used as part of the identification
of a STUN message when STUN is multiplexed with other protocols on the
same port, as is done for example in [13] and [18]. The magic cookie
additionally indicates the STUN client is compliant with this
specification.  The magic cookie is present in all STUN messages --
requests, success responses, error responses and indications. In
addition to the magic cookie and the leading zeroes in the STUN packet,
there is also a fingerprint attribute that further aids in identifying
the packet as a STUN packet.

The transaction ID is a unique 96-bit identifier that is used for
identify STUN transactions.  

For request/response transactions, the transaction ID is chosen by the
STUN client and MUST be unique for each new STUN transaction generated
by that STUN client.  The transaction ID MUST be uniformly and randomly
distributed between 0 and 2**96 - 1.  The large range is needed because
the transaction ID serves as a form of randomization, helping to prevent
replays of previously signed responses from the server.  A reponse to
the STUN request, whether it be a success or error response, carries the
same transaction ID as the request.

Indications are also identified by their transaction ID.  The
transaction ID there MUST also be uniformly and randomly distributed
between 0 and 2**96 - 1.As with requests, the value is chosen by the
server and MUST be unique for each unique indication generated by the
server.  Unless a request or indication is bit-wise identical to a
previous request, and was sent to the same server from the same
transport address, a client MUST choose a new transaction ID for it.

STUN Requests are sent reliably, and can run over UDP, TCP or TCP/TLS.
When run over UDP, STUN requests are retransmitted in order to achieve
reliability.  Indication messages can be sent either from the client to
the server, or from the server to the client using TCP or UDP.  STUN
itself does not provide reliability for these messages, though they will
be delivered reliably when sent over TCP.

The message length is the size, in bytes, of the message not including
the 20 byte STUN header.

[[ New subsection: 6.2 STUN Message Payload/Attributes ]]

		--- End replacement text ---

Section 7.1:

Question: Is it allowable to have multiple transactions outstanding
between the same two endpoints, or is it intended that a given server
will only have one transaction outstanding from any given client? Assume
it's the former and rephrased the text accordingly.

Tried to make the timeout behavior more specific, giving exact formulas
for the behavior and calling out the difference between STUN
retransmission/timeout behavior and the familiar SIP
retransmission/timeout behavior.

Question: Is there a linger timer at the server during which time it is
expected to cache the response to a particular request? For example, if
a request is retransmitted via UDP, and the first response is dropped by
the network, does the STUN server recalculate it's response or repeat
the last response it sent to the earlier request (as in SIP)? The NAT
binding could conceivably have changed between retransmissions due the
NAT losing state (reboot, admin action) so that the reflexive transport
address in the response is stale if the response is cached at the server
to the earlier request. 

Seems like caching of the STUN response at the server is safe; the
binding could always be lost at the NAT regardless of the timing of STUN
messages. Since detection of caching at the server would be undetectable
to the client, and should be left as optional, nothing needs to be said
in the text, does it?

Fifth paragraph was unclear in original text. If STUN should not be
retransmitted over TCP, then why wait until 7900ms, 1.6 seconds after
the last retransmission, to timeout? I'm assuming you're waiting for TCP
to timeout, but TCP may be using a different RTO value because it was
calculated at a different point in time as the STUN RTO value. Assuming
that we don't care about late responses due to TCP/STUN RTO value
mismatch, right? We only care about the STUN application timer. 

Result of this was to take a stab at rearranging the text a bit and
making it a bit more explicit:

--- Begin replacement text ---

STUN clients MAY have multiple outstanding STUN requests with different
transaction IDs and not wait for completion of a STUN request/response
exchange before sending another STUN request to the same STUN server.

[[ New section: 7.1.1 Reliability of STUN Requests ]]

STUN uses the TCP retransmission timeout (RTO) value, described in RFC
2988 [8], for timing internal events regardless of the transport
protocol used to send the request. This value is used as an input to the
algorithms used to achieve reliability of STUN requests regardless of
the transport protocol used.
 
Clients SHOULD use RFC 2988 [8] to compute an RTO value as an estimate
of the round-trip-time, but with two exceptions.  First, the initial
value for RTO SHOULD be configurable (rather than the 3s recommended in
RFC 2988).  In fixed-line access links, an RTO value of 100ms is
RECOMMENDED.  Secondly, the RTO value MUST NOT be rounded up to the
nearest second.  Rather, a 1ms accuracy MUST be maintained.  As with
TCP, the usage of Karn's algorithm is RECOMMENDED.  When Karn's
algorithm is applied to STUN, this means that RTT estimates SHOULD NOT
be computed from STUN transactions which result in the retransmission of
a request. This value is used for both TCP and UDP operation.

The RTO value SHOULD be cached by an agent after the completion of the
transaction and SHOULD be used as the starting RTO value for the next
transaction to the same host (based on equality of IP address). The
value SHOULD be considered stale for new transactions and discarded
after 10 minutes.

[[ New section: 7.1.2 Sending STUN requests via UDP ]]

When running STUN over UDP, it is possible that the STUN request or its
response might be dropped by the network. Therefore, reliability of a
STUN request sent over UDP is accomplished via explicit retransmissions
of the request by the STUN application. Clients SHOULD retransmit the
request up to 6 times. Each retransmission is sent, relative to the time
the original request was sent, and is given by:

	Time to send next retransmission = t + (RTO * ((2 ^ n) - 1))

Where t is the time the original request was sent, n is the current
retransmission counter value and RTO is given in milliseconds.
Retransmissions continue until a response is received, or a total of 7
requests have been sent.
 
For example, if the STUN request was sent at time t, the retransmissions
would be sent at: t + 100ms, t + 300ms, t + 700ms, t + 1500ms, t +
3100ms, and t + 6300ms. 

This differs from retransmission timings for other protocols such as SIP
where the interval between retransmissions is relative to the time the
last retransmission was sent, not the original request.

[[ New section: 7.1.3 Sending STUN requests via TCP ]]

When running STUN over TCP, the STUN application SHOULD NOT retransmit
STUN requests; TCP itself is responsible for ensuring reliable delivery.

[[ New section: 7.1.4 STUN Transaction Timeout ]]

The STUN application does not consider the transport protocol used to
send a STUN request when calculating when a STUN transaction will
timeout. The transaction timeout value is given by:

	Timeout of STUN transaction = t + ((2 ^ 6) -1) * RTO + 1600ms

Where t is the time the original request was sent, and RTO is expressed
in milliseconds, the client SHOULD consider the transaction to have
failed regardless of the transport protocol used to send the STUN
request. A STUN transaction over UDP is also considered failed if there
has been a transport failure of some sort, such as a fatal ICMP error.
Using our earlier example (with an RTO value of 100ms) gives an overall
transaction timeout value of 7900ms after the original request was sent.
The STUN client would consider the transaction to have timed out if no
response had been received by that time if either UDP or TCP was used.

Regardless of whether TCP or UDP was used for the transaction, if a
failure occurs and the client has other servers it can reach (as a
consequence of an SRV query which provides a multiplicity of STUN
servers Section 8.1, for example), the client SHOULD create a new
request, which is identical to the previous, but has a different
transaction ID (and consequently a different MESSAGE INTEGRITY and/or
FINGERPRINT attribute).

--- End replacement text ---

===

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

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 28 Nov 2006 11:10:30 -0600

One other thought on section 7.1... The current text states that
transport failures (ICMP errors) for UDP should be considered failures.
What about other transport failures? Does a TCP connection reset
constitute a failure of the STUN transaction?

Regards,
Brian 

> -----Original Message-----
> From: Stucker, Brian (RICH1:AR00) 
> Sent: Monday, November 27, 2006 10:35 PM
> To: Jonathan Rosenberg; Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] Review of rfc3489bis-05 up to section 8
> 
> Hi guys,
> 
> Mirroring Kevin's format for WGLC review comments, here's 
> what I have up to section 8.
> 
> I will make a very broad disclaimer that the comments may 
> seem extensive (especially sections 6 and 7.1), but most of 
> them are intended to be editorial. Now that the functionality 
> has been settled, I have been going back through the document 
> as a designer having an interoperability debate with another 
> vendor. With that in mind, my comments are generally trying 
> to make the text as easy to follow (it's already better than 
> most specs I have read) and get rid of any points of future 
> debate for the folks having to write code to the spec.
> 
> Rather than give change bars on the larger chunks, I've 
> offered replacement text. I didn't know of a more expedient 
> way of doing this that was easily understandable, sorry for 
> the length (hoping cut & paste into the draft will work 
> here). A lot of it is simply moving existing text around to 
> improve the flow. Unless otherwise noted ahead of the change 
> offered, the edits are intended to be editorial in nature, 
> and not to change the intent of the mechanism. I'll be 
> working on getting through the rest of the document tomorrow. 
> Sorry I couldn't get these to you earlier.
> 
> Cheers,
> Brian
> 
> ---
> 
> General nit: Aren't the document references supposed to be of 
> the format [RFC2988] instead of [8] now?
> 
> 
> Page 9, third paragraph: 
> 		NIT: "sent over TLS [5] over TCP." May wish to 
> change to "sent via TLS[5] over TCP."
> 
> 		NIT: Second sentence seems awkward, consider 
> revising first two sentences to read:
> 
> 		There are many ways in which the basic 
> mechanisms within the STUN protocol can be combined to 
> accomplish a specific task. Such combinations of STUN 
> protocol elements are known as a 'usage' within the protocol.
> 
> 		The text in this paragraph seems to muddle SIP 
> outbound concepts with STUN too heavily. The result is that 
> the STUN mechanism being described is not as clearly called 
> out as it could be. Consider clarifying to better call out 
> the STUN mechanism being described:
> 
> 		   The binding keep-alive usage also utilizes 
> the STUN binding request message, but for a different 
> purpose. Bindings allocated by a NAT typically expire if left 
> dorment. When this happens, the client behind the NAT is no 
> longer reachable by the server on the other side of the NAT. 
> As a result, the client must generate periodic traffic to 
> refresh the existing NAT binding. Rather than use potentially 
> expensive application layer messages, a STUN binding request 
> is sent by the client to the server. This binding request is 
> sent to the exact same transport address used by the server 
> for the application protocol (in the case of SIP, this would 
> typically port 5060 or 5061). In addition to keeping the 
> effects: they inform the client that the server is still 
> responsive, and if the client's transport address towards the 
> server has changed (its reflexive transport address). If the 
> client's transport address has changed, it may need 
> additional application layer protocol messaging to update its 
> transport address as seen by the server (i.e. the binding 
> 		   The binding discovery and keep-alive usages 
> both utilize the same Binding Request message, and require 
> the same basic processing on the server.  They differ only in 
> where the server is (a standalone server in the network, or 
> embedded in an application layer server), when the Binding 
> Request is used and what the client does with the mapped 
> address that is returned.
> 
> 		This section seemed to jump around a lot and 
> have duplicate information. I took the liberty to reorder the 
> material and clarify the text in this section of the document 
> to make it flow better, and be more easily understood by the 
> reader. I modeled the flow of the text around the format of 
> the message.
> 
> repeated, and tried to lay out the material in the order in 
> which it would appear in a STUN header such that if someone 
> were looking at a STUN packet in a debugger, they could 
> follow along in the text as they looked at the binary itself.
> 
> 		Also reorganized some of the parenthetical 
> information to help more clearly separate informative text 
> from normative text.
> 
> 		I've given my suggested updated text below. 
> This would replace from the start of Section 6 down to the 
> second paragraph on page
> STUN messages are encoded using a TLV (type-length-value) 
> format with network ordered binary fields (most significant 
> byte or octet first, also commonly known as big-endian). The 
> transmission order is described in detail in Appendix B of 
> RFC791 [2]. Unless otherwise noted, numeric constants are 
> given in decimal (base 10).
> 
> All STUN messages start with a single, 20 byte, STUN header 
> followed by a STUN payload. The STUN header contains a STUN 
> message type, magic cookie, transaction ID, and total payload length. 
> 
>    0                   1                   2                   3
> 		The most significant two bits of every STUN 
> message are both zeroes to aid in distinguishing STUN traffic 
> from other protocols that may be multiplexed on the same port.
> 
> 		The message type defines the message class 
> (request, success response, failure response, or indication) 
> and the message method (the primary function) of the STUN 
> message. Although there are four message classes, there are 
> only two types of transactions in STUN:
> request/response transactions (which utilize a request 
> message and a response message), and indication transactions 
> (which utilizes a single indication message). Response 
> classes are differentiated to aid in quickly processing the 
> STUN message.
> 
> 		The message type field is decomposed further 
> into the following structure:
> 
> M11 through M0 represent a 12-bit encoding of the method.  C1 
> through C0 represent a 2 bit encoding of the class.  A class 
> of 0 is a Request, a class of 1 is an indication, a class of 
> 2 is a success response, and a class of 3 is an error 
> response.  This specification defines two
> methods: Binding and Shared Secret.  Their method values are 
> enumerated in Section 15.
> 
> A number of mechanisms are provided to aid in differentiating 
> STUN packets from other protocols that STUN may be 
> multiplexed with on the same port. The magic cookie is a 
> fixed value, 0x2112A442.  In the previous version of this 
> specification [15] this field was part of the transaction ID. 
>  This fixed value is used as part of the identification of a 
> STUN message when STUN is multiplexed with other protocols on 
> the same port, as is done for example in [13] and [18]. The 
> magic cookie additionally indicates the STUN client is 
> compliant with this specification.  The magic cookie is 
> present in all STUN messages -- requests, success responses, 
> error responses and indications. In addition to the magic 
> cookie and the leading zeroes in the STUN packet, there is 
> also a fingerprint attribute that further aids in identifying 
> The transaction ID is a unique 96-bit identifier that is used 
> for identify STUN transactions.  
> 
> For request/response transactions, the transaction ID is 
> chosen by the STUN client and MUST be unique for each new 
> STUN transaction generated by that STUN client.  The 
> transaction ID MUST be uniformly and randomly distributed 
> between 0 and 2**96 - 1.  The large range is needed because 
> the transaction ID serves as a form of randomization, helping 
> to prevent replays of previously signed responses from the 
> server.  A reponse to the STUN request, whether it be a 
> success or error response, carries the same transaction ID as 
> the request.
> 
> transaction ID there MUST also be uniformly and randomly 
> distributed between 0 and 2**96 - 1.As with requests, the 
> value is chosen by the server and MUST be unique for each 
> unique indication generated by the server.  Unless a request 
> or indication is bit-wise identical to a previous request, 
> and was sent to the same server from the same transport 
> address, a client MUST choose a new transaction ID for it.
> 
> When run over UDP, STUN requests are retransmitted in order 
> to achieve reliability.  Indication messages can be sent 
> either from the client to the server, or from the server to 
> the client using TCP or UDP.  STUN itself does not provide 
> reliability for these messages, though they will be delivered 
> reliably when sent over TCP.
> 
> The message length is the size, in bytes, of the message not 
> including the 20 byte STUN header.
> 
> Question: Is it allowable to have multiple transactions 
> outstanding between the same two endpoints, or is it intended 
> that a given server will only have one transaction 
> outstanding from any given client? Assume it's the former and 
> rephrased the text accordingly.
> 
> Tried to make the timeout behavior more specific, giving 
> exact formulas for the behavior and calling out the 
> difference between STUN retransmission/timeout behavior and 
> the familiar SIP retransmission/timeout behavior.
> 
> Question: Is there a linger timer at the server during which 
> time it is expected to cache the response to a particular 
> request? For example, if a request is retransmitted via UDP, 
> and the first response is dropped by the network, does the 
> STUN server recalculate it's response or repeat the last 
> response it sent to the earlier request (as in SIP)? The NAT 
> binding could conceivably have changed between 
> retransmissions due the NAT losing state (reboot, admin 
> action) so that the reflexive transport address in the 
> response is stale if the response is cached at the server to 
> the earlier request. 
> 
> Seems like caching of the STUN response at the server is 
> safe; the binding could always be lost at the NAT regardless 
> of the timing of STUN messages. Since detection of caching at 
> the server would be undetectable to the client, and should be 
> left as optional, nothing needs to be said in the text, does it?
> 
> Fifth paragraph was unclear in original text. If STUN should 
> not be retransmitted over TCP, then why wait until 7900ms, 
> 1.6 seconds after the last retransmission, to timeout? I'm 
> assuming you're waiting for TCP to timeout, but TCP may be 
> using a different RTO value because it was calculated at a 
> different point in time as the STUN RTO value. Assuming that 
> we don't care about late responses due to TCP/STUN RTO value 
> Result of this was to take a stab at rearranging the text a 
> bit and making it a bit more explicit:
> 
> STUN clients MAY have multiple outstanding STUN requests with 
> different transaction IDs and not wait for completion of a 
> STUN request/response exchange before sending another STUN 
> request to the same STUN server.
> 
> 2988 [8], for timing internal events regardless of the 
> transport protocol used to send the request. This value is 
> used as an input to the algorithms used to achieve 
> reliability of STUN requests regardless of the transport 
> protocol used.
>  
> Clients SHOULD use RFC 2988 [8] to compute an RTO value as an 
> estimate of the round-trip-time, but with two exceptions.  
> First, the initial value for RTO SHOULD be configurable 
> (rather than the 3s recommended in RFC 2988).  In fixed-line 
> access links, an RTO value of 100ms is RECOMMENDED.  
> Secondly, the RTO value MUST NOT be rounded up to the nearest 
> second.  Rather, a 1ms accuracy MUST be maintained.  As with 
> TCP, the usage of Karn's algorithm is RECOMMENDED.  When 
> Karn's algorithm is applied to STUN, this means that RTT 
> estimates SHOULD NOT be computed from STUN transactions which 
> result in the retransmission of a request. This value is used 
> for both TCP and UDP operation.
> 
> The RTO value SHOULD be cached by an agent after the 
> completion of the transaction and SHOULD be used as the 
> starting RTO value for the next transaction to the same host 
> (based on equality of IP address). The value SHOULD be 
> considered stale for new transactions and discarded after 10 minutes.
> 
> When running STUN over UDP, it is possible that the STUN 
> request or its response might be dropped by the network. 
> Therefore, reliability of a STUN request sent over UDP is 
> accomplished via explicit retransmissions of the request by 
> the STUN application. Clients SHOULD retransmit the request 
> up to 6 times. Each retransmission is sent, relative to the 
> time the original request was sent, and is given by:
> 
> Where t is the time the original request was sent, n is the 
> current retransmission counter value and RTO is given in milliseconds.
> Retransmissions continue until a response is received, or a 
> total of 7 requests have been sent.
>  
> For example, if the STUN request was sent at time t, the 
> retransmissions would be sent at: t + 100ms, t + 300ms, t + 
> 700ms, t + 1500ms, t + 3100ms, and t + 6300ms. 
> 
> This differs from retransmission timings for other protocols 
> such as SIP where the interval between retransmissions is 
> relative to the time the last retransmission was sent, not 
> the original request.
> 
> When running STUN over TCP, the STUN application SHOULD NOT 
> retransmit STUN requests; TCP itself is responsible for 
> ensuring reliable delivery.
> 
> The STUN application does not consider the transport protocol 
> used to send a STUN request when calculating when a STUN 
> transaction will timeout. The transaction timeout value is given by:
> 
> Where t is the time the original request was sent, and RTO is 
> expressed in milliseconds, the client SHOULD consider the 
> transaction to have failed regardless of the transport 
> protocol used to send the STUN request. A STUN transaction 
> over UDP is also considered failed if there has been a 
> transport failure of some sort, such as a fatal ICMP error.
> Using our earlier example (with an RTO value of 100ms) gives 
> an overall transaction timeout value of 7900ms after the 
> original request was sent.
> The STUN client would consider the transaction to have timed 
> out if no response had been received by that time if either 
> UDP or TCP was used.
> 
> Regardless of whether TCP or UDP was used for the 
> transaction, if a failure occurs and the client has other 
> servers it can reach (as a consequence of an SRV query which 
> provides a multiplicity of STUN servers Section 8.1, for 
> example), the client SHOULD create a new request, which is 
> identical to the previous, but has a different transaction ID 
> (and consequently a different MESSAGE INTEGRITY and/or 
> FINGERPRINT attribute).
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Nov 2006 17:07:50 -0800

I expect that would interact poorly with TCP simultaneous-open.  Saikat, any
thoughts?

-d

> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Tuesday, November 28, 2006 9:11 AM
> Subject: RE: [BEHAVE] Review of rfc3489bis-05 up to section 8
>

---

From: Saikat Guha <[email-masked]>
Date: Wed, 29 Nov 2006 21:26:25 -0500

> > constitute a failure of the STUN transaction?

If an app is trying TCP S-O and *only* TCP S-O, then RSTs can be
annoying, but apps should be doing both regular connections and S-O in
parallel as per ICE.

If an endpoint gets an RST while trying to STUN the other end, then
packets must be getting through to the other end (BEHAVE compliant NATs
are not supposed to RST new connections). In those cases, the regular
connection should work (i.e. local LAN or already-punched NAT).

-- 
Saikat