Subject: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt

From: [email-masked]
Date: Tue, 17 Feb 2015 08:32:43 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TURN Revised and Modernized Working Group of the IETF.

        Title           : Session Traversal Utilities for NAT (STUN)
        Authors         : Marc Petit-Huguenin
                          Gonzalo Salgueiro
                          Jonathan Rosenberg
                          Dan Wing
                          Rohan Mahy
                          Philip Matthews
	Filename        : draft-ietf-tram-stunbis-01.txt
	Pages           : 57
	Date            : 2015-02-17

Abstract:
   Session Traversal Utilities for NAT (STUN) is a protocol that serves
   as a tool for other protocols in dealing with Network Address
   Translator (NAT) traversal.  It can be used by an endpoint to
   determine the IP address and port allocated to it by a NAT.  It can
   also be used to check connectivity between two endpoints, and as a
   keep-alive protocol to maintain NAT bindings.  STUN works with many
   existing NATs, and does not require any special behavior from them.

   STUN is not a NAT traversal solution by itself.  Rather, it is a tool
   to be used in the context of a NAT traversal solution.

   This document obsoletes RFC 5389.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tram-stunbis-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 18 Feb 2015 03:46:52 -0700

All,

We have requested 40 minutes in Dallas to discuss the modifications summarized below.  We plan to release -02 before the cutoff with minor edits for the remaining of the TODO list, but we wanted to release a first version with the most important modifications ahead of the meeting.  We may not have the time to answer every email before Dallas, but we will collect the feedback and address it appropriately during the meeting.

Thanks.

Changelog:

   o  Add negotiation mechanism for new password algorithms.
   o  Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol.
   o  Add support for SCTP to solve the fragmentation problem.
   o  Merge RFC 7350:
      *  Split the "Sending over..." sections in 3.
      *  Add DTLS-over-UDP as transport.
      *  Update the cipher suites and cipher/compression restrictions.
      *  A stuns uri with an IP address is rejected.
      *  Replace most of the RFC 3489 compatibility by a reference to
         the section in RFC 5389.
      *  Update the STUN Usages list with transport applicability.
   o  Merge RFC 7064:
      *  DNS discovery is done from the URI.
      *  Reorganized the text about default ports.
   o  Add more C snippets.
   o  Make clear that the cached RTO is discarded only if there is no
      new transactions for 10 minutes.

> ftp://ftp.ietf.org/internet-drafts/

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Feb 2015 10:47:55 -0800

I checked the text and I am not sure that SCTP - over DTLS - over UDP
is the right tunneling sequence. This is a typo or a mistake, I
believe.

I suppose that the right sequence is DTLS - over SCTP - over UDP. That
would be easier to implement, it is closer to the "true" SCTP, and I
see no security benefits in hiding SCTP inside DTLS.

Thanks
Oleg

On Tue, Feb 17, 2015 at 8:32 AM,  <[email-masked]> wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Benjamin Schwartz <[email-masked]>
Date: Tue, 24 Feb 2015 14:01:06 -0500

WebRTC uses UDP/DTLS/SCTP, not the other way.

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Feb 2015 11:08:15 -0800

I do not see word "webrtc" anywhere in the text. We are discussing
STUN protocol here, right ? From the networking point of view,
DTLS/SCTP/UDP makes much more sense.

Thanks
Oleg

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Feb 2015 14:12:06 -0500

> DTLS/SCTP/UDP makes much more sense.

Is SCTP demultiplexing specified anywhere?

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Feb 2015 11:22:04 -0800

I did not find any reference.

But from the networking point of view, SCTP is supposed to be between
IP and DTLS. If we cannot use IP directly and we substitute it for
UDP, that's fine and that can be explained; but switching SCTP and
DTLS looks like a bizarre and temporary hack.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 24 Feb 2015 12:48:35 -0700

Yes, the intent is "whatever the WebRTC guys are using", so experience and code (and bugs) can be shared.

On 02/24/2015 12:01 PM, Benjamin Schwartz wrote:
> On Tue, Feb 24, 2015 at 1:47 PM, Oleg Moskalenko <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Tue, Feb 17, 2015 at 8:32 AM,  <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 24 Feb 2015 12:50:59 -0700

On 02/24/2015 12:12 PM, Simon Perreault wrote:
> 
> On Tue, Feb 24, 2015 at 2:08 PM, Oleg Moskalenko <[email-masked] <mailto:[email-masked]>> wrote:
> 

Section 6.2.3: "... the SCTP source and destination ports MUST be chosen so the two most significant bits are 0b11."

- -- 
Marc Petit-Huguenin

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Feb 2015 15:11:08 -0500

