STUN Changes draftietfbehaverfc3489bis03

1
STUN Changesdraft-ietf-behave-rfc3489bis-03

• Jonathan RosenbergDan Wing
• Cisco Systems

2
Changes since -02

• Magic-Cookie
• Determines RFC3489 or RFC3489bis
• Whether to use XOR or old mapped address
• Stolen from transaction ID
• Branch cookie style from SIP
• Puts differentiation high up in the message

• Created usages and defined 4
• Binding Discovery (classic RFC3489)
• Connectivity Check (ICE)
• NAT Keepalives (sip-outbound)
• Short-Term Password (classic RFC3489)
• Removed attributes to determine NAT type

3
Changes since -02

• Clarified 0b00 begins each STUN packet
• Support for IPv6
• Removed text recommending listening for
  late-arriving STUN responses for 10 seconds
• Was an attempt to detect STUN attacks

4
Changes since -02

• Moved from TURN to STUN
• Magic-Cookie originated in TURN, but found
  additional value when used in STUN
• STUN Indications
• Authentication framework
• Digest
• Attributes
• ALTERNATE-SERVER
• REALM
• NONCE

5
Changes since -02

• Added BINDING-LIFETIME attribute
• Placeholder for configuring stun keepalives easily

6
Open Issue 1 Fate of type-determination
attributes

• NAT type attributes
• RESPONSE-ADDRESS
• CHANGED-ADDRESS
• CHANGE-REQUEST
• SOURCE-ADDRESS
• REFLECTED-FROM
• What should we do with them?
• Leave them in RFC3489bis
• Back-reference to RFC3489
• Proposal Create separate diagnostic I-D

7
Open Issue 2 TLS

• Not fully specd out on how to determine whether
  to send or receive TLS
• Issue raised on list should we use NAPTR?
• This was done in SIP because we needed to have
  priority across disparate protocols
• Not the case here client knows exactly which it
  needs (TCP/UDP/TLS)
• Need to factor in usages may want different
  ports for them
• Proposal just SRV
• _usage._transport.domain
• Stun binding discovery usage
• Backwards compatible and folds naturally into
  ports per usage

8
Need Help On

• Failover behavior
• Usage-specific (NAT keepalive behavior is
  different from connectivity check)