Source based routing??

[jonseung]

Hi,

I ran into a siutation where I had to create a static route based on the source. I enabled ip source route but I'm not sure how this should be entered into the router.

i.e I need two static routes for;

Any traffic to 0.0.0.0 from 10.0.0.0/8 to be routed to A

Any traffic to 192.0.0.0 from 10.0.0.0/8 to be routed to B

Thank you in advance for your prompt response.

[Giuseppe Larosa · Accepted solution]

Hello Jon,

you need to use Policy Based Routing to achieve this:

ip access-list 11 permit 10.0.0.0 0.255.255.255

ip access-list 111 permit ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.255.255

route-map pbr_net10 permit 10

match ip address 111

set ip next-hop B

route-map pbr_net10 permit 20

match ip address 11

set ip next-hop A

then you need to apply this on the interface(s) that receive the traffic to be policy routed

example

int gi0/0

ip policy route-map pbr_net10

PBR is supported also on multilayer switch.

Additional tuning can be provided by next-hop verify-availability but this is not supported in all platforms

you still need one or more default static routes pointing to next-hops:

ip route 0.0.0.0 0.0.0.0 next-hop-A

eventually if needed

ip route 0.0.0.0 0.0.0.0 netxt-hop-B

Hope to help

Giuseppe

[jonseung]

Giuseppe,

This is exactly what I needed.

Thanks for your response.

[Peter Paluch]

Hello Jon,

Giuseppe has provided a perfect explanation and solution suggestion. Allow me to add just one more comment: The source routing you were originally talking about is concerned with a sender specifying the entire path that a packet should go over hop-by-hop in the packet's header header. As you can see, it is something different than what you actually wanted - to make routing selection based on something other than just the packet's destination.

The source routing is used very rarely today (in fact, I have never used it myself and I have never seen anyone utilizing it). If you have turned it on on your router, I suggest you turn it back off, as it is often considered a potential security threat.

Best regards,

Peter

[Joseph W. Doherty]

"The source routing is used very rarely today (in fact, I have never used it myself and I have never seen anyone utilizing it). If you have turned it on on your router, I suggest you turn it back off, as it is often considered a potential security threat. "

I've used IP source routing on multiple (rare) occasions using Cisco extended ping/traceroute options (I think it's available in both, but don't have, at the moment, a box to check against.) Can be of benefit investigating certain network performance issues.

It's useful when there are multiple paths, and you need to insure your packets flow as you intend for your debugging purpose. Especially useful, when you cross routed network segments where you don't have access to the devices.

Since most never use it, and it can be misused, security recommendations, under the general recommendation if something isn't used, suggests it be disabled. However, the risk is low, so I suggest for internal networks leave it active, for Internet involved (customer, not ISP) routing, deactivate it.

[Peter Paluch]

Joseph,

Thank you very much indeed for your insight. I agree with everything you have written. Regarding the security - mostly, I am concerned with the fact that the source routing essentially allows to route a packet completely disregarding the existing routing tables, eventually delivering it to a network which is not advertised at all. You just specify the sequence of routers and voila - your packet may end up in some internal network behind a NAT whose address has not been advertised at all. I do realize that this is a problem of securing that network in the first place. Nevertheless, the source routing is in my personal opinion a strong tool that hasn't took off as a general routing mechanism so leaving it running just for occasional clever debugging tricks does not justify the inherent risks associated with its powers.

But that is my personal opinion only - I am very much open to discussion. I really do see a great value in using it, for example, in the traceroute as you have suggested.

Best regards,

Peter

[jonseung]

Again, thank you all for your help on this.

Is there any other ways to route packets based on the source and destination in secure manner without using source based routing?

[Joseph W. Doherty]

Jon, hope you don't mind if I go a bit off subject on source routing with Peter. Oh, and for your quesiton about secure source routing, PBR would be, I think, the correct approach (assuming you get it to work).

