Subject: Re: [Sipping] Comments on Overlap Security Considerations

From: [email-masked]
Date: Fri, 2 Aug 2002 14:11:03 EDT

In a message dated 8/1/02 3:46:21 PM Eastern Daylight Time, [email-masked] 
writes:

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

Fair question. I suspect there is not currently an easy answer, but it 
appears to me that this quandry is the root of many problems related to 
security and other issues for PSTN interworking. Of course, all INVITEs 
"originate" in the IP world. The question is whether it originates from 
another trusted gateway (which could be trusted to behave properly and 
allowed to do certain things) or from an end user in the IP world (who should 
not be trusted and should not be allowed to do those things). Unless this is 
solved, I see a lot of difficulty with interworking.

If one's model is a limited set of Gateways connected to the Internet, with 
those GWs constituting a "service provider" (or a set of cooperating Service 
Providers), then there would be a trust relationship established between 
them, so that the INVITE includes the necessary identification and 
authentication credentials so that the receiving GW knows it came from an 
authorized originator, i.e., a trusted GWs. Lack of these credentials means 
it did not. My comments address this model.

If one's model is an unlimited number of Gatways belonging to anyone who 
wants to claim to provide "gateway" service out of their garage, then I guess 
it is a little more complex. While maybe this should be supported, it 
requires a different approach to security, maybe what is described in the 
draft. There should still be the notion of determining that the INVITE came 
from such an "untrusted" IP end user (who claims it is a GW). But then, in 
that case, a destination GW should be able to refuse to handle overlap from 
one of those originating devices, since it can't be trusted to do it 
correctly. (A destination "Service Provider" GW might refuse to handle any 
traffic from such a "gateway", or at least handle it very differently, since 
there may be lots of other security, privacy, regulatory, billing, 
performance concerns anyway.)

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 5 Aug 2002 07:29:08 -0500

A few notes on the overlap security considerations:
 
1) Yes, the new text in the Security Considerations considers a case in
which an attacker has control over a normal SIP user agent (not a gateway)
and uses it to send calls with incomplete addresses en masse (by the tens of
thousands, let's say) to a gateway. The point of this passage is to use a
credible attack to illustrate the rather obvious truth that unless the
gateway challenges and authenticates these INVITE requests, anyone with a
SIP user agent will be able to fill up quite a few ports on a gateway
indefinitely by sending a few calls destined for an incomplete address. I
agree that the need for a gateway to authenticate callers is not specific to
overlap signaling - but I think the unusual properties of overlap signaling
(calls that exist in some limbo state between initiation and completion) do
warrant special mention of authentication. Authentication would even also
allow the gateway to ascertain whether or not this is an ISUP-SIP-ISUP call,
if it turns out that information is useful, as you say it might be.
 
2) Suggesting a limit on the number of simultaneous "hung" IAMs (either on a
per-source basis or globally for the gateway) provides an additional
safeguard against port saturation. I don't think the draft needs to
recommend any hard number (maybe a percentage of ports would be more
plausible), but I do think this is a useful concept. If any single source
sends you a thousand calls to incomplete addresses in a row, I think a
gateway would be justified in refusing the thousand-and-first regardless of
what the authentication data says (a legitimate authenticated source could
just be malfunctioning, after all). It probably won't be clear to the
gateway until after it sends an INVITE, and fails to receive an ACM, that
this is an overlap signaling call.
 
3) I do feel that the sort of denial of service that would result from port
saturation if the gateway does not authenticate requests is categorically
more damaging than any SIP signaling flood at the gateway, whether or
results from authentication or not. Tying up physical resources arbitrarily
(which prevents the gateway from receiving calls as well as sending them)
would require an attacker to send very few messages (one per gateway port,
which would be quite a small number) - a much easier attack than spamming
the gateway with enough garbage to stop up its interfaces. Moreover, RFC3261
has some reasonably enlightened approaches to authentication overhead
(stateless challenges, etc) that have rendered the authentication process as
lightweight as possible.
 
Finally, I'd like to note that these textual changes came in response to
comments from the Security Area Directors on the draft.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 01, 2002 9:22 AM
To: [email-masked]
Subject: [Sipping] Comments on Overlap Security Considerations

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: [email-masked]
Date: Mon, 5 Aug 2002 12:42:40 EDT

