Subject: [Sipping] Re: mike pierce issue summary (item #1)

From: [email-masked]
Date: Fri, 16 Aug 2002 17:28:47 EDT

In a message dated 8/15/02 5:11:13 PM Eastern Daylight Time, 
[email-masked] writes:

> > [MAP] 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. 
> 
> [JP] This is a hostile reading of the text, which actually says 'the 
> telephone
> 

[MAP] It could have been an incorrect reading of the text, but it certainly 
wasn't "hostile". I read it with no emotion.

I was commenting on the new text in -05 which states "no known risk is 
associated with end-users having arbitrary control over the value of the 
Carrier Identification Code or Transit Network Selection parameter and the 
telephone number portion of the Called Party Number field; these fields are 
already set directly by the user today". I don't think I misread that. I 
believe it contains 2 incorrect statements which is what I commented on.

There is certainly a security risk in allowing a user to directly set any 
value in the ISUP message which will then be processed in the PSTN. No 
carrier allows it today, to my knowledge. If any carrier claims they do, I 
can be sure that their network isn't secure.

> > [MAP] 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.
> > 
> 
> [JP] 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. 
> 

If a SIP user puts something in an INVITE that looks like an encapsulated 
IAM, the egress gateway would pass it to the PSTN. The user could have set 
the NoA and every other field in it. Again, this leads to the conclusion that 
the egress gateway "MUST" authenticate every INVITE (and every other message).

On the other hand, there is a statement in Section 7.2.1.1 that the values of 
SIP headers "MUST" overwrite the parameter values (in the encpasulated ISUP). 
Doesn't this allow the contents of a SIP header to modify the NoA if the 
number in the header is a different form?

No, there won't be a SIP URI for INWATS, but such a number could be used 
within the Callled Party Number in some network and only intended to be 
passed between gateways (in encapsulated IAM). A user can't be allowed to 
enter it.

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 18 Aug 2002 21:51:53 -0400

If operators elect to have some privileged, unreachable phone numbers in
their network, they had better install some policies to make sure that users
cannot send requests to them - this could apply equally well to 'private'
carrier identification codes, I suppose. But I don't think this means that
there are huge risks that result from the fact that users can signal
telephone numbers or enter 101+XXXX CICs. What I meant was that users
suggest values for particular fields in the CPN or TNS parameters (the
telephone number part and CIC part, respectively); I will make sure the text
states clearly that users do not arbitrarily populate these parameters. Of
course we agree it would be bad if users could arbitrarily set ISUP
parameters. The security considerations resulting from encapsulation, by the
way, are dealt with in other documents (see sipping-sipt-04).
 
In answer to your question about 7.2.1.1, if the CPN parameter is
overwritten, a new CPN parameter will be created as described in 12.2 -
while that means that the user influences how the NoA is set in the CPN, it
doesn't mean that users somehow signal the bytes that will be used in the
NoA, or something.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 16, 2002 2:29 PM
To: [email-masked]; [email-masked]
Subject: Re: mike pierce issue summary (item #1)

messages, 
does 

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

use 

these 

If a SIP user puts something in an INVITE that looks like an encapsulated
IAM, the egress gateway would pass it to the PSTN. The user could have set
the NoA and every other field in it. Again, this leads to the conclusion
that the egress gateway "MUST" authenticate every INVITE (and every other
message). 

On the other hand, there is a statement in Section 7.2.1.1 that the values
of SIP headers "MUST" overwrite the parameter values (in the encpasulated
ISUP). Doesn't this allow the contents of a SIP header to modify the NoA if
the number in the header is a different form? 

Mike Pierce 
Artel

---

From: Al Varney <[email-masked]>
Date: Sun, 18 Aug 2002 23:22:05 -0500

At 09:51 PM 8/18/02 -0400, Peterson, Jon wrote:

>their network, they had better install some policies to make sure that 
>users cannot send requests to them - this could apply equally well to 
>'private' carrier identification codes, I suppose. But I don't think this 
>means that there are huge risks that result from the fact that users can 
>signal telephone numbers or enter 101+XXXX CICs. What I meant was that 
>users suggest values for particular fields in the CPN or TNS parameters 
>(the telephone number part and CIC part, respectively); I will make sure 
>the text states clearly that users do not arbitrarily populate these 
>parameters. Of course we agree it would be bad if users could arbitrarily 
>set ISUP parameters. The security considerations resulting from 
>encapsulation, by the way, are dealt with in other documents (see 
>sipping-sipt-04).

    It's not the operators that "elect" private carrier identification 
codes for their own networks.  The owner of a code gets to state whether 
one of their codes is "dialable" or not from every OTHER network.  Thus 
EVERY operator has to screen those codes.  In the US, the same applies to 
numbers that are designated (by NANP Administrator) as non-dialable.  An 
NXX of 059, for example, is blocked by exchanges today, when entered from 
an access interface (analog line, ISDN BRI/PRI.  But it might be a 
perfectly valid inter-network number for routing calls between operators.

    I think you are suggesting this "dialable code" screening applies to 
SIP-originated calls as well.  But since other networks must be allowed to 
send calls non-dialable numbers/TNS into a network, the receiving network 
cannot, via policy, screen out those dialed by users from those generated 
internally by the other network.  Thus screening for such numbers/codes is 
pushed out to all network operators.  (In effect, networks have 
numbers/codes they can use for internal inter-network purposes, but block 
from all users.)

    However, the text should make it clear that, in SIP-bridging 
situations, a SIP agent between the ISUP nodes could perform "intelligent 
network" functions.  This could include changing the TNS/CarrierCode and 
the Called Party Number even to values that users cannot dial.  So a 
gateway that's mapping SIP information into IAM parameters might have to 
screen in a restrictive manner IF the SIP INVITE is from an "end-point" and 
a less restrictive manner if the INVITE is from a prior ISUP-SIP gateway 
with valid IAM encapsulated.

    Does that make sense?

Al Varney

_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Aug 2002 07:06:22 -0500

This is a point you've raised before in a couple of mails, the idea that
gateways should somehow differentiate between trusted and untrusted SIP
entities when determining how to perform their SIP-ISUP mappings. I believe
Mr. Pierce, for one, has some sympathy with your viewpoint here. While I
don't want to rule this out entirely, I don't think we need to give it a
whole lot of attention in sipping-isup-0x either.

Our goal in this particular draft is to define gateway behavior. Gateways
may want to enforce arbitrarily policies on behalf of their operators. We
recommend that gateways perform authentication in the draft, but we are
decidedly silent on authorization  - once you know who is sending a request
to a gateway, what policies do you enforce based on the identity of the
originating party? The authors envision that such policies could vary widely
between nationalities and/or networks, and there doesn't seem to be any need
to standardize these policies. These policies might entail anything from
restricting access to particular target numbers, to forwarding calls to
special treatment, debit functions, and so on - I doubt that one size fits
all.

What we will note in the Security Considerations of -06 is the possibility
that some phone numbers or carrier IDs could be privileged - what particular
policies should address that is not our concern, I think. We'll try to
phrase this in a way that is informed by your (as always, valuable) insights
below.

Jon Peterson
NeuStar, Inc.

> From: Al Varney [mailto:[email-masked]]
> Sent: Sunday, August 18, 2002 9:22 PM
> To: [email-masked]
> Subject: Re: [Sipping] RE: mike pierce issue summary (item #1)
> 
>

---

From: Al Varney <[email-masked]>
Date: Mon, 19 Aug 2002 09:30:34 -0500

>entities when determining how to perform their SIP-ISUP mappings. ...
>
>originating party?

    I agree, enforcement (or behavior in general) based on the identity of 
sender is a more flexible mechanism than my simplistic "end-point" vs. 
"bridge-point" dichotomy.  Your proposal sounds good to me.

    By the way, your use of "originating party" above has a particular 
interpretation in a ISUP context -- it can be a synonym for "calling party 
number".  I think you meant it to mean the identity of the node generating 
the incoming SIP messages, which could be some SIP agent downstream from 
call origination.

    As I understand it, from a policy perspective, it's the sender of the 
message (the incoming INVITE) whose identity you FIRST want to authenticate 
for purposes of determining acceptance/believability of SIP content 
(including the identity of any "calling party number", encapsulated ISUP or 
identity of prior SIP proxy nodes).  Once that is complete, a gateway MAY 
alter behavior based on the calling party number, encapsulated ISUP 
parameters, etc.  Or, for some senders, it may assume that preceding node 
has done all needed calling party/SIP proxy screening.

    (This loosely corresponds to the two levels of "policy" applied in 
current ISUP exchanges; incoming messages are verified based on rules 
associated with the incoming circuit, and then further handling may be 
based on the actual calling party number.)

Al Varney

---

From: Michael Hammer <[email-masked]>
Date: Mon, 19 Aug 2002 12:39:42 -0400

Al,

If I read you correctly, the two steps are:

1) Validate that the data in the message is not bogus,
2) Apply policy and make decisions base on that data.

Step one means that either all data in the message must be authenticated or 
you are trusting that the previous node has done this for you, i.e. you 
trust the previous node.  I would not rely on any statement that suggested 
that the end-user does not have the knowledge to construct any SIP header 
or any encapsulated ISUP body.

Step two means that every data element must be screened and authorized or 
changed at ingress to the service provider network, unless you can rely on 
a previous service provider to do that for you based on some agreement.

The basic security mechanisms should be well-known.  The specific policy 
decisions are implementation.

Mike

At 09:30 AM 8/19/2002 -0500, Al Varney wrote:
> interpretation in a ISUP context -- it can be a synonym for "calling 
> party number".  I think you meant it to mean the identity of the node 
> generating the incoming SIP messages, which could be some SIP agent 
> downstream from call origination.
>
> message (the incoming INVITE) whose identity you FIRST want to 
> authenticate for purposes of determining acceptance/believability of SIP 
> content (including the identity of any "calling party number", 
> encapsulated ISUP or identity of prior SIP proxy nodes).  Once that is 
> complete, a gateway MAY alter behavior based on the calling party number, 
> encapsulated ISUP parameters, etc.  Or, for some senders, it may assume 
> that preceding node has done all needed calling party/SIP proxy screening.
>