The IPv6 protocol suite was designed to accommodate the present and future growth of the Internet, by providing a much larger address space than that of its IPv4 counterpart, and is expected to be the successor of the original IPv4 protocol suite. It has already been deployed by most major content providers (including Google and Facebook) and many Internet Service Providers (ISPs). While the ultimate goal of IPv6 is virtually the same as that of IPv4 (moving packets across the Internet), the underlying mechanisms and technical details are significantly different, typically resulting in unexpected security and privacy implications. In this presentation, Fernando will cover the state of the art in everything ranging from IPv6 pentesting, to security controls and operational mitigations for IPv6 attacks, thus providing valuable information to red, blue, and purple teams.

1. C:>
State of the Art in IPv6 Security
Fernando Gont
Director of Information Security, EdgeUno
www.thehacksummit.com 5/11/2021 online ORGANIZERS:

2. Brief Introduction to IPv6
2

3. What is this IPv6 thing?
• Solves the problem of IPv4 address exhaustion
• Uses 128-bit addresses (vs. IPv4’s 32-bit addresses)
• Provides the same service as IPv4
• It is not “backwards compatible” with IPv4
3

4. Brief comparison of IPv4/IPv6
IPv4 IPv6
Addressing 32 bits 128 bits
Address resolution ARP ND (ICMPv6-based)
Configuration DHCP SLAAC & DHCPv6 (optional)
Fault isolation ICMPv4 ICMPv6
IPsec support Optional Optional
Fragmentation Hosts and routers Only hosts
4

5. IPv6 Security Tools
5

6. IPv6 security toolkits
• SI6 Networks' IPv6 Toolkit
• THC-IPv6
• Chiron
6

7. IPv6 Security Implications
7

8. IPv6 Addressing
8

9. Brief overview
• The increased address space is the “driver” for IPv6
• Address semantics similar to those of IPv4:
• Addresses are aggregated into “prefixes”
• Several address types
• Several address scopes
• Each interface employs multiple addresses of different types and scopes
• One link-local unicast address, one or more global unicast addresses, etc
9

10. IPv6 Global Unicast Addresses
• The interface ID can be set in a number of ways:
• Embed the underlying MAC address (traditional SLAAC)
• Embed the corresponding IPv4 address (e.g. 2001:db8::192.168.1.1)
• Low-byte (ej. 2001:db8::1, 2001:db8::2, etc.)
• Wordy (ej. 2001:db8::dead:beef)
• Stable and random addresses (RFC7217, current SLAAC)
Global Routing Prefix Subnet ID Interface ID
| n bits | m bits | 128-n-m bits |
10

11. IPv6 Addressing
Security and Privacy Implications
11

12. Security and privacy implications
• Implications dependent on IID-generation algorithm
• Stable IIDs Activity correlation over time
→
• Constant IIDs Activity correlation over space
→
• IIDs with patterns Network reconnaissance
→
• IIDs embedding MAC addresses Device-specific attacks
→
12

13. IPv6 Addressing
Mitigations
13

14. RFC 7217: Stable addresses
• Generate the Interface Identifier with:
F(Prefix, Net_Iface, Network_ID, Secret_Key)
• As the host moves:
• Prefix and Network_ID change from one network to another
• But they remain constant within each network
• F() varies across networks, but remains constant within each network
• Implementations: Mac OS, Linux, etc.
14

15. RFC 8981: Temporary addresses
• Randomized IIDs that change over time
• Generated in addition to to stable addresses
• Use:
• Temporary addresses: outgoing communications
• Stable addresses: incoming communications
• Implementations: All major OSes
15

16. IPv6 Addressing
Advice
16

17. Red-team advice
• You may need to change the way you do Network Reconnaissance!
• Check RFC 7707 (“Network Reconnaissance in IPv6 Networks”)
17

18. Red-team advice (II)
• Use pattern-based address-scanning attacks
18

