Presd1 09

28
17-May-10 1 IPv6 The Latest Security Challenge Ron Broersma DREN Chief Engineer SPAWAR Network Security Manager [email protected] Cyber Defence Conference Tallin, Estonia 17 May 2010

description

 

Transcript of Presd1 09

Page 1: Presd1 09

17-May-10 1

IPv6 The Latest Security Challenge

Ron Broersma DREN Chief Engineer

SPAWAR Network Security Manager [email protected]

Cyber Defence Conference Tallin, Estonia 17 May 2010

Page 2: Presd1 09

17-May-10 2

Agenda

•  Brief introduction to IPv6 •  Implementing IPv6 across DREN •  New security challenges

Page 3: Presd1 09

17-May-10 3

Brief introduction to IPv6

Page 4: Presd1 09

17-May-10 4

IP version 6 •  “IP” (Internet Protocol) is the glue that makes the Internet work

–  Every device on the network has an IP “address” •  What we use today is IP version 4

–  In production use for 27 years (1983), and showing its age –  32 bit addresses

•  IPv6 is the next generation Internet protocol –  Huge address space (128 bit addresses) –  Aggregation based hierarchy for route table efficiency –  Simplified, fixed length header – better options support –  Mandatory IPsec (promise for improved security) –  Autoconfiguration, ease of renumbering –  Support for QoS

•  The most important piece right now is that it has incredibly vast address space

Page 5: Presd1 09

17-May-10 5

The piece that has changed

ISO 7 Layer Model

Application

Presentation

Session

Transport

Network

Link

Physical

Sockets

TCP, UDP

IP

Mac Layer

Internet Stack

IPv6

Page 6: Presd1 09

17-May-10 6

The Transition to IPv6

•  Running out of IPv4 address space –  Expected depletion in 2012

•  Every network connected device must upgrade.

•  Transition to IPv6 should have happened by now –  delays in product availability and maturity –  apathy on all fronts, lack of sense of urgency –  other priorities

Page 7: Presd1 09

Implementation approach: “Dual Stack”

•  IPv6 is not compatible with IPv4. –  They can exist side by side, but don’t interoperate.

•  It is not possible to communicate between IPv4 and IPv6 Internets without translators. –  Translators are problematic, and we should avoid them.

•  “Dual Stack” is when you run both protocols on all networks and systems. –  This allows full connectivity to both IPv4 and IPv6 Internets. –  It is the most pragmatic transition mechanism today if you

have sufficient IPv4 addresses.

•  When we speak of “transition”, we mean “transition to dual-stack”, not to “IPv6 only”.

17-May-10 7

Page 8: Presd1 09

17-May-10 8

Address exhaustion •  ARIN Board of Trustees Resolution dated 7 May 2007:

RESOLUTION OF THE BOARD OF TRUSTEES OF ARIN ON INTERNET PROTOCOL NUMBERING RESOURCE AVAILABILITY

WHEREAS, community access to Internet Protocol (IP) numbering Resources has proved essential to the successful growth of the Internet; and,

WHEREAS, ongoing community access to Internet Protocol version 4 (IPv4) numbering resources can not be assured indefinitely; and,

WHEREAS, Internet Protocol version 6 (IPv6) numbering resources are available and suitable for many Internet applications,

BE IT RESOLVED, that this Board of Trustees hereby advises the Internet community that migration to IPv6 numbering resources is necessary for any applications which require ongoing availability from ARIN of contiguous IP numbering resources; and, BE IT ORDERED, that this Board of Trustees hereby directs ARIN staff to take any and all measures necessary to assure veracity of applications to ARIN for IPv4 numbering resources; and,

BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN Advisory Council to consider Internet Numbering Resource Policy changes advisable to encourage migration to IPv6 numbering resources where possible.

Unanimously passed by the Board of Trustees on 7 May 2007.

Page 9: Presd1 09

IPv4 address depletion

17-May-10 9

Page 10: Presd1 09

Notice of IPv4 Address Depletion

“Make your organization’s publicly accessible resources available via IPv6 as soon as possible”

17-May-10 10

Page 11: Presd1 09

Potential scenario

•  Projected IPv4 address depletion in 2012 –  Address blocks become scarce commodity –  Broken into smaller pieces, and “sold”

•  Then, IPv4 Routing tables exceed router capacity –  Upwards of 2M routes, won’t fit router memory –  Some parts of Internet become isolated

•  Islands of IPv6-only –  Can’t get IPv4 addresses –  Don’t want complexity of dual stack –  National mandates

•  No good IPv4/IPv6 translator solution yet –  But IETF is working on proposals.

17-May-10 11

Page 12: Presd1 09

17-May-10 12

IPv6 Deployment on DREN

Page 13: Presd1 09

17-May-10 13

Background •  DREN (Defense Research and Engineering Network)

–  is DoD’s Internet Service Provider for the Research and Engineering community

–  also serves as the DoD IPv6 “pilot” network

•  Started the transition to IPv6 nearly 10 years ago •  In full production “dual stack” for some years now

–  Significant operational experience, and lessons learned

Page 14: Presd1 09

Benefits already realized •  Adversaries can’t map nets, due to sparse addressing •  Vastly reduced routing tables, resulting in faster convergence •  Everything gets an address (or many of them), and NATs are

eliminated. –  End to end model is restored –  With IPSEC, an end to end security model is possible –  Facilitates “one-IP one-service” model –  Improved battery life of network devices (sensors, cell phones)

•  Multicast is greatly simplified –  Rendezvous Point (RP) embedded in multicast group address –  No more MSDP

