Subject: [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 02 Jul 2014 05:45:43 -0600

Following discussions with Martin Thomson and Magnus Westerlund, we
prepared this draft that aims to fix some issues in RFC 5764.

The discussion in this mailing-list should be about updating the IANA
STUN Methods Registry.  Discussions about the TLS ContentType Registry
should stay in the TLS mailing-list, and the RFC 5764 modifications
should stay in the AVTCORE mailing-list.

Thanks.

URL:
http://www.ietf.org/internet-drafts/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00.txt
Status:
https://datatracker.ietf.org/doc/draft-petithuguenin-avtcore-rfc5764-mux-fixes/
Htmlized:
http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

-- 
Marc Petit-Huguenin
Developer  |  Jive Communications, Inc.
Jive.com  |  [email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Wed, 23 Jul 2014 23:32:14 -0400

Following up on my comments from the session today:

I don't think the demux situation is as dire as is described in this
document.
1) TURN channel messages only need to be demuxed from STUN. Channeldata
packets will only come from the TURN server, and packets from the TURN
server will never be unencapsulated. And so the RFC 5764 rules never need
to consider channeldata. (i.e. point #3 in Section 1 is a non-issue.)
2) STUN is trivially demuxable from both RTP and DTLS, because of both
MAGIC-COOKIE and FINGERPRINT, both of which are mandatory for ICE. So we
can just say "use fingerprint" to resolve any demux ambiguity.
3) This just leaves RTP vs DTLS, or RTP vs RTCP, all of which can be
distinguished using trivial existing methods.

On Wed, Jul 2, 2014 at 7:45 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Jul 2014 07:14:21 -0400

> I don't think the demux situation is as dire as is described in this

Yay! :)

> server will never be unencapsulated. And so the RFC 5764 rules never
> need to consider channeldata. (i.e. point #3 in Section 1 is a non-issue.)

All good points that IMHO need to be detailed in Marc's draft. Demux can
be done by looking at more things than just the first byte, and we need
to describe how.

Do we still need to change the IANA STUN registry ranges then?

Simon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Jul 2014 13:21:53 -0400

> Do we still need to change the IANA STUN registry ranges then?

IMO this is not necessary, as there never is a problem with demuxing STUN
in any known protocol scenarios. We just need to update the 5764 text to
refer to 5389, Section 7.3, which outlines how STUN demux should be done.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 24 Jul 2014 20:16:44 +0000

Hi,

Inline and answering several people at once..
On 24 Jul 2014, at 13:21, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jul 24, 2014 at 7:14 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
> I don't think the demux situation is as dire as is described in this

Yay! :)
+1..

> need to consider channeldata. (i.e. point #3 in Section 1 is a non-issue.)
Agree

> can just say "use fingerprint" to resolve any demux ambiguity.
I would prefer to say use MAGIC-COOKIE. It is at a static place in the header thus making et very easy to look for it.
The fingerprint is at the tail of the packet, can in some instances be a pain if you are not interested in the stun packet to read that far.

Implementation wise we have always checked for the MAGIC-COOKE when determining if this is a STUN packet or not.

Or am I missing something important regarding the demuxing problem?

Sample code:

bool stunlib_isStunMsg(const uint8_t *payload, uint16_t length)
{
    /* first 2 bits must be 00, STUN header and magic cookie */
    return (((*payload & STUN_PACKET_MASK) == STUN_PACKET)
        &&  (length >= 20)
        &&  (memcmp(payload+4, (void *)StunCookie, StunCookieSize) == 0));
}

I think this is pretty clear in the existing STUN spec?

IMO this is not necessary, as there never is a problem with demuxing STUN in any known protocol scenarios. We just need to update the 5764 text to refer to 5389, Section 7.3, which outlines how STUN demux should be done.
+1

.-.
Pål-Erik

________________________________________
_______
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Jul 2014 18:16:39 -0400

On Thu, Jul 24, 2014 at 4:16 PM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>  On 24 Jul 2014, at 13:21, Justin Uberti <[email-masked]> wrote:
>
>
>   I would prefer to say use MAGIC-COOKIE. It is at a static place in the
> header thus making et very easy to look for it.
> The fingerprint is at the tail of the packet, can in some instances be a
> pain if you are not interested in the stun packet to read that far.
>
>  Implementation wise we have always checked for the MAGIC-COOKE when
> determining if this is a STUN packet or not.
>

This is what the spec says (S 7.3):

When a STUN agent receives a STUN message, it first checks that the
   message obeys the rules of Section 6.  It checks that the first two
   bits are 0, that the magic cookie field has the correct value, that
   the message length is sensible, and that the method value is a
   supported method.  It checks that the message class is allowed for
   the particular method.  If the message class is "Success Response" or
   "Error Response", the agent checks that the transaction ID matches a
   transaction that is still in progress.  If the FINGERPRINT extension
   is being used, the agent checks that the FINGERPRINT attribute is
   present and contains the correct value.

So the spec says to check FINGERPRINT, if all previous checks succeed.
Since you're also going to have to verify MESSAGE-INTEGRITY, checking
FINGERPRINT shouldn't be a big deal.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Jul 2014 18:22:42 -0400

> FINGERPRINT shouldn't be a big deal.

And if FINGERPRINT is deemed useless, we should remove it in STUN-bis.

Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 25 Jul 2014 00:34:49 +0000

On 24 Jul 2014, at 18:22, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

>From Section 8 of RFC5389:

   This section describes an optional mechanism for STUN that aids in
   distinguishing STUN messages from packets of other protocols when the
   two are multiplexed on the same transport address.  This mechanism is
   optional, and a STUN usage must describe if and when it is used.

I think that text is fine. The usage is optional, and whoever uses STUN to do smartThings(tm) can include it if necessary.

I do remember to have seen some probability calculations on false positives, but can not find them.

Is the value of the MAGIC COOKIE chosen specifically to avoid clashes with other protocols? Or is its value some sort of smart pun that I do not get?

.-.
Pål-Erik

Simon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 24 Jul 2014 22:43:06 -0400

On Thu, Jul 24, 2014 at 8:34 PM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>
>  On 24 Jul 2014, at 18:22, Simon Perreault <[email-masked]> wrote:
>
>  I think that text is fine. The usage is optional, and whoever uses STUN
> to do smartThings(tm) can include it if necessary.
>

Right, this is a question for MMUSIC, since ICE is the only usage (AFAIK)
where FINGERPRINT is mandatory.

> positives, but can not find them.

There was a clear need for FINGERPRINT back when TURN allowed one to set a
default destination, meaning that you could get unencapsulated traffic
mixed with TURN message traffic, and so FINGERPRINT was needed to separate
ICE connectivity checks from messages from the TURN server. Now, I think it
is mainly useful to avoid random collisions.

>
>  Is the value of the MAGIC COOKIE chosen specifically to avoid clashes
> with other protocols? Or is its value some sort of smart pun that I do not
> get?
>
>  .-.
> Pål-Erik
>
>
> Simon
>
>
>

---

From: Dan Wing <[email-masked]>
Date: Fri, 25 Jul 2014 18:46:37 -0700

> Is the value of the MAGIC COOKIE chosen specifically to avoid clashes with other protocols? Or is its value some sort of smart pun that I do not get?

Magic cookie was chosen randomly by flipping a coin 32 times.

-d