idnits 2.17.1 draft-scip-payload-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (April 16, 2021) is 1105 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AUDIOSCIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCIP210' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCIP214' -- Possible downref: Non-RFC (?) normative reference: ref. 'VIDEOSCIP' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Payload Working Group D. Hanson 3 Internet Draft M. Faller 4 Intended status: Standards Track K. Maver 5 Expires: October 18, 2021 General Dynamics Mission Systems 6 April 16, 2021 8 RTP Payload Format for the SCIP Codec 9 draft-scip-payload-00.txt 11 Status of this Memo 13 Copyright (c) 2021 IETF Trust and the persons identified as the 14 document authors. All rights reserved. 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 This document is subject to BCP 78 and the IETF Trust's Legal 20 Provisions Relating to IETF Documents 21 (http://trustee.ietf.org/license-info) in effect on the date of 22 publication of this document. Please review these documents 23 carefully, as they describe your rights and restrictions with 24 respect to this document. 26 Internet-Drafts are working documents of the Internet 27 Engineering Task Force (IETF). Note that other groups may also 28 distribute working documents as Internet-Drafts. The list of 29 current Internet-Drafts is at 30 http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as 36 "work in progress." 38 This Internet-Draft will expire on October 18, 2021. 40 Abstract 42 This document describes the RTP payload format of the Secure 43 Communication Interoperability Protocol (SCIP) as audio and 44 video media subtypes. It provides RFC 6838 compliant media 45 subtype definitions. SCIP-214.2 and SCIP-210 describe the 46 protocols that comprise the SCIP RTP packet payload. This 47 document follows the registration for related media types 48 called "audio/scip" and "video/scip" with IANA and formatted 49 according to RFC 4855. 51 Table of Contents 53 1. Introduction..............................................2 54 1.1. Conventions..........................................2 55 1.2. Abbreviations........................................3 56 2. Background................................................3 57 3. Media Format Description..................................4 58 4. Payload Format............................................5 59 4.1. RTP Header Fields....................................5 60 5. Payload Format Parameters.................................5 61 5.1. Media Subtype "audio/scip"...........................6 62 5.2. Media Subtype "video/scip"...........................7 63 5.3. Mapping to SDP.......................................8 64 5.4. SDP Offer/Answer Considerations......................9 65 6. Security Considerations...................................9 66 7. IANA Considerations.......................................9 67 8. References................................................9 68 8.1. Normative References.................................9 69 8.2. Informative References..............................11 70 9. Authors' Addresses.......................................12 72 1. Introduction 74 The IANA registration of media subtype types in the IETF tree 75 created two similar media subtypes "scip" under the audio and 76 video media types [AUDIOSCIP], [VIDEOSCIP]. This document, as 77 the common top-level reference, provides information on their 78 similarities and differences and the usage of those media 79 subtypes. 81 This document details usage of the scip pseudo-codec as a 82 secure session establishment protocol and transport protocol 83 over RTP. It provides a reference for network security 84 policymakers, network equipment OEMs, procurement personnel, 85 and government agency and commercial industry representatives. 87 1.1. Conventions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 90 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described 92 in [RFC2119]. 94 Best current practices for writing an RTP payload format 95 specification were followed [RFC2736] [RFC8088]. 97 1.2. Abbreviations 99 The following abbreviations are used in this document. 101 AVP: Audio/Video Profile 102 DTX: Discontinuous Transmission 103 FNBDT: Future Narrowband Digital Terminal 104 ICWG: Interoperability Control Working Group 105 IICWG: International Interoperability Control Working 106 Group 107 NATO: North Atlantic Treaty Organization 108 SCIP: Secure Communication Interoperability Protocol 109 SDP: Session Description Protocol 111 2. Background 113 The Secure Communication Interoperability Protocol (SCIP) 114 allows the negotiation of several voice, data, and video 115 applications using various encryption suites. SCIP also 116 provides several important characteristics that have led to its 117 broad acceptance in the international user community. These 118 features include end-to-end security at the application layer, 119 authentication of user identity, the ability to apply different 120 security levels for each secure session, and secure 121 communication over any end-to-end data connection. 123 SCIP began in the U.S. as the FNBDT (Future Narrowband Digital 124 Terminal) Protocol. A combined Department of Defense and 125 vendor consortium formed a governing organization named the 126 ICWG (Interoperability Control Working Group). In time, the 127 group expanded to include NATO, NATO partners and European 128 vendors under the name IICWG (International Interoperability 129 Control Working Group), which was later renamed the SCIP 130 Working Group. 132 SCIP is presently implemented in U.S. and NATO secure voice, 133 video, and data products operating on commercial, private, and 134 tactical IP networks worldwide using the scip media subtype. 135 First generation SCIP devices operated on circuit-switched 136 networks. SCIP was then expanded to radio and IP networks. 137 The scip media subtype transports SCIP secure session 138 establishment signaling and secure application traffic. The 139 built-in negotiation and flexibility provided by the SCIP 140 standards make it a natural choice for many scenarios that 141 require various secure applications and associated encryption 142 suites. SCIP has been endorsed by many nations as the secure 143 end-to-end solution for secure voice, video, and data devices. 144 SCIP standards are currently available to participating 145 government/military communities and select OEMs of equipment 146 that support SCIP. 148 However, SCIP must operate over global networks (including 149 private and commercial networks). Without access to necessary 150 information to support SCIP, some networks may not support the 151 SCIP media subtypes. Issues may occur simply because 152 information is not as readily available to OEMs, network 153 administrators, and network architects. 155 This RFC provides essential information about audio/scip and 156 video/scip media subtypes that enables network equipment 157 manufacturers to include scip as a known audio and video media 158 subtype in their equipment and enables network administrators 159 to define and implement a compatible security policy. 161 All current IP-based SCIP devices support "scip" as a media 162 subtype. Registration of scip as a media subtype provides a 163 common reference for network equipment manufacturers to 164 recognize SCIP in a payload declaration. 166 3. Media Format Description 168 The "scip" media subtype indicates support for and identifies 169 SCIP traffic that is being transferred using RTP. SCIP traffic 170 requires end-to-end bit integrity, therefore transcoding SHALL 171 NOT be performed over the end-to-end IP connection. The 172 audio/scip and video/scip media subtype data streams within the 173 network, including the VoIP network, MUST be a transparent 174 relay and be treated as "clear-channel data", similar to the 175 Clearmode media subtype defined by RFC 4040. However, 176 Clearmode is defined as a gateway protocol and limited to a 177 sample rate of 8000 Hz and 64kbps bandwidth only [RFC4040]. 178 Clearmode is not defined for the higher sample and data rates 179 required for some SCIP traffic. 181 4. Payload Format 183 The RTP Packet content of SCIP traffic is dependent upon the 184 SCIP session state. SCIP secure session establishment uses 185 protocols defined in SCIP-210 [SCIP210] to negotiate an 186 application. SCIP secure traffic may consist of the encrypted 187 output of codecs such as MELPe [RFC8130], G.729D [RFC3551], 188 H.264 [RFC6184], or other media encodings, based on the 189 application negotiated during SCIP secure session 190 establishment. SCIP traffic is highly variable and may include 191 other SCIP signaling information in the media stream. SCIP 192 traffic may not always be a continuous stream at the bit rate 193 specified in the SDP [RFC8866] since discontinuous transmission 194 (DTX) or other mechanisms may be used. The SCIP payload size 195 will vary, especially during SCIP secure session establishment. 197 4.1. RTP Header Fields 199 The RTP header fields SHOULD conform to RFC 3550. This is a 200 SHOULD rather than a SHALL in recognition that legacy SCIP- 201 enabled products may not strictly adhere to RFC 3550. 203 SCIP traffic may be continuous or discontinuous. The Timestamp 204 field increments based on the sampling clock for discontinuous 205 transmission as described in [RFC3550], Section 5.1. The 206 Timestamp field for continuous transmission applications is 207 dependent on the sampling rate of the media as specified in the 208 media subtype's specification (e.g., MELPe [RFC8130]). Note 209 that during a call, both discontinuous and continuous traffic 210 is highly probable. Therefore, a jitter buffer MAY be 211 implemented in endpoint devices only but SHOULD NOT be 212 implemented in network devices. 214 The Marker bit SHOULD be set to zero for discontinuous traffic. 215 The Marker bit for continuous traffic is based on the 216 underlying media subtype specification. This specification is 217 a SHOULD rather than a SHALL in recognition that legacy SCIP- 218 enabled products may not strictly adhere to the media subtype 219 specification. 221 5. Payload Format Parameters 223 The SCIP RTP payload format is identified using the scip media 224 subtype, which is registered in accordance with [RFC4855] and 225 per the media type registration template form [RFC6838]. A 226 clock rate of 8000 Hz SHALL be used for "audio/scip". A clock 227 rate of 90000 Hz SHALL be used for "video/scip". 229 5.1. Media Subtype "audio/scip" 231 Media type name: audio 233 Media subtype name: scip 235 Required parameters: N/A 237 Optional parameters: N/A 239 Encoding considerations: Binary. This media subtype is only 240 defined for transfer via RTP. There SHALL be no 241 encoding/decoding (transcoding) of the audio stream as it 242 traverses the network. 244 Security considerations: See Section 6. 246 Interoperability considerations: N/A 248 Published specifications: [SCIP214], [SCIP210] 250 Applications which use this media: N/A 252 Fragment Identifier considerations: none 254 Restrictions on usage: N/A 256 Additional information: 258 1. Deprecated alias names for this type: N/A 260 2. Magic number(s): N/A 262 3. File extension(s): N/A 264 4. Macintosh file type code: N/A 266 5. Object Identifiers: N/A 268 Person to contact for further information: 270 1. Name: Michael Faller and Daniel Hanson 272 2. Email: michael.faller@gd-ms.com and dan.hanson@gd-ms.com 274 Intended usage: Common, Government and Military 275 Authors: 277 Michael Faller - michael.faller@gd-ms.com 279 Daniel Hanson - dan.hanson@gd-ms.com 281 Change controller: 283 SCIP Working Group - ncia.cis3@ncia.nato.int 285 5.2. Media Subtype "video/scip" 287 Media type name: video 289 Media subtype name: scip 291 Required parameters: N/A 293 Optional parameters: N/A 295 Encoding considerations: Binary. This media subtype is only 296 defined for transfer via RTP. There SHALL be no 297 encoding/decoding (transcoding) of the video stream as it 298 traverses the network. 300 Security considerations: See Section 6. 302 Interoperability considerations: N/A 304 Published specifications: [SCIP214], [SCIP210] 306 Applications which use this media: N/A 308 Fragment Identifier considerations: none 310 Restrictions on usage: N/A 312 Additional information: 314 1. Deprecated alias names for this type: N/A 316 2. Magic number(s): N/A 318 3. File extension(s): N/A 320 4. Macintosh file type code: N/A 321 5. Object Identifiers: N/A 323 Person to contact for further information: 325 1. Name: Michael Faller and Daniel Hanson 327 2. Email: michael.faller@gd-ms.com and dan.hanson@gd-ms.com 329 Intended usage: Common, Government and Military 331 Authors: 333 Michael Faller - michael.faller@gd-ms.com 335 Daniel Hanson - dan.hanson@gd-ms.com 337 Change controller: 339 SCIP Working Group - ncia.cis3@ncia.nato.int 341 5.3. Mapping to SDP 343 The mapping of the above defined payload format media subtype 344 and its parameters SHALL be done according to Section 3 of 345 [RFC4855]. 347 An example mapping for audio/scip is: 349 m=audio 50000 RTP/AVP 96 350 a=rtpmap:96 scip/8000 352 An example mapping for video/scip is: 354 m=video 50002 RTP/AVP 97 355 a=rtpmap:97 scip/90000 357 An example mapping for both audio/scip and video/scip is: 359 m=audio 50000 RTP/AVP 96 360 a=rtpmap:96 scip/8000 361 m=video 50002 RTP/AVP 97 362 a=rtpmap:97 scip/90000 364 The application negotiation between endpoints will determine 365 whether the audio and video streams are transported as separate 366 streams over the audio and video payload types or as a single 367 media stream on the video payload type. 369 5.4. SDP Offer/Answer Considerations 371 In accordance with the SDP Offer/Answer model [RFC3264], the 372 SCIP device SHALL list the SCIP payload type in order of 373 preference in the "m" media line. 375 6. Security Considerations 377 RTP packets using the payload format defined in this 378 specification are subject to the security considerations 379 discussed in the RTP specification [RFC3550], and in any 380 applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF 381 [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. 382 However, as "Securing the RTP Protocol Framework: Why RTP Does 383 Not Mandate a Single Media Security Solution" [RFC7202] 384 discusses, it is not an RTP payload format's responsibility to 385 discuss or mandate what solutions are used to meet the basic 386 security goals like confidentiality, integrity, and source 387 authenticity for RTP in general. This responsibility lays on 388 anyone using RTP in an application. They can find guidance on 389 available security mechanisms and important considerations in 390 "Options for Securing RTP Sessions" [RFC7201]. Applications 391 SHOULD use one or more appropriate strong security mechanisms. 392 The rest of this Security Considerations section discusses the 393 security impacting properties of the payload format itself. 395 This RTP payload format and its media decoder do not exhibit 396 any significant non-uniformity in the receiver-side 397 computational complexity for packet processing, and thus are 398 unlikely to pose a denial-of-service threat due to the receipt 399 of pathological data. Nor does the RTP payload format contain 400 any active content. 402 7. IANA Considerations 404 The audio/scip and video/scip media subtypes have been 405 registered with IANA [AUDIOSCIP] [VIDEOSCIP]. 407 8. References 409 8.1. Normative References 411 [AUDIOSCIP] Faller, M., and D. Hanson, "audio/scip", Internet 412 Assigned Numbers Authority (IANA), 28 January 2021, 413 . 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, DOI 418 10.17487/RFC2119, March 1997, . 421 [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers 422 of RTP Payload Format Specifications", BCP 36, RFC 423 2736, DOI 10.17487/RFC2736, December 1999, 424 . 426 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer 427 Model with Session Description Protocol (SDP)", RFC 428 3264, June 2002, . 431 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 432 Jacobson, "RTP: A Transport Protocol for Real-Time 433 Applications", STD 64, RFC 3550, July 2003, 434 . 436 [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for 437 Audio and Video Conferences with Minimal Control", 438 RFC 3551, July 2003, . 441 [RFC3711] Baugher, M., McGrew, D., Naslund M., Carrara, E., 442 and K. Norrman, "The Secure Real-time Transport 443 Protocol (SRTP)", RFC 3711, March 2004, 444 . 446 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and 447 J. Rey, "Extended RTP Profile for Real-time 448 Transport Control Protocol (RTCP)-Based Feedback 449 (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 450 2006, . 452 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP 453 Profile for Real-time Transport Control Protocol 454 (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 455 10.17487/RFC5124, February 2008, . 458 [RFC8866] Begen, A., Kyzivat P., Perkins C., and M. Handley, 459 "SDP: Session Description Protocol", RFC 8866, 460 January 2021, . 463 [SCIP210] SCIP-210, "SCIP Signaling Plan", Revision 3.10, 26 464 October 2017, request access via email 465 . 467 [SCIP214] SCIP-214.2, "Secure Communication Interoperability 468 Protocol (SCIP) over Real-time Transport Protocol 469 (RTP)", Revision 1.1, 18 April 2014, request access 470 via email . 472 [VIDEOSCIP] Faller, M., and D. Hanson, "video/scip", Internet 473 Assigned Numbers Authority (IANA), 28 January 2021, 474 . 477 8.2. Informative References 479 [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s 480 Transparent Call", RFC 4040, April 2005, 481 . 483 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 484 Formats", RFC 4855, February 2007, 485 . 487 [RFC6184] Wang, Y., Even, R., et al. "RTP Payload Format for 488 H.264 Video", RFC 6184, May 2011, . 491 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 492 Specifications and Registration Procedures", BCP 493 13, RFC 6838, January 2013, . 496 [RFC7201] Westerlund, M. and C. Perkins, "Options for 497 Securing RTP Sessions", RFC 7201, DOI 498 10.17487/RFC7201, April 2014, . 501 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 502 Framework: Why RTP Does Not Mandate a Single Media 503 Security Solution", RFC 7202, DOI 10.17487/RFC7202, 504 April 2014, . 507 [RFC8088] Westerlund, M. "How to Write an RTP Payload 508 Format", RFC 8088, May 2017, . 511 [RFC8130] Demjanenko, V., and D. Satterlee, "RTP Payload 512 Format for MELPe Codec", RFC 8130, March 2017, 513 . 515 9. Authors' Addresses 517 Daniel Hanson 518 General Dynamics Mission Systems, Inc. 519 150 Rustcraft Road 520 Dedham, MA 02026, USA 521 E-mail: dan.hanson@gd-ms.com 523 Michael Faller 524 General Dynamics Mission Systems, Inc. 525 150 Rustcraft Road 526 Dedham, MA 02026, USA 527 E-mail: michael.faller@gd-ms.com 529 Keith Maver 530 General Dynamics Mission Systems, Inc. 531 150 Rustcraft Road 532 Dedham, MA 02026, USA 533 E-mail: keith.maver@gd-ms.com 535 SCIP Working Group, CIS3 Partnership 536 NATO Communications and Information Agency 537 Oude Waalsdorperweg 61, 2597AK 538 The Hague, The Netherlands 539 E-mail: ncia.cis3@ncia.nato.int