In a message dated 8/5/02 8:30:39 AM Eastern Daylight Time, 
[email-masked] writes:

1) Yes, the new text in the Security Considerations considers a case in which 
an attacker has control over a normal SIP user agent (not a gateway) and uses 
it to send calls with incomplete addresses en masse (by the tens of 
thousands, let's say) to a gateway. The point of this passage is to use a 
credible attack to illustrate the rather obvious truth that unless the 
gateway challenges and authenticates these INVITE requests, anyone with a SIP 
user agent will be able to fill up quite a few ports on a gateway 
indefinitely by sending a few calls destined for an incomplete address. I 
agree that the need for a gateway to authenticate callers is not specific to 
overlap signaling - but I think the unusual properties of overlap signaling 
(calls that exist in some limbo state between initiation and completion) do 
warrant special mention of authentication. Authentication would even also 
allow the gateway to ascertain whether or not this is an ISUP-SIP-ISUP call, 
if it turns out that information is useful, as you say it might be.

[MAP] Yes, you describe a credible attack, but not one unique to overlap. 
Whether using overlap or not, a mis-behaving user is able to tie up one, but 
no more than one, port with each message. Overlap only allows (currently) 
tying up multiple ports with one call, but it requires multiple INVITEs.  
There is no way to tie up multiple ports with one message as your comment 
suggests. (If there were, I would be a lot stronger in my objection to the 
current description of overlap!)

Incidentally, the comments I have made on this draft are to change the 
procedures so that there could never be more than one IAM (and port tied up) 
per call origination.

Regarding the notion that a port can be tied up "indefinitely": Q.764 
requires that an international exchange handling overlap set a "Network 
Protection Timer" (T7) every time it sends an address message forward. This 
is 20-30 seconds, after which the call is released. An egress GW should be 
considered as being an "incoming international exchange", therefore, its 
operation must include this timer. The interconnected PSTN would require 
this, or it would apply the timer at its first switch,  for its own 
protection.

2) Suggesting a limit on the number of simultaneous "hung" IAMs (either on a 
per-source basis or globally for the gateway) provides an additional 
safeguard against port saturation. I don't think the draft needs to recommend 
any hard number (maybe a percentage of ports would be more plausible), but I 
do think this is a useful concept. If any single source sends you a thousand 
calls to incomplete addresses in a row, I think a gateway would be justified 
in refusing the thousand-and-first regardless of what the authentication data 
says (a legitimate authenticated source could just be malfunctioning, after 
all). It probably won't be clear to the gateway until after it sends an 
INVITE, and fails to receive an ACM, that this is an overlap signaling call.

[MAP] The problem with applying limits: for any definition of a limit based 
on "source" and "similar calls", after which the network rejects 
calls,someone will come up with a valid case for that traffic pattern. The 
PSTN can not indiscriminately block calls. It is incorrect to think that a 
device at the terminating side can properly apply a limit based on the 
"source".  In the network architecture I am interested in, and on which my 
comments are based, this must be the responsibility of a device at or near 
the source. I understand that, in the network architecture others are 
interested in, there is no device near the source to provide this protection. 
But this problem, and its solution, is not unique to overlap and, I believe, 
completely unaffected by it.

3) I do feel that the sort of denial of service that would result from port 
saturation if the gateway does not authenticate requests is categorically 
more damaging than any SIP signaling flood at the gateway, whether or results 
from authentication or not. Tying up physical resources arbitrarily (which 
prevents the gateway from receiving calls as well as sending them) would 
require an attacker to send very few messages (one per gateway port, which 
would be quite a small number) - a much easier attack than spamming the 
gateway with enough garbage to stop up its interfaces. Moreover, RFC3261 has 
some reasonably enlightened approaches to authentication overhead (stateless 
challenges, etc) that have rendered the authentication process as lightweight 
as possible.