On Tue, Feb 24, 2015 at 2:50 PM, Marc Petit-Huguenin <[email-masked]>
wrote:

> Section 6.2.3: "... the SCTP source and destination ports MUST be chosen
> so the two most significant bits are 0b11."
>

I see! Clever.

It would be awesome if you could update
draft-petithuguenin-avtcore-rfc5764-mux-fixes to match this before the
deadline!

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Feb 2015 12:17:05 -0800

> Section 6.2.3: "... the SCTP source and destination ports MUST be chosen so the two most significant bits are 0b11."

0b11 looks more like bytes than bits.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 24 Feb 2015 13:20:39 -0700

On 02/24/2015 01:11 PM, Simon Perreault wrote:
> 
> On Tue, Feb 24, 2015 at 2:50 PM, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>> wrote:
> 

With thanks to Michael Tuexen for his help on this.

> 
> It would be awesome if you could update draft-petithuguenin-avtcore-rfc5764-mux-fixes to match this before the deadline!

We plan to do so.

Thanks.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 24 Feb 2015 13:26:13 -0700

> 0b11 looks more like bytes than bits.

Java binary literal.  Will fix.

- -- 
Marc Petit-Huguenin

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 25 Feb 2015 04:45:32 +0000

Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UDP ?

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
> Sent: Wednesday, February 25, 2015 12:38 AM
> To: Benjamin Schwartz
> Cc: [email-masked]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-01.txt
> 
> I do not see word "webrtc" anywhere in the text. We are discussing STUN
> protocol here, right ? From the networking point of view, DTLS/SCTP/UDP
> makes much more sense.
> 
> Thanks
> Oleg
> 
> 
> >> I suppose that the right sequence is DTLS - over SCTP - over UDP.
> >> That would be easier to implement, it is closer to the "true" SCTP,
> >> and I see no security benefits in hiding SCTP inside DTLS.
> >>
> >> Thanks
> >> Oleg
> >>
> >>
> >> > Please note that it may take a couple of minutes from the time of
> >> > submission until the htmlized version and diff are available at
> >> > tools.ietf.org.
> >> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 25 Feb 2015 04:51:15 +0000

The cipher suites and other recommendations in http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-09 must be used and there is no need explicitly mention the subset in section 6.2.4

-Tiru

