Ipv6 Network

#CLUS Designing and Deploying a Secure IPv6 Network

Timothy Martin - @bckcntryskr Eric Vyncke - @evyncke Christopher Werny - @bcp38_

TECRST-2001

#CLUS Agenda

• IPv6 Design Considerations

• IPv6 Routing Protocols

• IPv6 Translation Technologies

• IPv6 Only, A case study

• Securing the IPv6 Perimeter

• Conclusion

Questions? Use Cisco Webex Teams to chat with the speaker after the session How 1 Find this session in the Cisco Live Mobile App 2 Click “Join the Discussion” 3 Install Webex Teams or go directly to the team space 4 Enter messages/questions in the team space

Webex Teams will be moderated cs.co/ciscolivebot# TECRST-2001 by the speaker until June 16, 2019.

Tim Martin Solutions Specialist TECRST-2001 @bckcntryskr #2020

#CLUS Hardening IPv6 Management Plane

• SSH, SNMPv3, Syslog, NTP, NetFlow v9

• Disable HTTP/HTTPS access if not needed

• RADIUS over IPv6

• IPv6 access-class for SSH VTY access

• Important: Harden the router, before enabling routing ipv6 access-list V6ACCESS permit ipv6 2001:db8:10:10::1/128 any deny ipv6 any any log-input line vty 0 4 ipv6 access-class V6ACCESS in transport input ssh

• Enable IPv6 routing • ipv6 unicast-routing (ios) • no switchport (ios-xe) • IPv6 Next Hop • Link local addresses • Global address on interface not required • Topology & alignment with existing RP’s Management Routing • Router ID Switching Services • Unique 32-bit number identifier 

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 7 Routing Design Considerations ipv6 route ::/0 gigabitethernet0/1 • Do you need to accept the full table ipv6 router eigrp 123 • Memory, processing, capital.. eigrp stub • Single router, single circuit ipv6 router ospf 1 • Take a default route router-id 3.3.3.3 area 2 stub • Dual router, private circuit • Use stub command from IGP interface Fastethernet0/1 ipv6 address 2001:db8:46:67::a • Dual router, Internet circuit bfd interval 222 min_rx 222 multiplier 3 ! • Take default from provider router bgp 65110 neighbor 2001:db8:46:67::b fail-over bfd • Bidirectional forwarding detection

• Use a prefix length of /127 • Reserve the /64, configure the /127 • Nodes 1 & 2 are NOT in the same subnet

• Suppress RAs for global assigned addressing

• Disable ICMPv6 redirects interface FastEthernet0/1 ipv6 address 2001:db8:46:67::a/127 • Don’t send ICMPv6 unreachable ipv6 nd ra suppress • RFC 7404, Link local only no ipv6 redirects 2001:db8:46:67::/127 no ipv6 unreachables ::a ::b

• Link Local Next Hop ipv6 unicast-routing • Redistribution needs GUA or ULA !direct ipv6 route 2001:db8:1::/48 ethernet1/0 • Direct (interface) !recursive • Recursive (next hop) ipv6 route 2001:db8:5::/48 2001:db8:4::1 !fully qualified • Fully qualified (interface) (next hop) ipv6 route 2001:46::/32 ethernet0/0 fe80::9 !default • Default route ::/0 ipv6 route ::/0 ethernet0/2 fe80::2

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 10 IPv6 Routing Protocols OSPFv3 ipv6 unicast-routing ! • OSPFv3 – IP 89 interface loopback0 • fe80::/64 Source  ff02::5, ff02::6 (DR’s) ipv6 address 2001:db8:1000::1/128 • Link-LSA (8) – Local Scope, NH ipv6 ospf 46 area 0 • Intra-Area-LSA (9) – Routers’ Prefixes ! interface ethernet 0/0 • LSA’s Disconnect topology from prefixes ipv6 address 2001:db8:50:31::1/64 • Can converge quickly to a point of scale ipv6 ospf 46 area 0 • Initial database build takes time ! ipv6 router ospf 46 router-id 4.6.4.6 passive-interface loopback0

LSPs* full mesh

router ospfv3 46 • Multiple AF’s (RFC5838) router-id 4.6.4.6 ! • Legacy IPv4 prefixes address-family ipv6 unicast • IPv6 prefixes passive-interface Loopback 0 exit-address-family • Transport over IPv6 ! address-family ipv4 unicast • Common elements passive-interface Loopback 0 • Neighbor table exit-address-family ! • Link State Data Base (LSDB) interface GigabitEthernet 0/2 ip address 192.168.4.1 255.255.255.0 • Show command structure ipv6 enable • ip ospf (IPv4 over OSPFv2) ospfv3 46 ipv4 area 0 ospfv3 46 ipv6 area 0 • ipv6 ospf (IPv6 over OSPFv3) sh ip route ospfv3

• AH for authentication (RFC4552) interface Ethernet0/0 ipv6 ospf 46 area 0 • Manual key process ipv6 ospf authentication ipsec spi 500 sha • ESP could be used for confidentiality 1234567890ABCDEF1234567890ABCDEF • Need a security license for IPsec key chain AUTH • RFC7166 Authentication Trailers key 1 • Anti-replay key-string RFC • HMAC-SHA-1, 256, 384, 512 cryptographic-algorithm hmac-sha-512 ! address-family ipv6 unicast authentication mode strict area 0 authentication key-chain AUTH

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 14 Classic EIGRP or EIGRPv6 ipv6 unicast-routing • EIGRP – IP 88 ! Interface ethernet 0/0 • fe80::/64 Source  ff02::a Destination ipv6 address 2001:db8:1000::1/128 • No shutdown for older versions ipv6 eigrp 46 ! • Apply the route process to interfaces interface ethernet 0/1 • Auto Summary disabled ipv6 address 2001:db8:50:31::1/64 ipv6 eigrp 46 • Transport & peering over IPv6 ! ipv6 router eigrp 46 no shutdown eigrp router-id 4.6.4.6

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 15 EIGRP Named Mode router eigrp IPv6rocks ! • Name creates a virtual instance address-family ipv6 unicast • Does not need to be common in domain autonomous-system 46 ! • Address family configures protocol instance af-interface Loopback0 passive-interface • AS number must common within domain exit-af-interface ! • Auto Applied to all IPv6 enabled interfaces af-interface Ethernet0/0 exit-af-interface • No need to configure under the interfaces eigrp router-id 4.6.4.6 exit-address-family

Large-scale hub and spoke environments

• EIGRP supports HMAC-SHA-256

• To generate or validate messages, hash is constructed using: • Configured shared secret • Link Local address of sender • EIGRP packet prior to adding the IP header

! router eigrp IPv6rocks address-family ipv6 autonomous-system 46 af-interface ethernet 0/0 authentication mode hmac-sha-256 0 Cisco123 !

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 17 IS-IS ipv6 unicast-routing ! interface ethernet 0/0 • Single topology mode ipv6 address 2001:db8:5000:31::1/64 • Single LSDB, single cost ipv6 router isis CISCO isis circuit-type level-1 • Links must be congruent (dual stacked) isis ipv6 metric 10000 • Multi topology mode isis authentication mode md5 ! • LSDB & cost per protocol router isis CISCO • Flexible, transition mode available net 49.0001.2222.2222.222.00 • Authentication uses MD5 (TLV) metric style wide ! A B C A B C A B C address-family ipv6 D E D E D E multi-topology Physical Topology IPv4 SPT IPv6 SPT SPs, Underlay’s

ipv6 unicast-routing • RIPng – UDP 521, 15 hops ! • fe80::/64 Source  ff02::9 Destination interface loopback 0 ipv6 address 2001:db8:1000::1/128 • Distance Vector, Hop Count (1-15) ipv6 rip CISCO enable • Split Horizon, Poison Reverse ! interface ethernet 0/0 • Lightweight IPv6 only protocol ipv6 address 2001:db8:5000:31::1/64 • Uses AH for authentication ipv6 rip CISCO enable ! ipv6 router rip CISCO Star topology, single path edge devices

• RFC 6296 - NPTv6 Internet • Translators attached to internal network • Unique Local Addressing (ULA) inside • Provider allocated addressing outside

• Swaps Left Most Bits of Address • Equal length Prefixes 2001:db8:46::/48

• Small-to-Medium Enterprise interface GigabitEthernet0/0/0 fd07:18:4c::/48 nat66 inside interface GigabitEthernet0/0/1 nat66 outside ! nat66 prefix inside fd07:18:4c::/48 outside 2001:db8:46::/48

• Solve for Ingress & Egress separately Internet

• Peer over IPv6 for IPv6 prefixes ISP A ISP B

• Controlling hop limit, accepting ~254 only

• MD5, AH possible, next-hop-self (fe80::)

