SIP – ohh my!!

I am sorry that I haven’t been on  for a very long time,  dealing with lots of work, however today, I just wanted to share an experience about  what people do with SIP,  using any Sip Soft-phone and pointing the proxy address to a router registered in a SIP Trunk, Non Authorized individuals can perform outbound calls at your own cost!

This gateway is calling a valid SIP registered number

R2(cfg-translation-rule)#do show sip reg status
Line                             peer       expires(sec) registered P-Associ-URI
=========== === ======= ====== ========
2002                             -1         67           yes

Back to the victim router we get this:

/-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-07178976d20f5e3d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:5001@172.1.1.112:18980>
To: "2002"<sip:2002@cisco.com>
From: "5001"<sip:5001@cisco.com>;tag=092be37d
Call-ID: OWNhNmQ4Mzk3YjY3YzlkZjhhZjY1MzI4OTdiYjVlZTI.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 332

v=0
o=- 1 2 IN IP4 172.1.1.112
s=CounterPath X-Lite 3.0
c=IN IP4 172.1.1.112
t=0 0
m=audio 60372 RTP/AVP 0 8 101
a=alt:1 3 : NP37ITbQ 7Z5WbGrz 213.16.33.139 60372
a=alt:2 2 : Q0JIKunJ uW14UV3u 172.2.1.111 60372
a=alt:3 1 : sKuD8lqI yL6F082u 172.1.1.112 60372
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100
R1(config)#Trying
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-07178976d20f5e3d-1---d8754z-;rport
From: "5001"<sip:5001@cisco.com>;tag=092be37d
To: "2002"<sip:2002@cisco.com>
Date: Wed, 15 Sep 2010 18:41:09 GMT
Call-ID: OWNhNmQ4Mzk3YjY3YzlkZjhhZjY1MzI4OTdiYjVlZTI.
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:2002@6.6.6.6:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2212B1
Remote-Party-ID: "5001" <sip:1001@192.168.3.140>;party=calling;screen=no;privacy=off
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>
Date: Wed, 15 Sep 2010 18:41:09 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2755665842-3224310239-2190538297-1039164110
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1284576069
Contact: <sip:1001@192.168.3.140:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 215

v=0
o=CiscoSystemsSIP-GW-UserAgent 6044 0 IN IP4 192.168.3.140
s=SIP Call
c=IN IP4 192.168.3.140
t=0 0
m=audio 18384 RTP/AVP 0 19
c=IN IP4 192.168.3.140
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2212B1
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>
Date: Wed, 15 Sep 2010 18:16:05 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Timestamp: 1284576069
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2212B1
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>;tag=94CD3D4-BBA
Date: Wed, 15 Sep 2010 18:16:05 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Timestamp: 1284576069
CSeq: 101 INVITE
Require: 100rel
RSeq: 7480
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:6004@192.168.3.136>;party=called;screen=no;privacy=off
Contact: <sip:2002@192.168.3.136:5060>
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.3.140:5060;branch=z9hG4bK2316C4
From: "5001" <sip:1001@6.6.6.6>;tag=12FA79C-2109
To: <sip:2002@6.6.6.6>;tag=94CD3D4-BBA
Date: Wed, 15 Sep 2010 18:16:05 GMT
Call-ID: A441F42A-C02F11DF-8296F639-3DF062CE@192.168.3.140
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 PRACK
Content-Length: 0
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
CANCEL sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-07178976d20f5e3d-1---d8754z-;rport
To: "2002"<sip:2002@cisco.com>
From: "5001"<sip:5001@cisco.com>;tag=092be37d
Call-ID: OWNhNmQ4Mzk3YjY3YzlkZjhhZjY1MzI4OTdiYjVlZTI.
CSeq: 1 CANCEL
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 0

!! hanged the phone here, not believing on what i was seeing !!!

The solution for this Fraud is to configure

R1(config)#access-list 1 permit 192.168.3.0 0.0.0.255
R1(config)#access-list 1 deny any
R1(config)#voice source-group SIPIN
R1(cfg-source-grp)#access-list 1
R1(cfg-source-grp)#^Z
R1#

The access list that is there is to prevent toll fraud. If the SIP message comes in from a SIP server that is not allowed by this acl, the Gateway would reject the call with “500 Internal Server Error”

