9. Security Considerations

Security considerations from Section 9 are preserved below.

9.  Security Considerations

   The RTP payload format is subject to security threats commonly
   associated with RTP payload formats, as well as threats specific to
   the interaction of haptic devices with the physical world and threats
   associated with the use of compression by the codec.  Security
   considerations for threats commonly associated with RTP payload
   formats are outlined in [RFC3550], as well as in RTP profiles such as
   RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], and RTP/
   SAVPF [RFC5124].

   Haptic sensors and actuators operate within the physical environment.
   This introduces the potential for information leakage through sensors
   or damage to actuators due to data tampering.  Additionally, misusing
   the functionalities of actuators (such as force, position,
   temperature, vibration, electrotactile, etc.) may pose a risk of harm
   to the user, for example, by setting keyframe parameters (e.g.,
   amplitude, position, and frequency) or channel gain to a value that
   surpasses a permissible range.  While individual devices can
   implement security measures to reduce or eliminate those risks on a
   per-device basis, in some cases, harm can be inflicted by setting
   values that are permissible for the individual device.  For example,
   causing contact with the physical environment or triggering
   unexpected force feedback can potentially harm the user.  Each haptic
   system should therefore implement system-dependent security measures,
   which are more error prone.  To limit the risk that attackers exploit
   weaknesses in haptic systems, it is important that haptic
   transmission be protected against malicious traffic injection or
   tampering.

   However, as "Securing the RTP Framework: Why RTP Does Not Mandate a
   Single Media Security Solution" [RFC7202] discusses, it is not an RTP
   payload format's responsibility to discuss or mandate what solutions
   are used to meet the basic security goals like confidentiality,
   integrity, and source authenticity for RTP in general.  The
   responsibility for implementing security mechanisms lies with the
   application developer.  They can find guidance on available security
   mechanisms and important considerations in "Options for Securing RTP
   Sessions" [RFC7201], although [RFC7201] is now considered dated and
   several mechanisms described therein have since evolved.

   Applications SHOULD use appropriate and current strong security
   mechanisms.  For modern best practices, applications can consider the
   following options:

   *  (D)TLS-based protection: For guidance on using TLS 1.3 and DTLS,
      applications should refer to [BCP195], which provides up-to-date
      recommendations.

   *  IPsec-based protection: Relevant and current protocol
      specifications include [RFC4303] ("IP Encapsulating Security
      Payload (ESP)") and [RFC7296] ("Internet Key Exchange Protocol
      Version 2 (IKEv2)").

   This document does not mandate a specific security mechanism.
   Instead, applications are responsible for selecting mechanisms that
   follow current best practices for confidentiality, integrity, and
   source authentication and that reflect the evolving security
   landscape beyond what is covered in [RFC7201].

   The haptic codec used with this payload format uses a compression
   algorithm (see Sections 8.2.8.5 and 8.3.3.2 in [ISO.IEC.23090-31]).
   An attacker may inject pathological datagrams into the stream that
   are complex to decode and cause the receiver to be overloaded,
   similarly to [RFC3551].

   End-to-end security with authentication, integrity, or
   confidentiality protection will prevent a Media-Aware Network Element
   (MANE) from performing media-aware operations other than discarding
   complete packets.  In the case of confidentiality protection, it will
   even be prevented from discarding packets in a media-aware way.  To
   be allowed to perform such operations, a MANE is required to be a
   trusted entity that is included in the security context
   establishment.