Peter, not sure you can quite use source routing quite the way you think. What it does, basically, is override preferred paths, not direct a packet where ever you want. What happens is you load a set of intermediate hop addresses (up to nine?) that you want to transit. They can be strict (hop by hop) or loose (must cross in sequence defined). If any are unknown, the packet wouldn't be able to be forwarded (I believe) when it hits the unknown network address, much like the final destination address if unknown. I.e. routing tables, I believe, are not completely disregarded.

You're sort of correct about "clever" debugging, but when I get to the point I need to use it, then often it's not the time to try to get it activated since that's also when there's major production network problem, and perhaps we want to avoid the time to change multiple L3 devices configs besides the fact of introducing a new variable (changing their configs).

As you, the forgoing is my personal opinion, and also believe it should be discussed.

From a security perspective, I really don't see the source route function, itself, much risk, unless someone can think of a potential issue. Actually, since the function is so little used, from a security perspective, I would be more concerned, perhaps, whether a L3 device might have a potential bug in its source routing implementation that could be exploited.

[Peter Paluch]

Hello Joseph,

It's a pleasure to read your comments!

Regarding the source routing: of course, in order to successfully exploit the source routing in order to get a packet into an unknown network, you would basically need to know the sequence of routers beforehand. However, that is not that much of a problem - if that network is NATted, a simple traceroute to the public IP might be sufficient. In any case, determining the route is not a big problem.

However, I am afraid that when a source route option is specified in the IP header, the router disregards the destination IP address until the source route list is exhausted. That means that the destination indeed does not need to be known by routers.

I have concocted a small testing scenario: four routers in a row:

R1 - 10.0.12.0/24 - R2 - 10.0.23.0/24 - R3 10.0.34.0/24 - R4

The last octet in the network IP number is always assigned as the number of the router in question. Also, the R1 has a loopback 192.168.1.1/24. OSPF is running on all routers and the network 10.0.0.0/8 is added to it, however, the 192.168.1.0/24 loopback on R1 is not advertised - it is thus completely unknown to any other router:

R1#show ip route 192.168.1.0

Routing entry for 192.168.1.0/24

Known via "connected", distance 0, metric 0 (connected, via interface)

Routing Descriptor Blocks:

* directly connected, via Loopback0

Route metric is 0, traffic share count is 1

R2#show ip route 192.168.1.0

% Network not in table

R3#show ip route 192.168.1.0

% Network not in table

R4#show ip route 192.168.1.0

% Network not in table

Now I do the traceroute from R4 using the strict source routing:

R4#traceroute ip

Target IP address: 192.168.1.1

Source address: 10.0.34.4

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]: 1

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]: s

Source route: 10.0.34.3 10.0.23.2 10.0.12.1

Loose, Strict, Record, Timestamp, Verbose[SV]:

Type escape sequence to abort.

Tracing the route to 192.168.1.1

1 10.0.34.3 8 msec

Received packet has options

Total option bytes= 16, padded length=16

Strict source route: <*>

(10.0.23.2)

(10.0.12.1)

(192.168.1.1)

End of list

2 10.0.23.2 12 msec

Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.23.3) <*>

(10.0.12.1)

(192.168.1.1)

End of list

3 10.0.12.1 12 msec

Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.23.3)

(10.0.12.2) <*>

(192.168.1.1)

End of list

4 10.0.12.1 12 msec

Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.23.3)

(10.0.12.2)

(192.168.1.1)

<*>

End of list

R4#

Continuation follows:

[Peter Paluch]

You can see that the traceroute eventually reached the unknown network. Also

the ping succeeds:

R4#ping ip

Target IP address: 192.168.1.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 10.0.34.4

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]: s

Source route: 10.0.34.3 10.0.23.2 10.0.12.1

Loose, Strict, Record, Timestamp, Verbose[SV]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 10.0.34.4

Packet has IP options: Total option bytes= 15, padded length=16

Strict source route: <*>

(10.0.34.3)

(10.0.23.2)

(10.0.12.1)

Reply to request 0 (24 ms). Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.12.1)

(10.0.23.2)

(10.0.34.3)

<*>

End of list

Reply to request 1 (16 ms). Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.12.1)

(10.0.23.2)

(10.0.34.3)

<*>

End of list

Reply to request 2 (16 ms). Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.12.1)

(10.0.23.2)

