Unicast Reverse PathUnicast Reverse Path Forwarding

From the inside out:Campus subnets to regional networks

Andrew Gallo

uRPF ‐ OverviewuRPF Overview

• Problem statement• Options for the campus network

• Campus subnet routing• At the campus borderAt the campus border

• Implementation for a small regional• Options aren’t great, but something is better than nothing

uRPF ‐ TerminologyuRPF Terminology

• uRPF , SAV• BCP 38

• RFC 2827 – May 2000

• Modes• Modes• Strict• Loose

bl ( h d f bl )• Feasible (+ enhanced feasible)

• Assignment, ”used by”• Even if you have PI space (allocated or assigned), you likely have addresses y p ( g ), y youtside these blocks in use

uRPF – A PleauRPF A Plea• This presentation may be review for many of you

• Great‐ please share your experience‐ tell us what has worked, what hasn’t

• If this is new, if you have questions:

PLEASE, PLEASE, PLEASE, ASK!• Like other routing security topics,  your effort improves my security• Let me (us, the I2 community) help you help

uRPF – The ProblemuRPF The Problem

• Why are you sending me garbage?• Internet routing is primarily concerned with moving a packet closer to its source – destination address is rarely examined by intermediate routers.

• Why would a host originate a packet with a source other than it’s own?• Special case‐ it doesn’t have an address (yet)Special case it doesn t have an address (yet)

• DHCP/BOOTP – source address could be• Discover/Request

• Mobile IP• Traffic to client is tunneled.  Traffic from client is not (unless reverse tunnel used)• Anyone using this?• Anyone using this?

• Other cases• Link Local / Self Assigned

• Shouldn’t leave local network anyway

• If you’re going to emit a packet and expect a response (and even if you don’t)• If you re going to emit a packet, and expect a response (and even if you don t) –Be a good neighbor and tell us who you are

Distributed Denial of Service AttackDistributed Denial of Service Attack

• A great use‐case or vector for a network (read: The Internet) that doesn’t enforce g ( )source address validation.

• Lack of source address validation allows reflection attacks

DDoS, now with Amplification !DDoS, now with Amplification !• Feature (bug?) of NTP allowed retrieval of list of clients/peers.

• Small request large reply (upwards of 200X amplification)1Small request, large reply (upwards of 200X amplification)

1  source: https://www.incapsula.com/ddos/attack‐glossary/ntp‐amplification.html

uRPF – Think Global (and Local*), but act LocaluRPF Think Global (and Local ), but act Local

• The ideal place to enforce source address validation is as close to the client iblas possible

• The source knows authoritatively what valid addresses are.• Also, why carry traffic that will eventually be dropped?

• Even at the layer‐2 port:Even at the layer 2 port:• Cisco IP Source guard: ‘ip verify source vlan dhcp-snooping’• Ideal, yes, but let’s make our lives a little easier

* Remember – uRPF can help protect your own network from internally spoofed traffic

Configuration at a Layer 3Configuration at a Layer 3

• First Hop layer 3 interface is a logical place to enforce source address validation

172.16.142.254/24

172.16.142.0/24

172.16.142.21/24 172.16.142.54/24

192.168.56.22/24

Configuration at a Layer 3Configuration at a Layer 3

• Default configuration: accept packets from 192.168.56.22 – but why?

172.16.142.254/24

172.16.142.0/24

172.16.142.21/24 172.16.142.54/24

192.168.56.22/24

Configuration at a Layer 3 – strict modeConfiguration at a Layer 3  strict mode• Cisco IOS command

• ip verify unicast source reachable-via rxp y• Router checks incoming packet SA against route table:

• Is this interface *the best* way to get back to SA?• If yes, accept• If no drop• If no, drop

• Good option for “end‐user” or “single‐homed” networks

172.16.142.254/24

172.16.142.0/24

172.16.142.21/24

192.168.56.22/24

172.16.142.54/24

Configuration at a Layer 3 – strict modeG hGotcha

• Experience with early versions of NX‐OS, strict mode broke DHCP (50% of the time) when using a first‐hop router redundancy protocolof the time) when using a first hop router redundancy protocol 

• Work around – use loose mode• Newer versions of code might have fixed this• Network evolution moved end‐user subnets to single control plane boxes (single routers or VSS)

HSRP/GLBP172.16.142.253/24

172.16.142.0/24

172.16.142.252/24

172.16.142.254

172.16.142.21/24

192.168.56.22/24

172.16.142.54/24

Configuration at a Layer 3 – loose mode

