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

[Simon Perreault <[e-mail]>]

>                     +----------------+
>                     | 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.

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.

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.

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.

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.

Simon