> From: tram [mailto:[email-masked]] On Behalf Of Marc Petit-
> Huguenin
> Sent: Wednesday, February 18, 2015 4:17 PM
> To: [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> All,
> 
> We have requested 40 minutes in Dallas to discuss the modifications
> summarized below.  We plan to release -02 before the cutoff with minor
> edits for the remaining of the TODO list, but we wanted to release a first
> version with the most important modifications ahead of the meeting.  We
> may not have the time to answer every email before Dallas, but we will
> collect the feedback and address it appropriately during the meeting.
> 
> Thanks.
> 
> Changelog:
> 
> submission
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJU5G2cAAoJECnERZXWan7ED1EP+gPP0+Xn+EcgqtGe/jxzGG
> 6F
> iLmEt2GSjLMMLfoTZV5UaD4n7jUU0K3kL915PwP8ypoo750H/lh03K5Utsm9Zxe
> L
> nu7//dNyo1KsEB2cHNCAwLpXeVMnyes7RjiTUOtK8gf2TcvQjlOu9UksUJIy58E7
> dxczH58sujoAjsLqg2ml7JJejKEUsowbGJtj6aaEGt61QYV7ojc1sNoNqF6tuGqY
> EhrDbzuu/SfeW0bxC/EOwitbpISBy9m289eMcOz9UdnoVRyOD14+gst/glizRU/
> 2
> X1v+4ABsv0TtEZrq8pf57FhI8ImMkseY/7A7nhft7zObUW2Lk67H9+KitoLtUiPn
> cPEolUvmA4RBAOnTpopR//o+4lUMnu4RbwZhlUdfBGxQsZ1iOWGmt7GYD6j+
> q5ow
> 9KxALPyuFUcm4Os3klGaCdZS2THEc6T4VIROMMifs3i1kCvCKnqPOPVF3GKeS4
> bw
> lLNwf+YuhS5m9WPylx1OMTsbfSVqzh+Bh9qekar57yUuNoAgnqqYMxAiWH7M
> lveS
> O3OiXI10papVe1UNfStmQX8SuYSb7DlsadQzldgOlMRveImKa3tRtzS7AXQ02Exj
> apv7o/j0uuEVr9NJE1CCKonfZqCzPnaU7LrTAHZZnQrz/lmN97spwCCyfbQcqOa
> k
> 5RfMzQZxVJo6YFkWpseE
> =CmHq
> -----END PGP SIGNATURE-----
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 24 Feb 2015 21:04:08 -0800

Tiru, that is exactly what I am trying to understand - why ? I have a feeling that we are trying to stretch the RFC to cover a proprietary library or else. I d like to hear more arguments from the authors.

Thanks
Oleg

> On Feb 24, 2015, at 8:45 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 25 Feb 2015 02:45:16 -0700

> Even in WebRTC why should STUN messages be sent over SCTP over DTLS over UDP ?

Nobody said anything like this.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 25 Feb 2015 03:00:30 -0700

> Tiru, that is exactly what I am trying to understand - why ? I have a feeling that we are trying to stretch the RFC to cover a proprietary library or else. I d like to hear more arguments from the…

I resent this accusation.  I am here only to "make the Internet work better".

WebRTC is sending *data* over SCTP over DTLS over UDP.

- -- 
Marc Petit-Huguenin

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 25 Feb 2015 11:03:53 +0000

> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Wednesday, February 25, 2015 3:15 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko; Benjamin Schwartz
> Cc: [email-masked]

Data channel traffic is sent over SCTP over DTLS over UDP after ICE checks and candidate selection which happens either over TCP or UDP. ICE keepalives and consent checks after media session is established are sent over UDP/TCP but not over SCTP. You may want to refer to the figure 5 in https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 

-Tiru

> >> On Tue, Feb 24, 2015 at 11:01 AM, Benjamin Schwartz
> <[email-masked]>
> >> wrote:
> iQIcBAEBCAAGBQJU7ZmsAAoJECnERZXWan7Ewa4QAK2B74KwKoTNH+7ScIFz
> FKwC
> k99A2Ip3DN8avwpYcSOau8WP/7MGInzfIRfpLlemNPi368TJiUXIADQ2CMRndC
> Zu
> 0ewuzn9OH4x3zzsfNSwPq0pMG8GU4nQ5F+0b46lk4fj+9z/LH74EdQhD84wVw
> +TC
> +Oc+2VPz3AtfyDztk4AQwHwfVSiAQbWBh0yPCON+q9YNRtiOMRzR2bKTrwX9
> mEjl
> VGv7D9n/+96YrriIEG+jfM5AO1418yI/OTmyGLlKkhA3KDe729INSHi3NQzKXNU
> w
> AAaCLf1PYXePngA0abMj0us3O9AGCiR35IHacG0K9mZ+6HPLFPGbLiMZxwMUz
> 3TN
> 9Ee8n6gbs5FFwXHGEdzqkrYZ0LkRS6HaZ6RY8kaKgWGXJKvuGVEr8j2sIxajcUH1
> u/ZQpjhPaBZL0dyfSNHXWRKwkPgm5f9/Tw+LzP217FGpPYoCFmgp1X0/yLwtdZ
> /N
> nO7UgP9Ue80qPh3TSa24RPvGTCwGUk314vl4g+wfYZfUu9q7bVtQoaUN70nmc
> Kph
> XfbZRGoe5iepVYEDzk2ulpmFFAIcDOeXG4XqZ/YvFxAl5HvlgLK70ubp+1ly4fp5
> qICj/fecTi1sGCtrj1HMghSWPM/xxDr2msP0BZ04jC2A50i5Xx0IldJXPepMIWjQ
> n6qZPY8xvYbNQFlX5rBh
> =C/AN

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 25 Feb 2015 04:45:34 -0700

The choice of SCTP [over DTLS] over UDP to solve the STUN fragmentation problem has nothing to do with WebRTC.  The stack order is aligned with WebRTC's because of the probability that the two stacks will be collocated, and so can share code.  There is no other reason than this one.

- -- 
Marc Petit-Huguenin

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 Feb 2015 09:14:32 -0500

On Wed, Feb 25, 2015 at 6:45 AM, Marc Petit-Huguenin <[email-masked]>
wrote:

> The choice of SCTP [over DTLS] over UDP to solve the STUN fragmentation
> problem has nothing to do with WebRTC.  The stack order is aligned with
> WebRTC's because of the probability that the two stacks will be collocated,
> and so can share code.  There is no other reason than this one.

Right. Technically, both possibilities would work, but the fact is that
there is tons of code floating around for SCTP/DTLS/UDP, but not as much
for DTLS/SCTP/UDP. So that reason makes sense to me.

Another reason that I can think of is that it allows one to reuse the DTLS
session in case you're also multiplexing DTLS-SRTP on the socket. That
makes session establishment take fewer round-trips.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Feb 2015 08:53:54 -0800

> I resent this accusation.  I am here only to "make the Internet work better".

Marc, I am sorry if that sounded harsh, as an personal "accusation". I
was referring to the impression that the written text makes, I did not
mean anything personal.

Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Feb 2015 09:04:47 -0800

> Nobody said anything like this.

I am looking at the section 6.2.3 and it is clearly discussing STUN
commands being sent over SCTP-over DTLS-over UDP. If that was not the
authors intention, then the text has to be changed.

We already have DTLS-over UDP. The TURN client is free to encapsulate
into that protocol whatever they want, including SCTP, that is about a
concrete application and that is totally fine. But putting a somewhat
unnatural special case of encapsulation - SCTP-over-DTLS - into the
standard text, and mandating the SCTP port choices, sounds like a
somewhat un-clean approach. Even if there are tons of code out there.
But that pre-existing code - does it require standardization, or
everything probably is OK as-is with the current STUN DTLS specs ? Do
we really have to add SCTP to the standard ?

Thanks
Oleg

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 25 Feb 2015 10:55:48 -0700

> authors intention, then the text has to be changed.

Again, that has nothing to do with WebRTC.

Section 6.1:

"If a STUN client needs to send requests that are larger than the MTU,
 or if an application envisions that a response would be larger then
 the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as
 transport, unless the purpose of sending an oversized packet is to
 probe for MTU characteristics (see [RFC5780])."

- -- 
Marc Petit-Huguenin

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Feb 2015 10:57:47 -0800

> Again, that has nothing to do with WebRTC.

I did not say that it has. WebRTC point was raised by somebody else.

>  probe for MTU characteristics (see [RFC5780])."

So, SCTP is used here purely as a tool to solve the fragmentation
problem ? Right ?

Thanks
Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 25 Feb 2015 11:23:06 -0800

I'd like to clarify the necessity of the MESSAGE-INTEGRITY2 attribute.
My opinion is that we can avoid introducing a new MESSAGE-INTEGRITY[X]
attribute for every new used hash algorithm. What if we decide to use
SHA-384 ? Introduce MESSAGE-INTEGRITY3, and so on ? I think that this
is redundant, messy and unnecessary.

There is a well-defined association between the hash length and the
algorithm. SHA-1 produce 20 bytes, SHA-256 produce 32 bytes, SHA-384
produce 48 bytes and SHA-512 produce 64 bytes. Why we cannot use the
MESSAGE-INTEGRITY length to determine the algorithm that the peer is
using ?

 If we want to support algorithm negotiation (vs the out-of-band
negotiation) then we can introduce a new error code "too weak
credentials" or something (and possibly another code "too strong
credentials") and use that error code in the negotiation stage. That
may mean a possible extra round trip on connection establishment. But
in most cases the client and the server will have a mutual
understanding which algorithm to be used.

Or, we may require that all new STUN agents SHOULD support SHA-1
through SHA-512 algorithms. It is not a problem these days, giving
current available libraries state. That would actually eliminate the
necessity of a new error code, new attribute and extra round-trip. The
client can propose an algorithm in the initial authenticated message;
if the server is not happy about the algorithm chosen by client, then
the server may reply OK but sign the message with a different hash
size. Then, the client must use the algorithm chosen by server, or
cancel the session. The server can always abort the session if the
algorithm strength does not match the server policy and if the client
is not cooperating.

Thanks
Oleg

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 26 Feb 2015 08:04:54 -0700

> MESSAGE-INTEGRITY length to determine the algorithm that the peer is

Does not work with SHA-3.

- -- 
Marc Petit-Huguenin

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 26 Feb 2015 08:56:20 -0800

> Does not work with SHA-3.

If there is a requirement to support wide multiplicity of algorithms,
even SHA-3, then I see two clear choices:

1) Leave the algorithm negotiation to the out-of-bound communication
channel between the client and the server. They can negotiate what
kind of hash is used, and what is the size of the MESSAGE-INTEGRITY to
be.
2) Implement a usual negotiation scheme, like in TLS. We can introduce
a new attribute that contains "algorithm ID" and optionally "algorithm
attribute(s)" (specific to algorithm). The client sends a number of
supported algorithm attributes to the server, server either rejects or
picks one and sends back authenticated response with the chosen
algorithm attribute. If no attribute is included in the client or
server message, that means default "SHA-1, 160 bits". If a variable
length hash algorithm chosen, then that's fine, the message recipient
will just use the MESSAGE-INTEGRITY attribute length (given they
already agree on a particular algorithm).

I'd vote for the second approach. That way, we introduce no extra
round trips, we cover multiple algorithms (including the future ones),
and we have full backward compatibility.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 27 Feb 2015 05:19:52 -0700

> Java binary literal.  Will fix.

In fact this is the same exact notation that is used in RFC 5389 section 6, so unless the WG wants us to also change section 6, the binary literal in stunbis section 6.2.3 will stay the same.

- -- 
Marc Petit-Huguenin