Skip to content

Commit

Permalink
Merge pull request #21 from suhasHere/iesg-security-considerations
Browse files Browse the repository at this point in the history 
Iesg security considerations
  • Loading branch information
@suhasHere
suhasHere committed Aug 14, 2019
2 parents 9661db5 + 166cb9b commit d4f59f8
Showing 1 changed file with 104 additions and 31 deletions.
135 changes: 104 additions & 31 deletions draft-ietf-mmusic-ice-sip-sdp-38.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -946,7 +946,7 @@ If the candidate is a host candidate, <rel-addr> and <rel-port> MUST
<t hangText="">
In some cases, e.g., for privacy reasons, an agent may not want to reveal the related
address and port. In this case the address MUST be set to "0.0.0.0" (for IPv4 candidates)
or "::" (for IPv6 candidates) and the port to zero.
or "::" (for IPv6 candidates) and the port to '9'.
</t>
</list>
</t>
Expand Down Expand Up @@ -1341,41 +1341,114 @@ It is outside of the scope of ICE for it to act as a tool for "working around" S
If one is present, ICE will not be used and the SBC techniques take precedence.
</t>
</section>
<section anchor="sec-alg-sip" title="Interactions with Application Layer Gateways and SIP">
<t>
Application Layer Gateways (ALGs) are functions present in a Network Address Translation (NAT)
device that inspect the contents of packets and modify them, in order to facilitate NAT traversal
for application protocols. Session Border Controllers (SBCs) are close cousins of ALGs, but are
less transparent since they actually exist as application-layer SIP intermediaries. ICE has
interactions with SBCs and ALGs.
</t>
<t>
If an ALG is SIP aware but not ICE aware, ICE will work through it as long as the ALG correctly
modifies the SDP. A correct ALG implementation behaves as follows:
</t>
<t>
<list style="symbols">
<t>
The ALG does not modify the "m=" and "c=" lines or the rtcp attribute if they contain
external addresses.
</t>
<t>
If the "m=" and "c=" lines contain internal addresses, the modification depends on the state of the ALG:
<list style="symbols">
<t>
If the ALG already has a binding established that maps an external port to an internal connection
address and port matching the values in the "m=" and "c=" lines or rtcp attribute, the ALG uses that
binding instead of creating a new one.
</t>
<t>
If the ALG does not already have a binding, it creates a new one and modifies the SDP, rewriting
the "m=" and "c=" lines and rtcp attribute.
</t>
</list>
</t>
</list>
</t>
<t>
Unfortunately, many ALGs are known to work poorly in these corner cases.
ICE does not try to work around broken ALGs, as this is outside the scope of its functionality.
ICE can help diagnose these conditions, which often show up as a mismatch between the set of candidates and
the "m=" and "c=" lines and rtcp attributes. The ice-mismatch attribute is used for this purpose.
</t>
<t>
ICE works best through ALGs when the signaling is run over TLS.
This prevents the ALG from manipulating the SDP messages and interfering with ICE operation.
Implementations that are expected to be deployed behind ALGs SHOULD provide for TLS transport of the SDP.
</t>
<t>
If an SBC is SIP aware but not ICE aware, the result depends on the behavior of the SBC.
If it is acting as a proper Back-to-Back User Agent (B2BUA), the SBC will remove any SDP attributes
it doesn&#8217;t understand, including the ICE attributes. Consequently, the call will appear to both
endpoints as if the other side doesn&#8217;t support ICE. This will result in ICE being disabled, and
media flowing through the SBC, if the SBC has requested it. If, however, the SBC passes the ICE attributes
without modification, yet modifies the default destination for media (contained in the "m=" and "c=" lines
and rtcp attribute), this will be detected as an ICE mismatch, and ICE processing is aborted for the call.
It is outside of the scope of ICE for it to act as a tool for "working around" SBCs.
If one is present, ICE will not be used and the SBC techniques take precedence.
</t>
</section>
<section title="Security Considerations">
<t>
The generic ICE security considierations are defined in <xref target="RFC8445"/>, and the
generic SDP offer/answer security considerations are defined in <xref target="RFC3264"/>. These
security considerations also apply to implementations of this document.
</t>
<section title="IP Address Privacy">
<t>
In some cases, e.g., for privacy reasons, an agent may not want to reveal the related
address and port. In this case the address MUST be set to "0.0.0.0" (for IPv4 candidates)
or "::" (for IPv6 candidates) and the port to '9'.
</t>
</section>
<section title="Attacks on the Offer/Answer Exchanges">
<t>
An attacker that can modify or disrupt the offer/answer exchanges themselves can readily launch a variety of attacks with ICE.
They could direct media to a target of a DoS attack, they could insert themselves into the data stream, and so on.
These are similar to the general security considerations for offer/answer exchanges, and the security considerations in <xref target="RFC3264"/> apply.
These require techniques for message integrity and encryption for offers and answers, which are satisfied by the TLS mechanism <xref target="RFC3261"/> when SIP is used.
As such, the usage of TLS with ICE is RECOMMENDED.
</t>
An attacker that can modify or disrupt the offer/answer exchanges themselves can readily
launch a variety of attacks with ICE. They could direct media to a target of a DoS attack,
they could insert themselves into the data stream, and so on. These are similar to the general
security considerations for offer/answer exchanges, and the security considerations in
<xref target="RFC3264"/> apply. These require techniques for message integrity and encryption
for offers and answers, which are satisfied by the TLS mechanism <xref target="RFC3261"/> when
SIP is used. As such, the usage of TLS with ICE is RECOMMENDED.
</t>
</section>
<section title="Insider Attacks">
<section anchor="sec-voice-hammer" title="The Voice Hammer Attack">
<t>
In addition to attacks where the attacker is a third party trying to insert fake offers, answers, or STUN messages, there are several attacks possible with ICE when the attacker is an authenticated and valid participant in the ICE exchange.
</t>
<section anchor="sec-voice-hammer" title="The Voice Hammer Attack">
<t>
The voice hammer attack is an amplification attack.
In this attack, the attacker initiates sessions to other agents, and maliciously includes
the connection address and port of a DoS target as the destination for media traffic
signaled in the SDP. This causes substantial amplification; a single offer/answer exchange
can create a continuing flood of media packets, possibly at high rates (consider video sources).
This attack is not specific to ICE, but ICE can help provide remediation.
</t>
<t>
Specifically, if ICE is used, the agent receiving the malicious SDP will first perform connectivity checks to the target of media before sending media there.
If this target is a third-party host, the checks will not succeed, and media is never sent.
</t>
<t>
Unfortunately, ICE doesn&#8217;t help if it&#8217;s not used, in which case an attacker could simply send the offer without the ICE parameters.
However, in environments where the set of clients is known, and is limited to ones that support ICE, the server can reject any offers or answers that don&#8217;t indicate ICE support.
</t>
<t>
SIP User Agents (UA) <xref target="RFC3261"/> that are not willing to receive non-ICE answers MUST include an "ice" Option Tag <xref target="RFC5768"/> in the SIP Require Header Field in their offer. UAs that reject non-ICE offers will generally use a 421 response code, together with an Option Tag "ice" in the Require Header Field in the response.
</t>
</section>
The voice hammer attack is an amplification attack, and can be triggered even if the attacker
is an authenticated and valid participant in a session.
In this attack, the attacker initiates sessions to other agents, and maliciously includes
the connection address and port of a DoS target as the destination for media traffic
signaled in the SDP. This causes substantial amplification; a single offer/answer exchange
can create a continuing flood of media packets, possibly at high rates (consider video sources).
The use of ICE can help to prevent against this attack.
</t>
<t>
Specifically, if ICE is used, the agent receiving the malicious SDP will first perform connectivity
checks to the target of media before sending media there. If this target is a third-party host, the
checks will not succeed, and media is never sent.
</t>
<t>
Unfortunately, ICE doesn&#8217;t help if it&#8217;s not used, in which case an attacker could simply
send the offer without the ICE parameters. However, in environments where the set of clients is known,
and is limited to ones that support ICE, the server can reject any offers or answers that don&#8217;t
indicate ICE support.
</t>
<t>
SIP User Agents (UA) <xref target="RFC3261"/> that are not willing to receive non-ICE answers MUST include
an "ice" Option Tag <xref target="RFC5768"/> in the SIP Require Header Field in their offer. UAs that
reject non-ICE offers will generally use a 421 response code, together with an Option Tag "ice" in the
Require Header Field in the response.
</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
Expand Down

0 comments on commit d4f59f8

Please sign in to comment.