• Cisco IOS command• ip verify unicast source reachable-via anyip verify unicast source reachable via any

• Router checks incoming packet SA against route table:• Do I have any route back to the SA

• even if it isn’t the best – it just has to exist in the route tablej• If yes, accept• If no, drop

172.16.142.254/24

172.16.142.0/24

172.16.142.21/24

192.168.56.22/24

172.16.142.54/24

Configuration at a Layer 3 – loose mode

• Consider‐h t if I h d f lt t i t bl (0 0 0 0/0)?• what if I have a default route in my table (0.0.0.0/0)?• It matches all packets, so what’s the point of checking?• Junos – it depends on the platform• IOS – by default, will ignore default route of loose mode RPF checking

• Static route to Null0 (IOS) or discard (Junos)• Drop if SA matches a route that points to these interfacesDrop if SA matches a route that points to these interfaces• Knobs to modify behavior• Juniper – platform/software specifics

• Many caveats with loose mode which is why strict mode as close to the• Many caveats with loose mode – which is why strict mode as close to the hosts as possible is ideal

Our design

• We have strict mode enabled at end user subnets (except when routed by NX‐OSOS

• We do not have any RFP checking on backbone links• We have static ACLs (firewall filters) at the border of our network:We have static ACLs (firewall filters) at the border of our network:

• For packets leaving, the SA must be something that can return to us• For packets arriving, the DA must be for something ‘assigned’ to us

Monitoring ‐ CiscoMonitoring  Cisco

• Most platforms provide show commands to see how uRPF is working:CAT6K-ACAD-B2-1#show ip interface vlan 105Vlan105 is up, line protocol is up<snip> IPv4 WCCP Redirect exclude is disabled

IP verify source reachable via ANY Loose ModeIP verify source reachable-via ANY Loose Mode0 verification drops0 suppressed verification drops0 verification drop-rate

IP verify source reachable-via RX Strict Mode0 verification drops0 suppressed verification drops0 verification drop rate0 verification drop-rate

Monitoring ‐ CiscoMonitoring  Cisco

• See any non‐zero values?  Need more detail?  Create an ACL• Similar to ‘fail‐filter’ in Junosinterface Vlan105ip verify unicast source reachable-via rx 166

show ip access-lists 166Extended IP access list 166

10 permit ip any any log (378 matches)

Feb 26 08:52:25: %SEC-SW1-6-IPACCESSLOGP: list 166 permitted udp 192 168 48 150(0) -> 192 168 51 255(0) 1 packetFeb 26 08:52:25: %SEC-SW1-6-IPACCESSLOGP: list 166 permitted udp 192.168.48.150(0) -> 192.168.51.255(0), 1 packet

Feb 26 08:58:25: %SEC-SW1-6-IPACCESSLOGP: list 166 permitted udp 192.168.48.150(0) -> 192.168.51.255(0), 1 packet

• But you don’t get MAC addresses, so if your hunting for a host, packet capture y g , y g , p pwill help

Tools• CAIDA’s Spoofer:• https://www.caida.org/projects/spoofer/

Vid htt // t b / N4 WTNSd• Video https://youtu.be/rxN4zWTNSds

CAIDA reports

• Report with some spoofing allowed

• https://spoofer.caida.org/report.php?sessionid=78418

• Shows leaking towards one site – one egress didn’t have proper filters

• Report after filters appliedReport after filters applied

• https://spoofer.caida.org/report.php?sessionid=552406

uRPF For Transit Networks – It’s ComplicateduRPF For Transit Networks  It s Complicated• It’s the Internet – Asymmetry abounds.• The best we can hope for is loose mode – does the source address exist panywhere on the internet?

• How much value does this provide?

uRPF For Transit Networks – It’s ComplicateduRPF For Transit Networks  It s Complicated•Things aren’t too bad if all customers are non‐transit

•In this topology, uRPF strict mode will drop traffic sent by AS11039, originated by interfaces address from other providersISP2

CAAREN (AS4901)

BGP advertise: 128.164.0.0/16

039)

ISP1

ISP3

WU

(AS

11 Route Policy:

Internet2: LP500

64.124.161.16/30.18 .19

Peering: LP200TRCPS: LP150Commercial Transit: (default LP)

Peering

GW

All EBGP links addressed from provider space

uRPF For Transit Networks – It’s ComplicateduRPF For Transit Networks  It s Complicated•In Junos, use “fail‐filter”

•How to generate and maintain??•Look at BGP, whois, IRR, fail‐filter with log, ask customers about infrastructure addresses•Continuously monitor fail‐log

•What did we see when we turned uRPF on?ISP2

CAAREN (AS4901)

BGP advertise: 128.164.0.0/16

•NAT•High number of failures swamped logging service•One customer ‐ only certain prefixes advertised to AS4901

Thi i h li t d f th t039)