//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-2b7ae0685139182a-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:5001@172.1.1.112:18980>
To: "2002"<sip:2002@cisco.com>
From: "5001"<sip:5001@cisco.com>;tag=9f2fa51e
Call-ID: ZmRlNmEyNGJlNjU3NmIxNzJmOWI1MjM1NzM4MjUzNjc.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: X-Lite release 1104o stamp 56125
Content-Length: 332

v=0
o=- 9 2 IN IP4 172.1.1.112
s=CounterPath X-Lite 3.0
c=IN IP4 172.1.1.112
t=0 0
m=audio 24758 RTP/AVP 0 8 101
a=alt:1 3 : YfWuKpv6 FtHUNojM 213.16.33.139 24758
a=alt:2 2 : +01pKF2W hOqOjQos 172.2.1.111 24758
a=alt:3 1 : Y3arJ6mi i4oz9+5p 172.1.1.112 24758
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 500
R1#Internal Server Error
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-2b7ae0685139182a-1---d8754z-;rport
From: "5001"<sip:5001@cisco.com>;tag=9f2fa51e
To: "2002"<sip:2002@cisco.com>;tag=110E318-D3C
Date: Wed, 15 Sep 2010 18:07:33 GMT
Call-ID: ZmRlNmEyNGJlNjU3NmIxNzJmOWI1MjM1NzM4MjUzNjc.
CSeq: 1 INVITE
Allow-Events: telephone-event
Reason: Q.850;cause=63
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:2002@cisco.com SIP/2.0
Via: SIP/2.0/UDP 172.1.1.112:18980;branch=z9hG4bK-d8754z-2b7ae0685139182a-1---d8754z-;rport
To: "2002"<sip:2002@cisco.com>;tag=110E318-D3C
From: "5001"<sip:5001@cisco.com>;tag=9f2fa51e
Call-ID: ZmRlNmEyNGJlNjU3NmIxNzJmOWI1MjM1NzM4MjUzNjc.
CSeq: 1 ACK
Content-Length: 0

A Networker Blog

All i want to do is to give the victim a voice.!

Advertisements

MPLS NAT Aware Sample Configurations

 

Internet access is perhaps one of the most popular services that Service Providers offer their customers. Customers have flexibility to purchase MPLS VPN services Internet connectivity from separate Service Providers. Customers can alternatively offer Internet connectivity directly from their network may it be from one of their remote sites or the central site. In the latter case, the Internet Service Provider (ISP) does not need to distinguish customer’s Internet and VPN traffic, because all traffic traversing through a Service Provider network would be MPLS VPN traffic.

In MPLS based BGP-VPNs (RFC 2547),  ISPs offered customers an interface that was capable of carrying intranet and internet traffic.

Traffic between intranet and internet in a MPLS BGP-VPNs requires NAT Services at the customer edge router, between the customer private addresses and a globally routable address.

Traditional NAT operation can be summarized as follows:

  • NAT’s interfaces are classified as either inside or outside interfaces
  • Typically inside interface(s) connect to private address space and outside interface connect to global address space.
  • NAT occurs after routing for traffic from inside-to-outside interfaces.
  • NAT occurs before routing for traffic from outside-to-inside interfaces.
  • Routing information must be populated in the next-hop router for prefixes used in the NAT pool that is used for translation, for routing return traffic.

Topology

R3#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#
R3(config)#ip vrf 23
R3(config-vrf)#rd 23:23
R3(config-vrf)#route-t 23:23
R3(config-vrf)#
R3(config-vrf)#ip vrf 13
R3(config-vrf)#rd 13:13
R3(config-vrf)#route-t 13:13
R3(config-vrf)#
R3(config-vrf)#int s0/0
R3(config-if)#ip vrf for 13
R3(config-if)#ip add 10.1.13.3 255.255.255.0
R3(config-if)#ip nat inside
R3(config-if)#no sh
R3(config-if)#
R3(config-if)#int s0/1
R3(config-if)#ip vrf for 23
R3(config-if)#ip add 10.1.23.3 255.255.255.0
R3(config-if)#ip nat inside
R3(config-if)#no sh
R3(config-if)#
R3(config-if)#int s0/2
R3(config-if)#ip add 10.1.34.3 255.255.255.0
R3(config-if)#ip nat out
R3(config-if)#no sh
R3(config-if)#exit
R3(config)#access-list 1 permit any
R3(config)#ip route vrf 13 1.1.1.1 255.255.255.255 10.1.13.1
R3(config)#ip route vrf 13 0.0.0.0 0.0.0.0 10.1.34.4 global
R3(config)#
R3(config)#ip route vrf 23 2.2.2.2 255.255.255.255 10.1.23.2
R3(config)#ip route vrf 23 0.0.0.0 0.0.0.0 10.1.34.4 global
R3(config)#
R3(config)#ip nat pool MYPOOL 10.1.34.50 10.1.34.255 netmask 255.255.255.0
R3(config)#ip nat inside source list 1 pool MYPOOL vrf 13
R3(config)#
R3(config)#ip nat inside source list 1 pool MYPOOL vrf 23
R3(config)#

