Session Initiation Protocol (SIP) over
Datagram Transport Layer Security (DTLS)Cisco Systems170 West Tasman DriveMS: SJC-21/2San JoseCA95134USA+1 408 902-3341fluffy@cisco.comGoogle, Inc.1600 Ampitheatre ParkwayMuntain ViewCA94043USAngm@google.comThis specification defines how to use Datagram Transport Layer
Security (DTLS) as a transport for Session Initiation Protocol (SIP).
DTLS is a protocol for providing Transport Layer Security (TLS) security
over a datagram protocol. This specification also specifies the IANA
registrations for using SIP with Datagram Congestion Control Protocol
(DCCP). DTLS can be used with either UDP or the Datagram Congestion
Control Protocol (DCCP). To accommodate this, this specification also
defines how to use SIP directly over DCCP. Datagram Transport Layer Security (DTLS) provides communication privacy similar to
TLS for datagram packets. SIP can run over
both stream and datagram transports, including UDP and TCP. SIP already defines how to use TLS with stream
oriented transports. This specification extends SIP to use DTLS with
datagram oriented transports. Since DTLS can be used with either UDP or
the Datagram Congestion Control Protocol (DCCP) as the underlying
transport this specification also defines the usage of SIP directly over
DCCP.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.Via header fields in SIP carry a transport protocol identifier. This
specification extends RFC 3261 to define the value "DTLS-UDP" for DTLS
over UDP and "DTLS-DCCP" for DTLS over
DCCP and "DCCP" for directly
over DCCP. The update to the ABNF in RFC 3261 for this parameter is the
following:The following is an example Via header field:The normal rules for sending a request over UDP in RFC 3261 apply to
sending over DTLS and directly over DCCP. Note that the congestion
safety rules for UDP do not apply to DTLS over DCCP and DCCP. In
addition, the normal rules for validating a TLS connection in RFC 3261
apply to DTLS connections. Requests with a SIPS URI can be sent over
DTLS as well as TLS.Note that DCCP performs Path Maximum Transfer Unit (PMTU) discovery.
Implementations of SIP over DTLS over DCCP and SIP over DCCP MUST use
the PMTU discovered by DCCP when determining the maximum request size
for the connection.The following considerations regarding the usage of DCCP options
and features apply to the DCCP connections for DTLS and SIP directly
over DCCP:Congestion Control ID (CCID) negotiation for both directions of
the connection MUST include CCID 2 (TCP-like congestion control).
CCID 2 optimizes for throughput over smooth rate changes and
should be suitable for SIP applications. Applications MAY choose
to include other CCIDs, in any preference order.Connections MUST NOT use the Minimum Checksum Coverage
Feature.The normal rules from RFC 3263 apply
when locating a SIP server that supports DTLS. The following new
NAPTR service values are defined:
"SIPS+D2U" for UDP, and "SIPS+D2D" for DCCP. In addition, the service value "SIP+D2D"
should be used for SIP without DTLS directly over DCCP.The default port for DTLS over UDP or DCCP is 5061. The default port
for SIP directly over DCCP is 5060.The security issues with SIP using DTLS are equivalent to the issues
of using SIP with TLS. All the security considerations in RFC 3261
relevant to TLS apply to DTLS.SIP over DCCP presents the same security issues as SIP over UDP, with
the exception that DCCP enforces congestion control at the transport
layer.This document defines new NAPTR service field values for DTLS over
DCCP and UDP as well as over DCCP with no DTLS. IANA is requested to
register these values under the "Registry for the SIP SRV Resource
Record Services Field". The resulting entries should be:[Note to RFC Editor: Please replace XXXX with the RFC number of this
specification.]This document registers two new DCCP Service Codes registry as
defined by RFC 4340.This document defines to new ports in the DCCP Port Numbers Registry
as defined by RFC 4340.Much of text and outline for this specification came from RFC 4168
authored by Jonathan Rosenberg, Henning Schulzrinne, and Gonzalo
Camarillo. Jakob Schlyter caught several typos. Eric Rescorla provided
helpful comments and text. Tom Phelan provided much of the DCCP text.
Thanks also to Colin Perkins.Datagram Transport Layer Security (DTLS) over the Datagram
Congestion Control Protocol (DCCP)This document describes the use of Datagram Transport Layer
Security (DTLS) over the Datagram Congestion Control Protocol
(DCCP).Datagram Transport Layer SecurityThis document specifies Version 1.0 of the Datagram Transport
Layer Security (DTLS) protocol. The DTLS protocol provides
communications privacy for datagram protocols. The protocol allows
client/server applications to communicate in a way that is
designed to prevent eavesdropping, tampering, or message forgery.
The DTLS protocol is based on the Transport Layer Security (TLS)
protocol and provides equivalent security guarantees. Datagram
semantics of the underlying transport are preserved by the DTLS
protocol. [STANDARDS TRACK]Augmented BNF for Syntax Specifications: ABNFSIP: Session Initiation ProtocolKey words for use in RFCs to Indicate
Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordSession Initiation Protocol (SIP): Locating SIP
ServersDynamic Delegation Discovery System (DDDS) Part Three: The
Domain Name System (DNS) DatabaseDatagram Congestion Control Protocol (DCCP)The Datagram Congestion Control Protocol (DCCP) is a transport
protocol that provides bidirectional unicast connections of
congestion-controlled unreliable datagrams. DCCP is suitable for
applications that transfer fairly large amounts of data and that
can benefit from control over the tradeoff between timeliness and
reliability. [STANDARDS TRACK]The Transport Layer Security (TLS) Protocol Version
1.1This document specifies Version 1.1 of the Transport Layer
Security (TLS) protocol. The TLS protocol provides communications
security over the Internet. The protocol allows client/server
applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery. [STANDARDS
TRACK]