rfc9607.original   rfc9607.txt 
Payload Working Group D. Hanson Internet Engineering Task Force (IETF) D. Hanson
Internet-Draft M. Faller Request for Comments: 9607 M. Faller
Intended status: Standards Track K. Maver Category: Standards Track K. Maver
Expires: 16 August 2024 General Dynamics Mission Systems, Inc. ISSN: 2070-1721 General Dynamics Mission Systems, Inc.
13 February 2024 July 2024
RTP Payload Format for the Secure Communication Interoperability RTP Payload Format for the Secure Communication Interoperability
Protocol (SCIP) Codec Protocol (SCIP) Codec
draft-ietf-avtcore-rtp-scip-09
Abstract Abstract
This document describes the RTP payload format of the Secure This document describes the RTP payload format of the Secure
Communication Interoperability Protocol (SCIP). SCIP is an Communication Interoperability Protocol (SCIP). SCIP is an
application layer protocol that provides end-to-end capability application-layer protocol that provides end-to-end session
exchange, packetization/de-packetization of media, reliable establishment, payload encryption, packetization and de-packetization
transport, and payload encryption. of media, and reliable transport. This document provides a globally
available reference that can be used for the development of network
SCIP handles packetization/de-packetization of the encrypted media equipment and procurement of services that support SCIP traffic. The
and acts as a tunneling protocol, treating SCIP payloads as opaque intended audience is network security policymakers; network
octets to be encapsulated within RTP payloads prior to transmission administrators, architects, and original equipment manufacturers
or decapsulated on reception. SCIP payloads are sized to fit within (OEMs); procurement personnel; and government agency and commercial
the maximum transmission unit (MTU) when transported over RTP thereby industry representatives.
avoiding fragmentation.
SCIP transmits encrypted traffic and does not require the use of IESG Note
Secure RTP (SRTP) for payload protection. SCIP also provides for
reliable transport at the application layer, so it is not necessary
to negotiate RTCP retransmission capabilities.
To establish reliable communications using SCIP over RTP, it is This IETF specification depends upon a second technical specification
important that middle boxes avoid parsing or modifying SCIP payloads. that is not available publicly, namely [SCIP210]. The IETF was
Because SCIP payloads are confidentiality and integrity protected and therefore unable to conduct a security review of that specification,
are only decipherable by the originating and receiving SCIP devices, independently or when carried inside Audio/Video Transport (AVT).
modification of the payload by middle boxes would be detected as an Implementers need to be aware that the IETF hence cannot verify any
integrity failure in SCIP devices, resulting in retransmission and/or of the security claims contained in this document.
communication failure. Middle boxes do not need to parse the SCIP
payloads to correctly transport them. Not only is parsing
unnecessary to tunnel/detunnel SCIP within RTP, but the parsing and
filtering of SCIP payloads by middle boxes would likely lead to
ossification of the evolving SCIP protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 16 August 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9607.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Key Points . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Key Points
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Conventions
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 6 4. Payload Format
4.1. RTP Header Fields . . . . . . . . . . . . . . . . . . . . 8 4.1. RTP Header Fields
4.2. Congestion Control Considerations . . . . . . . . . . . . 9 4.2. Congestion Control Considerations
4.3. Use of Augmented RTP Transport Protocols with SCIP . . . 9 4.3. Use of Augmented RTPs with SCIP
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10 5. Payload Format Parameters
5.1. Media Subtype "audio/scip" . . . . . . . . . . . . . . . 10 5.1. Media Subtype "audio/scip"
5.2. Media Subtype "video/scip" . . . . . . . . . . . . . . . 11 5.2. Media Subtype "video/scip"
5.3. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 12 5.3. Mapping to SDP
5.4. SDP Offer/Answer Considerations . . . . . . . . . . . . . 13 5.4. SDP Offer/Answer Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations
8. SCIP Contact Information . . . . . . . . . . . . . . . . . . 14 8. SCIP Contact Information
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References
Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Key Points 1. Key Points
* SCIP is an application layer protocol that uses RTP as a * SCIP is an application-layer protocol that uses RTP as a
transport. This document defines the SCIP media subtypes to be transport. This document defines the SCIP media subtypes to be
listed in the Session Description Protocol (SDP) and only requires listed in the Session Description Protocol (SDP) and only requires
a basic RTP transport channel for SCIP payloads. This basic a basic RTP transport channel for SCIP payloads. This basic
transport channel is comparable to [RFC4040] Clearmode. transport channel is comparable to Clearmode as defined by
[RFC4040].
* SCIP transmits encrypted traffic and does not require the use of
Secure RTP (SRTP) for payload protection. SCIP also provides for
reliable transport at the application layer, so it is not
necessary to negotiate RTCP retransmission capabilities.
* SCIP includes built-in mechanisms that negotiate protocol message
versions and capabilities. To avoid SCIP protocol ossification
(as described in [RFC9170]), it is important for middleboxes to
not attempt parsing of the SCIP payload. As described in this
document, such parsing serves no useful purpose.
* SCIP is designed to be network agnostic. It can operate over any * SCIP is designed to be network agnostic. It can operate over any
digital link, including non-IP modem-based PSTN and ISDN. The digital link, including non-IP modem-based PSTN and ISDN. The
SCIP media subtypes listed in this document were developed for SCIP media subtypes listed in this document were developed for
SCIP to operate over RTP. SCIP to operate over RTP.
* SCIP handles packetization/de-packetization of payloads by * SCIP handles packetization and de-packetization of payloads by
producing encrypted media packets that are not greater than the producing encrypted media packets that are not greater than the
MTU size. The SCIP payload is opaque to the network, therefore, MTU size. The SCIP payload is opaque to the network, therefore,
SCIP functions as a tunneling protocol for the encrypted media, SCIP functions as a tunneling protocol for the encrypted media,
without the need for middle boxes to parse SCIP payloads. Since without the need for middleboxes to parse SCIP payloads. Since
SCIP payloads are integrity protected, modification of the SCIP SCIP payloads are integrity protected, modification of the SCIP
payload is detected as an integrity violation by SCIP endpoints payload is detected as an integrity violation by SCIP endpoints,
leading to communication failure. leading to communication failure.
* SCIP includes built-in mechanisms that negotiate protocol message
versions and capabilities. To avoid SCIP protocol ossification
(as described in [RFC9170]), it is important for middle boxes to
not attempt parsing of the SCIP payload. As described in this
document, such parsing serves no useful purpose.
2. Introduction 2. Introduction
The purpose of this document is to provide enough information to This document details usage of the "audio/scip" and "video/scip"
enable SCIP payloads to be transported through the network without pseudo-codecs [MediaTypes] as a secure session establishment protocol
modification or filtering. The document provides a reference for and media transport protocol over RTP.
network security policymakers; network equipment OEMs,
administrators, and architects; procurement personnel; and government
agency and commercial industry representatives.
The document details usage of the "audio/scip" and "video/scip" It discusses how:
pseudo-codecs [AUDIOSCIP], [VIDEOSCIP] as a secure session
establishment protocol and media transport protocol over RTP. It 1. encrypted audio and video codec payloads are transported over
discusses (1) how encrypted audio and video codec payloads are RTP;
transported over RTP; (2) the IP network layer not implementing SCIP
as a protocol since SCIP operates at the application layer in 2. the IP network layer does not implement SCIP as a protocol since
endpoints; (3) the IP network layer enabling SCIP traffic to SCIP operates at the application layer in endpoints;
transparently pass through the network; (4) network devices not
recognizing SCIP, and thus removing the scip codecs from the SDP 3. the IP network layer enables SCIP traffic to transparently pass
media payload declaration before forwarding to the next network node; through the network;
and finally, (5) SCIP endpoint devices not operating on networks due
to the scip media subtype removal from the SDP media payload 4. some network devices do not recognize SCIP and may remove the
declaration. SCIP codecs from the SDP media payload declaration before
forwarding to the next network node; and finally,
5. SCIP endpoint devices do not operate on networks if the SCIP
media subtype is removed from the SDP media payload declaration.
The United States, along with its NATO Partners, have implemented The United States, along with its NATO Partners, have implemented
SCIP in secure voice, video, and data products operating on SCIP in secure voice, video, and data products operating on
commercial, private, and tactical IP networks worldwide using the commercial, private, and tactical IP networks worldwide using the
scip media subtype. The SCIP data traversing the network is scip media subtype. The SCIP data traversing the network is
encrypted, and network equipment in-line with the session cannot encrypted, and network equipment in-line with the session cannot
interpret the traffic stream in any way. SCIP-based RTP traffic is interpret the traffic stream in any way. SCIP-based RTP traffic is
opaque and can vary significantly in structure and frequency making opaque and can vary significantly in structure and frequency, making
traffic profiling not possible. Also, as the SCIP protocol continues traffic profiling not possible. Also, as the SCIP protocol continues
to evolve independently of this document, any network device that to evolve independently of this document, any network device that
attempts to filter traffic (e.g., deep packet inspection) may cause attempts to filter traffic (e.g., deep packet inspection) may cause
unintended consequences in the future when changes to the SCIP unintended consequences in the future when changes to the SCIP
traffic may not be recognized by the network device. traffic may not be recognized by the network device.
The SCIP protocol defined in SCIP-210 [SCIP210] includes built-in The SCIP protocol defined in SCIP-210 [SCIP210] includes built-in
support for packetization/de-packetization, retransmission, support for packetization and de-packetization, retransmission,
capability exchange, version negotiation, and payload encryption. capability exchange, version negotiation, and payload encryption.
Since the traffic is encrypted, neither the RTP transport nor middle Since the traffic is encrypted, neither the RTP transport nor
boxes can usefully parse or modify SCIP payloads; modifications are middleboxes can usefully parse or modify SCIP payloads; modifications
detected as integrity violations resulting in retransmission, and are detected as integrity violations resulting in retransmission, and
eventually, communication failure. eventually, communication failure.
Because knowledge of the SCIP payload format is not needed to Because knowledge of the SCIP payload format is not needed to
transport SCIP signaling or media through middle boxes, SCIP-210 transport SCIP signaling or media through middleboxes, SCIP-210
represents an informative reference. While older versions of the represents an informative reference. While older versions of the
SCIP-210 specification are publicly available, the authors strongly SCIP-210 specification are publicly available, the authors strongly
encourage network implementers to treat SCIP payloads as opaque encourage network implementers to treat SCIP payloads as opaque
octets. When handled correctly, such treatment does not require octets. When handled correctly, such treatment does not require
referring to SCIP-210, and any assumptions about the format of SCIP referring to SCIP-210, and any assumptions about the format of SCIP
messages defined in SCIP-210 are likely to lead to protocol messages defined in SCIP-210 are likely to lead to protocol
ossification and communication failures as the protocol evolves. ossification and communication failures as the protocol evolves.
| Note: The IETF has not conducted a security review of SCIP and | Note: The IETF has not conducted a security review of SCIP and
| therefore has not verified the claims contained in this | therefore has not verified the claims contained in this
| document. | document.
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Best current practices for writing an RTP payload format The best current practices for writing an RTP payload format
specification were followed [RFC2736] [RFC8088]. specification, as per [RFC2736] and [RFC8088], were followed.
When referring to the Secure Communication Interoperability Protocol, When referring to the Secure Communication Interoperability Protocol,
the uppercase acronym "SCIP" is used. When referring to the media the uppercase acronym "SCIP" is used. When referring to the media
subtype scip, lowercase "scip" is used. subtype scip, lowercase "scip" is used.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document. The following abbreviations are used in this document.
AVP: Audio/Video Profile AVP: Audio-Visual Profile
AVPF: Audio/Video Profile Feedback
AVPF: Audio-Visual Profile with Feedback
FNBDT: Future Narrowband Digital Terminal
ICWG: Interoperability Control Working Group ICWG: Interoperability Control Working Group
IICWG: International Interoperability Control Working Group IICWG: International Interoperability Control Working Group
MELPe: Mixed Excitation Linear Prediction Enhanced
MTU: Maximum Transmission Unit
NATO: North Atlantic Treaty Organization NATO: North Atlantic Treaty Organization
OEM: Original Equipment Manufacturer OEM: Original Equipment Manufacturer
SAVP: Secure Audio/Video Profile
SAVPF: Secure Audio/Video Profile Feedback SAVP: Secure Audio-Visual Profile
SAVPF: Secure Audio-Visual Profile with Feedback
SCIP: Secure Communication Interoperability Protocol SCIP: Secure Communication Interoperability Protocol
SDP: Session Description Protocol SDP: Session Description Protocol
SRTP: Secure Real-Time Transport Protocol
SRTP: Secure Real-time Transport Protocol
STANAG: Standardization Agreement STANAG: Standardization Agreement
3. Background 3. Background
The Secure Communication Interoperability Protocol (SCIP) allows the The Secure Communication Interoperability Protocol (SCIP) allows the
negotiation of several voice, data, and video applications using negotiation of several voice, data, and video applications using
various cryptographic suites. SCIP also provides several important various cryptographic suites. SCIP also provides several important
characteristics that have led to its broad acceptance as a secure characteristics that have led to its broad acceptance as a secure
communications protocol. communications protocol.
SCIP began in the United States as the Future Narrowband Digital SCIP began in the United States as the Future Narrowband Digital
Terminal (FNBDT) Protocol in the late 1990s. A combined U.S. Terminal (FNBDT) Protocol in the late 1990s. A combined U.S.
Department of Defense and vendor consortium formed a governing Department of Defense and vendor consortium formed a governing
organization named the Interoperability Control Working Group (ICWG) organization named the Interoperability Control Working Group (ICWG)
to manage the protocol. In time, the group expanded to include NATO, to manage the protocol. In time, the group expanded to include NATO,
NATO partners and European vendors under the name International NATO partners, and European vendors under the name International
Interoperability Control Working Group (IICWG), which was later Interoperability Control Working Group (IICWG), which was later
renamed the SCIP Working Group. renamed the SCIP Working Group.
First generation SCIP devices operated on circuit-switched networks. First generation SCIP devices operated on circuit-switched networks.
SCIP was then expanded to radio and IP networks. The scip media SCIP was then expanded to radio and IP networks. The scip media
subtype transports SCIP secure session establishment signaling and subtype transports SCIP secure session establishment signaling and
secure application traffic. The built-in negotiation and flexibility secure application traffic. The built-in negotiation and flexibility
provided by the SCIP protocols make it a natural choice for many provided by the SCIP protocols make it a natural choice for many
scenarios that require various secure applications and associated scenarios that require various secure applications and associated
encryption suites. SCIP has been adopted by NATO in STANAG 5068. encryption suites. SCIP has been adopted by NATO in STANAG 5068.
SCIP standards are currently available to participating government/ SCIP standards are currently available to participating government
military communities and select OEMs of equipment that support SCIP. and military communities and select OEMs of equipment that support
SCIP.
However, SCIP must operate over global networks (including private However, SCIP must operate over global networks (including private
and commercial networks). Without access to necessary information to and commercial networks). Without access to necessary information to
support SCIP, some networks may not support the SCIP media subtypes. support SCIP, some networks may not support the SCIP media subtypes.
Issues may occur simply because information is not as readily Issues may occur simply because information is not as readily
available to OEMs, network administrators, and network architects. available to OEMs, network administrators, and network architects.
This document provides essential information about audio/scip and This document provides essential information about the "audio/scip"
video/scip media subtypes that enables network equipment and "video/scip" media subtypes that enable network equipment
manufacturers to include settings for "scip" as a known audio and manufacturers to include settings for "scip" as a known audio and
video media subtype in their equipment. This enables network video media subtype in their equipment. This enables network
administrators to define and implement a compatible security policy administrators to define and implement a compatible security policy
which includes audio and video media subtypes "audio/scip" and that includes audio and video media subtypes "audio/scip" and "video/
"video/scip", respectively, as permitted codecs on the network. scip", respectively, as permitted codecs on the network.
All current IP-based SCIP endpoints implement "scip" as a media All current IP-based SCIP endpoints implement "scip" as a media
subtype. Registration of scip as a media subtype provides a common subtype. Registration of scip as a media subtype provides a common
reference for network equipment manufacturers to recognize SCIP in an reference for network equipment manufacturers to recognize SCIP in an
SDP payload declaration. SDP payload declaration.
4. Payload Format 4. Payload Format
The "scip" media subtype indicates support for and identifies SCIP The "scip" media subtype identifies and indicates support for SCIP
traffic that is being transported over RTP. Transcoding, lossy traffic that is being transported over RTP. Transcoding, lossy
compression, or other data modifications MUST NOT be performed by the compression, or other data modifications MUST NOT be performed by the
network on the SCIP RTP payload. The audio/scip and video/scip media network on the SCIP RTP payload. The "audio/scip" and "video/scip"
subtype data streams within the network, including the VoIP network, media subtype data streams within the network, including the VoIP
MUST be a transparent relay and be treated as "clear-channel data", network, MUST be a transparent relay and be treated as "clear-channel
similar to the Clearmode media subtype defined by [RFC4040]. data", similar to the Clearmode media subtype defined by [RFC4040].
RFC 4040 is referenced because Clearmode does not define specific RTP [RFC4040] is referenced because Clearmode does not define specific
payload content, packet size, or packet intervals, but rather enables RTP payload content, packet size, or packet intervals, but rather
Clearmode devices to signal that they support a compatible mode of enables Clearmode devices to signal that they support a compatible
operation and defines a transparent channel on which devices may mode of operation and defines a transparent channel on which devices
communicate. This document takes a similar approach. Network may communicate. This document takes a similar approach. Network
devices that implement support for SCIP need to enable SCIP endpoints devices that implement support for SCIP need to enable SCIP endpoints
to signal that they support SCIP and provide a transparent channel on to signal that they support SCIP and provide a transparent channel on
which SCIP endpoints may communicate. which SCIP endpoints may communicate.
SCIP is an application layer protocol that is defined in SCIP-210. SCIP is an application-layer protocol that is defined in SCIP-210.
The SCIP traffic consists of encrypted SCIP control messages and The SCIP traffic consists of encrypted SCIP control messages and
codec data. The payload size and interval will vary considerably codec data. The payload size and interval will vary considerably
depending on the state of the SCIP protocol within the SCIP device. depending on the state of the SCIP protocol within the SCIP device.
Figure 1 below illustrates the RTP payload format for SCIP. Figure 1 below illustrates the RTP payload format for SCIP.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| | | |
| SCIP payload | | SCIP Payload |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SCIP RTP Payload Format Figure 1: SCIP RTP Payload Format
The SCIP codec produces an encrypted bitstream that is transported The SCIP codec produces an encrypted bitstream that is transported
over RTP. Unlike other codecs, SCIP does not have its own upper over RTP. Unlike other codecs, SCIP does not have its own upper
layer syntax (e.g., no Network Adaptation Layer (NAL) units), but layer syntax (e.g., no Network Adaptation Layer (NAL) units), but
rather encrypts the output of the audio/video codecs that it uses rather encrypts the output of the audio and video codecs that it uses
(e.g., G.729D, H.264 [RFC6184], etc.). SCIP achieves this by (e.g., G.729D, H.264 [RFC6184], etc.). SCIP achieves this by
encapsulating the encrypted codec output that has been previously encapsulating the encrypted codec output that has been previously
formatted according to the relevant RTP payload specification for formatted according to the relevant RTP payload specification for
that codec. SCIP endpoints MAY employ mechanisms, such as Inter- that codec. SCIP endpoints MAY employ mechanisms, such as inter-
media RTP Synchronization as described in [RFC8088] Section 3.3.4, to media RTP synchronization as described in [RFC8088], Section 3.3.4,
synchronize audio/scip and video/scip streams. to synchronize "audio/scip" and "video/scip" streams.
Figure 2 below illustrates notionally how codec packets and SCIP Figure 2 below illustrates notionally how codec packets and SCIP
control messages are packetized for transmission over RTP. control messages are packetized for transmission over RTP.
+-----------+ +-----------------------+ +-----------+ +-----------------------+
| Codec | | SCIP control messages | | Codec | | SCIP control messages |
+-----------+ +-----------------------+ +-----------+ +-----------------------+
| | | |
| | | |
V V V V
skipping to change at page 8, line 29 skipping to change at line 352
+--------------+ | +--------------+ |
| | | |
| | | |
V V V V
+--------------------------------------------------+ +--------------------------------------------------+
| RTP | | RTP |
+--------------------------------------------------+ +--------------------------------------------------+
Figure 2: SCIP RTP Architecture Figure 2: SCIP RTP Architecture
| * Packetizer: The SCIP application layer will ensure that all * Packetizer: The SCIP application layer will ensure that all
| traffic sent to the RTP layer will not exceed the MTU size. traffic sent to the RTP layer will not exceed the MTU size. The
| The receiving SCIP RTP layer will handle packet identification, receiving SCIP RTP layer will handle packet identification,
| ordering, and reassembly. When required, the SCIP application ordering, and reassembly. When required, the SCIP application
| layer handles error detection and retransmission. layer handles error detection and retransmission.
As described above, the SCIP RTP payload format is variable and As described above, the SCIP RTP payload format is variable and
cannot be described in specificity in this document. Details can be cannot be described in specificity in this document. Details can be
found in SCIP-210. SCIP will continue to evolve and as such the SCIP found in SCIP-210. SCIP will continue to evolve and, as such, the
RTP traffic MUST NOT be filtered by network devices based upon what SCIP RTP traffic MUST NOT be filtered by network devices based upon
currently is observed or documented. The focus of this document is what currently is observed or documented. The focus of this document
for network devices to consider the SCIP RTP payload as opaque and is for network devices to consider the SCIP RTP payload as opaque and
allow it to traverse the network. Network devices MUST NOT modify allow it to traverse the network. Network devices MUST NOT modify
SCIP RTP packets. SCIP RTP packets.
4.1. RTP Header Fields 4.1. RTP Header Fields
The SCIP RTP header fields SHALL conform to RFC 3550. The SCIP RTP header fields SHALL conform to [RFC3550].
SCIP traffic may be continuous or discontinuous. The Timestamp field SCIP traffic may be continuous or discontinuous. The Timestamp field
MUST increment based on the sampling clock for discontinuous MUST increment based on the sampling clock for discontinuous
transmission as described in [RFC3550], Section 5.1. The Timestamp transmission as described in [RFC3550], Section 5.1. The Timestamp
field for continuous transmission applications is dependent on the field for continuous transmission applications is dependent on the
sampling rate of the media as specified in the media subtype's sampling rate of the media as specified in the media subtype's
specification (e.g., MELPe). Note that during a SCIP session, both specification (e.g., Mixed Excitation Linear Prediction Enhanced
discontinuous and continuous traffic are highly probable. (MELPe)). Note that during a SCIP session, both discontinuous and
continuous traffic are highly probable.
The Marker bit SHALL be set to zero for discontinuous traffic. The The Marker bit SHALL be set to zero for discontinuous traffic. The
Marker bit for continuous traffic is based on the underlying media Marker bit for continuous traffic is based on the underlying media
subtype specification. The underlying media is opaque within SCIP subtype specification. The underlying media is opaque within SCIP
RTP packets. RTP packets.
4.2. Congestion Control Considerations 4.2. Congestion Control Considerations
The bitrate of SCIP may be adjusted depending on the capability of The bitrate of SCIP may be adjusted depending on the capability of
the underlying codec (such as MELPe [RFC8130], G.729D [RFC3551], the underlying codec (such as MELPe [RFC8130], G.729D [RFC3551],
skipping to change at page 9, line 40 skipping to change at line 407
Techniques (RMCAT) working group [RMCAT] describes the interactions Techniques (RMCAT) working group [RMCAT] describes the interactions
and conceptual interfaces necessary between the application and conceptual interfaces necessary between the application
components that relate to congestion control, including the RTP components that relate to congestion control, including the RTP
layer, the higher-level media codec control layer, and the lower- layer, the higher-level media codec control layer, and the lower-
level transport interface, as well as components dedicated to level transport interface, as well as components dedicated to
congestion control functions. congestion control functions.
Use of the packet loss feedback mechanisms in AVPF [RFC4585] and Use of the packet loss feedback mechanisms in AVPF [RFC4585] and
SAVPF [RFC5124] are OPTIONAL because SCIP itself manages SAVPF [RFC5124] are OPTIONAL because SCIP itself manages
retransmissions of some errored or lost packets. Specifically, the retransmissions of some errored or lost packets. Specifically, the
Payload-Specific Feedback Messages defined in RFC 4585 section 6.3 payload-specific feedback messages defined in [RFC4585], Section 6.3
are OPTIONAL when transporting video data. are OPTIONAL when transporting video data.
4.3. Use of Augmented RTP Transport Protocols with SCIP 4.3. Use of Augmented RTPs with SCIP
The SCIP application layer protocol uses RTP as a basic transport for The SCIP application-layer protocol uses RTP as a basic transport for
the audio/scip and video/scip payloads. Additional RTP transport the "audio/scip" and "video/scip" payloads. Additional RTPs that do
protocols that do not modify the SCIP payload are considered OPTIONAL not modify the SCIP payload are considered OPTIONAL in this document
in this document and are discretionary for a SCIP device vendor to and are discretionary for a SCIP device vendor to implement. Some
implement. Some examples include but are not limited to: examples include, but are not limited to:
* RTP Payload Format for Generic Forward Error Correction [RFC5109] * "RTP Payload Format for Generic Forward Error Correction"
* Multiplexing RTP Data and Control Packets on a Single Port [RFC5109]
* "Multiplexing RTP Data and Control Packets on a Single Port"
[RFC5761] [RFC5761]
* Symmetric RTP/RTP Control Protocol (RTCP) [RFC4961] * "Symmetric RTP / RTP Control Protocol (RTCP)" [RFC4961]
* Negotiating Media Multiplexing Using the Session Description * "Negotiating Media Multiplexing Using the Session Description
Protocol (BUNDLE) [RFC9143] Protocol (SDP)" a.k.a. BUNDLE [RFC9143]
5. Payload Format Parameters 5. Payload Format Parameters
The SCIP RTP payload format is identified using the scip media The SCIP RTP payload format is identified using the scip media
subtype, which is registered in accordance with [RFC4855] and per the subtype, which is registered in accordance with [RFC4855] and per the
media type registration template form [RFC6838]. A clock rate of media type registration template from [RFC6838]. A clock rate of
8000 Hz SHALL be used for "audio/scip". A clock rate of 90000 Hz 8000 Hz SHALL be used for "audio/scip". A clock rate of 90000 Hz
SHALL be used for "video/scip". SHALL be used for "video/scip".
5.1. Media Subtype "audio/scip" 5.1. Media Subtype "audio/scip"
Media type name: audio Type name: audio
Media subtype name: scip
Required parameters: N/A Subtype name: scip
Optional parameters: N/A Required parameters: N/A
Encoding considerations: Binary. This media subtype is only defined Optional parameters: N/A
for transfer via RTP. There SHALL be no encoding/decoding
(transcoding) of the audio stream as it traverses the network.
Security considerations: See Section 7. Encoding considerations: Binary. This media subtype is only defined
for transfer via RTP. There SHALL be no transcoding of the audio
stream as it traverses the network.
Interoperability considerations: N/A Security considerations: See Section 6.
Published specifications: [SCIP210] Interoperability considerations: N/A
Applications which use this media: N/A Published specification: [SCIP210]
Fragment Identifier considerations: none Applications that use this media type: N/A
Restrictions on usage: N/A Fragment identifier considerations: none
Additional information: Additional information:
1. Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A
2. Magic number(s): N/A File extension(s): N/A
3. File extension(s): N/A Macintosh file type code(s): N/A
4. Macintosh file type code: N/A
5. Object Identifiers: N/A
Person to contact for further information:
1. Name: Michael Faller and Daniel Hanson
2. Email: michael.faller@gd-ms.com and dan.hanson@gd-ms.com
Intended usage: Common
Authors: Person & email address to contact for further information: Michael
Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and
Daniel Hanson (dan.hanson@gd-ms.com)
Michael Faller - michael.faller@gd-ms.com Intended usage: COMMON
Daniel Hanson - dan.hanson@gd-ms.com Restrictions on usage: N/A
Change controller: Authors: Michael Faller (michael.faller@gd-ms.com or
MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com)
SCIP Working Group - ncia.cis3@ncia.nato.int Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int)
5.2. Media Subtype "video/scip" 5.2. Media Subtype "video/scip"
Media type name: video Type name: video
Media subtype name: scip Subtype name: scip
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: Binary. This media subtype is only defined Encoding considerations: Binary. This media subtype is only defined
for transfer via RTP. There SHALL be no encoding/decoding for transfer via RTP. There SHALL be no transcoding of the video
(transcoding) of the video stream as it traverses the network. stream as it traverses the network.
Security considerations: See Section 7. Security considerations: See Section 6.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specifications: [SCIP210] Published specification: [SCIP210]
Applications which use this media: N/A Applications that use this media type: N/A
Fragment Identifier considerations: none Fragment identifier considerations: none
Restrictions on usage: N/A
Additional information: Additional information:
1. Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A
2. Magic number(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A
3. File extension(s): N/A
4. Macintosh file type code: N/A
5. Object Identifiers: N/A
Person to contact for further information:
1. Name: Michael Faller and Daniel Hanson
2. Email: michael.faller@gd-ms.com and dan.hanson@gd-ms.com
Intended usage: Common
Authors: Person & email address to contact for further information: Michael
Faller (michael.faller@gd-ms.com or MichaelFFaller@gmail.com) and
Daniel Hanson (dan.hanson@gd-ms.com)
Michael Faller - michael.faller@gd-ms.com Intended usage: COMMON
Daniel Hanson - dan.hanson@gd-ms.com Restrictions on usage: N/A
Change controller: Authors: Michael Faller (michael.faller@gd-ms.com or
MichaelFFaller@gmail.com) and Daniel Hanson (dan.hanson@gd-ms.com)
SCIP Working Group - ncia.cis3@ncia.nato.int Change controller: SCIP Working Group (ncia.cis3@ncia.nato.int)
5.3. Mapping to SDP 5.3. Mapping to SDP
The mapping of the above defined payload format media subtype and its The mapping of the above-defined payload format media subtype and its
parameters SHALL be implemented according to Section 3 of [RFC4855]. parameters SHALL be implemented according to Section 3 of [RFC4855].
Since SCIP includes its own facilities for capabilities exchange, it Since SCIP includes its own facilities for capabilities exchange, it
is only necessary to negotiate the use of SCIP within SDP Offer/ is only necessary to negotiate the use of SCIP within SDP Offer/
Answer; the specific codecs to be encapsulated within SCIP are then Answer; the specific codecs to be encapsulated within SCIP are then
negotiated via the exchange of SCIP control messages. negotiated via the exchange of SCIP control messages.
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[RFC8866], which is commonly used to describe RTP sessions. When SDP [RFC8866], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the SCIP codec, the mapping is is used to specify sessions employing the SCIP codec, the mapping is
as follows: as follows:
* The media type ("audio") goes in SDP "m=" as the media name for * The media type ("audio") goes in SDP "m=" as the media name for
audio/scip, and the media type ("video") goes in SDP "m=" as the "audio/scip", and the media type ("video") goes in SDP "m=" as the
media name for video/scip. media name for "video/scip".
* The media subtype ("scip") goes in SDP "a=rtpmap" as the encoding * The media subtype ("scip") goes in SDP "a=rtpmap" as the encoding
name. The required parameter "rate" also goes in "a=rtpmap" as name. The required parameter "rate" also goes in "a=rtpmap" as
the clock rate. the clock rate.
* The optional parameters "ptime" and "maxptime" go in the SDP * The optional parameters "ptime" and "maxptime" go in the SDP
"a=ptime" and "a=maxptime" attributes, respectively. "a=ptime" and "a=maxptime" attributes, respectively.
An example mapping for audio/scip is: An example mapping for "audio/scip" is:
m=audio 50000 RTP/AVP 96 m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000 a=rtpmap:96 scip/8000
An example mapping for video/scip is: An example mapping for "video/scip" is:
m=video 50002 RTP/AVP 97 m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000 a=rtpmap:97 scip/90000
An example mapping for both audio/scip and video/scip is: An example mapping for both "audio/scip" and "video/scip" is:
m=audio 50000 RTP/AVP 96 m=audio 50000 RTP/AVP 96
a=rtpmap:96 scip/8000 a=rtpmap:96 scip/8000
m=video 50002 RTP/AVP 97 m=video 50002 RTP/AVP 97
a=rtpmap:97 scip/90000 a=rtpmap:97 scip/90000
5.4. SDP Offer/Answer Considerations 5.4. SDP Offer/Answer Considerations
In accordance with the SDP Offer/Answer model [RFC3264], the SCIP In accordance with the SDP Offer/Answer model [RFC3264], the SCIP
device SHALL list the SCIP payload type number in order of preference device SHALL list the SCIP payload type number in order of preference
skipping to change at page 14, line 11 skipping to change at line 589
a=rtpmap:96 scip/8000 a=rtpmap:96 scip/8000
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
6. Security Considerations 6. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550], and in any applicable RTP profile such as specification [RFC3550], and in any applicable RTP profile such as
RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/
SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: SAVPF [RFC5124]. However, as "Securing the RTP Framework: Why RTP
Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] Does Not Mandate a Single Media Security Solution" [RFC7202]
discusses, it is not an RTP payload format's responsibility to discusses, it is not an RTP payload format's responsibility to
discuss or mandate what solutions are used to meet the basic security discuss or mandate what solutions are used to meet the basic security
goals like confidentiality, integrity, and source authenticity for goals like confidentiality, integrity, and source authenticity for
RTP in general. This responsibility lies on anyone using RTP in an RTP in general. This responsibility lies on anyone using RTP in an
application. They can find guidance on available security mechanisms application. They can find guidance on available security mechanisms
and important considerations in "Options for Securing RTP Sessions" and important considerations in "Options for Securing RTP Sessions"
[RFC7201]. Applications SHOULD use one or more appropriate strong [RFC7201]. Applications SHOULD use one or more appropriate strong
security mechanisms. The rest of this Security Considerations security mechanisms. The rest of this Security Considerations
section discusses the security impacting properties of the payload section discusses the security impacting properties of the payload
format itself. format itself.
This RTP payload format and its media decoder do not exhibit any This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus do not inherently pose a complexity for packet processing, and thus do not inherently pose a
denial-of-service threat due to the receipt of pathological data. denial-of-service threat due to the receipt of pathological data, nor
Nor does the RTP payload format contain any active content. does the RTP payload format contain any active content.
SCIP only encrypts the contents transported in the RTP payload; it SCIP only encrypts the contents transported in the RTP payload; it
does not protect the RTP header or RTCP packets. Applications does not protect the RTP header or RTCP packets. Applications
requiring additional RTP header and/or RTCP security might consider requiring additional RTP headers and/or RTCP security might consider
mechanisms such as SRTP [RFC3711], however these additional mechanisms such as SRTP [RFC3711], however these additional
mechanisms are considered OPTIONAL in this document. mechanisms are considered OPTIONAL in this document.
7. IANA Considerations 7. IANA Considerations
The audio/scip and video/scip media subtypes have previously been The "audio/scip" and "video/scip" media subtypes have previously been
registered with IANA [AUDIOSCIP] [VIDEOSCIP]. IANA should update registered in the "Media Types" registry [MediaTypes]. IANA has
[AUDIOSCIP] and [VIDEOSCIP] to reference this document upon updated these registrations to reference this document.
publication.
8. SCIP Contact Information 8. SCIP Contact Information
The SCIP protocol is maintained by the SCIP Working Group. The The SCIP protocol is maintained by the SCIP Working Group. The
current SCIP-210 specification may be requested from the email current SCIP-210 specification [SCIP210] may be requested from the
address below. email address below.
SCIP Working Group, CIS3 Partnership SCIP Working Group, CIS3 Partnership
NATO Communications and Information Agency NATO Communications and Information Agency
Oude Waalsdorperweg 61 Oude Waalsdorperweg 61
2597 AK The Hague, Netherlands 2597 AK The Hague, Netherlands
Email: ncia.cis3@ncia.nato.int Email: ncia.cis3@ncia.nato.int
An older public version of the SCIP-210 specification can be An older public version of the SCIP-210 specification can be
downloaded from https://www.iad.gov/SecurePhone/index.cfm. downloaded from https://www.iad.gov/SecurePhone/index.cfm. A U.S.
Department of Defense Root Certificate should be installed to access
this website.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 16, line 21 skipping to change at line 693
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866, Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021, DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>. <https://www.rfc-editor.org/info/rfc8866>.
9.2. Informative References 9.2. Informative References
[AUDIOSCIP] [MediaTypes]
Faller, M. and D. Hanson, "audio/scip: Internet Assigned IANA, "Media Types",
Numbers Authority (IANA)", 28 January 2021, <https://www.iana.org/assignments/media-types>.
<https://www.iana.org/assignments/media-types/audio/scip>.
[RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s
Transparent Call", RFC 4040, DOI 10.17487/RFC4040, April Transparent Call", RFC 4040, DOI 10.17487/RFC4040, April
2005, <https://www.rfc-editor.org/info/rfc4040>. 2005, <https://www.rfc-editor.org/info/rfc4040>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>. <https://www.rfc-editor.org/info/rfc4855>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
skipping to change at page 17, line 47 skipping to change at line 765
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 9143, Description Protocol (SDP)", RFC 9143,
DOI 10.17487/RFC9143, February 2022, DOI 10.17487/RFC9143, February 2022,
<https://www.rfc-editor.org/info/rfc9143>. <https://www.rfc-editor.org/info/rfc9143>.
[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol [RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
December 2021, <https://www.rfc-editor.org/info/rfc9170>. December 2021, <https://www.rfc-editor.org/info/rfc9170>.
[RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat) [RMCAT] IETF, "RTP Media Congestion Avoidance Techniques (rmcat)",
Working Group", <https://datatracker.ietf.org/wg/rmcat/about>.
<https://datatracker.ietf.org/wg/rmcat/about/>.
[SCIP210] SCIP Working Group, "SCIP Signaling Plan", SCIP-210,
r3.11, September 2023,
<https://www.iad.gov/SecurePhone/index.cfm>.
[VIDEOSCIP] [SCIP210] SCIP Working Group, "SCIP Signaling Plan, SCIP-210".
Faller, M. and D. Hanson, "video/scip: Internet Assigned Available by request via email to
Numbers Authority (IANA)", 28 January 2021, <ncia.cis3@ncia.nato.int>.
<https://www.iana.org/assignments/media-types/video/scip>.
Authors' Addresses Authors' Addresses
Daniel Hanson Daniel Hanson
General Dynamics Mission Systems, Inc. General Dynamics Mission Systems, Inc.
150 Rustcraft Road 150 Rustcraft Road
Dedham, MA 02026 Dedham, MA 02026
United States of America United States of America
Email: dan.hanson@gd-ms.com Email: dan.hanson@gd-ms.com
Michael Faller Michael Faller
General Dynamics Mission Systems, Inc. General Dynamics Mission Systems, Inc.
150 Rustcraft Road 150 Rustcraft Road
Dedham, MA 02026 Dedham, MA 02026
United States of America United States of America
Email: michael.faller@gd-ms.com Email: michael.faller@gd-ms.com, MichaelFFaller@gmail.com
Keith Maver Keith Maver
General Dynamics Mission Systems, Inc. General Dynamics Mission Systems, Inc.
150 Rustcraft Road 150 Rustcraft Road
Dedham, MA 02026 Dedham, MA 02026
United States of America United States of America
Email: keith.maver@gd-ms.com Email: keith.maver@gd-ms.com
 End of changes. 100 change blocks. 
269 lines changed or deleted 256 lines changed or added

This html diff was produced by rfcdiff 1.48.