IPv6 @ INFN

Francesco Prelz

INFN, sezione di Milano

(on behalf of the INFN IPv6 interest group)

Summary

INFN is experimenting with IPv6 at four sites (Milan, CNAF/Bologna, Catania and Rome). The addressing plan agreed with GARR puts all of INFN under the 2001:760:4200::/40 prefix.
  1. The driving forces.
  2. What would we like to do with IPv6 ?
    • Or: what would we like to do with...
  3. What do we consider essential, security-wise ?
  4. Transition scenarios.
  5. IPv6-on-IPv4 tunnels: what for ?
  6. Address allocation options.
  7. Network access authorisation options.
  8. Monitoring tools
  9. Conclusions

The driving forces


Photo by Articulate Matter 		IPv6 is pulled from various sides.
  • Technological:
    • Regain transparency between transport layer peers
      (implies removal of any intermediate stateful element, including NATs and Firewalls).
    • Facilitate transport layer autoconfiguration.
    • Allow mobile IP applications.
  • => Neighbour discovery, Authentication, Encryption, Host & Network mobility functions absorbed in the transport layer.
  • Sociological:
    • Continue the usual level of IP connectivity to and from areas where public IPv4 addresses are becoming scarce.
Increased host and network security should not be expected from the change...
More on this later.

What would we like to do with IPv6 ?

  • I mean: what would we like to do that we don't currently do with IPv4 ?
  • The answer may vary with individual sites and organisations, but, given the amount of optional headers in IPv6, (and the stack complexity following from the fact that they must be supported) the question cannot be avoided.
  • And... the answer likely has nothing to do with IPv6 per se, so let's revise the question.

Better: what would we like to do with:

Better question: what would we like to do with:
  1. IPsec deployment:
    • Where and why do we see useful applications of Level 3 authentication and encryption functions ?
    • Today we likely maintain secure applications (and, more importantly and expensively, the structure of related trust roots), both at levels 2 and >= 4.
    • What are the fundamental reasons for this ?
      Likely not the lack of IETF specs on IPSec.
  2. Site-, organisation-, NREN- or HEP-wide mobility applications
    • Do we care ?
    • If the answer is yes, will we build them on Level 3 or with IEEE 802.16?
  3. Anycast address applications ?

Essential security features

What do we see as essential, security-wise ?
  • Last-hop traceback for associating network activity to a (properly authorised) person.
    • May be a legal requirement depending on the local legal system.
    • Fundamentally incompatible with any form of network address autoconfiguration (and with proposals to randomise it over time for the sake of privacy, as proposed in rfc3041).
    • Requires proper authorisation for local and wide area network access.
  • Protection from external detection of accessible hosts (via ping o port sweep).
  • Local network address resolution protection.
    • How do we protect ourselves today from ARP poisoning and DHCP spoofs ? Fundamentally nothing changes for IPv6 there.
    • How much do we usually fear the enemy inside today ?
  • Sensitive data protection.
    • How much of this is done at the transport level ?
  • Upkeep of best practices to prevent known exploits.
  • Anything else?

Transition scenario: when should we do it ?.

  • Activating the peering and enabling the DNS service are no-brainers.
  • Enabling the SMTP servers that serve as MX records for the site should be equally painless.
  • But: how many people around us are actually doing this ?
  • Will 'the' killer IPv6-only application ever appear ?
  • Do drop-dead-deadlines help ?
.

Transition scenario: dual stack everywhere.


Transition scenario: IPv6-only hosts? (1)


Transition scenario: IPv6-only hosts? (2)


IPv6-on-IPv4 tunnels: what for ?

  • There are also various (disproportionately many) transition techniques that allow IPv6 access without support on a local pure-IPv4 network.
    • 6to4 allows to access the global IPv6 network by establishing a tunnel to anycast IPv4 address 192.88.99.1. Extremely simple to deploy on many systems, beginning with Windows.
    • Teredo Allows IPv6 global network access also from behind a NAT, by sending traffic via UDP to a network of well-known servers (usually on port 3544, but other networks may appear on any other port).
    • Tunnel brokering on www.sixxs.net. The site actively promotes the transition to IPv6 by offering public addresses to anyone requesting it.
  • These techniques are inherently vulnerable to denial-of-service, spoof and, redirect attacks.
  • We don't need them: as long as we can get a direct IPv6 peering from our NREN. This tunnel traffic would probably be better filtered at the boundary of our networks.

IPv6 address allocation options

  • What is available to configure the transport layer in a simple, automatic and hopefully painless fashion ?:
    • Stateless auto-configuration or SLAAC (hosts append their MAC address to a network prefix received in a Router Advertisement multicast)
    • Stateful auto-configuration or DHCPv6 (clients are identified by two runtime-generated numbers: the DUID identifies the host and the IAID identifies a network interface)
    • Manual address allocation and configuration is always an option, but will it scale and be sufficiently error-proof ?
  • Duplicate address collision just cannot be the right way to enforce network access authorisation (not just for IPv6).
  • What do people prefer, what is being experimented with or deployed ?

Access authorisation options

  • Maintenance of (long) ACLs allowing only network traffic to and from legitimately assigned IPv6 addresses.
  • IEEE 802.1x enforced everywhere ?
  • IPSEC enforced everywhere (but it may not be enough to protect IPv6 Neighbour Discovery, see rfc 3971) ?
  • Does everyone have good trust anchors for these systems ?
  • Would we trust automatic DNS updates if we had strong authentication, authorisation and encryption everywhere ?

Monitoring tools for IPv6

  • It's hard to think about a real wide-scale deployment of IPv6 without up-to-date and trusted level-3 network monitoring tools
  • Both commercial and free tools evolve slowly, following market demand (or lack thereof)...
  • NDPmon, an ARPwatch substitute, started being developed in 2006. As of now (v1.4.0 - August 2009) it is able to store address-MAC associations in an XML file and send reports via e-mail and syslog.
  • OpenVAS added initial IPv6 support in December 2009 with version 3.0.0.
  • Any experience with other (commercial) tools ?

Conclusions

  • IPv6
    1. Cannot be ignored: the stack is on by default on many systems, and there's enough auto-configuration in place to allow them to communicate happily, even to the global IPv6 internet.
    2. Does not allow to drop any of the security measures that are in place today for IPv4. Possible vulnerabilities are the same, and they act on a large base of juicy new code. Only the lack of en-route packet fragmentation seems to be an uncontroversial improvement in this field.
    3. Requires an update of security measures and monitoring tools.
  • There are no approved protocol translation mechanisms that remove the need to have a proper IPv4 public address allocated for hosts that need to communicate with IPv4 services. (NAT-PT was deprecated in rfc 4966, while both SIIT and IVI require an IPv4 address), so a full dual-stack deployment appears to be the only reasonable transition method.
  • There are various options for address allocation and network access authorisation.
    It would help if we could share best practices in this field.

Bibliography