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

From: <[email-masked]>
Date: Tue, 28 Mar 2006 04:26:02 -0800 (PST)

Hi Dan,

I found another inconsistency in rfc3489bis-03:

8.1.1.  Discovery

   The DNS SRV service name is "stun".  The protocol is "udp" for
   sending Binding Requests, or "tcp" for sending Shared Secret
   Requests. 

12.5.2.  Client Discovery of Server

   The client follows the procedures in Section 8.1.1, except the SRV
   protocol is TCP rather than UDP and the service name "stun-tls".

   For example a client would look up "_stun-tls._tcp.example.com" in
   DNS.

So what is the service name for discovering STUN server supporting
Shared Secret requests over TLS: "stun" or "stun-tls" ? I would
prefer "stun" unless there is a really good reason to introduce
a new service name for this usage. What was the reason for
introducing "stun-tls" ?

Regards,

Erkki

>-----Original Message-----
>From: ext Dan Wing [mailto:dwing@xxxxxxxxx] 
>Sent: 21.March.2006 21:46
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Subject: RE: [Ietf-behave] Comments on draft-ietf-behave-rfc3489bis-03
>
>You're right.  Let me play with some text and reply back, 
>probably later
>tonight.
>
>-d
> 
>
>> -----Original Message-----
>> From: Erkki.Koivusalo@xxxxxxxxx [mailto:Erkki.Koivusalo@xxxxxxxxx] 
>> Sent: Tuesday, March 21, 2006 8:56 AM
>> To: dwing@xxxxxxxxx; ietf-behave@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [Ietf-behave] Comments on 
>draft-ietf-behave-rfc3489bis-03
>> 
>> 
>> Hi,
>> 
>> >> 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.
>> >
>> >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.
>> 
>> 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
>> 
>> >-----Original Message-----
>> >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
>> >
>> >> -----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,
>> >> 
>> >> 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.
>> >
>> >Thanks.  Will be fixed in -04.
>> >
>> >> 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.
>> >
>> >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.
>> >
>> >>    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.
>> >
>> >Ok, will fix.  That's a bug when we merged text from TURN.
>> >
>> >> 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 ?
>> >
>> >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.
>> >
>> >> 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)
>> >
>> >Yes, they're redundant.  Will be fixed in -04.
>> >
>> >-d
>> >
>> >> Regards,
>> >> 
>> >> Erkki
>> >> ____________________________________
>> >> 
>> >>   Erkki Koivusalo
>> >>   Nokia Mobile Software
>> >>   tel:+358 40 7571197
>> >>   mailto:erkki.koivusalo@xxxxxxxxx
>> >> ____________________________________ 
>> >> _______________________________________________
>> >> Ietf-behave mailing list
>> >> Ietf-behave@xxxxxxxxxxxxxxxxxxx
>> >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>> >
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Mar 2006 08:07:12 -0800 (PST)

> a new service name for this usage. What was the reason for

Many server implementations need to know if they're going to 
receive a TCP SYN (and subsequent TCP connection establishment)
and then a TLS client hello (and subsequent TLS setup) and then
a STUN Request message, or if they're going to receive a TCP SYN
(and TCP connection establishment) followed immediately by a STUN 
Request.

With most protocols (HTTP/HTTPS, POP3/POP3S, IMAP/IMAPS) this
is done with separate ports.  Using different SRV records for
STUN and STUN-over-TLS allows the same separation if the server
wants separate ports.  If the server is capable of multiplexing
TLS and non-TLS connections on the same port, the DNS SRV
record can be pointed to the same port.

-d