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 capability
exchange, packetization/de-packetization of media, reliable exchange, packetization/de-packetization of media, reliable
transport, and payload encryption. transport, and payload encryption.
SCIP handles packetization/de-packetization of the encrypted media SCIP handles packetization/de-packetization of encrypted media and
and acts as a tunneling protocol, treating SCIP payloads as opaque acts as a tunneling protocol, treating SCIP payloads as opaque octets
octets to be encapsulated within RTP payloads prior to transmission to be encapsulated within RTP payloads prior to transmission or
or decapsulated on reception. SCIP payloads are sized to fit within decapsulated on reception. SCIP payloads are sized to fit within the
the maximum transmission unit (MTU) when transported over RTP thereby maximum transmission unit (MTU) when transported over RTP, thereby
avoiding fragmentation. avoiding fragmentation.
SCIP transmits encrypted traffic and does not require the use of SCIP transmits encrypted traffic and does not require the use of
Secure RTP (SRTP) for payload protection. SCIP also provides for Secure RTP (SRTP) for payload protection. SCIP also provides for
reliable transport at the application layer, so it is not necessary reliable transport at the application layer, so it is not necessary
to negotiate RTCP retransmission capabilities. to negotiate RTCP retransmission capabilities.
To establish reliable communications using SCIP over RTP, it is To establish reliable communications using SCIP over RTP, it is
important that middle boxes avoid parsing or modifying SCIP payloads. important that middleboxes avoid parsing or modifying SCIP payloads.
Because SCIP payloads are confidentiality and integrity protected and Because SCIP payloads are confidentiality and integrity protected and
are only decipherable by the originating and receiving SCIP devices, are only decipherable by the originating and receiving SCIP devices,
modification of the payload by middle boxes would be detected as an modification of the payload by middle boxes would be detected as an
integrity failure in SCIP devices, resulting in retransmission and/or integrity failure in SCIP devices, resulting in retransmission and/or
communication failure. Middle boxes do not need to parse the SCIP communication failure. Middle boxes do not need to parse the SCIP
payloads to correctly transport them. Not only is parsing payloads to correctly transport them. Not only is parsing
unnecessary to tunnel/detunnel SCIP within RTP, but the parsing and unnecessary to tunnel/detunnel SCIP within RTP, but the parsing and
filtering of SCIP payloads by middle boxes would likely lead to filtering of SCIP payloads by middle boxes would likely lead to
ossification of the evolving SCIP protocol. ossification of the evolving SCIP protocol.
Status of This Memo IESG Note
This Internet-Draft is submitted in full conformance with the This IETF specification depends upon a second technical specification
provisions of BCP 78 and BCP 79. that is not available publicly, namely [SCIP210]. The IETF was
therefore unable to conduct a security review of that specification,
independently or when carried inside Audio/Video Transport (AVT).
Implementers need to be aware that the IETF hence cannot verify any
of the security claims contained in this document.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 August 2024. This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
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 RTP Transport Protocols 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 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/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 middle boxes 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 * SCIP includes built-in mechanisms that negotiate protocol message
versions and capabilities. To avoid SCIP protocol ossification versions and capabilities. To avoid SCIP protocol ossification
(as described in [RFC9170]), it is important for middle boxes to (as described in [RFC9170]), it is important for middle boxes to
not attempt parsing of the SCIP payload. As described in this not attempt parsing of the SCIP payload. As described in this
document, such parsing serves no useful purpose. document, such parsing serves no useful purpose.
2. Introduction 2. Introduction
The purpose of this document is to provide enough information to The purpose of this document is to provide enough information to
enable SCIP payloads to be transported through the network without enable SCIP payloads to be transported through the network without
modification or filtering. The document provides a reference for modification or filtering. This document provides a reference for
network security policymakers; network equipment OEMs, network security policymakers; network equipment OEMs,
administrators, and architects; procurement personnel; and government administrators, and architects; procurement personnel; and government
agency and commercial industry representatives. agency and commercial industry representatives.
The document details usage of the "audio/scip" and "video/scip" This document details usage of the "audio/scip" [AUDIOSCIP] and
pseudo-codecs [AUDIOSCIP], [VIDEOSCIP] as a secure session "video/scip" [VIDEOSCIP] pseudo-codecs as a secure session
establishment protocol and media transport protocol over RTP. It establishment protocol and media transport protocol over RTP. It
discusses (1) how encrypted audio and video codec payloads are discusses:
transported over RTP; (2) the IP network layer not implementing SCIP
as a protocol since SCIP operates at the application layer in 1. how encrypted audio and video codec payloads are transported over
endpoints; (3) the IP network layer enabling SCIP traffic to RTP;
transparently pass through the network; (4) network devices not
recognizing SCIP, and thus removing the scip codecs from the SDP 2. the IP network layer not implementing SCIP as a protocol since
media payload declaration before forwarding to the next network node; SCIP operates at the application layer in endpoints;
and finally, (5) SCIP endpoint devices not operating on networks due
to the scip media subtype removal from the SDP media payload 3. the IP network layer enabling SCIP traffic to transparently pass
declaration. through the network;
4. network devices not recognizing SCIP, and thus removing the SCIP
codecs from the SDP media payload declaration before forwarding
to the next network node; and finally,
5. SCIP endpoint devices not operating on networks due to the scip
media subtype removal 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/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 middle
skipping to change at page 4, line 48 skipping to change at line 203
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/Video Profile
skipping to change at page 5, line 17 skipping to change at line 219
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/Video Profile
AVPF: Audio/Video Profile Feedback AVPF: Audio/Video Profile Feedback
ICWG: Interoperability Control Working Group ICWG: Interoperability Control Working Group
IICWG: International Interoperability Control Working Group IICWG: International Interoperability Control Working Group
NATO: North Atlantic Treaty Organization NATO: North Atlantic Treaty Organization
OEM: Original Equipment Manufacturer OEM: Original Equipment Manufacturer
SAVP: Secure Audio/Video Profile SAVP: Secure Audio/Video Profile
SAVPF: Secure Audio/Video Profile Feedback SAVPF: Secure Audio/Video Profile 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. 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 and
video/scip media subtypes that enables network equipment video/scip media subtypes that enable network equipment manufacturers
manufacturers to include settings for "scip" as a known audio and to include settings for "scip" as a known audio and video media
video media subtype in their equipment. This enables network subtype in their equipment. This enables network administrators to
administrators to define and implement a compatible security policy define and implement a compatible security policy that includes audio
which includes audio and video media subtypes "audio/scip" and and video media subtypes "audio/scip" and "video/scip", respectively,
"video/scip", respectively, as permitted codecs on the network. 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 media
subtype data streams within the network, including the VoIP network, subtype data streams within the network, including the VoIP network,
MUST be a transparent relay and be treated as "clear-channel data", MUST be a transparent relay and be treated as "clear-channel data",
similar to the Clearmode media subtype defined by [RFC4040]. 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/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 364
+--------------+ | +--------------+ |
| | | |
| | | |
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 419
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 RTP Transport Protocols 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 not
protocols that do not modify the SCIP payload are considered OPTIONAL modify the SCIP payload are considered OPTIONAL in this document and
in this document and are discretionary for a SCIP device vendor to 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 encoding/decoding
(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) 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) 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 encoding/decoding
(transcoding) of the video stream as it traverses the network. (transcoding) of the video 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) 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) 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
skipping to change at page 14, line 11 skipping to change at line 601
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 with IANA [AUDIOSCIP] [VIDEOSCIP]. IANA should update
[AUDIOSCIP] and [VIDEOSCIP] to reference this document upon [AUDIOSCIP] and [VIDEOSCIP] to reference this document upon
publication. publication.
skipping to change at page 16, line 22 skipping to change at line 705
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] [AUDIOSCIP]
Faller, M. and D. Hanson, "audio/scip: Internet Assigned IANA, "audio/scip",
Numbers Authority (IANA)", 28 January 2021,
<https://www.iana.org/assignments/media-types/audio/scip>. <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>.
skipping to change at page 17, line 47 skipping to change at line 776
[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, [SCIP210] SCIP Working Group, "SCIP Signaling Plan", SCIP-210,
r3.11, September 2023, r3.11, September 2023,
<https://www.iad.gov/SecurePhone/index.cfm>. <https://www.iad.gov/SecurePhone/index.cfm>.
[VIDEOSCIP] [VIDEOSCIP]
Faller, M. and D. Hanson, "video/scip: Internet Assigned IANA, "video/scip",
Numbers Authority (IANA)", 28 January 2021,
<https://www.iana.org/assignments/media-types/video/scip>. <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. 89 change blocks. 
202 lines changed or deleted 204 lines changed or added

This html diff was produced by rfcdiff 1.48.