• Prefix Size Filtering, /32 - /48 router bgp 200 bgp router-id 4.6.4.6 no bgp default ipv4-unicast neighbor 2001:db8:460:102::2 remote-as 2014 neighbor 2001:db8:460:102::2 ttl-security hops 1 neighbor 2001:db8:460:102::2 password cisco4646

• Equal load distribution

• Advertise more specific /45 & /44 Ingress Internet

• Non equal load distribution ISP A ISP B AS 64499 AS 64497 • Use AS path prepend, if accepted 2001:db8:a1::/32 2001:db8:b1::/32 ipv6 prefix-list ISPAout seq 5 2001:db8:460::/44 ipv6 prefix-list ISPAout seq 10 2001:db8:460::/45 ! ipv6 prefix-list ISPBout seq 5 2001:db8:460::/44 ipv6 prefix-list ISPBout seq 10 2001:db8:468::/45 2001:db8:460::/44 Enterprise Domain neighbor 2001:db8::b1 route-map ISPBout out ! route-map ISPBout permit 10 set as-path prepend 64498 64498 64498 64498

• Accept the full table from provider A • Filter everything except the aggregate 2001::/18 Internet

• Accept the full table from provider B ISP A ISP B AS 64499 AS 64497 • Use local-preference for ::/0 2001:db8:a1::/32 2001:db8:b1::/32 ipv6 prefix-list ISPAin seq 5 permit ::/0 ipv6 prefix-list ISPAin seq 10 permit 2001:0000::/18 le 32 neighbor 2001:db8::b1 prefix-list ISPBin seq 5 permit ::/0 neighbor 2001:db8::b1 route-map LOCAL in

! Egress 2001:db8:460::/44 Enterprise Domain ipv6 prefix-list ISPBin seq 5 permit ::/0 route-map LOCAL permit 10 set local-preference 200

• Firewalls are redundant and share state Internet • Common VLAN between the firewalls & routers ISP A ISP B

• Hot Standby Router Protocol (HSRP)

• Default routes on firewall to HSRP groups HSRP 1 ! Send first aggregate block to HSRP Group 1 HSRP 2 ipv6 route outside 2001:0000::/18 2001:db8:46::1 ! Send Second aggregate block to HSRP Group 2 VLAN 46 ipv6 route outside 2001:4000::/20 2001:db8:46::2 ipv6 route outside 2001:8000::/22 2001:db8:46::2 ipv6 route outside 2001:5000::/20 2001:db8:46::2 ipv6 route outside 2400:0000::/6 2001:db8:46::2 ipv6 route outside 2800:0000::/5 2001:db8:46::2

• IGP between edge routers & Layer 3 switch Internet • EIGRP, OSPF, iBGP, IS-IS ISP A ISP B • Edge routers redistribute ::/0 (or Prefixes) into IGP

• Layer 3 Switch has static route for PI address ::/0 • Set to next-hop of the firewall

• Firewall has a default route 2001:db8:46::/44 • Pointed at the Layer 3 switch ip route outside ::/0 2001:db8:37::1

Internet • Internet connectivity is split across two data centers ISP A ISP B • Each firewall is active; state is not shared AS 64498 • Advertising the /44 out both could cause asymmetry • NAT solves this problem for the legacy protocol • More specific routes plus aggregate needed for IPv6 • IPv6 will require an iBGP peer link at Internet edge • Protects against failure • Provides better outbound load distribution AS 65535 AS 65534 • Alternatives exist, use with caution Subnets Subnets • GRE thru the DCI link X,Y,Z EIGRP 46 A,B,C • Layer 3 VPN service over ISP

Internet • Create eBGP multihop link to the core routers ISP A ISP B

• Advertise default route over this link to core routers AS 64498 • Redistribute the default route into the IGP

• Increase the metric for the default route router bgp 65535 neighbor 2001:db8:460:66::2 remote-as 64498 ::/0 ::/0 neighbor 2001:db8:460:66::2 ebgp-multihop 255 ! router eigrp 46 AS 65535 AS 65534 redistribute bgp 65535 metric * * * * * route-map BGP-EIGRP ::/0 ! >M ipv6 prefix-list DEFAULT seq 5 permit ::/0 EIGRP 46 ! route-map BGP-to-EIGRP permit 10 match ip address prefix-list DEFAULT

Internet • Redistribute subnets from IGP into BGP ISP A ISP B • Use a route map with set command X,Y,Z MED AS 64498X,Y,Z >MED • Internet edge routers install prefixes • bgp always-compare-med

router bgp 65535 neighbor 2001:db8:460:66:2 remote-as 64498 neighbor 2001:db8:460:66:2 ebgp-multihop 255 redistribute eigrp 46 route-map MED ! AS 65535 AS 65534 route-map MED permit 10 match ipv6 prefix-list SUBS Subnets Subnets set metric 200 X,Y,Z X,Y,Z EIGRP 46 A,B,CA,B,C ! ipv6 prefix-list SUBS seq 10 permit 2001:db8:460::/45

• RFC 7381 enterprise IPv6 guidelines • Updated white paper – Cisco.com • Routed access, routed host, IPv6 only?

Access

Distribution Si

Core

Distribution

Access WAN Data Center Internet

Christopher Werny TECRST-2001

@bcp38_ Make the world a safer place

#CLUS Introduction & Motivation Motivation of this Presentation

• We are involved in a project where $COMPANY plans to enable IPv6 in up to 10K WiFi hotspots in supermarkets in Western Europe • (with expected 50-100k concurrent users)

• One of the first questions discussed during the initial meeting(s) • Shall we go Dual-stack or v6-only?

• An increasing number of organizations currently consider implementing IPv6 in a specific mode often called “v6-only + NAT64”.

• Some conferences already implement this in their WiFi networks: • Troopers ;-) • FOSDEM • Cisco Live Europe

https://insinuator.net/2019/02/some-notes-on-the-ipv6-properties- of-the-wireless-network-cisco-live-europe/

• Theory that seeks to explain how new ideas and technology spread.

• The more consumers will adopt a certain technology, the market share will reach a saturation level.

• Where are we today in regards to IPv6 adoption?

• Hint: Keep that 34% in mind ;-)

https://en.wikipedia.org/wiki/Diffusion_of_innovations

• Dual Stack increases the overall complexity of the network significantly

• Everything (on the infrastructure level) needs to be maintained for both protocols • Routing Protocols • Security Policy • QoS • Yadda...yadda....yadda

• Depending on the environment, more layers of NAT are necessary • Mergers & Acquisition et. al.

• Prices have gone up steadily in the last couple of years.

• Currently, a /16 equates to 1.245.165$ • 19$ per address

• Prices for smaller network are even higher • 26$ per address for a /24

• Going IPv6-only without a translation mechanism is currently not a feasible solution.

• 73% of all Websites are still IPv4-only 

• In order to ensure a smooth user experience, packets need to be translated from IPv6 to IPv4 to provide connectivity to v4-only resources

• Stateful NAT64 is a mechanism to translate IPv6 packets to IPv4 and vice-versa. • A specific (arbitrary) prefix (/96) from your address space will be used for translation.

• NAT64 is in basically all deployments used in conjunction with DNS64.

• DNS64 sythesis AAAA records from A records • As the IPv6-only systems is only asking for AAAA records.

DNS64

2. IPv6-Only Client 1. 3. 4.

NAT64 6. 5.

IPv6-only internal network

• Works reliable for • TCP • UDP • ICMP

• Does not work for protocols that embed IPv4 literals in the payload of the packet • FTP • SIP

• Separate ALG necessary if translation of these packets shall succeed

• Some Network Elements do not support dual stack.

• T-Mobile has successfully deployed IPv6-only networks.

• Full control on mobile devices and only allow IPv6-only compatible devices.

• RFC6877 464xLAT, “fixes” broken code for now

Handset Carrier Network Internet

Legacy Edge Application Services IPv4 4 IPv6 4 CLAT only PLAT 6 6

Intelligent IPv6 Application

• End-to-end IPv6: Facebook, Google, Wikipedia, Yahoo, Youtube … IPv6IPv6

• Application supports IPv6 (web browser), but the server is only IPv4, so DNS64/NAT64 translates IPv6IPv4

• Application does not support IPv6, the client must provide a stateless NAT46 to the application and stateful NAT64 must be in the network: IPv4IPv6IPv4

• $COMPANY plans to enable IPv6 in up to 3K Wi-Fi hotspots in supermarkets in Western Europe • Dual-stack or v6-only?

• Free offering → no SLAs

• But still they’d like to avoid “discussions which could affect their brand”.

• Dual-Stack vs. v6-only (+NAT64) • From “IPv6 perspective” the most important one

• Lots of misinformation floating, in different circles • Which is why we built the lab -> covered in a second

