Subject: [Sipping] mike pierce issue summary

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Aug 2002 16:10:35 -0500

Summarizing three mails from Mike below, for those that are interested.
First his mail on security, then his mail on the tel URL, then his comments
on 'last calls'.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 7:29 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Sipping] new draft-ietf-sipping-isup-05 (Security)
> 
> 
> 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.)

Authentication is already amply motivated in the draft. Thresholds for
unanswered calls, admittedly, are not. I suppose we could add some text
about that in -06. The only reason it appeared in the overlap draft was
because the IESG asked for the question to be addressed - to date, they have
not raised that specific point about sipping-isup-05.

> 
> 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. 

This is a hostile reading of the text, which actually says 'the telephone
number portion of the CPN'.

> 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.

Again, the user doesn't set the NoA or other fields of the CPN. Extensive
text discusses the use of E.164 numbers as opposed to private dialing plans
or nationally-signicant numbers elsewhere in the draft. That much said, we
could add some text to the Security Considerations on this general point...
I'll try to come up with something appropriate. I don't think there will be
a SIP URI equivalent of INWATS KP+121+ST, or something - we have safely
departed the 70s, thankfully. 

> 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.
> 

Can anyone provide some corroboration (a textual reference would be nice)
for that cause code 25 behavior in ITU-T standards?

If there is a good reason to think this is the case, we'll change that
particular mapping so that cause 25 is not sent.

> 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.
> 

The mechanism in your point (4) below provide clear recommendations that
would satisfy this concern. No mechanism needs to be added to address your
concerns (nor do you suggest one). You're just throwing up more dust because
you dislike the SIP architecture, which allows (gasp) a network of equals.
This creates challenges and opportunities for designer. In any event, we're
not going to change the SIP architecture, especially not in this document.

> 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.
> 

Actually, I submit that both are useful suggestions. Neither will be
removed. People can also use the automated collect call system to make calls
from Mr. WeHadABabyIt'sABoy, as a recent TV commercial suggested. Clipping
is more or less orthogonal to the 200 cut-off issue (SDP can be exchanged
without starting a media flow in these precondition-based systems, I
understand). 

Your irrational defeatism and grandiose posturing make your arguments
extremely unpersuasive.

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

This is also false. The purpose of a Security Considerations section is to
make implementers aware of risks, and to suggest any known ways of
addressing these risks.

SIP-ISUP interworking has been occuring for some time in practice in the
absence of these considerations. Are you going to come around and arrest the
perpetrators?

We are aware that you consider SIP harmful/inferior to ISUP, and unworthy to
participate in the PSTN. Perhaps you should be reassigned to track some
other standards efforts that are less profoundly uncongenial to you?

> 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 ..."
> 

We dictate in the IETF only what is mandatory to implement, not what is
mandatory to use. I agree with the spirit of what you are saying, however,
which is why we put in the text you cite here.

-----

[next mail]
> A lot of this disagreement is still related to your contention that what
is 
> being described is an "optional practice" like ENUM. I'm sorry, but
regardless 
> of the choice of the English word "SHOULD" in the text, what is being
described 
> is required, if one really wants to complete a pohne call. 

I appealed for direction on this point to the IESG and I am following their
guidance. You have already attempted to persuade the IESG to tell me to do
something else. Are you actually suggesting that I should go against their
recommendation?

-----

[next mail]
> I too have found problems in -05 which were not in -04. I'm writting up
the 
> comments. Regardless of the result of any discussion, I believe it is
necessary 
> to have a new Last Call when that many changes are made. 

The fact that this discussion is taking place, that there is talk of a new
version -06, and so forth indicate that there is an extended period of
review of this draft. Whether or not it is formally a 'Last Call' is
immaterial - we are taking input from the working group on old and new
issues, and integrating comments and corrections into the text as necessary.
However, this is not an invitation for you to fabricate pseudo-problems in
an attempt to further delay the draft for whatever reason (or bandy around
unsubstantiated fear, uncertainty and doubt).

It is possible to string drafts along forever - during the RFC3261 process
it often seemed that would be the case. But as was noted at that time,
"finished is a feature". We will have a chance to revisit these issues in
further iterations of this work - no one expects that sipping-isup-06 will
be the final word on SIP-ISUP interworking. This draft is pretty much good
enough to go for now - if we can smooth out a few more details, I think
we'll have a relatively solid piece of guidance.

_______________________________________________
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