(10.0.34.3)

<*>

End of list

Reply to request 3 (12 ms). Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.12.1)

(10.0.23.2)

(10.0.34.3)

<*>

End of list

Reply to request 4 (16 ms). Received packet has options

Total option bytes= 16, padded length=16

Strict source route:

(10.0.12.1)

(10.0.23.2)

(10.0.34.3)

<*>

End of list

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/16/24 ms

R4#

So regarding the source routing, it's quite a heavy artillery in my personal opinion. The fact that this function is so little used is in this case a disadvantage, as many people may not have information about it and its

possible consequences. A feature that is powerful and obscure at the same time gives space to potentially serious ways of misuse.

This reminds me of a feature in the NTFS file system - a thing called Alternate Data Streams. Originally, they were implemented for a compatibility features with the HPFS, I think. Basically, in NTFS, every file can have a number of streams knitted together only by the primary file name. You could potentially have a multimedia file whose one stream is a video and the second stream is an audio track, or a different revisions of the same file - or any other imaginative uses. Quite nice feature - if it was documented properly. However, it is not. The result is that various viruses, trojans and other infiltrations hide themselves as alternate data streams of different other files like autoexec.bat, coookie files or browser history but ordinary users don't have a clue about it. The problem is that with using ordinary Windows tools, you cannot see these alternate data streams nor the space they occupy on a disk. What you see without specialized utilities is only the primary data stream of a file and its size, and you have no idea that there are other data streams present. So you can have a 30 byte autoexec.bat and 1 GByte of data slapped onto it without you knowing anything about it. You'll just miss the 1 GByte of disk space but you wonder where it'd go.

Best regards,

Peter

[Joseph W. Doherty]

Peter, very nice lab!

What you've demonstrated was using source routing to deliver a packet to a non-advertized (OSPF) destination network, not one to a really unknown network (i.e. the network was known to R1, directly connected [as also shown by your "R1#show ip route 192.168.1.0"]). Further, each hop's next network (within the IP source route list) had to also be known to the router that processed it. In other words, route tables are not ignored, although, in this example, OSPF routing is.

Indeed, this is "heavy artillery", as you basically can override predefined dynamic and static routing, which is what can also make it such a useful debugging tool. Again, though, networks need to be known by routers to correspond with the hop and final destination. (BTW, I believe you would see the same result if you only provided "10.0.12.1" as a source route address but used "loose" as an option.)

From a security perspective, this capability of providing a packet's own IP routing can be a surprise. However, the security "flaw" you've just exposed is the classic one sometimes known, I believe, as security by obfuscation, i.e. or, security by ignorance (assuming lack of information by the "attacker". This "security" approach is often very weak.

You're quite right about alternate data streams within NTFS. (From a network performance perspective, "features" such as these also explain why some later Windows OSs perform slower across WANs since they are doing so much more network I/O when they open a file.) Another NTFS feature not widely known, or easily seen by common tools, is "junction points".

On security and ignorance, what I sometimes encounter is someone using a "best practice" without understanding all the ramifications (which also sometimes apply to the "authority" that provided the suggested "best practice". Since you mentioned NTFS, I'll touch upon two common examples in the Windows security world not dealing with networking, but "security".

First, enabling required mixed cased for Windows passwords. Great in theory until I ask, did you also disable downlevel client password acceptance which ignores case?

Second, rename all your admin accounts such that it's not obvious they're admin accounts, e.g. rename "admin" account. However, one shop was a bit dismayed when I sent them a report of all their admin accounts. How? Using my ordinary user account, used the API and asked Windows to provide a list of all the admin enabled accounts.

PS:

Also, BTW, thank you for the comment "It's a pleasure to read your comments!". I'm impressed by yours, both quality and quanity. On the latter, though, hopefully don't burn yourself out.

[Peter Paluch]

Hello Joseph,

Thank you very much for your reply. Please allow me to have a couple of comments. I have enjoyed reading your reply immensely.

What you've demonstrated was using source routing to deliver a packet to a non-advertized (OSPF) destination network, not one to a really unknown network - yes, you are right. However, a network that is unknown by all routers, even by that one which is directly connected to the segment where this network operates, is a degenerated situation as this network does not actually have any connectivity with the remaining world - and I am not concerned about networks that have absolutely no connectivity with outside world. Obviously, no routing method can be used to overcome this.

My point was in reaching an existing network that has at least some IP connectivity to the outside world, by specifying a sequence of routers to reach it despite their routing tables do not contain that network or dictate otherwise about it. Of course, at some point, some router must know about it - there's no doubt about it. Otherwise, I would be contacting not an unknown but rather a non-existent network (at least from the viewpoint of the internetwork infrastructure).

In other words, route tables are not ignored, although, in this example, OSPF routing is. - Yes, right, however, regarding the specified hops only :-) No router on the explicit path was concerned about the real destination in the IP header until the list of predefined hops was exhausted. I admit, this is juggling with words. You are more precise. The routing tables are used, however, they are used to look up the next explicit hop rather than the destination.

Regarding the junction point - I just keep smiling about them, being familiar with Unix-type hard and symbolic links... :-)