• Thoroughly consider users, platforms, applications and expectations.

• Timeline might play a role, too.

• Audience • Expectations ( communication) • Types of devices (platforms, OSs, versions!) • Types of applications (e.g. gaming vs. VPN clients)

• Requires • Definition • Testing • Communication & mgmt/sponsor approval

• As of 06/2019 (→ issues might b gone 07/2019…) • Gaming (namely multiplayer) • VPN clients • But a lot of things (progress) seem to happen in this space right now.

• Please note: it is crucial that you perform your own testing if needed. This exact slide should *not* be used to spread FUD in future discussions ;-)

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 55 Types of Connections / Initial Thoughts Will most certainly work. + Very likely to work, but individual apps might expose problems. ++ Initial Thoughts Unclear. Will heavily depend on specific circumstances. ? Problems to be expected. –

Connection Endpoint IPv6 IPv4 Type of Client Device All Web Fat VPN VPN Other Client/ Client Client App (SSL) (IPsec) Smartphones iOS ++ ++ + ++ – + Android ++ ++ ++ ++ – + Other ++ ++ + ++ – + Laptops Windows, ++ ++ + ++ – + Pre–10 Windows 10 ++ ++ ++ ++ – + Other ++ ++ ? ++ – + Other IoT Devices ++ ++ ? ++ – +

• When we look into the legacy dual stack network, we notice that for the IPv4 traffic distribution we see outgoing • ~214M TCP packets and • ~6M ESP (VPN) packets while incoming was • ~394M TCP packets with • ~8M ESP packets

Src: https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc

• This means that at least about 2-3% of all traffic was on an IPSEC VPN. And this excludes the TCP VPN traffic on ports 443/TCP and 22/TCP. On the IPv6 network we do not see a similar amount of ESP traffic.

• This strongly suggests that the people remaining on the dual stack network do so because their VPN solution does not work with an IPv6 only network.

Src: https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc

Numbers/problems will get less/decrease over time

Connection Endpoint IPv6 IPv4 Type of Client Device All Web Fat VPN VPN Other Client/ Client Client App (SSL) (IPsec) Smartphones iOS ++ ++ + ++ – + Android ++ ++ ++ ++ – + Other ++ ++ + ++ – + Laptops Windows, ++ ++ + ++ – + Pre-10 Windows 10 ++ ++ ++ ++ – + Other ++ ++ ? ++ – + Other IoT Devices ++ ++ ? ++ – +

• IPv6-enabled connection endpoints (e.g. websites/servers) increase over time.

• Client-side apps increasingly support IPv6, not least due to Apple's respective requirements (2016).

• Overall IPv6 support of client OSs and "exotic applications" continuously gets better.

• Pretty small and basic setup:

• Cisco ISR 4321 as NAT64 GW • Running Everest-16.6.5 MD

• Unbound 1.9.0 as DNS64 resolver

• WLC + AP for Wifi Connectivity • Running 8.5.140.0 ED

ISR4321 R1 NAT64 The Lab – Overview

WLC

Server Access DNS64 point

Laptop iOS Android

• Windows 10 – Build 1809 / Windows 7

• macOS 10.14 – Mojave

• Apple iOS – 12.1.4

• Arch Linux – Kernel 4.19

• Android 9 Pie (API 28)

• Group applications in categories. • e.g. Social Media, Communication etc.

• Define first set of (potential) relevant applications to be tested.

• Define test cases for each app

• Perform the tests

• (Try) to evaluate root cause for failed test cases

• Social Media

• Streaming

• Communication

• Games

• Informational

• Other

• OS-wise iOS apps successfully completed all test cases • Maybe not a surprise given Apple’s strategy

• Most categories worked quite nicely, e.g. • Social Media • Communication

• Issues were mostly identified in two areas • Games • Streaming

• In general, we could observe two failure scenarios:

• Either the app just doesn’t work at all without IPv4

• In general the app works but some functionality is limited.

“Enabling IPv6 for a client application is not technically a big deal.....

....Unfortunately our client code had its own IP-address type which didn’t support IPv6, and it also assumed that an IP-address would fit in 4 bytes in numerous places....”

Src: https://labs.spotify.com/2015/11/05/ oh-ipv6-where-art-thou/

https://community.spotify.com/t5/Live- Ideas/Other-IPv6-Support/idi-p/4469460

• Unfortunately, the Spotify app on Windows 10/7/macOS does not work. • The web client and iOS/Android work as intended

• No network activity could be observed. We assume the client tries to open a IPv4 socket, which of course fails.

• Downloading and installing worked without a problem.

• Unfortunately, the updater (that is run on every start) fails with a “connection problem”.

• As with Spotify, no network activity could be observed -> potentially tries to open IPv4 socket.

• “Hottest“ Battle Royal game for a year or two.

• Based on the Unreal engine developed by Epic.

• To play Fortnite, one has to install the Epic Games Launcher.

• XMPP doesn’t work.....

• You can join the lobby, download content and contact the matchmaking server.

• Unfortunately, during the loading screen you get a network connectivity lost error and are back in the lobby.

• Wasn’t able to verify what exactly causes the game to fail until now -> further research necessary.

• https://answers.unrealengine.com/questions/583305/bug-dedicated-server-connection-issues-with-ipv6-n.html

https://www.unrealengine.com/en-US/blog/unreal-engine-4-21-released Nov 2018

• We tested around 35 different applications with a total of 120 test cases • On (if available) six different operating systems.

• Only three applications didn’t work at all on non-mobile operating systems.

• Two applications had some feature limitations • E.g. not able to join a voice channel @Discord

• While we still see some (minor) breakage (that was to be expected) it is lower than we initially anticipated.

• Apps on mobile devices (Android/iOS) work just fine in an IPv6-only environment.

• Still, there is some work to do primarily for applications installed on your “typical” workstation.

• Validate / further investigate failure cases

• Vendor communication!

• Probably even easier when the vendor is the only failing one in a group of similar apps ;-)

• WLANs are shared media • Ftr: yes, even with 802.11ax ;-)

• IPv6 communication on the local link involves a lot of multicast. How does that translate to/affect traffic

• On air See also: • Between APs serving “[the same] IP subnets” https://www.troopers.de/medi a/filer_public/5b/34/5b340a5 8-2c8e-46a0-9d96- 834e5edd9154/tr16_ipv6_se c_summit_secure_reliable_gu est_wlan_v15.pdf • Some ongoing discussion, e.g. • IETF I-D IPv6 Neighbor Discovery on Wireless Networks. draft-thubert-6man- ipv6-over-wireless

• Some tuning is needed • (WLAN) Controller level • Which (of the above) to proxy/throttle/block • Inter-AP communication

• L3 infrastructure • Properties of RAs • Properties of ND • Other (e.g. MLD[?])

FHS Feature Default Configurable? RA Guard Enabled Yes (only on APs) DHCPv6 Guard Enabled No IPv6 Source Guard Enabled Yes IPv6 ACLs Disabled Yes

• To reduce the multicast traffic the following parameters adjusted in Troopers network:

• Router lifetime to 9000 seconds

• Reachable lifetime to 900 seconds

• Unicast solicited RAs

• The above are some “best practice” values, initially inspired by Andrew Yourtchenko from the Cisco Live Wi-Fi implementation.

interface GigabitEthernet0/0/0.30 description ====TRP-NAT64=== encapsulation dot1Q 30 ipv6 address FE80::1 link-local ipv6 address 2A02:8071:F00:64::1/64 ipv6 enable ipv6 mtu 1280 ipv6 nd reachable-time 900000 ipv6 nd other-config-flag ipv6 nd router-preference High ipv6 nd ra solicited unicast ipv6 nd ra lifetime 9000 ipv6 nd ra interval 4 ipv6 nd ra dns server 2A02:8071:F00:64::251 ipv6 dhcp server DHCP-TRP-NAT64-v6-POOL nat64 enable

• Infrastructure • Captive Portal (usually 3rd party provider)  IPv6? ;-) • Management & WLC/AP-communication  IPv6? ;-) • Telemetry

• Processes

• Communication • Users • Feedback loop re: stuff not working • Management / Sponsor • Vendors (of apps that don’t work)

• We wanted to get a feeling about the NAT64 translations that are active on our gateway during Troopers at any given time.

• But how do we get these data? • SNMP? Unfortunately there is no OID we can query to get the active translations.

• One nice person on the c-nsp list send me a clever workaround • Thank you Nikolay!

• While he had initially created the EEM template for IPv4 NAT entries, we could adjust it easily to our needs

1. Perform the relevant “show commands” • Show nat64 translations in this case

2. Parse the output with some Regex magic

3. Store this value in a SNMP “Expression” MIB

