Re: [tram] Request to update STUN's IANA registration in STUNbis work

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/16/2014 12:18 PM, Simon Perreault wrote:
>> +----------------+ | 127 < B < 192 -+--> forward to RTP |
>> | packet -->  |  19 < B < 64  -+--> forward to DTLS |                | |
>> B < 2   -+--> forward to STUN +----------------+
> 
> Here's my reasoning...
> 
> I'm pretty sure the RFC 5764 authors looked at RFC 3489, for which B < 2
> would have been correct. The fact that draft-mcgrew-tls-srtp-00, which did
> contain the above graph, was published long before RFC 5389 was reinforces
> that hypothesis.

But the STUN usage is ICE connectivity check, which explicitly forbids RFC
3489 (see section 7 of RFC 5245).

> 
> With RFC 5389, B < 64 would be necessary, ergo the conflict with DTLS.
> 
> I'm unable to find a justification for 19 < B < 64 --> DTLS. Can anyone
> please spell it out for me? I'm just going to assume it is correct.

It's not, as it restricts TLS ContentType:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-5.

At a minimum 0-19 and 64-255 should be marked as reserved.

> 
> Fact: There are currently no registered STUN methods which would actually
> cause STUN packets to be wrongly forwarded to DTLS by an implementation of
> RFC 5764.
> 
> Fact: B < 2 limits the number of STUN methods to 128. There are currently
> 13 methods registered. I know of no plans to register many STUN methods
> such that a limit of 128 would become problematic.

TURN had a limited deployment until now.  With WebRTC I expect more TURN
extensions coming and I myself have some currently being designed.  So that's
certainly not the right time to restrict the number of methods possible.

> 
> Fact: If STUN-bis restricts to 128 the range of STUN methods, current 
> implementations, of either STUNv1, STUNv2, or RFC 5764, will *not* need to
> be modified. STUN-bis could split on 0-63 for IETF Review and 64-127 for
> Designated Expert so that we can keep our dual registration procedures.

Maybe.  The main problem is that (implicit) assignments were done in TWO IANA
registries without following the process.  That's what need to stop.

> 
> Opinion: The only disadvantage I can see to making this change in STUN-bis
> would be a loss of STUN method range. I think we can live with it. If at
> some point we can't live with it anymore, which I doubt will ever happen,
> then we would need to revise both RFC 5764 and STUN-bis. There's no need
> for a revision of RFC 5764 now.

Or, we can reclaim 2-63 for STUN now and not have to pull an ugly EDNS(x)-like
workaround later.

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJTdmjGAAoJECnERZXWan7EocgQALGMzXkX/hKqHJjZafA+L9BK
LmhWPC/ABPGJspZXmaZSVMV/jYsyjUK10OiaxpR8VKM0yvaE5MrUXrRT5uQll/G2
6/tcrHXjs4lLhhAAfHmJzQu3tv8UYnTEKLJq7CNrr0Uoa5vRZtgiRMXmmDZH8IUn
alB2gRtHZR6jiBeWLKogdUaXOzIzIwnu86E8+HgeWL+vHRuc6gX1uiZZ+mr0MPzR
x0BlZXatCOSN7Ho/5DqgWsM+WMZXKS+UnfV58kjVk8Ycuk78ETIo+kzOc7qWcNfP
f0bq2mTDKWDQq6oyhJZ6z5s23v+EiemSTy5H5iYJ7f3iahnbS3yx6F0pni6dG+EK
GzeANH4riPwJoZvx5zmdXUBpnbMjUDxUZIs1H+M3ETlT3T93hQzaHDI/PVjMG3TQ
9AHqDyRfeI9J0noeNp1KO2nznxM1WaTOMTA36X2JuMgmqO04LpzUuNPw79HMVDyX
pnWfPoM+WrFid/iK9FV9L1t8zMcOHblaKtMARdM/h9jvrk8Lygjyf3ihomp7+oc/
GQr3yIx73vcJZ8aRsWNqjKWpsnMhU3/jPeunH52RqbvWjhXgS6L5XzIWiRQBujcZ
1FlipuMIKauIrwGdpNM7Wu5l42Ysh06pf1i0SYeLGXTLJwzZ3IK9YzZrEMpgM6O/
crLLyWye/L9GqbVK+sWG
=qfng
-----END PGP SIGNATURE-----