LTRSEC-2033.Pdf

IPv6 Network Threat Defense, Countermeasures, and Controls

LTRSEC-2033

Panos Kampanakis The Challenges Come from Every Direction

Sophisticated Complicit Attackers Users

Dynamic Boardroom Threats Engagement

Defenders

Complex Misaligned Geopolitics Policies

• Panos Kampanakis ([email protected]) - CCIE #28561 – Security Research and Operations – Applied Intelligence

• Introduction – State of IPv6 Network Security and Lab Overview

• Module 1 – Flexible NetFlow for IPv6

• Module 2 – IPv6 Anti-Spoofing and Unicast RPF for IPv6

• Module 3 – Infrastructure ACLs (iACLs) and Transit ACLs (tACLs) for IPv6

• Module 4 – Identifying and Reacting to IPv6 tunneling evasions

• There are more slides in the handout than what will be presented here • Marked as Reference Slide

• These are for your reference

• Application layer attacks – The majority of vulnerabilities are at the application layer, something that even IPSec will do nothing to prevent • Sniffing – IPv6 is as likely as IPv4 to fall victim to a sniffing attack • DoS/DDoS attacks – Flooding attacks are identical between IPv4 and IPv6 (but the IPv6 address space may make tracking the sources a bit harder) • Rogue devices – Rogue devices are as easy (if not easier) to insert into an IPv6 network • Spoofing – Though, again, the size of the IPv6 address space makes it easier

• Man-in-the-Middle – Now spoofing Neighbor Advertisements (NA), Router Advertisements (RA) or Redirects – no more playing with ARP ! • Reconnaissance – scanning 248 addresses (if using EUI-64) is hard. Scanning 264 addresses (if using DHCPv6 or privacy extensions) is bordering impossible. Attackers will rely more and more on DNS to find targets

• RA spoofing – Blackhole/redirect traffic, inject bogus prefixes (resource exhaustion, DoS) • DAD address auto configuration DoS – NA spoofing – all addresses are already in use ! • Neighbor Discovery Cache attacks • IPv6 Extension Headers – ACL bypass through malicious fragmentation, HbH processing on intermediate hops, resource exhaustion • IPv6 tunneling mechanisms – ISATAP, Teredo, 6in4, AYIYA – IPv6 traffic in your IPv4 network you may not even be aware of

• All equipment is located and virtualized at a Cisco location

• There are 35 student pods / VMs. Each VM is hosting: – Attackers (scripts) – Victim Servers – Infrastructure routers (virtual) – 3 pod routers (virtual) that students configure

Internet IPv6 Servers Intranet

SP IPv6

Dual-stack Intranet hosts IPv4

Internet IPv6 Servers Intranet

SP IPv6

- Protect IPv6 Infrastructure Intranet Dual-stack - Protect servers hosts - Prevent IPv4 IPv4 Hosts from doing “fancy” stuff

Internet Internet Intranet IPv6 RTR1 IPv6 Attackers Servers/Targets SP

RTR3 Intranet IPv4 RTR2 RTR6 Dual-Stack Hosts

RTR4 RTR5

RTR7

Student

Internet Internet Intranet IPv6 RTR1 IPv6 Attackers Servers/Targets SP

RTR3 Intranet IPv4 RTR2 RTR6 Dual-Stack Hosts

RTR4 RTR5

RTR7

Student

e0/1 rtr1 ::3 ::/0 rtr3 Servers e0/0 e0/0 e0/1 ::901 ::1 ::1 2001:DB8:1:21::/64 ::1 2001:DB8:1:11::/64 e0/2 sp1

2001:DB8:1:12::/64

::2 e0/2 e0/1 … rtr2 ::4 rtr4

e0/1

rtr6 Dual-Stack Hosts

… e0/0 e0/0 e0/1 .4 .5 .5 10.1.21.0/24 e0/1 10.1.11.0/24

rtr4 rtr5 .7 rtr7 Dual-Stack Hosts