4. Query OID over SNMP to retrieve the value.

5. Rinse and repeat every 30 seconds

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 100 Complete EEM Template > snmp mib expression owner NAT64 name NAT64TRANSLATIONS > description Total active translations > value type integer32 > expression 0 > ! > event manager applet NAT64-Translations > event timer watchdog time 300 maxrun 60 > action 010 cli command "enable" > action 030 cli command "configure terminal" > action 040 cli command "do-exec show nat64 translations" > action 050 regexp "^.+\s([0-9]+)" "$_cli_result" match total_translations > action 100 cli command "snmp mib expression owner NAT64 name NAT64TRANSLATIONS" > action 110 if $_regexp_result eq "1" > action 120 cli command "expression $total_translations" > action 130 else > action 140 cli command "expression 0" > action 150 cli command "exit" > action 160 end

• We also wanted to a get a feeling to which degree client systems use either the RA or (stateless) DHCPv6 provided DNS resolvers.

• To achieve this, we installed two instances of unbound, provided those per RA and DHCPv6 respectively, and counted the total amount of DNS queries each of them received.

• In general you should be very cautious re: telemetry (not only DNS-related) in Wi-Fi hotspot type of networks. • Evidently some data points might be privacy-invasive. • Regulations might kick in, even conflicting ones.

• How to incentivize users to use the v6-only SSID if there’s a “legacy” (usually: dual-stacked) in parallel?

• How to provide feedback loop for stuff not working? • “Go to vendor” [+ “here’s a template”] vs. • Common generic customer support channels

• We see an increasing interest in deploying v6-only + NAT64 networks. • For reasons…

• Testing creates #transparency ;-) & well-informed decision making

• Overall less issues than expected • Apple’s strategy seems to work. • Communication strategy will be crucial, with management, users & vendors.

• Deploying IPv6-enabled Wi-Fi hotspots requires specific considerations and tech. adjustments • Define strategy re: v6-only • Perform specific configuration on devices • Monitoring & telemetry

• Communication with users, vendors, mgmt.

• Based on our testing we think that going with v6-only (+ NAT64) is a reasonable approach now • Only very few issues (stuff not working) to expect • Namely on platforms or types of app which might not even be relevant for your deployment scenario • At the same time this can save a lot of operational effort. • Telemetry data & lab results are always a good idea ;-) • Proper supporting communication can be helpful.

• Note: for most scenarios distributing DNS resolvers via RAs/RDNNS and stateless DHCPv6 to be strongly considered.

• While we have seen that IPv6-only might make sense in the Access Layer, what about DCs?

• Where should I start? Or should I start at all?

• What works and what not?

• Questions, Questions, Questions....

• How did the Datacenter look like?

• Backbone/Core Network

• Management Network

• Staging environment

• Internal/Intranet Applications • Running on the production servers

• After several discussion rounds, it was decided (wisely) to deploy IPv6 within the staging environment first.

• First round of deployment was performed for the infrastructure systems. • Includes DNS, RADIUS, Syslog, SMTP, NTP etc.

• The most sensible approach (that also a number of other players do) is:

• Add v6 to the systems in scope, but do NOT publish AAAA records for these services yet. • Verify the correct behaviour of the system after v6 is active.

• Gradually add AAAA to “activate” the communication to these service over IPv6

• In short: It depends ;-)

• As I laid out in the morning session, from our perspective you have the following options: • Fully static configuration -> includes deactivation of RA processing on the host • „Hybrid” -> static configuration with default route via RA. • Stable “dynamic” addresses (RFC 7217) with dynamic DNS updates • DHCPv6 with reservations

• Regardless of how the gateway will be provided: Choose ONE link-local address (e.g. fe80::1) and use it everywhere. This simplifies the provisioning significantly

• Some apps work just fine with IPv6 and some don’t work as expected: Testing is key/crucial!

• What we have observed (and others have made the same observation): • DNS works just fine (as it is transport protocol independent) • Kerberos (to our surprise) works just fine as well • NTP somewhat works, but there are some intricacies • Syslog just works (under the assumption the receiver listens on IPv6) • SSH works just fine as well • SNMP works just fine (same as DNS)

• Hadoop Cluster • Getting better, but still not there yet -> https://issues.apache.org/jira/browse/HADOOP-11890

• Jira/Confluence • Somewhat limited supported -> https://confluence.atlassian.com/jirakb/ipv6-in-jira-949755622.html

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 115 Monitor Progress!! • I cannot stress this enough. It is very important that you track your progress to have good visibility where you are currently at with the deployment.

Source: https://www.ipv6.org.uk/wp-content/uploads/2018/11/IPv6-presentation-linkedin-The-Beginning-of-the-End.pdf

• As already laid out in the beginning. Dual stack significantly increases the overall complexity and operational effort.

• While getting IPv6 on the street within your datacenter will not work without a Dual stack implementation (exceptions are green field deployments), treat it as an interim step.

• Your overall goal MUST be to remove IPv4 from systems where feasible, otherwise you might run into trouble in later stages/phases of your transition.

• It helps to have a plan ;-)

• Measure! your progress! Do it in a controlled manner

• IPv6 still (suprise ;-)) requires people to deal with it: • Operators (system, network, help desk et. al.) • Developers -> Get them on board ASAP • Managers -> They need to understand what and why your are doing it • Corporate Lawyers -> to deal with external suppliers / contractors etc.

• If you happen to have the chance to do a „clean switch“ -> Do it!

• Core services (routing, infrastructure services) work well in an IPv6- only environment.

• Applications you rely on might not fully support IPv6 yet. • Be prepared -> Wave with your wallet.

RFC1918 RFC1918 10.0.0.0/8 10.0.0.0/8 Shared Datacenter

RFC1918 10.0.0.0/8

• Microsoft Directory Services do not work well through NAT boundaries

• Official Microsoft stance: • Active Directory over NAT has not been tested by Microsoft. • We do not recommend Active Directory over NAT. • Support for issues related to Active Directory over NAT will be very limited and will reach the bounds of commercially reasonable efforts very quickly.

Source: https://support.microsoft.com/en-us/help/978772/description-of-support-boundaries-for-active-directory-over-nat

• Implement a centralized Authentication Service within the datacenter • Do this in an IPv6-only fashion.

• Due to some constraints, AD of the affiliates has been implemented in Dual-Stack fashion.

• Communication is IPv6-only between these systems • No NAT issues for AD communication

• Overall this worked quite well without any (IPv6-related) issues.

Eric Vyncke TECRST-2001 @evyncke

#CLUS IPv6 Security Myths… IPv6 Myths: Better, Faster, More Secure

Sometimes, newer means better and more secure

Sometimes, experience IS better and safer!

Source: Microsoft clip-art gallery

• Default subnets in IPv6 have 264 addresses • 10 Mpps = more than 50 000 years

Source: Microsoft clip-art gallery

• If using EUI-64 addresses, just scan 248 • Or even 224 if vendor OUI is known...

• Public servers will still need to be DNS reachable • More information collected by Google...

• Increased deployment/reliance on dynamic DNS

Source: Microsoft clip-art gallery • More information will be in DNS

• Using peer-to-peer clients gives IPv6 addresses of peers

• Harvest NTP client addresses by becoming a member of pool.ntp.org

• Administrators may adopt easy-to-remember addresses • ::1,::80,::F00D, ::C5C0, :ABBA:BABE or simply IPv4 last octet for dual-stack

• By compromising hosts in a network, an attacker can learn new addresses to scan

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 128 Scanning Made Bad for CPU Remote Neighbor Cache Exhaustion (RFC 6583) Potential router CPU/memory attacks if aggressive scanning • Router will do Neighbor Discovery ….And waste CPU and memory

NS: 2001:db8::3

NS: 2001:db8::2

NS: 2001:db8::1

NS: 2001:db8::3

NS: 2001:db8::2

NS: 2001:db8::1

NS: 2001:db8::3

NS: 2001:db8::2

NS: 2001:db8::1

2001:db8::/64

• Built-in rate limiter with options to tune it • Since 15.1(3)T: ipv6 nd cache interface-limit • Or IOS-XE 2.6: ipv6 nd resolution data limit • Destination-guard is part of First Hop Security • Priority given to refresh existing entries vs. discovering new ones

• Using a /64 on point-to-point links => a lot of addresses to scan! • Using /127 helps (RFC 6164) or even link-local address only (RFC 7404)

• Internet edge/presence: a target of choice • Ingress ACL permitting traffic to specific statically configured (virtual) IPv6 addresses only

• Using infrastructure ACL prevents this scanning • iACL: edge ACL denying packets addressed to your routers • Easy with IPv6 because new addressing scheme  http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1

• IPv6 originally mandated the implementation of IPsec (but not its use)