•This is much more complicated farther upstreamISP1

ISP3

WU

(AS

11 Route Policy:

Internet2: LP500

64.124.161.16/30.18 .19

Peering: LP200TRCPS: LP150Commercial Transit: (default LP)

Peering

GW

All EBGP links addressed from provider space

Juniper Config ‐ InterfaceStrict Mode Loose Mode

3/1/6 {ge-3/1/6 {description "CUST:1";flexible-vlan-tagging;mtu 9192;encapsulation flexible-ethernet-services;unit 4 {

description "CUST:1";

xe-3/2/0 {description "CUST:GWU";flexible-vlan-tagging;mtu 9192;encapsulation flexible-ethernet-services;unit 4 {

description CUST:1 ;vlan-id 4;family inet {

rpf-check fail-filter uRPF-CUST1-fail_v4;mtu 9000;address 162.250.137.x/31;

}

description "CUST:GWU";vlan-id 4;family inet {

rpf-check {fail-filter uRPF-GWU-fail_v4;mode loose;

}}unit 6 {

description "CUST:1";vlan-id 6;family inet6 {

rpf-check fail-filter uRPF-CUST1-fail_v6;

}mtu 9000;address 162.250.137.130/31;

}}unit 6 {

description "CUST:GWU";mtu 9000;address 2620:118:5007:x::x/127;

}}

}

description CUST:GWU ;vlan-id 6;family inet6 {

rpf-check {fail-filter uRPF-GWU-fail_v6;mode loose;

}mtu 9000;address 2620:118:5007:ff1b::/127;

}}

}

Junos Config – Supporting sectionsJunos Config Supporting sectionsfilter uRPF-GWU-fail_v4 {

term other-legit-sources {from {from {

prefix-list {pf_uRPF-GWU-exceptions_v4;

}}then accept;

}}term fail {

then {syslog;discard;

}}}

}

policy-options prefix-list pf_uRPF-GWU-exceptions_v4 64.124.161.18/32policy-options prefix-list pf_uRPF-GWU-exceptions_v4 66.44.95.74/32policy-options prefix-list pf_uRPF-GWU-exceptions_v4 144.121.133.184/32

li ti fi li t f RPF GWU ti 4 206 126 236 172/32policy-options prefix-list pf_uRPF-GWU-exceptions_v4 206.126.236.172/32

Monitoring ‐ JunosMonitoring  Junosagallo@XR1.SUPP> show interfaces ge-3/1/6.4 statistics | match RPF

Flags: Sendbcast-pkt-to-re, User-MTU, uRPFg p , ,RPF Failures: Packets: 38966388, Bytes: 2459572332

Leaking 1918Sep 26 11:46:35 XR1.SUPP fpc3 PFE_FW_SYSLOG_IP: %-FW: ge-3/1/6.4 D tcp 10.130.150.32 131.253.61.84 56668 443 (1 packets)

Sep 26 11:46:36 XR1.SUPP fpc3 PFE_FW_SYSLOG_IP: %-FW: ge-3/1/6.4 D tcp 10.130.150.21 131.253.61.66 59240 443 (1 packets)

Sep 26 11:46:37 XR1.SUPP fpc3 PFE_FW_SYSLOG_IP: %-FW: ge-3/1/6.4 D icmp 10.0.254.2 13.95.153.77 11 0 (1 packets)

Sep 26 11:46:42 XR1.SUPP fpc3 PFE_FW_SYSLOG_IP: %-FW: ge-3/1/6.4 D tcp 10.130.150.21 131.253.61.66 59240 443 (1 packets)

S 26 11 46 47 XR1 SUPP f 3 PFE FW SYSLOG IP % FW 3/1/6 4 D t 10 130 150 32 131 253 61 66 56678 443 (1 k t )Sep 26 11:46:47 XR1.SUPP fpc3 PFE_FW_SYSLOG_IP: %-FW: ge-3/1/6.4 D tcp 10.130.150.32 131.253.61.66 56678 443 (1 packets)

**Need to check for other, legit sources

*****Be careful – if too much is logged, syslog will start dropping messages

SummarySummary

• Source Address Validation is critical to minimizing the impact of spoofed traffic

• It is best done as close to the source as possible• Your efforts protect other networks• Your efforts protect other networks

• Internet hygiene is a shared responsibility