idnits 2.17.1 draft-jennings-sip-dtls-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 239. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 263. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 10, 2007) is 6042 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 159 ** Obsolete normative reference: RFC 4347 (ref. '2') (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4234 (ref. '3') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '9') (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track N. Modadugu 5 Expires: April 12, 2008 Google, Inc. 6 October 10, 2007 8 Session Initiation Protocol (SIP) over Datagram Transport Layer Security 9 (DTLS) 10 draft-jennings-sip-dtls-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 12, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines how to use Datagram Transport Layer 44 Security (DTLS) as a transport for Session Initiation Protocol (SIP). 45 DTLS is a protocol for providing Transport Layer Security (TLS) 46 security over a datagram protocol. This specification also specifies 47 the IANA registrations for using SIP with Datagram Congestion Control 48 Protocol (DCCP). DTLS can be used with either UDP or the Datagram 49 Congestion Control Protocol (DCCP). To accommodate this, this 50 specification also defines how to use SIP directly over DCCP. 52 1. Introduction 54 Datagram Transport Layer Security (DTLS) [2] provides communication 55 privacy similar to TLS [9] for datagram packets. SIP can run over 56 both stream and datagram transports, including UDP and TCP. SIP [4] 57 already defines how to use TLS with stream oriented transports. This 58 specification extends SIP to use DTLS with datagram oriented 59 transports. Since DTLS can be used with either UDP or the Datagram 60 Congestion Control Protocol (DCCP) as the underlying transport this 61 specification also defines the usage of SIP directly over DCCP. 63 2. Terminology 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [5]. 69 3. VIA Codes 71 Via header fields in SIP carry a transport protocol identifier. This 72 specification extends RFC 3261 to define the value "DTLS-UDP" for 73 DTLS over UDP[2] and "DTLS-DCCP" for DTLS over DCCP[1] and "DCCP" for 74 directly over DCCP[8]. The update to the ABNF[3] in RFC 3261 for 75 this parameter is the following: 76 transport =/ "DCCP" / "DTLS-DCCP" / "DTLS-UDP" 78 The following is an example Via header field: 79 Via: SIP/2.0/DTLS-UDP atlanta.example.com:5060 81 4. DTLS and DCCP Usage 83 The normal rules for sending a request over UDP in RFC 3261 apply to 84 sending over DTLS and directly over DCCP. Note that the congestion 85 safety rules for UDP do not apply to DTLS over DCCP and DCCP. In 86 addition, the normal rules for validating a TLS connection in RFC 87 3261 apply to DTLS connections. Requests with a SIPS URI can be sent 88 over DTLS as well as TLS. 90 Note that DCCP performs Path Maximum Transfer Unit (PMTU) discovery. 91 Implementations of SIP over DTLS over DCCP and SIP over DCCP MUST use 92 the PMTU discovered by DCCP when determining the maximum request size 93 for the connection. 95 4.1. DCCP Option Usage 97 The following considerations regarding the usage of DCCP options and 98 features apply to the DCCP connections for DTLS and SIP directly over 99 DCCP: 101 o Congestion Control ID (CCID) negotiation for both directions of 102 the connection MUST include CCID 2 (TCP-like congestion control). 103 CCID 2 optimizes for throughput over smooth rate changes and 104 should be suitable for SIP applications. Applications MAY choose 105 to include other CCIDs, in any preference order. 106 o Connections MUST NOT use the Minimum Checksum Coverage Feature. 108 5. Locating DTLS SIP Servers 110 The normal rules from RFC 3263 [6] apply when locating a SIP server 111 that supports DTLS. The following new NAPTR[7] service values are 112 defined: "SIPS+D2U" for UDP, and "SIPS+D2D" for DCCP[8]. In 113 addition, the service value "SIP+D2D" should be used for SIP without 114 DTLS directly over DCCP. 116 The default port for DTLS over UDP or DCCP is 5061. The default port 117 for SIP directly over DCCP is 5060. 119 6. Security Considerations 121 The security issues with SIP using DTLS are equivalent to the issues 122 of using SIP with TLS. All the security considerations in RFC 3261 123 relevant to TLS apply to DTLS. 125 SIP over DCCP presents the same security issues as SIP over UDP, with 126 the exception that DCCP enforces congestion control at the transport 127 layer. 129 7. IANA Considerations 131 This document defines new NAPTR service field values for DTLS over 132 DCCP and UDP as well as over DCCP with no DTLS. IANA is requested to 133 register these values under the "Registry for the SIP SRV Resource 134 Record Services Field". The resulting entries should be: 136 Services Field Protocol Reference 137 -------------------- -------- --------- 138 SIPS+D2U UDP [RFCXXXX] 139 SIPS+D2D DCCP [RFCXXXX] 140 SIP+D2D DCCP [RFCXXXX] 142 [Note to RFC Editor: Please replace XXXX with the RFC number of this 143 specification.] 145 This document registers two new DCCP Service Codes registry as 146 defined by RFC 4340. 148 Service Code ASCII Description Reference 149 ------------ ----- ---------------------------------- --------- 150 1936289824 sip SIP over DCCP [RFCXXXX] 151 1936289907 sips SIP over DCCP over DTLS [RFCXXXX] 153 This document defines to new ports in the DCCP Port Numbers Registry 154 as defined by RFC 4340. 156 Port Name Port Number Description Reference 157 -------------- ------------- ------------------------- --------- 158 sip-dccp 5060/dccp SIP over DCCP [RFCXXXX] 159 sip-dtls-dccp 5061/dccp SIP over DTLS over DCCP [RFCXXXX] 161 8. Acknowledgments 163 Much of text and outline for this specification came from RFC 4168 164 authored by Jonathan Rosenberg, Henning Schulzrinne, and Gonzalo 165 Camarillo. Jakob Schlyter caught several typos. Eric Rescorla 166 provided helpful comments and text. Tom Phelan provided much of the 167 DCCP text. Thanks also to Colin Perkins. 169 9. References 171 9.1. Normative References 173 [1] Phelan, T., "Datagram Transport Layer Security (DTLS) over the 174 Datagram Congestion Control Protocol (DCCP)", 175 draft-ietf-dccp-dtls (work in progress). 177 [2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 178 Security", RFC 4347, April 2006. 180 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 181 Specifications: ABNF", RFC 4234, October 2005. 183 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 184 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 185 Session Initiation Protocol", RFC 3261, June 2002. 187 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 188 Levels", BCP 14, RFC 2119, March 1997. 190 [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 191 (SIP): Locating SIP Servers", RFC 3263, June 2002. 193 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 194 Three: The Domain Name System (DNS) Database", RFC 3403, 195 October 2002. 197 [8] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion 198 Control Protocol (DCCP)", RFC 4340, March 2006. 200 9.2. Informative References 202 [9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 203 Protocol Version 1.1", RFC 4346, April 2006. 205 Authors' Addresses 207 Cullen Jennings 208 Cisco Systems 209 170 West Tasman Drive 210 MS: SJC-21/2 211 San Jose, CA 95134 212 USA 214 Phone: +1 408 902-3341 215 Email: fluffy@cisco.com 217 Nagendra Modadugu 218 Google, Inc. 219 1600 Ampitheatre Parkway 220 Muntain View, CA 94043 221 USA 223 Email: ngm@google.com 225 Full Copyright Statement 227 Copyright (C) The IETF Trust (2007). 229 This document is subject to the rights, licenses and restrictions 230 contained in BCP 78, and except as set forth therein, the authors 231 retain all their rights. 233 This document and the information contained herein are provided on an 234 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 235 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 236 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 237 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 238 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 239 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 241 Intellectual Property 243 The IETF takes no position regarding the validity or scope of any 244 Intellectual Property Rights or other rights that might be claimed to 245 pertain to the implementation or use of the technology described in 246 this document or the extent to which any license under such rights 247 might or might not be available; nor does it represent that it has 248 made any independent effort to identify any such rights. Information 249 on the procedures with respect to rights in RFC documents can be 250 found in BCP 78 and BCP 79. 252 Copies of IPR disclosures made to the IETF Secretariat and any 253 assurances of licenses to be made available, or the result of an 254 attempt made to obtain a general license or permission for the use of 255 such proprietary rights by implementers or users of this 256 specification can be obtained from the IETF on-line IPR repository at 257 http://www.ietf.org/ipr. 259 The IETF invites any interested party to bring to its attention any 260 copyrights, patents or patent applications, or other proprietary 261 rights that may cover technology that may be required to implement 262 this standard. Please address the information to the IETF at 263 ietf-ipr@ietf.org. 265 Acknowledgment 267 Funding for the RFC Editor function is provided by the IETF 268 Administrative Support Activity (IASA).