• Now, RFC 6434 “IPsec SHOULD be supported by all IPv6 nodes”

• Some organizations still believe that IPsec should be used to secure all flows... • Need to trust endpoints and end-users because the network cannot secure the traffic: no IPS, no ACL, no firewall • Network telemetry is blinded: NetFlow of little use • Network services hindered: what about QoS or AVC ?

Recommendation: do not use IPsec end to end within an administrative domain.

Suggestion: Reserve IPsec for residential or hostile environment or high profile targets EXACTLY as for IPv4

• Network Prefix Translation, NPTv6, RFC 6296, • 1:1 stateless prefix translation allowing all inbound/outbound packets. • Main use case: multi-homing (see first section)

• Else, IETF has not specified any N:1 stateful translation (aka overload NAT or NAPT) for IPv6

• Do not confuse stateful firewall and NAPT* even if they are often co-located

• Nowadays, NAPT (for IPv4) does not help security • Host OS are way more resilient than in 2000 • Hosts are mobile and cannot always be behind your ‘controlled NAPT’ • Malware are not injected from ‘outside’ but are fetched from the ‘inside’ by visiting weird sites or installing any trojanized application

NAPT = Network Address and Port Translation

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 132 “By looking at the IP addresses in the Torpig headers we are able to determine that 144,236 (78.9%) of the infected machines were behind a NAT, VPN, proxy, or ﬁrewall. We identiﬁed these hosts by using the non- publicly routable IP addresses listed in RFC 1918: 10/8, 192.168/16, and 172.16-172.31/16”

Stone-Gross et al., “Your Botnet is My Botnet: Analysis of a Botnet Takeover”, 2009 http://www.cs.ucsb.edu/~rgilbert/pubs/torpig_ccs09.pdf

“Early 2017, a multi-stage Windows Trojan containing code to scan for vulnerable IoT devices and inject them with Mirai bot code was discovered. The number of IoT devices which were previously safely hidden inside corporate perimeters, vastly exceeds those directly accessible from the Internet, allowing for the creation of botnets with unprecedented reach and scale.”

“The call is coming from inside the house! Are you ready for the next evolution in DDoS attacks?” Steinthor Bjanarson, Arbor Networks, DEFCON 25

ICMP Message Type ICMPv4 ICMPv6 • Significant changes Connectivity Checks X X Informational/Error X X • More relied upon Messaging Fragmentation Needed X X Notification Address Assignment X Address Resolution X Router Discovery X Multicast Group Management X Mobile IPv6 Support X

=> ICMP policy on firewalls needs to change

Internet

ICMPv4 ICMPv4 Action Src Dst Name Type Code

Permit Any A 0 0 Echo Reply

Permit Any A 8 0 Echo Request

Dst. Unreachable— Permit Any A 3 0 Net Unreachable Dst. Unreachable— Permit Any A 3 4 Frag. Needed Time Exceeded— Permit Any A 11 0 TTL Exceeded

ICMPv6 ICMPv6 Action Src Dst Name Type Code

Permit Any A 128 0 Echo Reply Needed for Teredo traffic Permit Any A 129 0 Echo Request

Permit Any A 1 0 Unreachable

Permit Any A 2 0 Packet Too Big

Time Exceeded— Permit Any A 3 0 HL Exceeded

Permit Any A 4 0 Parameter Problem

Internal Server A Firewall B Internet

ICMPv6 ICMPv6 Action Src Dst Name Type Code

Permit Any B 2 0 Packet too Big For locally generated Permit Any B 4 0 Parameter Problem by the device Permit Any B 130–132 0 Multicast Listener

Neighbor Solicitation Permit Any B 135/136 0 and Advertisement

Deny Any Any

• https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa- 20160525-ipv6 (May 2015)

• RFC 4890 is a little too open

• RFC 4861 (Neighbor Discovery) • Hop Limit MUST be 255 • Source should be link-local, unspecified or global address belonging to the link and not "any"

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 141 IPv6 Attacks with Strong IPv4 Similarities Good news IPv4 IPS signatures can • Sniffing be re-used • IPv6 is no more or less likely to fall victim to a sniffing attack than IPv4 • Application layer attacks • The majority of vulnerabilities on the Internet today are at the application layer, something that IPSec will do nothing to prevent • Rogue devices • Rogue devices will be as easy to insert into an IPv6 network as in IPv4 • Man-in-the-Middle Attacks (MITM) • Without strong mutual authentication, any attacks utilizing MITM will have the same likelihood in IPv6 as in IPv4 • Flooding • Flooding attacks are identical between IPv4 and IPv6

• Can match on • Upper layers: TCP, UDP, SCTP port numbers, ICMPv6 code and type • TCP flags SYN, ACK, FIN, PUSH, URG, RST • Traffic class (only six bits/8) = DSCP, Flow label (0-0xFFFFF)

• IPv6 extension headers • routing matches any RH, routing-type matches specific RH • mobility matches any MH, mobility-type matches specific MH • dest-option matches any destination options • auth matches AH • hbh matches hop-by-hop (since 15.2(3)T)

• fragments keyword matches • Non-initial fragments (same as IPv4)

• undetermined-transport keyword does not match • TCP/UDP/SCTP and ports are in the fragment • ICMP and type and code are in the fragment • Everything else matches (including OSPFv3, …) • Only for deny ACE Check your platform & release as your mileage can vary…

• Implicit entries exist at the end of each IPv6 ACL to allow neighbor discovery:

... permit icmp any any nd-na permit icmp any any nd-ns

• This is different on IOS XE (i.e. ASR1k) : no default permit of ND / NA Packets

• The beginner’s mistake is to add a deny log at the end of IPv6 ACL . . . ! Now log all denied packets deny ipv6 any any log ! Heu . . . I forget about these implicit lines permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any Solution, explicitly add the implicit ACE . . . ! Now log all denied packets permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any log

• Since version 7.0 ! (April 2005)

• IPv6 header security checks (length & order)

• Management access via IPv6: Telnet, SSH, HTTPS, ASDM

• Routed & transparent mode, fail-over

• v6 App inspection includes: DNS,FTP, HTTP, ICMP, SIP, SMTP, and IPSec pass- through

• IPv6 support for site-to-site VPN tunnels was added in 8.3 (IKEv1 in ASA 8.3.1, and IKEv2 in ASA 8.4.1)

• Selective permit/deny of extension headers (ASA 8.4.2)

• OSPFv3, DHCPv6 relay, stateful NAT64/46/66, mixed mode objects (ASA 9.0)

• interface GigabitEthernet1/1 Allow ASA to process packet with hop nameif outside limit of 0 (Follow RFC 8200) security-level 0 ipv6 address dhcp default • CSCvi46759 ipv6 enable ipv6 nd suppress-ra • Fixing some bugs in the same shot (DHCP ipv6 dhcp client pd hint ::/48 packets sent with HL=0 by some CMTS  ) ipv6 dhcp client pd ISP

interface GigabitEthernet1/2 nameif inside • Alas, general-prefix cannot be used in security-level 100 ipv6 address ISP ::1/64 ACL... ipv6 address autoconfig ipv6 enable !

Check with

# show ipv6 general-prefix

policy-map type inspect ipv6 inspect_ipv6_fc_pmap parameters verify-header type verify-header order match header esp log match header fragment drop match header ah log match header destination-option log match header hop-by-hop drop log match header routing-type eq 2 log match header routing-type eq 3 drop match header routing-type eq 4 drop log

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 150 Spam over IPv6 Botnet member or open relay from Germany • Spammers are also using IPv6 of course... • Probably even without knowing it!

Nov 14 00:44:18 ks postfix/smtpd[22843]: connect from unknown[2a01:4f8:d16:4351::2] Nov 14 00:44:18 ks postfix/smtpd[22843]: A5CDC155: client=unknown[2a01:4f8:d16:4351::2] Nov 14 00:44:18 ks postfix/cleanup[22847]: A5CDC155: message- id= Nov 14 00:44:18 ks postfix/qmgr[3578]: A5CDC155: from=, size=27742, nrcpt=1 (queue active) • So, we need to fight IPv6 spam! • Content filtering: nothing has changed • Sender authentication (DKIM, SPF, DMARC) works with IPv6 • Sender reputation works with Cisco Senderbase / Talos

No geolocation yet though (albeit Maxmind supports IPv6)

Not a lot of data yet... PLEASE HELP

Per-User ACL Downloadable ACL

ACL ACL

-- ACL rules defined on RADIUS Server -- ACLACL onon thethe RADIUSRADIUS ServerServer -- Cisco AVP, limited by 4000 characters -- CiscoCisco AVP,AVP, nono limitlimit onon ACLACL sizesize -- Centralised policy management -- CentralisedCentralised policy policy management management

