idnits 2.17.1 draft-jennings-sip-dtls-00.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 240. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 12, 2005) is 7012 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: 'RFC3261' on line 144 -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 155 == Unused Reference: '1' is defined on line 167, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 170, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-rescorla-dtls-02 ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. '1') == Outdated reference: A later version (-13) exists of draft-ietf-dccp-spec-09 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP C. Jennings 3 Internet-Draft Cisco Systems 4 Expires: August 13, 2005 N. Modadugu 5 Stanford University 6 February 12, 2005 8 Using DTLS as a Transport for SIP 9 draft-jennings-sip-dtls-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 13, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This draft specifies how to use Datagram Transport Layer Security 45 (DTLS) as a transport for SIP. DTLS is a new protocol for providing 46 TLS security over a datagram protocol. 48 This draft is being discussed on the sip@ietf.org mailing list. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Transport Parameters . . . . . . . . . . . . . . . . . . . . . 3 55 4. DTLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Locating DTLS SIP Servers . . . . . . . . . . . . . . . . . . 4 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 5 62 9.2 Informational References . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 64 Intellectual Property and Copyright Statements . . . . . . . . 7 66 1. Introduction 68 Datagram Transport Layer Security (DTLS) [7] provides communication 69 privacy similar to TLS for datagram packets. SIP can run over both 70 stream and datagram transports. SIP already defines how to use TLS 71 with stream oriented transports. This specification extends SIP to 72 use DTLS with datagram oriented transports. 74 2. Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [3]. 80 3. Transport Parameters 82 SIP URIs can carry a transport parameter indicating the transport 83 protocol to be used. This specification defines two new values for 84 the transport parameter: "dtls-udp" for the SIP URI transport 85 parameter to be used for messages sent using DTLS over UDP, and 86 "dtls-dccp" for messages sent using DTLS over DCCP. The update to 87 the ABNF in RFC 3261 for this parameter is the following: 89 transport-param = "transport=" 90 ( "udp" / "tcp" / "sctp" / "tls" / "tls-sctp" 91 "dtls-dccp" / "dtls-udp" 92 / other-transport) 94 The following is an example of SIP URIs using "dtls-udp": 96 sip:alice@example.com;transport=dtls-udp 98 Via header fields also carry a transport protocol identifier. This 99 specification extends RFC 3261 to define the value "DTLS-UDP" for 100 DTLS over UDP and "DTLS-DCCP" for DTLS over DCCP. The update to the 101 ABNF in RFC 3261 for this parameter is the following: 103 transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" 104 "DTLS-DCCP" / "DTLS-UDP" 105 / other-transport 107 The following is an example Via header field: 109 Via: SIP/2.0/DTLS-UDP atlanta.example.com:5060 111 4. DTLS Usage 113 The normal rules for sending a request over UDP in RFC 3261 apply to 114 sending over DTLS. Note that the congestion safety rules for UDP do 115 not apply to DCCP. In addition, the normal rules for validating a 116 TLS connection in RFC 3261 apply to DTLS connections. Requests with 117 a sips URI can be sent over DTLS as well as TLS. 119 5. Locating DTLS SIP Servers 121 The normal rules from RFC 3263 [4] apply when locating a SIP server 122 that supports DTLS. The following new NAPTER[5] service values are 123 defined: "SIPS+D2U" for UDP, and "SIPS+D2D" for DCCP. In addition, 124 "SIP+D2D" should be used for SIP without DTLS over DCCP. 126 The default port for DTLS over UDP is 5061. 128 6. Security Considerations 130 The security issues with SIP using DTLS are closely equivalent to the 131 issues of using SIP with TLS. All the security considerations in RFC 132 3261 relevant to TLS apply to DTLS. 134 7. IANA Considerations 136 The IANA is requested to update the following entry to the "SIP/SIPS 137 URI Parameters" registry. The reference to this RFC should appear in 138 double-brackets and be appended to the list of references already 139 listed on for the transport parameter, as indicated in RFC 3969 [6]. 140 The resulting entry should be similar to: 142 Parameter Name Predefined Values Reference 143 -------------- ----------------- --------- 144 transport Yes [RFC3261] [[RFCXXXX]] 146 This document also defines new NAPTR service field values. The IANA 147 is requested to register these values under the "Registry for the SIP 148 SRV Resource Record Services Field". The resulting entries should 149 be: 151 Services Field Protocol Reference 152 -------------------- -------- --------- 153 SIPS+D2U UDP [RFCXXXX] 154 SIPS+D2D DCCP [RFCXXXX] 155 SIP+D2D DCCP [RFCXXXX] 157 8. Acknowledgments 159 Much of text and outline for this specification came from [8] 160 authored by Jonathan Rosenberg, Henning Schulzrinne, and Gonzalo 161 Camarillo. 163 9. References 165 9.1 Normative References 167 [1] Rescorla, E., "Datagram Transport Layer Security", 168 draft-rescorla-dtls-02 (work in progress), December 2004. 170 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 171 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 172 Session Initiation Protocol", RFC 3261, June 2002. 174 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 175 Levels", BCP 14, RFC 2119, March 1997. 177 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 178 (SIP): Locating SIP Servers", RFC 3263, June 2002. 180 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 181 Three: The Domain Name System (DNS) Database", RFC 3403, October 182 2002. 184 9.2 Informational References 186 [6] Camarillo, G., "The Internet Assigned Number Authority (IANA) 187 Uniform Resource Identifier (URI) Parameter Registry for the 188 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 189 2004. 191 [7] Kohler, E., "Datagram Congestion Control Protocol (DCCP)", 192 draft-ietf-dccp-spec-09 (work in progress), November 2004. 194 [8] Rosenberg, J., "The Stream Control Transmission Protocol (SCTP) 195 as a Transport for the Session Initiation Protocol (SIP)", 196 draft-ietf-sip-sctp-06 (work in progress), February 2005. 198 Authors' Addresses 200 Cullen Jennings 201 Cisco Systems 202 170 West Tasman Drive 203 MS: SJC-21/2 204 San Jose, CA 95134 205 USA 207 Phone: +1 408 902-3341 208 EMail: fluffy@cisco.com 210 Nagendra Modadugu 211 Stanford University 212 353 Serra Mall 213 Stanford, CA 94305 214 USA 216 EMail: Nagendra@cs.stanford.edu 218 Intellectual Property Statement 220 The IETF takes no position regarding the validity or scope of any 221 Intellectual Property Rights or other rights that might be claimed to 222 pertain to the implementation or use of the technology described in 223 this document or the extent to which any license under such rights 224 might or might not be available; nor does it represent that it has 225 made any independent effort to identify any such rights. Information 226 on the procedures with respect to rights in RFC documents can be 227 found in BCP 78 and BCP 79. 229 Copies of IPR disclosures made to the IETF Secretariat and any 230 assurances of licenses to be made available, or the result of an 231 attempt made to obtain a general license or permission for the use of 232 such proprietary rights by implementers or users of this 233 specification can be obtained from the IETF on-line IPR repository at 234 http://www.ietf.org/ipr. 236 The IETF invites any interested party to bring to its attention any 237 copyrights, patents or patent applications, or other proprietary 238 rights that may cover technology that may be required to implement 239 this standard. Please address the information to the IETF at 240 ietf-ipr@ietf.org. 242 Disclaimer of Validity 244 This document and the information contained herein are provided on an 245 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 246 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 247 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 248 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 249 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 250 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 252 Copyright Statement 254 Copyright (C) The Internet Society (2005). This document is subject 255 to the rights, licenses and restrictions contained in BCP 78, and 256 except as set forth therein, the authors retain all their rights. 258 Acknowledgment 260 Funding for the RFC Editor function is currently provided by the 261 Internet Society.