Inside to Outside packet flow:

NatIntoOUt

NAT get hold of the packet, and does the translation (static or dynamic) and also stores the VRF table ID in the translation entry.

R3#show ip nat translations verbose
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.1.34.50:5      10.1.23.2:5        4.4.4.4:5          4.4.4.4:5
create 00:00:10, use 00:00:00 timeout:60000, left 00:00:59, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : 23, entry-id: 3, lc_entries: 0
--- 10.1.34.50         10.1.23.2          ---                ---
create 00:16:50, use 00:00:11 timeout:86400000, left 23:59:48, Map-Id(In): 2,
flags:
none, use_count: 1, VRF : 23, entry-id: 1, lc_entries: 0

Outside to Inside packet flow:

image

NAT receives the packet before routing and performs lookup on the translation table. NAT performs the reverse translation, and also sets the VRF table ID in the packet descriptor header. This enables the subsequent route lookup to occur on the right Forwarding Information Block (FIB). If the outgoing interface is in a VRF on the same PE, then the packet is forwarded as an IP packet. If the destination is on a remote PE, then the packet is imposed with labels and forwarded on the core facing interface.

A Networker Blog

%LDP-4-PWD: MD5 protection is required!

MPLS LDP messages (discovery, session, advertisement, and notification messages) are exchanged between LDP peers through two channels:

  • LDP discovery messages are transmitted as User Datagram Protocol (UDP) packets to the well-known LDP port.
  • Session, advertisement, and notification messages are exchanged through a TCP connection established between two LDP peers.

The MPLS LDP—Lossless MD5 Session Authentication feature allows an LDP session to be password-protected without tearing down and reestablishing the LDP session.

Old Style

New Style

R2(config)#mpls ldp neighbor 1.1.1.1 password 123
R2(config)#! 
R2(config-if)#interface Ethernet  1/0
R2(config-if)#  ip address 192.168.1.2  255.255.255.0
R2(config-if)#  mpls ip

R2(config)#access-list 99  permit 1.1.1.1
R2(config)#mpls ldp password required for 99
R2(config)#mpls ldp password option 1 for 99 KC
R2(config)#!
R2(config)#key chain KC
R2(config-keychain)#key 1
R2(config-keychain-key)#  key-string password
R2(config-keychain-key)#!
%LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP

The disadvantage of using the old method is that when new password is required for a session,  this change would require the LDP session to be tear down. With this feature New passwords can be implemented/changed  without having to tear down the existing LDP session

KeyChain4LDP

A Networker Blog

My First EEM Applet Script


Cisco IOS Embedded Event Manager (EEM)
is a powerful tool integrated with Cisco IOS Software for system management from within the device itself. EEM offers the ability to monitor events and take informational, corrective, or any desired action when the monitored events occur or when a threshold is reached. Capturing the state of the router during such situations can be invaluable in taking immediate recovery actions and gathering information to perform root-cause analysis. Network availability is also improved if automatic recovery actions are performed without the need to fully reboot the routing device.

Ok let try to Prevent someone turning off Loopback Zero! 🙂

The Script:

event manager applet Lo0
event syslog occurs 2 pattern "Loopback0, changed state to admin"
action 1.0 syslog msg "Hey Someone shutdown my loopback0 - Turning it back on"
action 1.1 syslog msg "I am a Smart Router, i will turn my lo0 back up again"
action 1.2 cli command "enable"
action 1.3 cli command "configure ter"
action 1.4 cli command "int lo0"
action 1.5 cli command "no shut"
action 1.6 syslog msg "OK should be back up again"

EMMScript

Thanks to The Cisco Learning Network for this tip!

A Networker Blog

MPLS Traffic Engineering