IPv4YES IPv4YES Cisco AVP: “ip:inacl#1=permit ip any any” Cisco AVP: "#ACSACL#-IP-ACL_NAME- ”

IPv6YES IPv6YES Cisco AVP: “ipv6:inacl#1=permit ipv6 any Cisco AVP: "#ACSACL#Not Applicable-IPv6-ACL_NAME- any” ”

• ASA Firewall (Since version 7.0 released 2005) • FirePower Threat Defence (FTD) no

• Extension header filtering and inspection (ASA 8.4.2) IPv6 inspection support on the GUI (FlexConfig), no management over • Dual-stack ACL & object grouping (ASA 9.0) IPV6 • Email Security Appliance (ESA) IPv6 support since 7.6.1 (May 2012) • FirePower Device Manager (FDM) no IPv6 support • Web Security Appliance (WSA) with explicit and transparent proxy • Cisco Umbrella, answers AAAA but cannot manage policy for IPv6 • FirePower NGIPS provides Decoder for network IPv4 & IPv6 Packets

• Cisco Threat Defense / StealthWatch: mostly forever including SMC

• ISE 2.2 added IPv6 support, more w/ 2.6 Meraki growing IPv6 Support

• Scapy is a open source packet forgery tool built on Python

• Powerful albeit complex to understand and to use: evyncke@host1:~# scapy Welcome to Scapy (2.1.0) >>> target="2001:db8:23:0:60de:29ff:fe15:2” >>> packet=IPv6(dst=target)/ICMPv6EchoRequest(id=0x1234, seq=RandShort(), data="ERIC") >>> sr1(packet) Begin emission: Finished to send 1 packets. Received 2 packets, got 1 answers, remaining 0 packets >

• Variable can be assigned a value with “=“

• Packets are built with the concatenation operator “/”

• Headers are instantiated with default values (such as source address, checksum, next header, length, ...) all can be overwritten

• Packet can be displayed in various format: ls(), packet.show()

• Packet can be sent by • send(): simply send it • sr1(): send it and wait for one reply >>> target="2001:db8:23:0:60de:29ff:fe15:2” >>> packet=IPv6(dst=target)/ICMPv6EchoRequest(id=0x1234, seq=RandShort(), data="ERIC")

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 158 “Playing” with Extension Headers IPv6 Header Manipulation • Unlimited size of header chain (spec-wise) can make filtering difficult

• Potential DoS with poor IPv6 stack implementations • More boundary conditions to exploit • Can I overrun buffers with a lot of extension headers? • Mitigation: a firewall such as ASA/FTD which can filter on headers

Perfectly Valid IPv6 Packet According to the Sniffer

Header Should Only Appear Once Destination Header Which Should DestinationOccur at Most Options Twice Header Should Be the Last

http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html

• Finding the layer 4 information is not trivial in IPv6 • Skip all known extension header • Until either known layer 4 header found => MATCH • Or unknown extension header/layer 4 header found... => NO MATCH

IPv6 hdr HopByHop Routing AH TCP data

IPv6 hdr HopByHop Routing AH Unknown L4 ???

Next Header = 44 IPv6 Basic Header Fragment Header Fragment Header

Fragment Header Next Header Reserved Fragment Offset Identification Fragment Data

• In IPv6 fragmentation is done only by the end system • Tunnel end-points are end systems => Fragmentation / re-assembly can happen inside the network

• Reassembly done by end system like in IPv4

• RFC 5722/8200: overlapping fragments => MUST drop the packet. Most OS implement it since 2012

• Attackers can still fragment in intermediate system on purpose

• ==> a great obfuscation tool

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 162 Fragmentation Used in IPv4 by Attackers ... Also applicable to IPv6 of course • Great evasion techniques • Some firewalls do not process fragments except for the first one • Some firewalls cannot detect overlapping fragments with different content • IPv4 tools like whisker, fragrout, etc. • Makes firewall and network intrusion detection harder • Used mostly in DoSing hosts, but can be used for attacks that compromise the host • Send a fragment to force states (buffers, timers) in OS • See also: http://insecure.org/stf/secnet_ids/secnet_ids.html 1998!

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 163 Parsing the Extension Header Chain Fragments and Stateless Filters • Layer 4 information could be in 2nd fragment

• But, stateless firewalls could not find it if a previous extension header is fragmented IPv6 hdr HopByHop Routing Fragment1 Destination …

IPv6 hdr HopByHop Routing Fragment2 … Destination TCP Data

Layer 4 header is in 2nd fragment, Stateless filters have no clue where to find it!

• RFC 6980: “nodes MUST silently ignore NDP … if packets include a fragmentation header” • RFC 7112: “A host that receives a First Fragment that does not satisfy… SHOULD discard the packet” • RFC 8200: “If the first fragment does not include all headers through an Upper-Layer header, then that fragment should be discarded”

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 164 Fragment Obfuscation with Scapy & Tcpdump >>> packet=IPv6(dst=dst)/IPv6ExtHdrDestOpt(options=PadN(optdata='A'*20)) /TCP(sport=sport,dport=22,flags="S", seq=100) >>> frag1=IPv6(dst=dst)/IPv6ExtHdrFragment(nh=60, id=0xabbababe, m=1, offset=0)/str(packet)[40:48] >>> frag2=IPv6(dst=dst)/IPv6ExtHdrFragment(nh=60, id=0xabbababe, m=0, offset=1)/str(packet)[48:84] >>> send(frag1) >>> send(frag2)

IP6 (hlim 64, next-header Fragment (44) payload length: 16) 2001:...:1 > 2001:...:2: frag (0xabbababe:0|8) [|DSTOPT] 0x0000: 6000 0000 0010 2c40 2001 0db8 0001 0000 `.....,@...... 0x0010: 60de 29ff fe15 0001 2001 0db8 0023 0000 `.)...... #.. 0x0020: 60de 29ff fe15 0002 3c00 0001 abba babe `.).....<...... 0x0030: 0602 0114 4141 4141 ....AAAA

IP6 (hlim 64, next-header Fragment (44) payload length: 44) 2001:...:1 > 2001:...:2: frag (0xabbababe:8|36) 0x0000: 6000 0000 002c 2c40 2001 0db8 0001 0000 `....,,@...... 0x0010: 60de 29ff fe15 0001 2001 0db8 0023 0000 `.)...... #.. 0x0020: 60de 29ff fe15 0002 3c00 0008 abba babe `.).....<...... 0x0030: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA 0x0040: 47b3 0016 0000 0064 0000 0000 5002 2000 G...... d....P... 0x0050: da35 0000

IP6 (hlim 62, next-header Fragment (44) payload length: 16) 2001:..:1 > 2001:..:2: frag (0xabbababe:0|8) [|DSTOPT] IP6 (hlim 62, next-header Fragment (44) payload length: 44) 2001:..:1 > 2001:..:2: frag (0xabbababe:8|36)

SSH accepts connection and replies IP6 (hlim 64, next-header TCP (6) payload length: 24) 2001:...:2.22 > 2001:...:1.18355: Flags [S.], cksum 0x138c (correct), seq 621319016, ack 101, win 5760, options [mss 1440], length 0

• Matching against the first fragment non-deterministic: • layer 4 header might not be there but in a later fragment Need for stateful inspection

• fragment keyword matches • Non-initial fragments (same as IPv4), permitted by default • undetermined-transport keyword does not match • If non-initial fragment • Or if TCP/UDP/SCTP and ports are in the 1st fragment • Or if ICMP and type and code are in the 1st fragment • Everything else matches (including OSPFv3, RSVP, GRE, ESP, EIGRP, PIM …) • Only for deny ACE

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 167 Let’s Try undetermined-transport... ipv6 access-list NO_SSH2 deny ipv6 any any undetermined-transport log deny tcp any any eq 22 log permit ipv6 any any

%IPV6_ACL-6-ACCESSLOGSP: list NO_SSH2/10 denied tcp 2001:...:1 -> 2001:...:2, 1 packet

1st fragment is not received..

IP6 (hlim 62, next-header Fragment (44) payload length: 44) 2001:..:1 > 2001:..:2: frag (0xabbababe:8|36)

Reassembly fails after time-out, connection is never established

• The lack of fast wirespeed stateless ACL is a bad news of course

• IETF made 1st IPv6 fragment without layer-4 invalid and it SHOULD be dropped by receiving host and MAY be dropped by routers • RFC 7112 (born as draft-ietf-6man-oversized-header-chain) • RFC 8200 (the new IPv6 standard)

• Use of undetermined-transport is strongly recommended

• ASA/FTD always drops such initial fragment

• If not supported, consider • Bidirectional traffic (TCP, ...): block on the other direction using the source port • On an intermediate router: permit TCP, ICMP, UDP, ... Hence blocking everything else (including 1st fragment without layer-4)

