Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03

From: <[email-masked]>
Date: Tue, 21 Mar 2006 08:16:15 -0800 (PST)

Hi,

I have a few rather minor comments for the STUN bis-03:

5.  Overview of Operation

   This section is descriptive only.  Normative behavior is described in
   Section 8 and Section .

Section number is missing from the second reference.

8.1.4.  Processing Responses

   the response as described in Section 11.8.  The key to use depends on
   the shared secret mechanism.  If the STUN Shared Secret Request was
   used, the key MUST be same as used to compute the MESSAGE-INTEGRITY
   attribute in the request.

What if the Shared Secret Request was not used ? I believe also that
should be mentioned here for completeness.

   SHOULD obtain a new one-time username and password, and retry the
   Allocate Request with a new transaction. 

Allocate Request is not defined in this spec.

9.2.  Indication Message Types

   Indication messages cause the server to change its state.

What does that mean ? How does the server change its state ?

11.11.  ALTERNATE-SERVER
11.17.  ALTERNATE-SERVER

There are two sub-sections to section 11 that describe ALTERNATE-SERVER 
attributes (11.11 and 11.17). I think they are redundant.
(Fredrik Thulin already mentioned this but Dan did not answer to this
 point, so I decided to repeat the comment)

Regards,

Erkki
____________________________________

  Erkki Koivusalo
  Nokia Mobile Software
  tel:+358 40 7571197
  mailto:erkki.koivusalo@xxxxxxxxx
____________________________________

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 21 Mar 2006 08:34:36 -0800 (PST)

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Erkki.Koivusalo@xxxxxxxxx
> Sent: Tuesday, March 21, 2006 8:16 AM
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03
> 
> 
> Hi,
> 

Thanks.  Will be fixed in -04.

> should be mentioned here for completeness.

Ok.  I propose adding the following text:

  If the STUN client and STUN server do not share a secret (obtained
  for example via the STUN shared secret request), it isn't possible
  to protect the message using the MESSAGE-INTEGRITY attribute.

Let me know if that is satisfactory.

> Allocate Request is not defined in this spec.

Ok, will fix.  That's a bug when we merged text from TURN.

> What does that mean ? How does the server change its state ?

Right now, only TURN is using indication messages (send indication).  TURN's
send indication causes the TURN server to actually start forwarding data to
the remote endpoint.

The reason Indications are in STUN is to describe them in general.

I'll add more text in -04 so the purpose of indication messages is clearer.

>  point, so I decided to repeat the comment)

Yes, they're redundant.  Will be fixed in -04.

-d

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: <[email-masked]>
Date: Tue, 21 Mar 2006 08:56:18 -0800 (PST)

Hi,

>Let me know if that is satisfactory.

Sorry, not quite. You extended it for the case where there is no
message integrity check like in NAT keepalive usage like described
in draft-ietf-sip-outbound-02. But it would still lack the Connectivity
Check usage where message integrity check will be done based on
password got from a=ice-pwd SDP attribute, instead of getting it with
STUN Shared Secret Response.

I believe all those three cases are worth mentioning after the
"The key to use depends on the shared secret mechanism" statement.
Maybe you should make it to appear as a bulleted list of three cases ?

Regards,

Erkki

>From: ext Dan Wing [mailto:dwing@xxxxxxxxx] 
>Sent: 21.March.2006 18:35
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); 
>ietf-behave@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03
>