Restrict SIP dial-peer to trusted source?

[noisey_uk]

I just had the situation where a client's telco was sending inbound SIP calls which did not belong to said client. Therefore the CUBE appeared to be matching these incoming calls to the .T pattern dial-peer and hair-pinning them straight back out. This created a loop and the telco shut down the link! During business hours... awesome! The .T dial-peer has to be there for outbound calls from CUCM. Is there a way that I can restrict that dial-peer so only CUCM outbound calls can match, not erroneous inbound telco ones? NB. the client doesn't have a single block of DIDs and (at the moment) CUCM is used to strip the outbound ANI.

[Vivek Batra]

If you're on newer IOS, there is a feature (using command ip address trust authenticate) where you can program all white list IP address which could be CUCM and service providers IP address. Doing so, router will reject all calls from unknown IP address. 

However it seems that your trusted provider only sending the calls which are not actually destined for your router. If that is the case, above solution won't work.

Either you need to have your dial-peers more specific so that it can identify the call path OR try to use CoR. I assume you will be having inbound dial-peer (for CUCM to CUBE) and outbound dial-peer (for CUBE to SP). Prepare CoR in a way and assign to inbound dial-peer (CUCM to CUBE) so that it can access only outbound dial-peer (CUBE to SP).

Please note that now you should have two inbound dial-peer for calls from SP to CUBE. One is the desired dial-peer for genuine calls. These calls will be forwarded to CUCM. We should have CoR here which can access the outbound dial-peer (CUBE to CUCM). Now second inbound dial-peer (SP to CUBE) which should match all remaining numbers and that is what we want. Assign CoR to this dial-peer in a way it can't access any other dial-peer.

- Vivek

[noisey_uk]

Thanks for your response Vivek. The toll fraud prevention "ip trust authenticate" is configured but that only guards against a rogue SIP peer - the telco's SBC is a trusted address and they erroneously pushed a number to the client's SIP trunk. Difficult to create additional dial peers as CUCM strips the ANI... so what do you match on? Altering the design to apply privacy at the CUBE and then creating the additional dial peers could be an option, but it strikes me as a bit messy as it would create a lot of additional dial peers. I wondered whether maybe the max-forwards SIP header might be a cleaner solution?...

[Vivek Batra]

Most cleaner solution in my opinion is to force your ITSP not to deliver such calls to your gateway.

I'm not sure how max-forward will help here as its default value is 70 and when gateway receives call viz both genuine and unintended call, both INVITEs will be carrying same value of max-forward. So no specific identification.

- Vivek

[noisey_uk]

How can I force them? Go to their houses with a baseball bat? ;) They shouldn't have delivered the call but did due to an error on their part. I need to guard against it occurring in the future.

My thought on the Max-Forwards header was this:

Initial erroneous call from SP > CUBE, SIP Max-Forwards header states 70

Hits .T dial-peer on CUBE. CUBE decrements SIP Max-Forwards header by 1

Forwarded call from CUBE > SP, SIP Max-Forwards header states 69

Hits erroneous dial-peer at SP. SP decrements SIP Max-Forwards header by 1

Forwarded call from SP > CUBE, SIP Max-Forwards header states 68

... and so on.

Or doesn't the Max-Forwards mechanism operate in this manner?

[Vivek Batra]

How can I force them? Go to their houses with a baseball bat? ;) 

I wouldn't mind if you do this. They can't get away from their responsibility.

Initial erroneous call from SP > CUBE, SIP Max-Forwards header states 70

Hits .T dial-peer on CUBE. CUBE decrements SIP Max-Forwards header by 1

Forwarded call from CUBE > SP, SIP Max-Forwards header states 69

Hits erroneous dial-peer at SP. SP decrements SIP Max-Forwards header by 1

Forwarded call from SP > CUBE, SIP Max-Forwards header states 68

... and so on.

So do you want CUBE to loop the same call 70 times? I'm not sure how good this option will work for you but otherwise you can try shorten the value of max-forward to 2 using SIP profiles to avoid looping. However if your service provider has multiple proxies in their network, genuine call may also fail.

- Vivek

[Aaron Harrison]

Hi 

There's a bunch of stuff you can do. I set up several kinds of security on the CUBEs I deploy, from ACLs, to trust lists, to dial-peer lock and key, to obscured routing prefixes for external access and so on.

In your case you want the lock and key/dial-peer CoR feature.

Set up dial-peer CoRs so that the inbound peers that receive calls from the service provider can ONLY access peers that point inwards to CUCM; and those CUCM peers should match your known/expected DDI ranges.

Set up the inbound dial-peers that come from CUCM in the same way so that they can only access the outbound .T peer.

That way no calls can loop; outsiders can't send calls in with or without external access prefixes and expect them to go anywhere. They'll go to CUCM if they are your numbers, or they'll get rejected.

Aaron

[Adam Pawlowski]

CoR can work but it is a bit of a pain. I've also run into issues with stacking features into the IOS voice router, and having to try and figure out why something is going where and dig into the peer matching because the peer targets are so generic, is probably not worth your time.

There is a reason that prefixing is a popular concept when gateways are involved.

The way I've been setting up ours, however, is to treat the IOS router as our voice "core" device, not the communications manager. A bit more effort is required but refining call routing pays off in the long run.

I have set up a e164-pattern-map class and applied it to my UCM dial peers. That is a flat file that includes your e164 destination patterns for your DIDs, and a single dial peer that then "matches" any of these destinations after the map is applied and loaded. Then, it won't match ".T" which is not a good idea for the reasons we see here.

The IOS router will answer with the needed cause codes to the ITSP, instead of throwing things into the UCM when they don't need to even go near that.

If you end up with other SIP services, one-off peering items, etc, you can then push them up to this IOS gateway instead of running trunks through the UCM, if that's how you would run your topology.

COR also works to create "conduits" between peers most of the time but it is a pain.

[Aaron Harrison]

Hi Adam

Sure - my '.T' does exist, it's a prefixed pattern to access the PSTN.

Pointing at CUCM would be specific DDI ranges; as these are known. 

So it's not dissimilar to your setup... CoR I find simplifies things; it reduces the potential number of dial-peers you need to consider. Depends on your thought process I guess? 

Aaron

[Ayodeji Okanlawon]

I have had similar issues in the past and I think you can just tell CUBE to stop hunting on un allocated number.. Basically when CUBE receives the call, it sends to cucm, CUCM sends a 404 not found, then CUBE hunts to the next dial-peer which is the outbound dial-peer to your ITSP (due to your .T), hence this creates a loop. This is part of the reason why using this approach to dial plan is not recommended. (.T is a bad idea)

You can tell CUBE to stop routing the next dial-peer when it receives a 404 not found. Here is what you should try..

conf t

no voice hunt unassigned-number
no voice hunt invalid-number
no voice hunt user-busy

[Jonathan Els]

Excellent suggestion!

[Jonathan Els]

Hi Noisy

If you you want granular control over this feature (disclaimer - punting my own blog post):

http://afterthenumber.com/2015/12/07/implementing-loop-prevention-on-cube/