• White list approach for your traffic • Only allow the REQUIRED extension headers (and types), for example: • Fragmentation header • Routing header type 2 & destination option (when using mobile IPv6) • IPsec  AH and ESP • And layer 4: ICMPv6, UDP, TCP, GRE, ... • If your firewall is capable: • Drop 1st fragment without layer-4 header • Drop routing header type 0 • Drop/ignore hop-by-hop

• See also draft-ietf-opsec-ipv6-eh-filtering Source: Tony Webster, Flickr

2) Sending RA with 1) I want IPv6, prefix for auto- send RA configuration

3) 3) 3) 3) Yahoo! Yahoo! Yahoo! Yahoo! IPv6  IPv6  IPv6  IPv6 

IPv4 protection: IPv4 protection: IPv4 Protection: iptables Packet filter Security center

4) Default protection… IPv6 Protection: IPv6 Protection: IPv6 Protection: No ip6tables ✗ Packet filter ✔ Security center ✔

Before Mac OS X 10.7, ipfw was IPv4 only….

Internet

2) Sending RA with 1) I want IPv6, “no auto-config” send RA

3) Yahoo! 3) No 3) No 3) No Static IPv6 IPv6 IPv6 IPv6 SLAAC SLAAC SLAAC address

IPv4 protection: IPv4 protection: IPv4 Protection: iptables Packet filter Security center

• Finding all hosts: • Address enumeration does not work for IPv6 • Need to rely on DNS or NDP caches or NetFlow

• Vulnerability scanning • IPv4 global address, IPv6 global address(es) (if any), IPv6 link-local address • Some services are single stack only (currently mostly IPv4 but who knows...) • Personal firewall rules could be different between IPv4/IPv6

• IPv6 vulnerability scanning MUST be done for IPv4 & IPv6 even in an IPv4-only network • IPv6 link-local addresses are active by default

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 175 More on tunnels L3-L4 Spoofing in IPv6 • Most IPv4/IPv6 transition mechanisms have no authentication built in

• => an IPv4 attacker can inject IPv6 traffic if spoofing on IPv4 and IPv6 addresses

IPv6 ACLs Are Ineffective since IPv4 & IPv6 are spoofed Tunnel termination forwards the Inner IPv6 Packet IPv4 IPv6 Public IPv4 Internet IPv6 Network IPv6 Network

IPv6 in IPv4

Tunnel Tunnel Server B Server A Termination Termination

ISATAP router 1 ISATAP router 2 1. Spoofed IPv6 packet S: 2001:db8:2::200:5efe:c000:201 Prefix 2001:db8:1::/64 Prefix 2001:db8:2::/64 D: 2001:db8:1::200:5efe: c000:202 192.0.2.1 192.0.2.2 2. IPv4 ISATAP packet to 192.0.2.2 containing S: 2001:db8:2::200:5efe:c000:201 D: 2001:db8:1::200:5efe:c000:202

3 IPv6 packet S: 2001:db8:2::200:5efe:c000:201 D: 2001:db8:1::200:5efe:c000:202 • Root cause Repeat until Hop Limit == 0 • ISATAP routers ignore each other • ISATAP router: Mitigation: • accepts native IPv6 packets .IPv6 anti-spoofing everywhere .ACL on ISATAP routers accepting IPv4 from valid clients only • forwards it inside its ISATAP tunnel .Within an enterprise, block IPv4 ISATAP traffic between ISATAP routers • Other ISATAP router decaps and .Within an enterprise block IPv6 packets between ISATAP routers forward as native IPv6

• Similar to IPv4 telemetry

• SNMP MIB • Not always available yet on Cisco gears

• Flexible Netflow for IPv6 • Available in : 12.4(20)T, 12.2(33)SRE • Public domain tools: nfsen, nfdump, nfcpad… • Cisco Threat Defense

• Model Driven Telemetry (YANG, OpenConfig, gRPC, ....)

IP FWD IP ICMP TCP UDP (ROUTES) Original IPv4 only 2096 2011 2012 2013 Protocol Version rfc2096-update rfc2011-update Independent (PVI) = = 4292 4293 = IP-MIB rfc2012- rfc2013- update update = = 4022 4113

IPv4/IPv6 stats can be monitored from CLI “show interface accounting” on most platforms

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 181 Using SNMP to Read IPv4/IPv6 Neighbors Cache evyncke@charly:~$ snmpwalk -c secret -v 1 udp6:[2001:db8::1] -m IP-MIB ipNetToPhysicalPhysAddress IP-MIB::ipNetToPhysicalPhysAddress.1.ipv4."192.168.0.2" = STRING: 0:13:c4:43:cf:e IP-MIB::ipNetToPhysicalPhysAddress.1.ipv4."192.168.0.3" = STRING: 0:23:48:2f:93:24 IP-MIB::ipNetToPhysicalPhysAddress.1.ipv4."192.168.0.4" = STRING: 0:80:c8:e0:d4:be ... IP-MIB::ipNetToPhysicalPhysAddress.2.ipv6."2a:02:05:78:85:00:01:01:02:07:e9:ff:fe:f2:a0:c6" = STRING: 0:7:e9:f2:a0:c6 IP-MIB::ipNetToPhysicalPhysAddress.2.ipv6."2a:02:05:78:85:00:01:01:02:20:4a:ff:fe:bf:ff:5f" = STRING: 0:20:4a:bf:ff:5f IP-MIB::ipNetToPhysicalPhysAddress.2.ipv6."2a:02:05:78:85:00:01:01:30:56:da:9d:23:91:5e:ea" = STRING: 78:ca:39:e2:43:3 ... evyncke@charly:~$ snmptable -c secret -v 1 udp6:[2001:db8::1] -Ci -m IP-MIB ipNetToPhysicalTable

IPv6 Routing Transport Destination AS IP (Source or Destination Port TCP Flag: ACK Payload Size Destination) Peer AS Source Port TCP Flag: CWR Prefix (Source or Packet Section Traffic Index ICMP Code TCP Flag: ECE Destination) (Header) Forwarding ICMP Type TCP Flag: FIN Status Mask (Source or Packet Section IGMP Type TCP Flag: PSH Destination) (Payload) Is-Multicast TCP ACK Number TCP Flag: RST Minimum-Mask IGP Next Hop (Source or DSCP BGP Next Hop TCP Header Length TCP Flag: SYN Destination) TCP Sequence Flow TCP Flag: URG Protocol Extension Number Sampler ID UDP Message Traffic Class Hop-Limit TCP Window-Size Direction Length Flow Label Length TCP Source Port UDP Source Port Option Header Next-header Interface TCP Destination UDP Destination Header Length Version Input Port Port Payload Length Output TCP Urgent Pointer

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 . 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

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 184 For Your Reference Flexible NetFlow: Exporter, Record and Monitor flow exporter FLOW-EXPORTER destination 2001:db8::1 <<< IPv6 is supported transport udp 9995 flow record FLOW-RECORD match ipv6 source address <<< key fields match ipv6 destination address match ipv6 protocol collect counter bytes <<< non key fields collect counter packets collect datalink mac source address input <<< can also collect MAC addresses ;-) flow monitor FLOW-MONITOR ; record netflow ipv6 original-output <<< for traditional NetFlow records record FLOW-RECORD exporter FLOW-EXPORTER statistics packet protocol statistics packet size interface GigEthernet0/15 ipv6 flow monitor FLOW-MONITOR output

• Scanning an IPv6 network is impossible (address space too large)

• How can we run a security audit? • Easy • Get all IPv6 addresses from Netflow • Note: scanning link-local addresses requires layer-2 adjacency, i.e. • ping6 ff02::1

• Every host can have multiple IPv6 addresses simultaneously • Need to do correlation! • Ensure that your Security Information and Event Management (SIEM) supports IPv6 • Usually, a customer is identified by its /48 

• Every IPv6 address can be written in multiple ways • 2001:0DB8:0BAD::0DAD • 2001:DB8:BAD:0:0:0:0:DAD • 2001:db8:bad::dad (this is the canonical RFC 5952 format) • => Grep cannot be used anymore to sieve log files…

• See also RFC 7721 “Security and Privacy Considerations for IPv6 Address Generation Mechanisms”

• Easy if EUI-64 format as MAC is embedded • 2001:db8::0226:bbff:fe4e:9434 • (need to toggle bit 0x20 in the first MAC byte = U/L)

• Is 00:26:bb:4e:94:34

• DHCPv6 address or prefix… the client DHCP Unique ID (DUID) can be • MAC address: trivial • Time + MAC address: simply take the last 6 bytes • Vendor number + any number: no luck… next slide can help • No guarantee of course that DUID includes the real MAC address.