* NATs: Network Address Translators * IPSEC: Internet Protocol Security * MSDP: Multicast Source Discovery Protocol

17-May-10 14

Page 15: Presd1 09

IPv6 Security Issues

17-May-10 15

Page 16: Presd1 09

17-May-10 16

IPv6 Security Review •  Independent security review

performed by SAIC for DREN during 2005 –  Publicly available

•  Conclusions: –  protocol is no less secure

than v4

Page 17: Presd1 09

Maturity of Implementations

•  IPv4 is very mature, implementations are solid –  used heavily for over 20 years

•  IPv6 is very new –  limited production experience –  vendors aren’t “eating their own dogfood” –  we haven’t found all the bugs yet

17-May-10 17

Near certainty that we will find Denial of Service Vulnerabilities

Page 18: Presd1 09

Tunnels •  If systems are connected to a network that does not

support IPv6, they may try to “tunnel” IPv6 in IPv4 packets –  Popular mechanisms are 6to4, ISATAP, Teredo –  Default in Windows

•  Tunnels can bypass firewalls and other security protections –  can easily happen by accident –  you may not be aware that it is happening

•  Recommendation: –  Block tunnels (IP Protocol 41) at security boundaries

17-May-10 18

Page 19: Presd1 09

Rogue routers •  In IPv6, routers announce themselves using “RA” (router

advertisements) •  Systems on the network learn a default gateway from the RAs

–  part of the auto-configuration feature of IPv6

•  Any system could pretend to be an IPv6 router and send RAs –  other systems will hear this and route traffic to this rogue router –  denial of service to the entire subnet

•  Windows systems that have Internet Connection Sharing (ICS) enabled will do this automatically.

•  Solution: –  Long term – Implement “RA Guard” when available –  Near term – set router priority to “high” on the true routers

17-May-10 19

Page 20: Presd1 09

THC report - 2008

•  http://www.thc.org •  Confirms early implementations are immature

–  47 implementation bugs reported by June 2008

•  Conclusions: –  no serious new risks with IPv6 –  some security improvements over IPv4

•  scanning and worming will be harder •  no record-route, no uptime check •  easier filtering and attack tracing

17-May-10 20

Page 21: Presd1 09

17-May-10 21

Many products lack IPv6 support

•  Many products that are critical to security infrastructure are not IPv6-enabled –  Firewall –  Web cache/proxy –  Load balancer –  Intrusion Detection System (IDS) –  Intrusion Prevention System (IPS) –  Many VPN products

•  Both SSL VPNs and IPSEC VPNs –  Vulnerability assessment and forensics tools from

most vendors

Page 22: Presd1 09

Privacy addresses •  See RFC 4941 •  Windows systems do this by default (and we don’t like it!) •  Breaks many things in our environment

–  Forensics –  Stable DNS entries –  Automated management tools

•  Could fix with DHCPv6, but client not available in important OS’s –  Windows XP, Mac OSX

•  Would be nice if RA’s could say “don’t do this” •  So we have to visit every Windows machine to disable this.

–  Breaks the “plug and play” goal of IPv6 for clients.

•  How To: (next slide)

22 17-May-10

Page 23: Presd1 09

Disabling privacy addresses

•  Windows XP

•  Windows 2003

•  Windows Vista

•  Windows 2008

ipv6 -p gpu UseTemporaryAddresses no

netsh interface ipv6 set privacy state=disabled store=persistent

netsh interface ipv6 set privacy state=disabled store=persistent netsh interface ipv6 set global randomizeidentifiers=disabled netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

netsh interface ipv6 set global randomizeidentifiers=disabled netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

23 17-May-10

Page 24: Presd1 09

Dual Stack complexities •  Operating dual stack is like running two separate

networks in parallel •  All security mechanisms must be equally applied to

both network protocols –  otherwise one of them becomes the “weakest link” –  new entry vector for adversaries

•  Addition of complexity –  makes it harder to maintain –  more prone to mistakes

•  Recommendation: topological and security congruency –  same topology for both IPv4 and IPv6 components –  identical security policies, ACLs, defences, etc.

17-May-10 24

Page 25: Presd1 09

VPN problems •  Travelers and telecommuters use client VPNs to connect to the

corporate Intranet securely –  Like Cisco IPSEC VPN or Juniper SSL VPN

•  Only tunnels the IPv4 traffic (today) •  IPv6 traffic, if supported at all, goes outside this tunnel

–  IPv6 traffic is now in the clear over the Internet, where user may think it is protected

–  But it may be blocked by the corporate firewall •  Seriously impacts performance for IPv6-enabled remote users. •  Users disable IPv6 to fix it (bad scenario)

•  Solution: –  Deploy ISATAP to Intranet. –  But MACs don’t have ISATAP client support.

17-May-10 25

Page 26: Presd1 09

Crisis response

•  Deployment of anything in a crisis is prone to mistakes –  insufficient time to plan and design the solution –  insufficient time to develop or procure the best

tools

•  Waiting too long to deploy IPv6 will put you into a crisis scenario at some point

•  Recommendation: deploy IPv6 now –  you should have been working on it for a few

years now

17-May-10 26

Page 27: Presd1 09

17-May-10 27

Summary •  DREN has been successfully using IPv6 in a

production environment, with many dual-stack systems and services, for years

•  IPv6 presents some new security challenges, but it is fundamentally no less secure than IPv4

•  Most significant problem is the very limited deployment to date

•  Strongest recommendation: IPv6-enable your public facing services now!

Page 28: Presd1 09

17-May-10 28

END