To VPN into the lab • Open the ( ) Cisco AnyConnect VPN Client from the Programs menu • “Connect to” 64.102.242.66 • Use credentials – Username: [see proctor] – Password: [see proctor] – Accept the Certificate warnings that may appear

LTRSEC-2033 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 Accessing the Pod Equipment • Each pod consists of 8 routers – one “service provider” router and seven “enterprise” routers • Out of the eight “enterprise” routers, you will only need to configure podX-rtr1, podX-rtr2 and podX-rtr5 (X being the pod number) – all of the other routers are NOT to be configured • Routers can be accessed by telnetting into the pod VM IP address 172.16.66.X or hostname ipv6-vmX on port 2000+router# (X being the pod number) and pressing ‘Enter’ to be prompted for credentials – For example to access pod1-rtr5 “telnet ipv6-vm1 2005” or “telnet 172.16.66.1 2005” – Press ‘Enter’ and put in the username and password • The username and password for podX-rtr1, podX-rtr2 and podX-rtr5 will be provided separately by the proctors • All the other routers have passwords to prevent accidental reconfiguration

• In this example, our VM is using IP address 172.16.66.2 (hostname ipv6-vm2) and we are accessing router pod2-rtr1 – hence, “telnet 172.16.66.2 2001” and press ‘Enter’ to be prompted for credentials

• Go to http://cs.co/9008doTy and chose the Files tab. Press the + icon next to the LTRSEC-2033 IPv6 Sec directory, and put in the password ciscoliveipv6 • Alternatively, get the LTRSEC-2033.zip file from your desktop • The directory contains – /initial_configs/ – Initial, base configurations for all routers (filenames are for pod1, but the configs for the other pods are identical) – /solutions/ – Solutions from each scenario (filenames are for pod1, but the configs for the other pods are identical) – Presentation PDFs – The presentation and lab guide. Also we include PDF for two more labs that are optional and we will not cover in the presentation.

• NetFlow is telemetry pushed from routers/switches – Each device can be a sensor – Simple summary of connections – Negligible performance impact on routers • Not just Cisco • Like a phone bill – Packet capture is like a wiretap

• NetFlow data can be collected and relayed to multiple tools

NetFlow Key Fields 2 3 NetFlow Reporting Export 1. Inspect a packet’s seven key fields and identify the values Packets 2. If the set of key field values is unique, create a flow record or cache entry 3. When the flow terminates, export the flow to the collector

• NetFlow is available on routers and switches • Have syslog-like information without having to buy a firewall • One NetFlow packet has information about multiple flows

Header • Sequence number Flow Flow • Record count Record … Record • Version number NetFlow Cache Export Packets • Approximately 1500 bytes • Typically contain 20–50 flow records • Sent more frequently if traffic increases on NetFlow-enabled interfaces LTRSEC-2033 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public 26 Version 5 - Flow Export Format

Usage • Packet Count • Source IP Address From/To • Byte Count • Destination IP Address

Time • Start sysUpTime • Source TCP/UDP Port Application of Day • End sysUpTime • Destination TCP/UDP Port

Port • Input ifIndex • Next Hop Address Utilization • Output ifIndex Routing • Source AS Number and • Type of Service • Dest. AS Number Peering QoS • TCP Flags • Source Prefix Mask • Protocol • Dest. Prefix Mask

Version 5 Used Extensively Today

• Traditional NetFlow with the v5, v7, or v8 NetFlow export – New requirements: build something flexible and extensible

• Traditional NetFlow with the v5, v7, or v8 NetFlow export – New requirements: build something flexible and extensible • Phase 1: NetFlow version 9 – Advantages: extensibility • Integrate new technologies/data types quicker (MPLS, IPv6, BGP next hop, etc.) • Integrate new aggregations quicker • Phase 2: Flexible NetFlow – Advantages: cache and export content flexibility • User selection of flow keys • User definition of the records

