Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

[Harald Alvestrand <[e-mail]>]

On 03/11/2015 03:33 PM, Justin Uberti wrote:
>
>
> On Wed, Mar 11, 2015 at 7:32 AM, Roman Shpount <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On Wed, Mar 11, 2015 at 10:24 AM, Christer Holmberg
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         I assume you mean SCTP-over-DTLS? Usage of "plain" SCTP with
>         ICE is not defined, as far as I know.
>
>
>     You are correct.
>      
>
>
>         > New things can be defined in the future. When they do, they
>         should treat ICE a virtual communication channel that
>         > provides unreliable packet transport with no order
>         guarantees which can span multiple 5-tuples.
>
>         Then the scope of what we discuss now should not be "whatever
>         protocol" - it should be the specific protocols we are discussing.
>
>
>     I think ICE-bis should define protocol requirements for the
>     protocols that can run on top of ICE, which includes:
>     1. Ability to run over unreliable packet based transport with no
>     order guarantees
>     2. Ability to demux with STUN packets
>     3. Not t make any assumption about IP addresses, ports, or other
>     transport level protocols attributes such as TOS. 
>
>
> I think these are good criteria. Note that TCP would meet these
> criteria, and I see no problem running TCP atop ICE (we used to do
> this in an old version of our data channel code).
>
> HTTP, on the other hand, would not meet criterion #1.

I seem to remember a draft I wrote once upon a time (Feb 2011).... I
called it a "datagram service".

draft-alvestrand-dispatch-rtcweb-datagram-01

The ability to demux with STUN packets was expressed here as:

   The datagram service is not completely transparent; in particular, it
   is not possible to carry a datagram where the two highest bits of the
   first octet are zero and octet 5 to 8 contain the value 0x2112A442,
   since these datagrams are reserved for use of the STUN protocol (RFC
   5389 section 6).

It didn't seem to warrant a special doc at the time, given responses, so
I dropped it.

Note that straight-up TCP on top of this model would require special
work, since the TCP header checksum covers the address fields. A
TCP-like protocol with different checksums would be trivial to define.