I'm impressed by yours, both quality and quanity. On the latter, though, hopefully don't burn yourself out. - Joseph, thank you very much. I feel honored by your compliment. Regarding the burning out - in two weeks, the winter semester is starting on my university so I'll spend most of my time teaching instead of having these pleasant conversations on NetPro, so I'm enjoying them while I can :)

Thanks!

Best regards,

Peter

[Joseph W. Doherty]

Peter,

Your point is quite will made. Mine being, do we want to rely on routing for security, and/or should we? As you well noted, I think, "I do realize that this is a problem of securing that network in the first place."

Consider, if we sourced from a host on the 192.168.1.x network, it can send packets to R4 via R1. By default, R4 won't be able to direct a reply, but for some recent UDP worms, there doesn't need to be a reply. So, without source routing, we still have a potential security issue in your sample network. This highlights another point being, security needs to be understood and implemented properly. What I sometimes object to is "mindless" adherence to some "best practice" without consideration of what's being recommended (which I doubt is the case for you).

When making such decisions, e.g. whether to allow source routing or not, we should consider benefit and risk, and other alternatives to minimize risk. It's possible to do without source routing, just as doing without ping (for those who block it; although often annoying). Some network exploits, though, can be hard to live without if we simply disable functions for "security". For instance, since there's the TCP half open issue, we need to block all TCP across the network to be safe. ;)

Hopefully, our discussion on source routing will demonstrate that all is not simple.

When you restart your active teaching, perhaps you'll set aside some "office hours" to keep your hand in on NetPro. Would regret seeing you going totally off-line.

[jonseung]

Giuseppe,

I tried your suggestion but unfortunately it didn't work. Maybe I should give you more details regarding our setup;

I have Cisco Catalyst 3560 L3 switch where all internal VLAN (10.34.x.x/16) resides. We also have ASA 5540 and 3800 series connected to it as next hop.

All internal and internet traffic have been forwarded to 3800 (next hop A).

We had some security issue with one of internal VLAN(10.34.90.x/24) which is why we decided its internet request to be routed to the ASA (next hop B) only.

So before we had ASA in place, I had default route in 3560 to be pointed to hop A.

I added access-list and route-map as indicated below;

access-list 11 permit 10.34.90.0 0.0.0.255

route-map PBR90 permit 10

match ip address 11

set ip next-hop B (ASA)

then apply this to the VLAN interface

int vlan 90

ip policy route-map PBR90

also added additional statice route

ip route 0.0.0.0 0.0.0.0 10.34.71.254(A)

<- in place

ip route 0.0.0.0 0.0.0.0 10.34.70.254(B) <- added

I noticed that when I reviewed configuration there's no route-map statement under VLAN interface 90.

What am I missing here?

Thanks again for your help on this.

[Giuseppe Larosa]

Hello Jon,

I've checked C3560 documentation it says:

>>To use PBR, you must have the IP services image installed on the switch

see

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/configuration/guide/swiprout.html#wp1210866

Edit:

so the question becomes what IOS image is in your switch?

Hope to help

Giuseppe