• Traditional NetFlow with the v5, v7, or v8 NetFlow export – New requirements: build something flexible and extensible • Phase 1: NetFlow version 9 – Advantages: extensibility Exporting • Integrate new technologies/data types quicker (MPLS, IPv6, BGP next hop, etc.) Process • Integrate new aggregations quicker • Phase 2: Flexible NetFlow – Advantages: cache and export content flexibility Metering • User selection of flow keys Process • User definition of the records

To Support Technologies such as MPLS or Multicast, this Export Format Can Flows from Flows from Be Leveraged to Easily Insert New Fields Interface A Interface B

Option Data Template FlowSet Data FlowSet Data FlowSet Option FlowSet (Version, FlowSet ID #1 FlowSet ID #2 Template FlowSet ID Number of Template Record Template Record FlowSet Packets, Template ID #1 Template ID #2 Data Record Data Record Data Record Template ID Option Option Sequence (Specific Field (Specific Field (Specific Data Data Number, Field Types Record Record Types and Types and (Field Values) (Field Values) (Field Values) Source ID) Lengths) Lengths) and (Field (Field Lengths) Values) Values)

• Matching ID numbers is the way to associate template to the data records

• The header follows the same format as prior NetFlow versions so collectors will be backward compatible

• Each data record represents one flow

• If exported flows have the same fields, they can be contained in the same template record; that is, unicast traffic can be combined with multicast records

• If exported flows have different fields, they cannot be contained in the same template record; that is, BGP next-hop cannot be combined with MPLS-aware NetFlow records Introduction to Flexible NetFlow (FNF)

• Fixed export formats (NetFlow version 1, 5, 7, 8) are not flexible and adaptable. Each new version contains new export fields; incompatible with previous version • Flexible NetFlow completely separates the collection and export processes • Allows customization of NetFlow collection: – Scalable by maintaining flow records of the granularity that is required for a particular user’s application – Supports more than 100 fields to configure flow records – Capture and export complete or partial packet headers and payload for security and other applications

• New Cache concept (normal, permanent, no-cache) – Normal: entries in the cache are aged out according to the “timeout active” and “timeout inactive” settings – when aged out, entry is removed from the cache and exported via any exporters configured – Immediate: entry is aged out as soon as created – every flow contains just one packet. Adds load to the CPU because timing out flows exports them by generating FNF packet which adds processing load. Desirable when you expect a small number of flows and want minimum latency between seeing the flow and exporting. – Permanent: entries are never aged – useful keeping long-term statistics on the device. Use only when a low number of flows are expected. Once the cache is full, no new entries will be added. • Flexible NetFlow is available starting from Cisco IOS release 12.4(9)T • IPv6 support starting from Cisco IOS release 12.4(20)T

• Flow record – combination of key and non-key fields to define the information that will be captured by Flexible NetFlow • Flow monitor – applied to an interface to perform network traffic monitoring – Can be ingress or egress – Optional packet sampling possible per flow monitor – References a flow record (pre-defined or user-defined) - mandatory – Cache is automatically created when flow monitor is applied to the interface – One or more flow exporters (optional) • Flow exporter – where Flexible NetFlow data will be exported – Multiple (optional) flow exporters per Flow Monitor • Flow samplers – Used to reduce the load on the device running FNF by limiting the number of packets selected for analysis.

Bits 11-31 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 Res ESP AH PAY DST HOP Res UNK FRA0 RH FRA1 Res

. FRA1: Fragment header – not first fragment

. RH: Routing header (any type)

. FRA0: Fragment header – First fragment

. UNK: Unknown Layer 4 header (compressed, encrypted, not supported)

. HOP: Hop-by-hop extension header

. DST: Destination Options extension header

. PAY: Payload compression header

. AH: Authentication header

. ESP: Encapsulating Security Payload header

. Res: Reserved

Configure the Flow Record flow record my-app-traffic match ipv6 source address match ipv6 destination address match ipv6 protocol 1 match transport tcp source-port match transport tcp destination-port collect counter bytes collect counter packets

Configure the Flow Exporter flow exporter my-exporter 2 destination 2001:DB8:100:200::1

Configure the Flow Monitor flow monitor my-monitor 3 exporter my-exporter record my-app-traffic

Assign the Flow Monitor to the Interface 4 interface FastEthernet0/0 ipv6 flow monitor my-monitor input

• Networks and network enabled devices constantly create traffic. However, this traffic follows certain patterns according to the applications and user behaviour – Analysing these patterns allows us to see what is NOT normal – The key is to collect traffic information (NetFlow) and calculate various statistics. These are then compared against a baseline and abnormalities are then analysed in more detail. • More info at http://blogs.cisco.com/security/step-by-step-setup-of-elk-for-netflow- analytics

• Larger number of cache entries will have an increasing level of impact to CPU – This is much more visible on the low end platforms • Short lived flows, short aging timeout or immediate cache adds CPU load because generating FNF packets to export flows adds processing load • NetFlow v9 and NetFlow v5 export have similar CPU impact • Having multiple exporters does not add significant CPU impact • Flexible NetFlow does add a slight CPU load – More visible on lower end platforms – However this difference is seen at large flow counts that are not expected to be seen on lower end platforms – FNF CPU load is higher (compared to traditional NetFlow) for higher numbers of packet per second • show commands that aggregate, query and match on flow characteristics add processing load to a live router. Safer to aggregate flow records and analyze off-box in production.

Router#show flow monitor cache format table

IPV6 EXTENSION MAP IPV6 SRC ADDR IPV6 DST ADDR TRNS SRC PORT TRNS DS T PORT IP PROT ======0x00000000 FE80::20A:B8FF:FEA9:5944 FF02::5 0 0 89 0x00000048 2962:80AC:AEF5:6FA5:D72:12FB:928:4E1B 2001:DB8:10:11:C:15C0:0:1 139 16042 17 0x00000042 2962:80AC:AEF5:6FA5:D72:12FB:928:4E1B 2001:DB8:10:11:C:15C0:0:1 0 0 17 0x00000088 245C:7CB1:1CC3:9F12:A5A1:556E:A2C8:8DE5 2001:DB8:10:11:C:15C0:0:1 137 24036 17 0x00000002 245C:7CB1:1CC3:9F12:A5A1:556E:A2C8:8DE5 2001:DB8:10:11:C:15C0:0:1 0 0 60 0x00000284 2001:DB8:10:EE81:8BB7:89A8:E9DA:2B42 2001:DB8:10:3D84:B2D3:D0D6:BBBB:3026 0 14850 58 0x00000244 2001:DB8:10:6563:40DF:AFE3:59EE:BF8F 2001:DB8:10:5EFB:C0D7:E201:1D93:3473 0 0 132 0x0000004C 2365:E5C7:14C1:5802:5105:B19E:F584:CED 2001:DB8:10:11:C:15C0:0:1 0 768 58 0x00000046 2365:E5C7:14C1:5802:5105:B19E:F584:CED 2001:DB8:10:11:C:15C0:0:1 0 0 58 0x00000000 29A3:1E07:7538:724D:E069:A445:FBA7:CD5E 2001:DB8:10:62CA:E7A9:66CB:1431:852C 1337 80 6

. IP PROT – protocol - 6 (TCP), 17 (UDP), 58 (ICMPv6), 60 (Destination Options EH), 89 (OSPF), 132 (SCTP), etc. For AH we report the protocol after the AH header – the presence of the AH header is a flag on the extension map. . Source and destination ports – only reported for TCP, UDP, IGMP and ICMPv6. For ICMPv6, dst = (type << 8) | code. For IGMP, dst = type. Not reported for SCTP. . UDP and TCP traffic with both source and destination port == 0 – this is most probably a non-initial fragment. Check the extension map.

Router#show flow monitor cache format table

. 60 (Destination Options EH) as protocol – either a malformed packet, or a non- initial fragment (original packet was carrying a DST EH) . The extension map is key to perform additional analysis – which packets are fragmented, which packets are carrying a hop-by-hop/routing/destination options EH, AH, etc. . Examples: 0x00000284 = carrying RH, HbH and AH – 0x0000004C = RH, HbH and DST

Filtering and pattern matching on Netflow flows with CLI could add significant load on a production device, so the commands below SHOULD be used on production devices with special care . Flows with a source address from the 2001:db8:10::/48 prefix – show flow monitor cache filter ipv6 source add 2001:db8:10::/48 format table . Flows with a destination address of 2001:DB8:10:11:C:15C0:0:1 – show flow monitor cache filter ipv6 dest add 2001:DB8:10:11:C:15C0:0:1 format table . Flows with a source address not in the 2000::/4 prefix (currently allocated IPv6 space is 2000::/3 is reserved by IANA) – show flow monitor cache filter ipv6 source add regexp ^[^2] format table . TCP flows with an AH header (5 dots – regexp – 2 dots ) – show flow monitor cache filter ipv6 extension map regexp 0x.....[2-3|6-7|A-B|E-F].. ipv6 protocol 6 format table

. Flows carrying a Hop-by-Hop Extension header (6 dots – regexp – 1 dot) – show flow monitor cache filter ipv6 ext map reg 0x...... [4-7|C-F] format table . Fragmented traffic – includes both initial and non-initial fragments (7 dots – regexp) – show flow monitor cache filter ipv6 ext map reg 0x...... [2-3|6-9|C-D] format table . Flows from prefix 2001:db8:10::/48 to 2001:db8:10:100:c:15c0:20:12, aggregated by protocol and destination port, collecting number of packets and number of bytes, output sorted by number of bytes (highest first), only top 10 results – show flow mon cache filter ipv6 source add 2001:db8:10::/48 ipv6 dest add 2001:DB8:10:100:C:15C0:20:12 agg ipv6 proto trans dest coll count bytes count pack sort counter bytes top 10 format table

LTRSEC-2033 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public 54 Flexible NetFlow Extension Header Mappings – Cheat sheet IPv6 Extension Header FNF Regex Comments Non-initial fragments 0x…….[2-3|6-7] 7 dots Initial fragments 0x…….[8-9|C-D] 7 dots Any fragments (initial and non-initial) 0x…….[2-3|6-9|C-D] 7 dots Routing header (any type) 0x…….[4-7|C-D] 7 dots Unknown 0x……[1|3|5|7|9|B|D|F]. 6 dots + 1 dot Hop-by-Hop 0x……[4-7|C-F]. 6 dots + 1 dot Destination Options 0x……[8-9|A-F]. 6 dots + 1 dot Authentication Header 0x…..[2-3|6-7|A-B|E-F].. 5 dots + 2 dots Encapsulating Security Payload header 0x…..[4-7|C-F].. 5 dots + 2 dots i.e. Traffic carrying a hop-by-hop extension header show flow monitor monitor-podX cache filter ipv6 extension map regexp 0x...... [4-7|C-F]. format table

More info at http://www.cisco.com/web/about/security/intelligence/FNFIPv6.html

Dest Port = ICMPv6 type << 8 || ICMPv6 code = ICMPv6 type * 256 + ICMPv6 code

Type Code ICMPv6 message Destination Port 1 0 Destination Unreachable, No route to destination 256 Destination Unreachable, Communication with 1 1 257 destination administratively prohibited 2 0 Packet Too Big 512 Time Exceeded 3 0 768 Hop Limit Exceeded in Transit Parameter Problem 4 0 1024 Erroneous Header Field Encountered 128 0 Echo Request 32768 129 0 Echo Reply 33024

More info at http://www.cisco.com/web/about/security/intelligence/FNFIPv6.html

• The following three tasks are to be performed on both podX-rtr1 and podX-rtr2 (X being the pod number) 1. Create a flow record – name should be record-podX. The record should include the following key fields: IPv6 source address, IPv6 destination address, IPv6 protocol, IPv6 extension map, transport source port, transport destination port. Record should collect the following information: bytes, packets, routing forwarding status reason 2. Create a flow monitor – name should be monitor-podX. Reference the previously created record. Set the inactive flow timeout to 2 minutes 3. Attach the flow monitor to the interface connected to the service provider router on router podX-rtr1 and to the interface connected to router podX-rtr1 on router podX-rtr2.

4. Use “show” commands on podX-rtr1 to identify: 1. Traffic using a source address from your pod’s assigned /48 prefix (2001:db8:1::/48) 2. Traffic using a source address unallocated by IANA 3. Traffic sent to your servers (2001:db8:1:100::1, 2001:db8:1:101::1 and 2001:db8:1:103::1) 4. Traffic sent to your infrastructure prefixes (2001:db8:1:30::/60) 5. Protocols in use 6. Destination ports for TCP and UDP traffic, ICMPv6 types and codes 7. Traffic carrying a hop-by-hop extension header and any other header (hint: use cheat sheet) 8. Fragmented traffic – both initial and non-initial fragments

• Some attacks rely upon source address spoofing to be successful • Cisco IOS contains several capabilities to thwart source address spoofing – Unicast Reverse Path Forwarding (Unicast RPF) – IPv6 Source Guard, IPv6 Prefix Guard – Port Security – Access Control Lists • Deny your own addresses sourced externally • RFC-5156 defines “Special-Use IPv6 Addressing” (but addresses like Teredo, 6to4 are OK !) • IPv6 Bogons - http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt • IANA’s IPv6 Special Purpose Addresses - http://www.iana.org/assignments/iana-ipv6-special- registry/iana-ipv6-special-registry.xml • Every network should implement two forms of anti-spoofing protections: – Prevent spoofed addresses from entering the network – Prevent the origination of packets containing spoofed source addresses

• Alternative technique for filtering ingress packets that lack a verifiable source IP address, such as spoofed IP source addresses • Unlike anti-spoofing ACLs, Unicast RPF dynamically adapts to changing network conditions – By using the FIB for source address verification, no reconfiguration changes are required as a result of topology changes or new prefix assignments • Unicast RPF applies to all packets that ingress the configured interface – May be configured in conjunction with interface ACLs

• CEF is required • The purported source of ingress IPv6 packets is checked to ensure that the route back to the source is “valid” • Three Cisco flavors of Unicast RPF: – Strict mode Unicast RPF – Loose mode Unicast RPF – VRF mode Unicast RPF (not yet available for IPv6) • Introduced in Release 12.2(13)T

router(config-if)# ipv6 verify unicast source reachable-via rx

int 2 int 2 int 1 int 3 int 1 int 3

Sx D data Sx D data Sy D data

FIB FIB Dest Path Dest Path Sx int 1 Sx int 1 Sy int 2 S y int 2 Sz null0 S z null0 sourceIP=rx int?  sourceIP=rx int? 

router(config-if)# ipv6 verify unicast source reachable-via any

int 2 int 2 int 1 int 3 int 1 int 3

Sy D data Sy D data Sz D data

FIB FIB Dest Path Dest Path Sx int 1 Sx int 1 Sy int 2 S y int 2 Sz null0 S z null0 sourceIP=any int? sourceIP=any int?

Router#show ipv6 cef switching statistics feature IPv6 CEF input features: Feature Drop Consume Punt Punt2Host Gave route RP LES Access List 1063840 0 365987 0 0 RP LES Verify Unicast R 2983 0 0 0 0 Total 1066823 0 365987 0 0

IPv6 CEF output features: Feature Drop Consume Punt Punt2Host New i/f Total 0 0 0 0 0 Router#show ipv6 traffic | inc RPF 3056 RPF drops, 0 RPF suppressed drops Router#

LTRSEC-2033 © 2015 Cisco and/or its affiliates. All rights reserved. Cisco Public 74 Monitoring Unicast RPF Using Cisco IOS CLI show ipv6 interface, show cef interface internal (hidden) Router#show ipv6 interface | section IPv6 verify IPv6 verify source reachable-via rx 0 verification drop(s) (process), 10177 (CEF) 0 suppressed verification drop(s) (process), 0 (CEF) ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds (using 30000) ND RAs are suppressed (periodic) Hosts use stateless autoconfig for addresses.

Router#show cef int FastEthernet 0/0 internal | inc drop IPv6 unicast RPF: via=rx acl=None, drop=17836, sdrop=0 Router#

Block Leaving Source ≠ Own Network ipv6 access-list block-spoof-acl-out Enterprise: 2001:db8:172::/48 permit ipv6 2001:db8:172::/48 any deny ipv6 any any or ipv6 verify unicast source reachable-via rx LAN 2001:db8:172:16::/64

LAN ISP 2001:db8:172:17::/64

LAN Block Entering Source = Own Network 2001:db8:172:18::/64 ipv6 access-list block-spoof-acl-in Block Sources That Do Not Belong to Subnet deny ipv6 2001:db8:172::/48 any ipv6 access-list block-spoof-acl-in permit ipv6 any any permit ipv6 2001:db8:172:18::/64 any or ipv6 verify unicast source reachable-via rx allow- deny ipv6 any any default or ipv6 verify unicast source reachable-via rx

The following tasks are to be performed on podX-rtr1 (X being the pod number) 1. Using “show” commands on the Flexible NetFlow cache, identify traffic entering your network with source addresses from the 2001:db8:1::/48 prefix. This traffic is spoofed, as it is coming from the outside using your addresses. 2. Configure strict mode unicast RPF for IPv6 on the interface facing the attackers. Include the “allow-default” keyword to allow a FIB match on the default route 3. Use “show” commands to verify the unicast RPF drops.

• Basic premise: filter traffic destined to your core infrastructure devices – Do your core routers really need to process all types of traffic? • Develop list of required protocols sourced from outside your AS that require access to core routers – Example: eBGP peering, GRE, IPSec, etc. – Use classification ACL as required (more later) • Identify core address block(s) – This is the protected address space – Summarization is critical; simpler and shorter ACLs

• Infrastructure ACL will permit only required protocols and deny all others to infrastructure IP addresses • ACL should also provide anti-spoof filtering – Deny your own addresses sourced externally – RFC-5156 defines Special-Use IPv6 Addressing (Teredo, 6to4 listed but OK) – Deny IPv6 Bogons – Team CYMRU keeps an up-to-date list of bogons at http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt – IANA’s IPv6 Special Purpose Addresses - http://www.iana.org/assignments/iana-ipv6- special-registry/iana-ipv6-special-registry.xml – Careful – as of 2015-JAN, the Team CYMRU full bogon list for IPv6 is . . . 55,877 entries ! (did we mention that 2128 is A LOT of addresses ? )

• RFC-4890 provides recommendations for Filtering ICMPv6 Messages – Error messages (Unreachable, TooBig, Time Exceeded, Parameter Problem) – Connectivity checking (Echo Request and Reply) – Mobility messages – Neighbor Discovery (RS/RA, NS/NA, Redirect, etc) – SEND-related, MLD, etc • Non-initial fragments destined to the core can be filtered by using the fragments keyword – May impact DNSSEC – Do your infrastructure devices use DNS? – Will impact IPv6 traffic that has been fragmented due to tunneling – do you expect traffic to your infrastructure to traverse a tunnel?

• Infrastructure ACL must permit transit traffic – Traffic passing through the network must be allowed by a permit ipv6 any any • ACL is applied to interfaces in the inbound direction • log and log-input keywords can be used for additional detail – Hits to ACL entry with log will increase CPU utilization. Impact varies by platform. • Additional information is available on the “Understanding Access Control List Logging” whitepaper at – http://www.cisco.com/web/about/security/intelligence/acl-logging.html

Next Next Next Next Next Next Next header = 0 header = 60 header = 43 header = 44 Header = 51 Header = 50 Header = 6

IPv6 Hop-by-Hop Destination Routing header Fragment Authentication Encapsulating Security Protocol header header Options header Options header Payload header (TCP) header DATA header

Same as IPv4 TCP Header

• IPv6 Header Only EH that has hard • Hop-by-Hop Options Header requirements on both • Destination Options Header position and number of instances: only once per • Routing Header IPv6 packet, and if present, • Fragment Header only immediately following the IPv6 header. • Authentication Header • Encapsulating Security Payload Header • Destination Options Header • Upper Layer Header

• IPv6 Hop-by-Hop EH not switched in hardware – needs to be punted for additional processing, even if transit traffic • IPv6 RH type 0 with segleft > 0 should be dropped by new implementations (was deprecated by RFC5095) – but we only process this EH if we are the packet’s destination – “no ipv6 source-route” on Cisco IOS disables RH0 processing – buggy/overzealous implementations may drop even if segleft == 0 • EH are not malicious - legitimate protocols use IPv6 EHs – MLD traffic carries a HbH EH with a Router Alert option – Jumbo packets (payload > 65575) carry an HbH with a Jumbo option – Mobile IPv6 uses a Home Address option within a Destination Options EH – Mobile IPv6 makes extensive use of the Mobile IPv6 Extension Header

• Keywords for matching on IPv6 extension headers – hbh matches a Hop-by-Hop EH (new for IOS 15.2(3)T, 15.2(2)S) – routing matches any RH, routing-type matches on a specific RH type (RH0, RH2, etc) – fragment matches on the presence of a Fragment EH with a non-zero offset – auth matches on the presence of an Authentication Header – dest-option matches on the presence of a Destination Options EH, dest-option- type matches a specific option within the EH (dest-option-type has recently been deprecated) – mobility matches any Mobility EH, mobility-type matches a specific Mobility EH type

• Note: the availability and exact behavior of those keywords depend on hardware platform and software release – read the documentation for your specific platform and software release to understand what is supported, how it works, default behavior and any limitations.

• In IPv6, fragmentation is performed only by the end system – intermediate systems don’t perform fragmentation (drop, send back TooBig) • Packet is divided in two parts: unfragmentable and fragmentable. A Fragment EH is inserted after the unfragmentable section of the packet, and the fragmentable part is divided in as many packets as required, based on outgoing interface MTU. Each fragment but the last should be on a 64-bit boundary. • Reassembly is performed by the destination - just like in IPv4 – based on packets with same Source, Destination, Fragment ID • Additional rules apply for corner conditions • Miscreants may use fragmentation to hide the packet L4 information, making filtering traffic more difficult in some cases

• An ACL without the fragments keyword matches both non-fragments and fragments (initial and non-initial) – Scope of matching depends on ACE contents (only L3 information, L3 and L4 information) and packet type (non-fragment, initial fragment, non-initial fragment) – Action to take (deny, permit, process next ACE) depends on action on ACL (permit, deny) and packet type • An explicit match is achieved by using the fragments keyword – DNSSEC and tunnels are two possible sources of fragments – Remember: it only applies to non-initial fragments – initial fragments are handled through the other ACEs • Some initial fragments can also be matched against by using the undetermined-transport keyword • Behavior for matching fragments is NOT the same as on IPv4 !

• The undetermined-transport keyword matches on non-fragments, or the initial fragment, under the following conditions: – if the Upper Layer Protocol (ULP) is TCP, UDP or SCTP – if the source and destination ports are NOT within the packet, or – if the ULP is ICMPv6 – if the type and code are NOT within the packet, or – if the ULP is anything else (GRE, ESP, VRRP, OSPF, EIGRP, etc.) • In addition to that, an ACE including the undetermined-transport keyword can only reference the IPv6 protocol, and the only action allowed is DENY • This is a powerful tool to drop malicious fragments – but has the risk of breaking connectivity if not correctly implemented !

SRC: 2001:db8::1 SRC: Valid DST: Any DST: Rx (Any R) ACL “in” ACL “in”

PR1 PR2

R3 R1 R2