9. Security Considerations
Questa pagina riassume la sezione corrispondente di RFC 9993 e conserva RTP payload, MIHS, SDP e dettagli IANA.
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.