Types & Flaws of OSPF Authentication (to Stop Route Injection & DOS)

OSPF authentication has 3 types.
Type 0 - Null (default)
Type 1 - Simple Password
Type 2 - Cryptic (MD5/SHA)

Let's see how it can be cracked and how it can be  implemented correctly. Authentication is the only protocol level security we can have to secure our OSPF network. Actually in OSPFv2, authentication can only prevent a rouge router from negotiating LSAs to stop route injection & DOS attacks. But still a man in the middle will be able to see the payload of the LSAs which he can compromise the network. Only in OSPFv3, an IPSec tunnel will prevent it happening.

I'm doing it in a simple lab of 2 routers in  area 0, and the wire is sniffed. Let's analyze the packets to see what's really happening in the network layer.
(did't upload initial config files because this is a very simple lab with few basic commands)

Let the 2 routers form adjacency.
Type 0 or Null type is always on by default.
Without doing any authentication configuration, let's capture a Hello packet and analyze them.

You can see the the authentication type is Null (0) and authentication data none.

It means you only need a router configured to match the Hello packet attributes (which u can see) and connect a router to the network to start injecting false routes & carry out a DOS attack.

Let's see about Type 2 now. It can be implemented by issuing the commands,
R1(config-if)#ip ospf authentication
in the interface level or
R1(config-router)#area 0 authentication command in the router config mode, anyhow always the interface level command will over run the router config mode command & the authentication keys and authentication data can only be configured in the interface level.

So if you see something like below in a packet capture,

This is Type 2. Even though it is type 2 you can see authentication data is empty.

It means you only need a router configured to authentication type 2 & match the Hello packet attributes (which u can see) and connect a router to the network to start injecting false routes & carry out a DOS attack.

Now let's see if authentication data is not empty (what if there is a password configured to authentication)
It can be only done in the interface level using the following command after setting the authentication type to 2 like above.
R1(config-if)#ip ospf authentication-key cisco468

The packet will be like this.

Now you can see there is a password and you can clearly see it.

It means you only need a router configured to authentication type 2 & match the password & Hello packet attributes (which u can see) and connect a router to the network to start injecting false routes & carry out a DOS attack.

So basically all above are useless against a hacker. So the correct method will be using the Type 3 with a hashing algorithm.

It can be implemented by issuing the commands,
R1(config-if)#ip ospf authentication message-digest 
in the interface level or
R1(config-router)#area 0 authentication message-digest command.

And the password can be given in interface level by issuing,
R1(config-if)#ip ospf message-digest key 1 md5 cisco321

Capture will be like this

Now the password will not be stated in the packet. Only the hash will be there. So even though the packet is captured it will be hard to crack it. If your platform supports SHA algorithm it is better to use than MD5 as MD5 is again vulnerable to rainbow tables.

Even though the hacker can see the payload of the packet which he can use to build the link state graph to identify the network, he will not be able to do any harm to the network.

So this is the only secure method for doing this. Anything other than this including encrypting the password to level 7 will not defend against a hacker. It can easily be cracked too.

Stop Originating Type 7 LSAs Only in ASBABRs

Let me explain the topic. In the diagram, you can clearly see that the R2 is the ABR. But in this lab it is also the ASBR.

ASBABR = ASBR + ABR

It is redistributing its connected subnet of the loopback 0 to the both area 1 (the NSSA) and area 0. When you enter the redistribute command it will start redistributing to both sides. As LSA type 7 to the NSSA and as LSA type 5 to the area 0.

If you do not want the routers of the NSSA to learn the redistributed routes while only the backbone routers to learn the routes, here is the way to do it.

Configuration files can be downloaded from here.

Let's see the databases of R3 & R1 1st.

We can see the redistributed route is advertised to both areas. To stop it goes to the NSSA just enter the following command in OSPF configuration of R2 which does the redistribution.

R2(config)#router ospf 1
R2(config-router)#area 1 nssa no-redistribution

You can see the databases again to see the effect. LSA type 7 is no longer in the NSSA.

Limit a Summary / Redistributed Route to NSSA (Stop 7/5 Translation)

Type 7 LSA is generated by an ASBR when it redistributes routes to a NSSA.
This LSA contains a "P" bit which tells other ABRs to translate the type 7 LSA into type 5 LSA when the LSA enters area 0.

If the P bit is set to 1 it is allowed for translation and if the P bit is 0 it says do not translate this LSA so that it will only remain in NSSA. This is useful when there are multiple ABRs in the NSSA while you need to traffic engineer the network. By the way, when the ASBR is the ABR it will automatically set this P bit to 0 for its originating type 7 LSAs to stop routing loops.

Configuration files can be downloaded from here.

Quick review of the topology:-
Area 1 is the NSSA, R2 is the ABR and R4 is the ASBR which redistributes its connected subnet of loopback 0 interface 192.168.4.1/32

1st let's look at the databases of R4 & R1

So now you can see that the type 7 LSA which is advertised by the R4 (4.4.4.4) is translated to a type 5 LSA by the R2 (2.2.2.2)

Let's look at the LSA in detail

It says "Type 7/5 translation" which actually means that the P bit is set to 1.
If you want to keep this route only inside NSSA just enter the following command in OSPF configuration of R4 which it is originating.

R4(config)#router ospf 1
R4(config-router)#summary-address 192.168.4.1 255.255.255.255 nssa-only

Now you can see the translation is off. So it will not be learned by the backbone routers.

Drawing OSPF Road Map Manually

Ever wondered how an OSPF Link State Graph or Shortest Path Tree (SPT) will look like? Well this is just modeling the Road Map which can be drawn using the Link State Database of an OSPF process. This is how the router uses self-originated and received LSAs to calculate the best path via a graph.
Download the configuration files from here.


Let's think as the router. He only understand what other routers say via LSAs. I am taking a random router named as R3 (router-id: 3.3.3.3) in a lab network.

Starting form viewing the LSDB which has all the LSAs he can see that there are 6 routers in the OSPF process numbered as 1 in the area 0 which he is also in.

The the SPT is drawn using the Router LSAs.

1st he sees what His own Router LSA says to others.

It says that there are 2 transit networks connected to him. Transit networks are network segments.

Their DRs are 10.0.35.5 and 10.0.34.4 and the Cost is 10 for the routers in those segments.










So the road map from him will start like this.

 Now it's the time to query Network LSAs to find out what those DRs are adjacent or connected with.

Network LSAs say that those DRs are connected to 5.5.5.5 & 4.4.4.4 nodes as well.



So he can continue drawing his map.

It's time to query the Router LSAs received from 4.4.4.4 & 5.5.5.5 to figure out their neighbors, attached links and costs.

Now he can continue drawing his map using these information like before.

Now he queries Network LSAs of new 3 DRs to find out other routers in those segments.

Now the map will be like below.

Now he queries other Router LSAs of 1.1.1.1 & 2.2.2.2 & 6.6.6.6 to find out their networks.

Here this router has a stub network with ip address of 1.1.1.1/32

Its a loopback.

The new DR (10.0.12.2) found from these Router LSAs is connected to 1.1.1.1 & 2.2.2.2 only. Following is its Network LSA.

Now the final diagram will be updated like this.

This is the road map which is used to reach & calculate the costs to all routes in the network. Every router in the same area has a copy of this. But the actual costs in the routing table will be like below.

It will be confusing if we look at the map and try to compare the costs of the routing table to the routes. Actually there is no problem in the map. Its is confusing because of the DRs in the map. They are used to calculate the costs to the network segments only. Because the Network LSAs say which routers are advertising it we can draw a simplified map by removing the DRs now. Then it will be ok.

By the way, the actual physical topology was like this.

Wiretapping IP Phones

It is possible to wiretap IP phones using Wireshark. If you have access to the network switch which the target phone is connected, you can capture packets of that interface and rebuild the conversation using Wireshark software easily.

Here, my target phone is connected to the Fa0/13 of a Cisco switch. And my PC is connected to the Fa0/9.

I need to start a monitoring session to mirror the port Fa0/13 as source and the destination port as Fa0/9 using following commands.

S(config)#monitor session 1 source interface Fa0/13
S(config#)monitor session 1 destination interface Fa0/9

Start a Wireshark capture from the PC & wait for a call. You can see RTP in protocol field when a call is taking place.  (click on the images to see in full size)

When the capturing is over save the capture and go to Telephony --> VoIP Calls

Click on a completed call and click on Player

Click Decode

You will see 2 streams for Rx side and Tx side. Tick a stream and hit Play

Note:- 

Currently supported protocols for VoIP in Wireshark are SIP, H323, ISUP, MGCP & UNISTM. Supported codes are G711 A-Law & G711 u-Law only.

Masking MTU Miss Match In OSPF

MTU is a common OSPF adjacency attribute. Which means that the MTU from both sides (interfaces connected) must be same. Anyhow if it is different from one side a unique problem of forming adjacency occurs.

So the neighbors will flap between in Exstart / Down states.

If the output and errors are like this, most probably the issue is with MTUs. Enter debug ip ospf adj on both routers to gather more information about the issue since this is a adjacency problem.

By reading the output we can easily say that the router with ID 1.1.1.1 (R1) has a lower MTU of 1000 Bytes & the 2.2.2.2 (R2) has the default MTU of 1500 Bytes.

MTU can be manually changed by entering ip mtu <size> command in interface level. But because MTU is a function of physical link you may not be able to change it for most cases. Even if so, you can mask the problem by entering the command ip ospf mtu-ignore in interface level on the lower MTU side so that the adjacencies will happen and the routers will work fine. But it is not a recommended solution because when the router with the larger MTU goes for a flooding event, the router with the lower MTU will not be able to handle it.

So even though you can technically issue the above command to solve the issue it will be never a valid design because it will probably call for more troubles in the future.

OSPF Flood War Caused by Duplicate Router-IDs

If you see this error on a router it means you have 2 or more routers in the same area which has same OSPF router-id configured. Situation is called OSPF flood war.
Router-ID is a unique adjacency attribute which the SPF algorithm use as nodes to solve shortest paths to routes, in the link state graph.

Flood war occours when someone is advertising a route into the network & someone is withdrawing it.

Here a duplicate router advertises networks by LSAs which the other router thinks "old information" which needs to get aged out of it's database.

So the 2nd router reflood the LSA with the maximum age telling everyone to delete it.

This mechanism is there in OSPF because if a router restarts and a connected link of that router is down during the reboot process, and if it received it's old router LSA which advertises it's old link which should not be circulating anymore. So the router floods the LSA with the maximum age telling others to ignore it.

So to troubleshoot this you must log into all routers in same area to see which router shows the same output & change one to a different ID.

Physical Topology of a Logical Diagram with Sub Interfaces

You will find these kind of logical diagrams in some books / tutorials. All routers are connected to each other with sub-interfaces of same interface. This post is to show you how to wire this setup in a physical topology.

In these kind of diagrams, we only see the L3 part (routers). But the actual topology contains a switch.





E0/0 of all routers are connected to the switch in a star topology where the switch is in the middle.

Sub interfaces must be created as 802.1Q trunks from both router end and switch end.

VLANs must be created on the switch for each and every sub-interface network segment.

Configuration

R1(config)#int e0/0
R1(config-if)#no shutdown
R1(config-if)#int e0/0.12
R1(config-if)#encapsulation dot1Q 12
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config-if)#int e0/0.13
R1(config-if)#encapsulation dot1Q 13
R1(config-if)#ip address 192.168.13.1 255.255.255.0

R2(config)#int e0/0
R2(config-if)#no shutdown
R2(config-if)#int e0/0.12
R2(config-if)#encapsulation dot1Q 12
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#int e0/0.13
R2(config-if)#encapsulation dot1Q 23
R2(config-if)#ip address 192.168.23.2 255.255.255.0

R3(config)#int e0/0
R3(config-if)#no shutdown
R3(config-if)#int e0/0.13
R3(config-if)#encapsulation dot1Q 13
R3(config-if)#ip address 192.168.13.3 255.255.255.0
R3(config-if)#int e0/0.23
R3(config-if)#encapsulation dot1Q 23
R3(config-if)#ip address 192.168.23.3 255.255.255.0

SW(config)#vlan 13
SW(config)#vlan 23
SW(config)#int e0/1
SW(config-if)#switchport trunk encapsulation dot1q
SW(config-if)#switchport mode trunk
SW(config-f)#int e0/2
SW(config-if)#switchport trunk encapsulation dot1q
SW(config-if)#switchport mode trunk
SW(config-if)#int e0/3
SW(config-if)#switchport trunk encapsulation dot1q
SW(config-if)#switchport mode trunk

Anyhow, final outputs must be like this,