# show ipv6 dhcp binding Client: FE80::225:9CFF:FEDC:7548 DUID: 000100010000000A00259CDC7548 Username : unassigned Interface : FastEthernet0/0 IA PD: IA ID 0x0000007B, T1 302400, T2 483840 Prefix: 2001:DB8:612::/48 preferred lifetime 3600, valid lifetime 3600 expires at Nov 26 2010 01:22 PM (369)

• Not so attractive  • Only supported in Windows Vista, and Windows 7, Max OS/X Lion • Not in Linux (default installation), … • Windows Vista does not place the used MAC address in DUID but any MAC address of the PC • See also: https://knowledge.zomers.eu/misc/Pages/How-to-reset-the-IPv6-DUID-in- Windows.aspx

# show ipv6 dhcp binding Client: FE80::FDFA:CB28:10A9:6DD0 Actual MAC address: DUID: 0001000110DB0EA6001E33814DEE 0022.5f43.6522 Username : unassigned IA NA: IA ID 0x1000225F, T1 300, T2 480 Address: 2001:DB8::D09A:95CA:6918:967 preferred lifetime 600, valid lifetime 600 expires at Oct 27 2010 05:02 PM (554 seconds)

• Interesting attribute: Acct-Session-Id to map username to IPv6 addresses • Can be sent at the begin and end of connections • Can also be sent periodically to capture privacy addresses • Not available through GUI, must use CLI to configure config wlan radius_server acct framed-ipv6 both [email protected] Acct-Session-Id=xyz Acct-Status-Type=Start Framed- IP-Address=192.0.2.1 Framed-IPv6-Address=fe80::cafe [email protected] Acct-Session-Id=xyz Acct-Status-Type=Alive Framed- IP-Address=192.0.2.1 Framed-IPv6-Address=fe80::cafe Framed-IPv6- Address=2001:db8::cafe Framed-IPv6-Address=2001:db8::babe [email protected] Acct-Session-Id=xyz Acct-Status-Type=Stop Framed-IP- Address=192.0.2.1

• Last resort… look in the live NDP cache (CLI, SNMP, MDT telemetry)

#show ipv6 neighbors 2001:DB8::6DD0 IPv6 Address Age Link-layer Addr State Interface

2001:DB8::6DD0 8 0022.5f43.6522 STALE Fa0/1

• If no more in cache, then you should have scanned and saved the cache… • EEM can be your friend

• First-Hop Security can generate a syslog event on each new binding

ipv6 neighbor binding logging

• No traffic sniffing

• No traffic injection

• No service theft

Public Network Site 2 Site Remote Access

. 6in4/GRE Tunnels Protected by . SSL VPN Client AnyConnect IPsec IPv4 . DMVPN 12.4(20)T . FlexVPN . IPsec VTI 12.4(6)T . AnyConnect 3.1 & ASA 9.0 IPv6 . DMVPN 15.2(1)T . FlexVPN

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 195 For Your DMVPN for IPv6 Configuration Reference Hub Spoke interface Tunnel0 interface Tunnel0 ipv6 address 2001:db8:100::1/64 ipv6 address 2001:db8:100::11/64 ipv6 eigrp 1 ipv6 eigrp 1 no ipv6 split-horizon eigrp 1 ipv6 nhrp map multicast 172.17.0.1 no ipv6 next-hop-self eigrp 1 ipv6 nhrp map 2001:db8:100::1/128 172.17.0.1 ipv6 nhrp map multicast dynamic ipv6 nhrp network-id 100006 ipv6 nhrp network-id 100006 ipv6 nhrp holdtime 300 ipv6 nhrp holdtime 300 ipv6 nhrp nhs 2001:db8:100::1 tunnel source Serial2/0 tunnel source Serial1/0 tunnel mode gre multipoint tunnel mode gre multipoint tunnel protection ipsec profile vpnprof tunnel protection ipsec profile vpnprof ! ! interface Ethernet0/0 interface Ethernet0/0 ipv6 address 2001:db8:0::1/64 ipv6 address 2001:db8:1::1/64 ipv6 eigrp 1 ipv6 eigrp 1 ! ! interface Serial2/0 interface Serial1/0 ip address 172.17.0.1 255.255.255.252 ip address 172.16.1.1 255.255.255.252 ! ! ipv6 router eigrp 1 ipv6 router eigrp 1 no shutdown no shutdown All combinations of IPv4 and IPv6 are allowed

• IPv4/IPv6 FlexVPN over IPv4 or IPv6 are allowed (IPv6 over IPv4 shown)

2001:db8:beef::/64 2001:db8:cafe::/64

172.16.1.1 172.16.2.1

interface Tunnel0 interface Tunnel0 ipv6 address fe80::1 link-local ipv6 address fe80::2 link-local ipv6 ospf 1 area 0 ipv6 ospf 1 area 0 tunnel source FastEthernet0/0 tunnel source FastEthernet0/0 tunnel destination 172.16.2.1 tunnel destination 172.16.1.1 tunnel protection ipsec profile default tunnel protection ipsec profile default

interface FastEthernet0/1 interface FastEthernet0/1 ipv6 address 2001:db8:cafe::1/64 ipv6 address 2001:db8:beef::1/64 ipv6 ospf 1 area 0 ipv6 ospf 1 area 0

interface FastEthernet0/0 interface FastEthernet0/0 ip address 172.16.1.1 255.255.255.0 ip address 172.16.2.1 255.255.255.0

• All inside hosts have a globally unique IPv6 address

• Routing-wise, remote sites could communicate over the Internet • Even OUTSIDE of VPN tunnels

• Ensure routes point into the tunnel (FlexVPN, DMVPN)

• Drop packets from the Internet having Source and Destination from your prefix

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 198 Secure RA IPv* over IPv* Public Network: AnyConnect SSL VPN Client & ASA IPv6/IPv4 Intranet AnyConnect supports native IPv4/6 connectivity • Connecting via IPv4/6 Internet to ASA IPv4/6 Transport • SSL Tunneling IPv6 in IPv6 , IPv4 in IPv4, IPv6 Network in IPv4, IPv4 in IPv6 • No support for DHCPv6 yet • Mobile does not support IPv6 transport

See also: http://blog.webernetz.net/2014/01/18/cisco-anyconnect-ipv6-access-through-ipv4-vpn-tunnel/

http://www.rmv6tf.org/wp-content/uploads/2015/10/2-Bavarian-Mauro_Success-and- future-of-IPv6-from-an-Electrical-Utility-Perspective-rev5.compressed.pdf On ciscolive.com: BRKARC-2008 - Smart Grid: Field Area Network Multi-Service Architecture and BC Hydro Case Study http://www.cisco.com/c/dam/en_us/solutions/industries/retail/downloads/bc-hydro-cisco.pdf

Do not plan to attend BRKSEC-3200 as there are a lot of similar contents

#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 202 Complete your online session • Please complete your session survey after each session. Your feedback evaluation is very important.

• Complete a minimum of 4 session surveys and the Overall Conference survey (starting on Thursday) to receive your Cisco Live water bottle.

• All surveys can be taken in the Cisco Live Mobile App or by logging in to the Session Catalog on ciscolive.cisco.com/us.

Cisco Live sessions will be available for viewing on demand after the event at ciscolive.cisco.com.

Demos in the Walk-in labs Cisco campus

Meet the engineer Related sessions 1:1 meetings

9 June 2019 / 9:00 TECRST-1991 Introduction to IPv6: Connecting nodes to the IPv6 access network

9 June 2019 / 14:00 TECRST-2001 Designing and deploying a security IPv6 network

10 June 2019/ 8:00 BRKRST-2619 IPv6 Deployment: Developing an IPv6 Addressing Plan and Developing IPv6

10 June 2019/ 8:00 BRKSPG-3001 Introduction to SRv6 technology

10 June 2019 / 13:00 BRKSPG-2602 IPv4 Exhaustion: IPv6 Transition and NAT Architectures

11 June 2019 / 8:00 BRKSEC-3018 IPv6 AAA, Port-Based auth and Security Implementation

11 June 2019/ 13:00 LTRRST-2016 IPv6 in the Enterprise for Fun and (fake) Profit: A Hands-On Lab

12 June / 8:00 BRKSEC-3200 Advanced IPv6 Security Threat and Mitigation

12 June / 8:00 BRKMPL-2132 Designing and deploying SRv6 networking overlaps

12 June / 13:00 BRKRST-3304 Hitchhiker's Guide to Troubleshooting IPv6

LABRST-2261 IPv6 planning, deployment and transition LABRST-1000 Intro IPv6 Addressing and Routing Lab LABSPG-1327 Introduction to Segment Routing v6 (SRv6) with IOS-XR

#CLUS #CLUS