Unicast Reverse Path Forwarding (uRPF)

Unicast Reverse Path Forwarding (uRPF)

uRPF est une feature permettant d'éviter l'IP Spoofing.
Lorsque urpf est activé sur une interface, le routeur examine chaque paquet reçu en entrée.
Il vérifie ensuite que les paquets arrivent bien par l'interface représentant la 'best return path' vers la source.
Pour cela, urpf effectue un reverse lookup dans la table CEF.

- Si le paquet arrive par la bonne interface, il est forwarded.
- Si le paquet arrive par une interface autre que l'interface inscrite dans la FIB, le paquet est détruit.

Il est possible de créer des exceptions via une acl.

Strict Mode uRPF
Configuration d'uRPF 'strict'
Router(config)# ip cef
Router(config-if)# interface type
Router(config-if)# ip verify unicast source ip verify unicast source reachable-via list

'list' correspond à une acl.
Si cette acl permet une plage d'ip, cette plage à le 'droit' d'être spoofée, le paquet est donc forwardé.
Si cette acl deny une plage d'ip, cette plage ne peut être spoofée, le paquet est détruit (comportement normal).

Pour permettre au routeur de répondre à ses propres requêtes icmp:
ip verify unicast source reachable-via rx allow-self-ping

Loose Mode uRPF
Avec strict mode uRPF, un problème apparait que lorsque le trafic est asymétrique (internet).
Pour éviter cela, on utilise loose mode uRPF.
Dans ce mode, il suffit que la source soit présente dans la table de routage pour que le paquet soit forwardé (quelque soit l'interface de sortie).
Dans le cas contraire, il est détruit.

Configuration d'uRPF 'loose'
Router(config)# ip cef
Router(config-if)# interface type
Router(config-if)# ip verify unicast source reachable-via any

Ici, à partir du moment où une entrée pour joindre l'adresse IP source se trouve dans la table de routage, le trafic est forwardé.
En option, il est possible de spécifier une acl.

ip verify unicast source reachable-via {rx | any} [allow-default] [allow-self-ping] [list] [l2-src] [phys-if]

Divers timers sont configurables pour le calcul du 'drop rate':
ip verify drop-rate compute interval
ip verify drop-rate compute window
ip verify drop-rate notify hold-down
Pour être notifié en cas de dépassement du seuil de paquets détruit:
ip verify unicast notification threshold
(Default is 1000)

Remotely-Triggered Black Hole - RTBH

RTBH est une technique permettant d'éviter qu'une attaque DDoS surcharge la capacité du réseau opérateur.

La technique consiste à envoyer l'ensemble du trafic à destination d'un routeur client vers un black hole.

R2 et R4 constituent le cœur de réseau de l'opérateur.

R5 est le client.
R3 est le routeur permettant l'injection de routes.
R1 représente internet.

Les routeurs R2, R3 et R4 sont dans le même IGP.
Une session iBGP existe entre R2 et R3 et entre R2 et R4. R2 est RR.

R1 et R2 possèdent une session eBGP permettant l'échange des préfixes 150.1.1.1 et 150.5.1.1.

Un DDoS est effectué vers R5, 150.5.1.1.

Les étapes pour effectuer le RTBH sont:
1\ Création d'une route vers Null0 pour un préfixe 'bidon', en général, le TEST-NET (RFC3330), 192.0.2.0/24.
Cette route est présente sur l'ensemble des routeurs de Cœur.

ip route 192.0.2.0 255.255.255.0 Null0 name RTBH

2\ Sur le routeur injectant la route, R3, il faut installer une route statique vers le préfixe attaqué et la faire pointer vers Null0 ( de manière à pouvoir annoncer ce network).
Un tag est ajouté sur la route pour pouvoir effectuer un match dans une route-map.
R3:

ip route 150.5.1.1 255.255.255.255 Null0 tag 666

3\ Toujours sur R3, il faut redistribuer cette route vers le préfixe attaqué.
Une route-map est configurée de manière à modifier le next-hop en 192.0.2.1, qui ira donc pointer vers Null0 pour chaque routeur de coeur.
Cette route-map permet également de faire préférer cette route par rapport à l'originale:

!
route-map RTBH permit 10
match tag 666
set local-preference 700
set origin igp
set ip next-hop 192.0.2.1
!
route-map RTBH permit 20
!

Enfin,

router bgp 3352
redistribute static route-map RTBH

!
Résultat:
Sur R4, à l'origine, la route était apprise correctement:

R4#sh ip route 150.5.1.1
Routing entry for 150.5.1.1/32
Known via "bgp 3352", distance 20, metric 0
Tag 65535, type external
Last update from 150.1.45.5 01:10:58 ago
Routing Descriptor Blocks:
* 150.1.45.5, from 150.1.45.5, 01:10:58 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65535

Suite aux modifications, elle est apprise de la manière suivante:
R4#sh ip route 150.5.1.1
Routing entry for 150.5.1.1/32
Known via "bgp 3352", distance 200, metric 0, type internal
Last update from 192.0.2.1 00:00:08 ago
Routing Descriptor Blocks:
* 192.0.2.1, from 150.2.1.1, 00:00:08 ago
Route metric is 0, traffic share count is 1
AS Hops 0

Et ce, sur chaque routeur de cœur.
L'interêt réside dans le fait que l'action n'est pas effectuée sur l'ensemble des routeurs de cœur, mais bien à partir d'un point centralisé.

L'inconvénient est que le DDoS à réussi, tout le trafic à destination du client est black-holed.

Multicast - Génération de trafic

Pour simuler une source de trafic multicast:

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#rtr 1
SW1(config-rtr)#type udpEcho dest-ipaddr 224.1.1.1 dest-port 12345 source-ipaddr 10.1.37.7 control disable
SW1(config-rtr-udp)#frequency 5
SW1(config-rtr-udp)#timeout 0
SW1(config-rtr-udp)#exit
SW1(config)#rtr schedule 1 start now
SW1(config)#end
SW1#

Traffic Engineering Tunnel Options

Options TE:
Envoyer le traffic dans un tunnel:
1\ PBR (RAS)
2\ Static Routing (RAS)
3\ Autoroute

Autoroute:
tunnel mpls traffic-eng autoroute announce
Le tail end est accessible via le tunnel.
Tous les équipements derrière le tail-end sont également joignable via ce tunnel.
Le cost vers le tail end est le même que le 'best path' vers l'igp.
Le cost vers les équipements derrière le tail end correspond au cost jusqu'au le tail-end plus le cost 'normal' vers l'igp.
R0:
show ip route
O 10.3.3.1 [110/31] via 10.3.3.1, 00:17:28, Tunnel0
O 10.2.2.1 [110/21] via 10.3.3.1, 00:17:28, Tunnel0



Modifier les métriques:Sur l'interface tunnel:
Par défaut, le cost vers le tail-end est égal au cost IGP.
tunnel mpls traffic-eng autoroute metric 5
Ici, on modifie ce comportement : la metrique vers le tail-end est de 5.
Les addresses derrière le tail-end ont un cost de 5+la valeur IGP.

tunnel mpls traffic-eng autoroute metric relative -5
Sur le head-end, la route vers le tunnel tail-end n'est plus égale au meilleur cost de l'igp, mais à la valeur de l'IGP + la valeur relative.

tunnel mpls traffic-eng autoroute metric absolute 5
Ne fonctionne qu'avec IS-IS: le cost du tail-end et des adresses derrière le tail-end est de 5.

Toutes ces modifications de valeurs ne sont valables que pour la source du tunnel.
Ces costs ne sont pas redistribués dans l'IGP.
Les modifications sont apportées après le calcul SPF.

Bande passante du tunnel

Les interfaces physiques possèdent une bande passante (RSVP):
- resv de pool:
ip rsvp bandwidth 10000
- resv avec sub-pool:ip rsvp bandwidth 10000 5000

Une interface Tunnel peut indiquer la bande passante qui lui sera reservée:
Sur l'interface tunnel:
- Réservation dans le pool,
tunnel mpls traffic-eng bandwidth 1400
- Réservation dans le sub-pool,
tunnel mpls traffic-eng bandwidth sub-pool1400
La BW d'un tunnel ne peut être pris dans le pool et le sub-pool. Si les deux sont spécifiés, par défaut, seul le sub-pool est considéré.

De manière automatique:
tunnel mpls traffic-eng auto-bw
La bp effective est modifiée suivant des timers définis en global:
gsr3(config-if)# tunnel mpls traffic-eng auto-bw ?
collect-bw Just collect Bandwidth info on this tunnel
frequency Frequency to change tunnel BW
max-bw Set the Maximum Bandwidth for auto-bw on this tunnel
min-bw Set the Minimum Bandwidth for auto-bw on this tunnel

vérification de la reservation:
show ip rsvp reservation

Load Sharing:
Deux valeur peuvent être utilisées:
tunnel mpls traffic-eng bandwidth
ou
tunnel mpls traffic-eng load-share

Le ''unequal'' load sharing est possible en jouant sur les valeurs de bandwidth ou load-share de chaque tunnel:
tunnel1: tunnel mpls traffic-eng bandwidth 1000
tunnel2: tunnel mpls traffic-eng bandwidth 100
Le ratio est 1:10.
On peut aussi utiliser la seconde commande:tunnel1: tunnel mpls traffic-eng load-share 40
tunnel2: tunnel mpls traffic-eng load-share 80

Basic Traffic-Engineering configuration

Configuration Basique d'un tunnel
! En global:
mpls traffic-eng tunnels
!
! Sur les interfaces:
interface S1/0
mpls traffic-eng tunnels
mpls ip
ip rsvp bandwidth 10000
!
! Configuration de IGP:
!OSPF, utilise les ''opaque LSA'', type 10:
router ospf 1
mpls traffic-eng area 0
mpls traffic-eng router-id loopback0
!
! ISIS, utilise les TLV22, TLV134 et TLV135:
router isis
net 49.0001.0000.000a.00
metric-style wide
mpls traffic-eng router-id loopback0
mpls traffic-eng level-1
! ou
router isis
net 49.0001.0000.000a.00
metric-style wide
mpls traffic-eng router-id loopback0
mpls traffic-eng level-2
is-type level-2-only
! attention, un routeur L1/L2 se base sur la topologie L1 pour joindre un autre routeur L1/L2 car ils sont dans la même ''aire" et que se serait illogique de passer par un routeur L2.
! Un routeur L1/L2 ne peut donc faire de TE avec un autre routeur L1/L2 sans ''mpls traffic-eng level-1"
!
!Configuration (minimale) du tunnel:

interface Tunnel0
ip unnumbered Loopback0
tunnel destination 10.3.3.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 5 dynamic

!

Vérifications:
Réservations RSVP (locale):
R0#show ip rsvp interface
interface allocated i/f max flow max sub max
Se1/0 0 10M 10M 0

Allocation label:
R0#show ip rsvp reservation detail filter destination 10.3.3.1
Reservation:
Tun Dest: 10.3.3.1 Tun ID: 0 Ext Tun ID: 10.0.0.1
Tun Sender: 10.0.0.1 LSP ID: 22
Next Hop: 192.168.1.2 on Serial1/0
Label: 24 (outgoing)

Process TE:
R0#show mpls traffic-eng tunnels summary
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled

Forwarding-Table:
R0#show mpls forwarding-table
[T] signifie que le trafic passe par un tunnel.
Pour connaitre le label utilisé pour le tunnel:
show mpls forwarding-table detail

Check du tunnel:
R0#show mpls traffic-eng tunnels tunnel 0