[MAP] Yes, an attacker can tie up all the ports by sending one message per 
port, whether using overlap or not. It is only a question of how long each 
can be tied up. As overlap is currently defined (I believe), they could tie 
up each port "indefinitely". If the "protection timer" as required in Q.764 
is used, they could tie up each port no more than 30 seconds. If overlap is 
not used and the mis-behaving user makes calls to a valid number which is 
known to never answer, then they could tie up each port for 3 minutes (if the 
optional answer timer is used) or indefinitely (if the timer is not used). So 
en-bloc could be worse than overlap in this regard.

[MAP] Yes, the document needs a security section, but it should address 
issues unique to overlap, not try to solve the general problem. I personally 
don't see any security problems unique to overlap (if the other problems are 
fixed).

Jon Peterson
NeuStar, Inc.

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: "Peterson, Jon" <[email-masked]>
Date: Mon, 5 Aug 2002 22:29:56 -0400

A few more comments inline.

Jon Peterson
NeuStar, Inc.

> Sent: Monday, August 05, 2002 9:43 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Sipping] Comments on Overlap Security Considerations
> 
> 
[snip]
> procedures so that there could never be more than one IAM (and port tied
up) 

Yes, and comments you have made elsewhere indicate that your discomfiture
with this idea is not restricted to overlap. I might conjecture that your
real problem is with the whole idea in SIP that a user agent can signal
multiple call setups at the same time (via forking, etc). This is an
essential feature of allowing a user-controlled station to participate in a
signaling network. Certainly if you gave a handset the ability to send SS7,
the results would be disastrous, which is why a slave protocol (Q.931) was
devised, a specifically untrusted protocol, that connects user devices to a
provider-controlled switch. We SIP people, of course, believe that the lack
of cryptographic properties and modern AAA necessitated that segregation in
the antique PSTN, and that with these tools in place, it is feasible to
construct a network of equals. From your posts I guess you believe this
confidence to be misplaced.

In any event, if you have a beef with this basic capability for a user agent
to signal multiple call setup attempts, you should be addressing your
comments to RFC3261, not this overlap draft.

> this, or it would apply the timer at its first switch,  for its own 

It is probably sensible advice to have such a timer, sure. We depict the use
of the T7 timer already in the main SIP-ISUP draft.

[snip]

> "source".  

This skepticism would need to be substantiated to be credible.
Authentication allows one to identify a source device (an originating SIP
user agent). Authorization policy can allow one to restrict the number of
overlap-signaled requests accepted from a given source device.

Your assessment that the PSTN cannot 'indiscriminately block calls' also
seems a little generous to me (automatic call gapping comes to mind, for
example).

[snip]

> is used, they could tie up each port no more than 30 seconds. 

Alternatively, an unauthenticated source that attempts to set up a call
using the overlap mechanism would tie up system resources only very briefly
(for less than a second overall, anyway) once it failed to provide valid
credentials. This section is intended to encourage the authentication of
overlap signaled requests.

> If overlap is 

True, this is also an credible general threat against gateways. But the
existence of this threat does not somehow preclude us from sketching the
other threat mentioned above, right?

On an academic point, there are small differences between these threats. A
gateway operator that authenticates originating parties might have any
number of ways of settling for access to their devices. Some gateway
operators will charge for the consumption of any port, regardless of the
state of the call (similar to how wireless operators charged for use of the
air interface). Perhaps some gateway operators would be inclined to use
receipt of an ACM as a billing trigger - in the draft-ietf-sipping-isup
state machine, there is a distinction between the state where IAM is sent
and where ACM is received. The circumstances of an overlap signaled call
differ from those of an unanswered call in at least that respect.

> don't see any security problems unique to overlap (if the other problems
are 

Specifically, we were asked by the Security Area Directors to comment on any
potential port saturation issue arising from the use of overlap mechanisms
by an attacker. Generally, reviewers get nervous when they read the
following text in Security Considerations: "This draft introduces no
security concerns above and beyond the concerns raised in [base protocol
RFC]."

I'd also like to reiterate that the "other problem" (i.e. multiple
call-setup requests) that you would like fixed is a base protocol "bug".

---

From: Michael Hammer <[email-masked]>
Date: Wed, 07 Aug 2002 13:26:13 -0400

Jon,

