1. RFC3489bis Jonathan Rosenberg Cisco

2. Issue #1: IPSec Demux Raised by HIP folks IPSec in the kernel and ICE in userland –IPSec kicksc all packets with SPI=0 to userland –SPI overlaps with first 32 bits of STUN (message length, message type) Proposal: –Keep STUN as is, but indicate sometimes its carried in a framing shim even for UDP –HIP defines a framing shim that has all four bytes zero

3. Changes in since -13 Addresses DISCUSS comments from –Cullen Jennings –Sam Hartman –Chris Newman –Lars Eggert –Tim Polk Couple minor bug fixes

4. Most significant changes Fixed bug on usage of length with MESSAGE- INTEGRITY Default and minimim RTO from 100ms to 500ms (these are overriden by ICEs pacing for ICE) 40s interval for when server has to send same response to request More explicit mention of security weaknesses in 3489 which are dealt with now SASLPrep for username and passwords Maximum message size now 576 in v4, 1280 in v6, when PMTU unknown, with exception (-15) when you are doing something like MTU discovery

5. Minor Changes IANA registry rules for error codes changed to IETF consensus Note that DNS SRV procedures for TCP and TLS have changed from RFC3489 Note that FINGERPRINT mechanism is not compatible with RFC3489 Number of retransmits SHOULD be configurable, default 7 Removed requirement that STUN over TLS be on a different port than STUN over TCP

6. Cullen Discuss1: Server Close Connections STUN should say –Clients need to send some form of data at least once every T seconds – can be another Binding –Server can close connections if it sees nothing for 2T –TURN has its own rules that will cause data to be sent more often “Can the sever close the TCP connection if the client just disappears? I don't think we can leave this leftover state from deal clients around forever even if the server is not overloaded. “

7. Cullen Discuss2: Next Nonce Main use case would be TURN long-lived allocations TURN server that wants to change nonce for every transaction Without next-nonce we double transaction volume Proposal: no [KISS] – can add later Do we need next- nonce? I am fine with "no" but left here so I don't forget.

8. Cullen Discuss3: IANA Rules Attributes and method space has 50% allocated for vendor codes FCFS This is a finite and not very large space Possibilities –Change both to “designated expert” –Change methods to designated expert and add a “vendor attribute” that contains a vendor name – like RADIUS Need to figure out goals of IANA registrations and sort out if we need Expert Review or not on FCFS stuff.

9. Cullen Discuss4: Determine Server Type Current text says – look for XOR-MAPPED vs. MAPPED in response Cullen concerned about RFC3489 implementations which used XOR-MAPPED and nothing else For basic server usage doesn’t seem to matter! Still talking about a way for the client to figure out if it is talking to a 3489 server or a 3489bis server.

10. Cullen Discuss5: MTU Worry is NATs breaking on fragmentation –Avoid the “VPN sucks” problem Individual field limits remain – TCP case Current exception text is sufficient I don't understand the limitation for 576 bytes -if we are worried about NATs not working on fragmented packets that with retransmissions that a small case. We have individual fields in this protocol that are required to support values longer than this. If we do need to have this limit, we need to change the fields to be much smaller.

11. Cullen Discuss6: Stringprep There are stun deployments using user-entered username/pass – matching SIP ones (softphones) Keep language with expectation no one will implement I'm concerned about if the WG would accept the spring-prep language or not. STUN is widely used on embedded systems and I know people worked to get it down to around 10k so that it would fit on a IP phone that smashed TLS, SIP, audio code, and a graphics library, and the rest of the curd needed for a phone into half a meg. I'm not sure how small one can get a SASL profile string prep but I know the library I am using for another project looks like it is about 300k but I don't know how much other stuff it has in that I could remove. Anyways, the things we are building with STUN tend to be all machine generated username/passwords set up in configuration not user entered one. I'd want to check that this did not cause any surprises in the WG.

12. Cullen Discuss7: Demux DTLS-SRTP algorithm assumes first byte is zero or one for STUN This is based on the assumption that it is ALWAYS a Binding If other methods are used for checks the demux will fail Document this limitation It says that The most significant two bits of every STUN message MUST be zeroes. However the demux of ICE, RTP, and DTLS is based on the requirement that the top 7 bits have to be zero.

13. Newman Comment1: Separate Port Proposal: KISS and leave current mechanism in place I'm not a big fan of using a separate port for a TLS-variant of the protocol. There's some discussion of the design and perception problems that introduces in RFC 2595. I also think the best proposal I've seen for an in-band start- tls style mechanism is: http://tools.ietf.org/html/draft-fanf-smtp- quickstart-a-00 which minimizes extra round-trips while remaining compatible with typical TLS stacks. I suspect auto- detecting the different packet formats between TLS and some other protocol is unlikely to work in practice with many deployed TLS stacks, so I question the usefulness of such a proposal.

14. Minor Changes Strong passwords a SHOULD STUN over TCP unframed when talking to stun server learned through DNS – framing only when negotiated Removed text on servers dropping existing connections on high load – say to follow best practices Explained why servers need to let clients closed connections

15. Minor Changes ALTERNATE-SERVER – don’t go back to server you tried before within 5m ICMP failures that terminate STUN now clear – hard failures in RFC1122 New section on base standalone STUN server – no auth, no ALTERNATE, no framing Security considerations section says MI not always needed and usages need to explain this

16. Minor Changes TLS ciphersuite recommendation is for STUN alone. When muxed, rules of that protocol apply Usages need to discuss RFC4107 (manual vs. automated keying) Point to RFC2617 on NONCE rotation When redirected by ALTERNATE- SERVER, use same transport protocol