19. Blue-team advice
• Use unpredictable IIDs where possible
• Consider the feasibility of using temporary addresses:
• Impact on network devices
• Impact on ACLs
• Impact on the ability to correlate network activity for legitimate purposes
• Implement IPv6 firewalling as necessary
19

20. IPv6 Extension Headers
20

21. IPv6 packet structure
• The IPv6 header only contains “mandatory” information
• Options are conveyed via “extension headers”
• They separate e.g. host vs. router options
• Only the MTU limits the number of extension headers and options
IPv6 HbH DO DO TCP
21

22. Implications
• Increase in the complexity of the resulting traffic
• Source of many vulnerabilities
• Increases the difficulty to obtain layer-4 information by intermediate systems
• They seldomly allows for circumvention of security controls
• Negative performance impact on network devices DoS
→
• Limited reliability on the public Internet
• F(not required, is problematic) drop!
→
22

23. Red-team advice
• IPv6 EHs can be useful for circumvention of security controls
• Possibly useful for DoS purposes
• But very unreliable across the Internet!
23

24. Blue-team advice
• At the edge of an organizational network use an “allow list”
→
• At transit networks use a “block list”
→
• Check vendor documentation regarding EH processing
• Use of EHs might require that packets be processed in the “slow path”
• It may be necessary to drop packets that employ EHs
• Check RFC 9098 (“Operational Implications of IPv6 Packets with
Extension Headers”)
24

25. Address Resolution
25

26. Brief overview
• Address resolution: IPv6 link-layer
→
• Performed with “Neighbor Discovery”:
• Based on ICMPv6 messages (Neighbor Solicitation and Neighbor Advertisement)
• Resulting traffic may be much more complex than that of IPv4’s ARP
• ARP-based attacks can be “ported” to the IPv6 world
• Man in The Middle
• Denial of Service
26

27. Blue-team advice
• Do you mitigate ARP attacks for the IPv4 case?
• If so, achieve policy-parity with:
• IPv6 Source Guard/SAVI
• Double-check if these mechanisms are actually effective!
27

28. Automatic Configuration
28

29. Brief overview
• Two mechanisms for IPv6 automatic configuration
• Stateless Address Auto-Configuration (SLAAC)
• Based on ICMPv6 messages
• DHCPv6
• Based on UDP datagrams
• SLAAC is mandatory, while DHCPv6 is optional
• But many networks use both, even with overlapping functionality
29

30. Security considerations
• Forged SLAAC and DHCPv6 packets can be leveraged for:
• Man In the Middle
• Denial of Service
• SLAAC may result in an increased attack window
• thanks to its push/pull model
30

31. Red-team advice
• SLAAC attacks are trivial to perform in local networks
• Use of IPv6 EHs can help circumvent SLAAC security controls
31

32. Blue-team advice
• Do you implement analogous mitigations in the IPv4 case?

DHCP-snooping, etc.
• Achieve policy-parity with:
• RA-Guard
• DHCPv6-Shield
• IPv6 Source Guard/SAVI
• Double-check if your implementations are actually effective!
32

33. Security Considerations for
Dual-Stack Networks
33

34. Security considerations
• Most networks have at least partial deployment of IPv6
• If you expect that IPv6 is not used, enforce such policy!
• Lack of feature and/or policy parity with IPv4
• Implementation of packet filtering is inconsistent:
• Different rulesets for IPv4 and IPv6 policy mismatches
→
• Evidence exists about filtering policies mismatches
• Always audit all addresses of all protocol families
34

35. Some Conclusions
35

36. Some conclusions
• IPv6 provides similar functionality to that of IPv4

Mechanisms are different

It is such differences that may lead to “surprises”
• Most systems already ship with IPv6 support

There is usually not such a thing as an “IPv4-only” network

All networks should address IPv6 security challenges
• Your {blue, red, purple} teams should embrace IPv6!
36

37. Questions?
37

38. Thanks!
Fernando Gont
fernando.gont@edgeuno.com
38

39. Thank you for watching!
Remember to leave your questions
and rate the presentation
in the section below.
www.thehacksummit.com 5/11/2021 online ORGANIZERS: