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 [email protected]> 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
Top Related