draft-ietf-v6ops-scanning-implications-00 IPv6 Implications for Network Scanning Tim Chown University of Southampton (UK) IETF 66, July 12th 2006 Montreal

draft-ietf-v6ops-scanning-implications-00 Purpose of document Document different properties of IPv6 networks for network scanning Suggest possible new attack vectors for discovery of host addresses to target By the usual scanning method Recommend measures that network administrators may take to mitigate these

draft-ietf-v6ops-scanning-implications-00 Recent changes In a past life this document used to be draft-chown-port-scanning-implications-02 Adopted by WG Received a number of comments Improvements: Addressed comments Changed to a new structure based on comments

draft-ietf-v6ops-scanning-implications-00 Comments addressed Avoided any suggestion that IPv6 subnet size makes networks resilient to network scanning Because other methods to harvest addresses exist Attackers will scan addresses that they can learn Restructured to 3 sections: IPv6 subnet size ‘problem statement’ Alternative address harvesting methods Recommendations/suggestions for admins

draft-ietf-v6ops-scanning-implications-00 Subnet size implications Problem space for IPv6 scanning Huge subnet size (64 bits) But can be reduced by heuristics Systems numbered ::1, ::2, etc Autoconfiguration uses fixed ‘fffe’ stuffing Well-known vendor NIC prefixes Sequential NIC IDs in batches of systems Dual-stack systems still ‘vulnerable’ via IPv4 May wish to perform defensive scanning

draft-ietf-v6ops-scanning-implications-00 Alternatives for attackers ‘New’ ways to harvest IPs On-link methods Multicast (including site scope) Logged or recorded Ips DNS advertised hosts DNS zone transfers Application participation Transition methods

draft-ietf-v6ops-scanning-implications-00 Measures for admins? Consider using Privacy Addresses (RFC3041) Reduces ‘useful lifetime’ of address to attacker who has harvested the address by some means Adds complexity for network management Consider DHCPv6 address pools Don’t allocate from ::1 upwards Avoid using sequential addresses Consider rolling server IP addresses e.g. change advertised MX addresses over time

draft-ietf-v6ops-scanning-implications-00 Next Steps Comments? Any anecdotal evidence of (mis)behaviour seen at site firewalls? Author sees port scanning on advertised IPs Cited by three(?) other current IDs WGLC?