Subject: Re: [Sipping] new draft-ietf-sipping-isup-05 (Security)

From: [email-masked]
Date: Thu, 15 Aug 2002 10:28:55 EDT

To all,

The Security Considerations section in sipping-isup-05 was extensively 
expanded from -04, but it does not mention the problem raised in the overlap 
draft, which is, in fact, a problem for all of SIP to ISUP interworking. That 
is, the ability of one SIP user to send multiple INVITEs which tie up 
facilities (real trunks) at the egress GW and in the destination network for 
a relatively long time. The following paragraph, copied and slightly changed 
from the latest overlap draft, should be added:

--------------------------------------------
  When SIP to ISUP interworking occurs, it is possible that an attacker
  could send multiple INVITEs containing an address which is known to never 
answer to the
  same gateway in an attempt to occupy all available ports and thereby
  deny service to legitimate callers. Since none of these 
  addressed calls would ever answer, in a traditional billing scheme
  the sender of the INVITEs would never be charged. To address this
  threat, the authors recommend that gateway operators authenticate the
  senders of INVITE requests, first in order to have some
  accountability for the source of calls (it is very imprudent to give
  gateway access to unknown users on the Internet), but second so that
  the gateway can determine when multiple calls are originating from
  the same source in a short period of time. Some sort of threshold of
  unanswered calls should be tracked by the gateway, and, after the
  limit is exceeded, further similar calls should be rejected to
  prevent the saturation of gateway trunking resources.

--------------------------------------------

(It should be noted that the capability mentioned in the final sentence above 
is already a standard feature of many PSTN switches. Calls to hard-to-reach 
codes can be limited to prevent saturation to destinations which probably 
can't be reached anyway.)

Further, some of the other statements of "no problem" in the Security 
Considerations are unjustified (all added in -05)

1. The ability of the user to directly set the contents of the ISUP messages, 
such as the Called Party Number field, is a security risk. It is not true 
that these fields are "already set directly by the user today". The user does 
not have direct access to any ISUP field. The user enters the Called Party 
Number by an access protocol. If it is DSS1, then the end office creates a 
similar field in the ISUP message, maybe using the exact same data format, 
but it controls it. For example, within the ISUP network, a carrier could use 
non-dialable numbers in the Called Party Number field for internal network 
routing purposes. It would be disasterous if the end user could enter these 
same numbers.

2. If the SIP user has the ability to send any response code, which gets 
translated to a specific Cause code, they could do harm by misleading the 
originating network. For example, a Cause code of 25, Exchange routing error, 
could be returned, causing the originating switch to not route to this number 
again or to any with the same routing digits. In the ISDN world, this was 
prevented since the user could not send this Cause value.

3. Cut-through of the backward path can be misused. SIP introduces 
significant additional risks that do not exist in Q.931-ISUP mapping. The 
solution in the PSTN world partly depended on the concept of defining 
different types of exchanges (originating, terminating, transit, 
international gateways, etc) and identifying trausted and non-trusted 
entities. SIP tries to avoid such a distinction, with a GW not knowing how it 
fits in the call setup, therefore, unaware of any special requirement it has 
regarding cut-through. The model in the PSTN was based on knowing that the 
call progess tones before answer came from a "trusted" entity, which wasn't 
going to misuse the transmission path to instead pass data. When the 
destination was not trusted, the final trusted switch would not cut-through 
until answer was returned so that billing could be started. It applied the 
call progress tones, and was allowed a very short time to remove that tone 
and cut-through locally. SIP doesn't have this concept, and the architecture 
and protocol do not allow for a fast cut-through upon answer, hence, the 
difficulty trying to deal with this problem.

4. The suggestion that a gateway could introduce a 20-30 seconds timer on the 
early media to prevent fraud fails to address the problem. Since before the 
invention of the modem, people having been using the 3 second grace period on 
answer to pass information without being charged, so using only a couple 
seconds of "early media" would still be a problem. Further, the suggestion 
that a "more conservative approach" is to not cut-through the media in the 
reverse direction until 2xx occurs completely ignores the speech clipping 
problem. This final suggestion must be removed.

There needs to be a clear way to deal with each of these threats, otherwise, 
SIP can not be used to interwork with ISUP.

The worst part of the above threats is that, without authentication, it isn't 
even known who is doing them. What I am looking for is a clear, unambiguous 
statement that ISUP interworking absolutely requires authentication of the 
originator (SIP device or ingress gateway) by the egress GW. That is, the 
words "the authors recommend that gateway operators authenticate ..." in the 
above suggested text should really read: "gateways MUST authenticate ..."

Mike Pierce
Artel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 15 Aug 2002 11:08:06 -0500

Please help me understand:

>ISUP interworking absolutely requires authentication of the 
>originator (SIP device or ingress gateway) by the egress GW.

Does this mean that I cannot use my SIP device to call someone who does
not know me? I don't tink this is acceptable, tough it would probably
block the telemarketers - highly desirable - but still not acceptable.

Do we have here the larger issue that IP-PSTN/ISDN interworking exposes
PSTN/ISDN to IP-like attacks? If yes, than it should be dealt with
outside the SIP-ISUP context. What do y'all think?

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Thursday, August 15, 2002 9:29 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Sipping] new draft-ietf-sipping-isup-05 (Security)
> 
> 
> To all,
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 15 Aug 2002 15:44:07 -0400

