Subject: [BEHAVE] Review of draft-ietf-behave-rfc3489bis-05 [update]

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 1 Jan 2007 18:18:19 +0100

I found an additional issue that I would like to add to my review of
draft-ietf-behave-rfc3489bis-05:

9. Section 8.3.2, paragraph 17:

"Any response response between 100 and 299 MUST result in the cessation
of request retransmissions, but otherwise is discarded."

The problem is that the "final" response that will be sent before the
7900ms timeout will not be retransmitted if it is lost.  The request
will eventually be retried on the next server, but it is still a problem
if the usage does not use DNS, or if there is only one SRV RR.

Here some suggestions to fix this:

o The simplest way is to remove this sentence, but I think that there is
a real need to have a way to stop the retransmissions until the response
can be calculated.  An example that comes to mind would be if the STUN
server needs to contact a authentication server (e.g. RFC 4590) that
will take more than 100ms to respond.

o Another way would be to keep the sentence and do what was done with
the 200/ACK for SIP INVITE.  For STUN this would mean to add an ACK
Indication, and retransmit the "final" response until an ACK Indication
with the same transaction id is received.

o Another way would be to remove the sentence, and add a new error
response code 448 Response Delayed that will signal that the response
will be sent later in a new Update request, but in the opposite
direction.  Here's an example for an Allocate request:

 UA                              TURN
  | Allocate request              |
1 |------------------------------>|
  |   Allocate Error Response 448 |
2 |<------------------------------|
  :                               :
  |                Update Request |
3 |<------------------------------|
  | Update Response               |
4 |------------------------------>|

1: An Allocate request is sent to the TURN server.
2: The TURN server needs more time to allocate the ports, and so
responds with a 448 response that stops the retransmissions.
3: After some time the TURN server manages to allocate the ports and so
sends an Update Request in the direction of the UA.  It copies in the
request all the attributes that it should have copied in the Allocate
Response if it was able to do it. The request also contains an
additional attribute containing the transaction id of the original
transaction.  It needs to send the request in the next 30 seconds after
receiving the Allocate request to be sure that the UDP binding is still
active in the NAT.
4: The UA responds with an Update Response to stop the retransmissions.

The advantage of this last method is that it does not change the STUN
transaction behavior.

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

---

From: "Frank W. Miller" <[email-masked]>
Date: Sun, 14 Jan 2007 15:47:22 -0700

I noticed in Section 15.2:

    0x8023: FINGERPRINT
    0x8023: ALTERNATE-SERVER

Are these two attributes supposed to have the same value?  My apologies if I overlooked something...

Thanks,
FM

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 14 Jan 2007 18:29:37 -0800

> apologies if I overlooked something...

No, they're not supposed to have the same value.  The double
assignment problem was mentioned at
http://www.employees.org/behave/stun-attributes.html but
it's also interesting how ALTERNATE-SERVERs values have evolved:

  grep -i "0x.*alternate-server" draft*turn*.txt
  draft-rosenberg-midcom-turn-00.txt:   0x0007: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-01.txt:   0x000e: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-02.txt:   0x000e: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-03.txt:   0x000e: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-04.txt:   0x000e: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-05.txt:   0x000e: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-06.txt:   0x000e: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-07.txt:   0x000e: ALTERNATE-SERVER
  draft-rosenberg-midcom-turn-08.txt:   0x000e: ALTERNATE-SERVER

  grep -i "0x.*alternate-server" draft-ietf-behave-rfc3489bis*.txt
  draft-ietf-behave-rfc3489bis-03.txt:        0x000E: ALTERNATE-SERVER
  draft-ietf-behave-rfc3489bis-03.txt:        0x8023: ALTERNATE-SERVER
  draft-ietf-behave-rfc3489bis-04.txt:    0x8023: ALTERNATE-SERVER
  draft-ietf-behave-rfc3489bis-05.txt:    0x8023: ALTERNATE-SERVER

I'm not sure if there are implementations that rely on those values.

-d

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 15 Jan 2007 22:01:51 -0700

Is the magic cookie field treated as a 32-bit value, i.e. do you apply
htonl() on it before sending or is it a byte array like the transaction
ID?

Thanks,
FM

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 16 Jan 2007 09:13:22 +0200

> htonl() on it before sending or is it a byte array like the transaction

How you read/write the cookie is an implementation detail. Of course, the 
cookie value in the specification is in network byte order.
-- 
Rémi Denis-Courmont <[email-masked]>
Research Engineer