Even the base RFC-3261 has timer T1 to limit the number of retransmissions 
of INVITEs and thus minimizes the work of downstream entities.  Although 
that is worried more about unreliable transports, could not the same 
general principle be applied to overlap?  That is, could an option for a 
timer be used that quarantines SAMs for some configurable amount, such that 
fewer INVITEs are generated at the originating ISUP-SIP GW?  While this 
does not preclude multiple INVITEs, it at least migiates the amplification 
effect.

Mike

p.s. comparisons to the forking situation are off-base, as I think that the 
INVITEs downstream from the forking point should not be targeting the same 
terminal, whereas in the overlap case the multiple INVITEs do target the 
same terminal.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 7 Aug 2002 12:42:26 -0500

I believe Mr. Pierce is concerned in this instance about the effects of the
other direction in an overlap flow - the SIP-ISUP direction, rather than the
ISUP-SIP direction; presumably the SIP-ISUP direction is only a cause for
concern in full ISUP-SIP-ISUP bridging since ordinary SIP UACs will not
instigate overlap signaling. So multiple IAMs, not multiple INVITEs. The
comparison to the effect of forking when SIP-ISUP gateways are in use has
been drawn by Mr. Pierce outside this mailing list.

The one thing that Mike and I seem to agree on is that the use of an overlap
mapping mechanism is discouraged, and that ISUP-SIP gateways should convert
overlap to en-bloc before passing calls to the SIP network. Doing so would
follow roughly the procedures you recommend below (delaying INVITE
transmission to collect SAMs according to the ISUP T10 timer).

Jon Peterson
NeuStar, Inc.

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Wednesday, August 07, 2002 10:26 AM
> To: Peterson, Jon
> Cc: [email-masked]'; [email-masked]
> Subject: RE: [Sipping] Comments on Overlap Security Considerations
> 
> 
> Jon,
> 
> > > procedures so that there could never be more than one IAM 
> (and port tied
> >up)
> > > per call origination.
> > >
> >
> > > Protection Timer" (T7) every time it sends an address 
> message forward.
> >This
> > > [MAP] The problem with applying limits: for any 
> definition of a limit
> >based
> > > can be tied up. As overlap is currently defined (I 
> believe), they could
> >tie
> > > up each port "indefinitely". If the "protection timer" as 
> required in
> >Q.764
> > > known to never answer, then they could tie up each port 
> for 3 minutes (if
> >the
> > > optional answer timer is used) or indefinitely (if the 
> timer is not used).
> >So
> > > don't see any security problems unique to overlap (if the 
> other problems
> >are
> > > fixed).
> > >
> >

---

From: Michael Hammer <[email-masked]>
Date: Wed, 07 Aug 2002 14:02:48 -0400

I was also concerned about the multiple IAMs.  Just trying to ask the 
originating side to behave somewhat, rather than resolving at receipt for 
the overlap case.

The other problem is "attacks" from users originating in the SIP network, 
which is a pure SIP problem having little to do with overlap, except 
perhaps trying to kill both birds with one stone.

Mike

---

From: [email-masked]
Date: Thu, 8 Aug 2002 12:20:30 EDT

In a message dated 8/5/02 10:30:55 PM Eastern Daylight Time, 
[email-masked] writes:

> with this idea is not restricted to overlap. 
> 

[MAP] To be honest, yes I have a discomfiture with this idea. And my 
discomfort is not being eased by what I am hearing about how regular 
telephone calls will be handled.

<snip>

> security concerns above and beyond the concerns raised in [base protocol
[MAP] I'm simply trying to make the point that overlap does not add any 
additional security requirements or concerns. Everything that has been 
mentioned ("port saturation") is equally a problem without overlap, so it 
must be addressed in other documents. The security statement in the overlap 
draft should reflect this fact. (I think I showed that, because of the 
timeouts that must be used with incomplete numbers, overlap is actually less 
of a problem than en-bloc in this regard.)

The description needs to be in a draft which covers the "regular" case 
(en-bloc). I suppose that is SIP-T (which somehow this overlap draft doesn't 
reference). Currently, SIP-T, ISUP to SIP, and SIP do not talk about this 
security concern of part saturation. Once this description is put someplace 
where it clearly shows the need to do significant security procedures for 
every "regular" call between any two users in the world whenever the call 
interworks to the PSTN, maybe other will start to have the same discomfort I 
have.

Mike Pierce
Artel