Henry,

I think it goes beyond just IP-like attacks.  The problem is that the PSTN 
trust model relies on the trust of the ISUP or it fails completely.  So, I 
don't think you can divorce the problem from ISUP.  It is the ability to 
control/fool ISUP that leads to the problems.

Mike

At 11:08 AM 8/15/2002 -0500, Henry Sinnreich wrote:
> > That is, the

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 15 Aug 2002 17:50:51 -0500

Mike,

>The problem is 
> that the PSTN 
> trust model relies on the trust of the ISUP or it fails 
> completely.

This means we are trying to connect an open environment (IP) to a
sensitive one (ISUP) and a general signaling gateway aproach is needed
to absorb the trust model differences that you mention. This goes beyond
the early media issue and may pop elsewhere as well. Yes, I know, this
sounds like very high level, but maybe stepping back from just the early
media issue would make sense. Does it?

Thanks, Henry

> On Behalf Of Michael Hammer
> Sent: Thursday, August 15, 2002 2:44 PM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Sipping] new draft-ietf-sipping-isup-05 (Security)
> 
> 
> Henry,
> 
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of [email-masked]
> > > The Security Considerations section in sipping-isup-05 was 
> > > extensively expanded from -04, but it does not mention 
> the problem 
> > > raised in the overlap
> > >   could send multiple INVITEs containing an address which 
> is known 
> > > to never answer to the
> > > (It should be noted that the capability mentioned in the final 
> > > sentence above is already a standard feature of many PSTN 
> switches. 
> > > Calls to hard-to-reach
> > > Further, some of the other statements of "no problem" in the 
> > > Security Considerations are unjustified (all added in -05)
> > >
> > > 1. The ability of the user to directly set the contents 
> of the ISUP 
> > > messages, such as the Called Party Number field, is a 
> security risk. 
> > > It is not true
> > > 2. If the SIP user has the ability to send any response 
> code, which 
> > > gets translated to a specific Cause code, they could do harm by
> > > misleading the
> > > significant additional risks that do not exist in Q.931-ISUP 
> > > mapping. The solution in the PSTN world partly depended on the 
> > > concept of defining different types of exchanges (originating, 
> > > terminating, transit, international gateways, etc) and 
> identifying 
> > > trausted and non-trusted entities. SIP tries to avoid such a 
> > > distinction, with a GW not knowing how it
> > > 4. The suggestion that a gateway could introduce a 20-30 seconds 
> > > timer on the early media to prevent fraud fails to address the 
> > > problem. Since before the
> > > There needs to be a clear way to deal with each of these threats, 
> > > otherwise, SIP can not be used to interwork with ISUP.
> > >
> > > The worst part of the above threats is that, without 
> authentication, 
> > > it isn't even known who is doing them. What I am looking for is a
> > > clear, unambiguous
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listin> fo/sipping
> > > This list 
> is for NEW development of the 
> application of SIP Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments of core SIP
> > >
> >
> >
> >Use [email-masked] for questions on 
> current sip Use 
> >[email-masked] for new developments of core SIP
> 
>