[VOIPSEC] 4G Issue Map: signaling complexity

[DePietro, John]

Remember there will be lots of SIP transaction for non-realtime services particularly around Instant Messaging and Presence (SUBSCRIBE, NOTIFY and MESSAGE).  Presence is particularly chatty.  

BTW - Since this is a security community.  Does anyone have comments on the Security risks and the mitigation of these risk via the mechanisms defined in RFC 3320, section 10?
<The following taken from rfc3320 section 10>

10.0 Security Considerations

10.1. Security Goals

The overall security goal of the SigComp architecture is to not
create risks that are in addition to those already present in the
application protocols. There is no intention for SigComp to enhance
the security of the application, as it always can be circumvented by
not using compression. More specifically, the high-level security
goals can be described as:

1. Do not worsen security of existing application protocol
2. Do not create any new security issues
3. Do not hinder deployment of application security.

10.2. Security Risks and Mitigation 

This section identifies the potential security risks associated with SigComp, and explains how each risk is minimized by the scheme.

10.2.1 Confidentiality Risks

- Attacking SigComp by snooping into state of other users: 

State is accessed by supplying a state identifier, which is a cryptographic hash of the state being referenced. This implies that the referencing message already needs knowledge about the state. To enforce this, a state item cannot be accessed without supplying a minimum of 48 bits from the hash. This also minimizes the probability of an accidental state collision. A compressor can, using the minimum_access_length operand of the STATE-CREATE and ENDMESSAGE instructions, increase the number of bits that need to be supplied to access the state, increasing the protection against attacks.

Generally, ways to obtain knowledge about the state identifier (e.g., passive attacks) will also easily provide knowledge about the referenced state, so no new vulnerability results. An endpoint needs to handle state identifiers with the same care it would handle the state itself.

10.2.2 Integrity Risks
The SigComp approach assumes that there is appropriate integrity protection below and/or above the SigComp layer. The state creation mechanism provides some additional potential to compromise the integrity of the messages; however, this would most likely be detectable at the application layer.

- Attacking SigComp by faking state or making unauthorized changes to state:

State cannot be destroyed by a malicious sender unless it can send messages that the application identifies as belonging to the same compartment the state was created under; this adds additional security risks only when the application allows the installation of SigComp state from a message where it would not have installed state itself.

Faking or changing state is only possible if the hash allows intentional collision.

10.2.3. Availability Risks (Avoiding DoS Vulnerabilities)

- Use of SigComp as a tool in a DoS attack to another target:

SigComp cannot easily be used as an amplifier in a reflection attack, as it only generates one decompressed message per incoming compressed message. This message is then handed to the application; the utility as a reflection amplifier is therefore limited by the utility of the application for this purpose.

However, it must be noted that SigComp can be used to generate larger messages as input to the application than have to be sent from the malicious sender; this therefore can send smaller messages (at a lower bandwidth) than are delivered to the application. Depending on the reflection characteristics of the application, this can be considered a mild form of amplification. The application MUST limit the number of packets reflected to a potential target - even if SigComp is used to generate a large amount of information from a small incoming attack packet.

- Attacking SigComp as the DoS target by filling it with state:

Excessive state can only be installed by a malicious sender (or a setof malicious senders) with the consent of the application. The system consisting of SigComp and application is thus approximately as vulnerable as the application itself, unless it allows the installation of SigComp state from a message where it would not have installed application state itself.

If this is desirable to increase the compression ratio, the effect can be mitigated by making use of feedback at the application level that indicates whether the state requested was actually installed - this allows a system under attack to gracefully degrade by no longer installing compressor state that is not matched by application state. 

Obviously, if a stream-based transport is used, the streams themselves constitute state that has to be handled in the same way that the application itself would handle a stream-based transport; if an application is not equipped for stream based transport, it should not allow SigComp connections on a stream-based transport. For the alternative SigComp usage described as "continuous mode" in Section 4.2.1, an attacker could create any number of active UDVMs unless
there is some DoS protection at a lower level (e.g., by using TLS in
appropriate configurations).

- Attacking the UDVM by faking state or making unauthorized changes
to state:

This is covered in Section 10.2.2.

- Attacking the UDVM by sending it looping code:

The application sets an upper limit to the number of "UDVM cycles" that can be used per compressed message and per input bit in the compressed message. The damage inflicted by sending packets with looping code is therefore limited, although this may still be substantial if a large number of UDVM cycles are offered by the UDVM. However, this would be true for any decompressor that can receive packets over an unsecured transport. 

<end section 10>

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]On
Behalf Of Hadriel Kaplan
Sent: Friday, August 25, 2006 1:42 AM
To: 'Paul E. Jones'
Cc: Voipsec at voipsa.org
Subject: Re: [VOIPSEC] 4G Issue Map: signaling complexity




> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Paul E. Jones
>
> SIP compression apparently came about because people felt like they needed
> to consume less bandwidth over wireless links.  Why that matters when you
> then send a bunch of RTP packets out seems illogical to me, but I suppose
> that's why I'm not making wireless handsets.  

Actually, its my understanding it's not so much the bandwidth (although that
may also matter when you take into account the number of phones in a cell,
where few are actually in-call but there's still signaling).  But the real
reasons were serialization delay and bit error rate.  The delay ended up
creating very long call setup times.  And BER obviously would make it worse
(not to mention consume more bandwidth).

 
> Perhaps, but machines do not get debugged all the time.  Further, I have
> never had any trouble personally debugging protocols written in ASN.1.
> When
> messages are decoded, you can print the contents on the screen.
> 
> Only 2 or 3 times in my life have I ever seen the binary decode operation
> fail.  The reason is that people generally use well-tested commercial
> compilers and libraries from companies like OSS.

Wow.  We must live in different worlds.  I get "H.323" traces all the time
Ethereal can't decode and I end up asking the vendor for their secret
decoder ring.  This literally happened last week.  When Ethereal can't parse
someone's SIP, I still can. (well, unless sigcomp is used ;)  

-hadriel



_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org


"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."