RFC3489bis

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 SPI0 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 doesnt 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
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.

• Worry is NATs breaking on fragmentation
• Avoid the VPN sucks problem
• Individual field limits remain TCP case
• Current exception text is sufficient

11
Cullen Discuss6 Stringprep
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.

• There are stun deployments using user-entered
  username/pass matching SIP ones (softphones)
• Keep language with expectation no one will
  implement

12
Cullen Discuss7 Demux
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.

• 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

13
Newman Comment1 Separate Port
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/dra
ft-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.

• Proposal KISS and leave current mechanism in
  place

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 dont 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