Subject: [Sipping] Comments on Overlap Security Considerations

From: [email-masked]
Date: Thu, 1 Aug 2002 12:22:06 EDT

To all,

I find the new security considerations section in the recent 
draft-ietf-sipping-overlap-02 to be confusing and inadequate. While the draft 
addresses the case of interworking PSTN-SIP-PSTN, this new Security 
Considerations section seems to be addressing the case of calls originated by 
a SIP telephone. (Yes, I know, you're trying to define a signaling which is 
oblivious to whether it came from an individual user's telephone-type device 
or from a service provider's gateway, but I don't believe security can be 
done one way to suit both architectures.)

Having the egress GW initiate an authentication procedure (multiple 
messages?) for each INVITE received with an incomplete address may prevent an 
attacker from tying up "all" available ports out of that GW into the PSTN, 
but it introduces another problem - Denial of Service because of the overload 
of processing the authentications. Anyway, what limit would be applied by the 
GW, considering that the described procedues allow multiple ports to be 
temporarily occupied for one call in the normal case? In addition, 
"authentication" would not help, since the originating GW will always be 
found to be "authentic". Would this procedure then limit the number of 
simultaneous overlap calls from one ingress GW? It is unknown what "similar 
calls" means that would be rejected.

The case being addressed seems to be one in which the attack is originatated 
from within the IP domain. A partial solution is to not allow overlap to 
originate there. In any case, this attack is unrelated to overlap. A user in 
the IP domain could initiate multiple normal (en-bloc) calls and do the same 
thing. If a solution is needed to prevent an attacker in the IP domain from 
attempting this type of attack, it needs to be defined someplace else for all 
cases, not just overlap.

The only case of overlap (INVITEs with an incomplete number) should be for a 
call which originates in the PSTN and interworks to IP through a GW (and may 
go back to the PSTN). Then, an attacker (in the PSTN) would have to tie up 
many resources at the originating side in order to attempt what is described 
in the Security Considerations. It is the responsiblity of the originating 
PSTN to deal with this problem.

The only responsibility of the egress GW is to ensure that an attempt to use 
overlap came from another GW. Whether this is based on a previously 
established trust relationship or real-time authentication is not important. 
However, no limit on the number of simultaneous calls can be applied.

Mike Pierce
Artel

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 1 Aug 2002 12:46:08 -0700

Mike,

How would the terminating GW determine if the INVITE originated in the 
IP world or the PSTN world?

thanks,
-rohan

On Thursday, August 1, 2002, at 09:22 AM, [email-masked] wrote:

> draft-ietf-sipping-overlap-02 to be confusing and inadequate. While the 
> draft addresses the case of interworking PSTN-SIP-PSTN, this new 
> Security Considerations section seems to be addressing the case of 
> calls originated by a SIP telephone. (Yes, I know, you're trying to 
> define a signaling which is oblivious to whether it came from an 
> individual user's telephone-type device or from a service provider's 
> gateway, but I don't believe security can be done one way to suit both 
> architectures.)
>
> messages?) for each INVITE received with an incomplete address may 
> prevent an attacker from tying up "all" available ports out of that GW 
> into the PSTN, but it introduces another problem - Denial of Service 
> because of the overload of processing the authentications. Anyway, what 
> limit would be applied by the GW, considering that the described 
> procedues allow multiple ports to be temporarily occupied for one call 
> in the normal case? In addition, "authentication" would not help, since 
> the originating GW will always be found to be "authentic". Would this 
> procedure then limit the number of simultaneous overlap calls from one 
> ingress GW? It is unknown what "similar calls" means that would be 
> rejected.
>
> The case being addressed seems to be one in which the attack is 
> originatated from within the IP domain. A partial solution is to not 
> allow overlap to originate there. In any case, this attack is unrelated 
> to overlap. A user in the IP domain could initiate multiple normal 
> (en-bloc) calls and do the same thing. If a solution is needed to 
> prevent an attacker in the IP domain from attempting this type of 
> attack, it needs to be defined someplace else for all cases, not just 
> overlap.
>
> The only case of overlap (INVITEs with an incomplete number) should be 
> for a call which originates in the PSTN and interworks to IP through a 
> GW (and may go back to the PSTN). Then, an attacker (in the PSTN) would 
> have to tie up many resources at the originating side in order to 
> attempt what is described in the Security Considerations. It is the 
> responsiblity of the originating PSTN to deal with this problem.
>
> The only responsibility of the egress GW is to ensure that an attempt 
> to use overlap came from another GW. Whether this is based on a 
> previously established trust relationship or real-time authentication 
> is not important. However, no limit on the number of simultaneous calls 
> can be applied.
>
> Mike Pierce
> Artel
>