MPLS TE allows the MPLS-enabled network to replicate and expand upon the TE capabilities of Layer 2 ATM and Frame Relay networks. MPLS uses the reachability information provided by Layer 3 routing protocols and operates like a Layer 2 ATM network. With MPLS, TE capabilities are integrated into Layer 3, which can be implemented for efficient bandwidth utilization between routers in the SP network.

image

MPLS traffic engineering automatically establishes and maintains the tunnel across the backbone, using RSVP. The path used by a given tunnel at any point in time is determined based on the tunnel resource requirements and network resources, such as bandwidth.

Available resources are flooded via extensions to a link-state based Interior Gateway Protocol  (IGP).

MPLS traffic engineering is built on the following IOS mechanisms:

  • Label-switched path (LSP) tunnels, which are signalled through RSVP, with traffic engineering extensions. LSP tunnels are represented as IOS tunnel interfaces, have a configured destination, and are unidirectional.
  • A link-state IGP (such as IS-IS) with extensions for the global flooding of resource information, and extensions for the automatic routing of traffic onto LSP tunnels as appropriate.
  • An MPLS traffic engineering path calculation module that determines paths to use for LSP tunnels.
  • An MPLS traffic engineering link management module that does link admission and bookkeeping of the resource information to be flooded.
  • Label switching forwarding, which provides routers with a Layer 2-like ability to direct traffic across multiple hops as directed by the resource-based routing algorithm.

image

All routers need to have the following configuration

image

OSPF must be configured to flood opaque LSA´s.   Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. so thought all devices we configured:

image

the Opaque LSA has a flooding scope associated with it so that the scope of flooding may be link-local (type 9), area-local (type 10) or the entire OSPF routing domain (type 11).  If you look at the ospf database on either of these routers now, you will see and entry for the new LSA types.

image

Each router creates a new Link ID for each link that traffic-eng is configured.

image

here we can see that the Maximum Bandwidth is 193000 bytes, but only 75% is available for bandwidth reservation.

now lets configure a tunnel

image54

here, we can confirm that the tunnel is operational and that it’s a dynamic tunnel

image

The tunnel runs over the directly connected interfaces between R1 and R5 because that’s the shortest path to the tunnel destination.

image

Now let see an explicit path configuration

image

image

A Networker Blog

MPLS LDP Time to Converge

When a link flaps, it could take a long time for LDP to reexchange labels, off course a network can use the FIB in the meanwhile, but this could present several problems with applications that leverage the use MPLS, line MPLS VPN to say at least one. With MPLS LDP Session Protection, we can provide faster LDP convergence when a link recovers from an outage, and this is done maintaining the LDP session for a period of time.

Now when a link fails, we know that in frame mode mpls LDP would store all the labels in the LIB, even if they are not used, this is because the IGP could decide to use another path, but the real problem here, comes into play when the link is recovered, when the IGP determines that the link is available could probably change the next hop is the path to reach the network is better. The problem here is the POP action used in the LFIB table of the router while the LDP tries to establish again the session, adding to our networks, more time to converge, since the LIB might not contain the label from the new next hop, by the time the IGP had converged.

We have 2 ways to solve the convergence issues that we are faced on flapping links, the first solution is to use MPLS LDP Session Protection and the second one is to use MPLS TE make before.

MPLS Fundamentals Book by Luc de Ghen CCIE 1897 states:

A common problem in networks is flapping links. The flapping of links can have several causes, but it is not the goal of this book to look deeper into this. Flapping links do have an important impact on the convergence of the network. Because the IGP adjacency and the LDP session are running across the link, they go down when the link goes down. This is unfortunate, especially because the link is usually not down for long. The impact is pretty severe though, because the routing protocol and LDP can take time to rebuild the neighborship. LDP has to rebuild the LDP session and must exchange the label bindings again. To avoid having to rebuild the LDP session altogether, you can protect it. When the LDP session between two directly connected LSRs is protected, a targeted LDP session is built between the two LSRs. When the directly connected link does go down between the two LSRs, the targeted LDP session is kept up as long as an alternative path exists between the two LSRs. The LDP link adjacency is removed when the link goes down, but the targeted adjacency keeps the LDP session up. When the link comes back up, the LSR does not need to re-establish the LDP session; therefore, the convergence is better. The global command to enable LDP Session Protection is this:

mpls ldp session protection [vrf vpn-name] [for acl] [duration seconds]

A Networker Blog