• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Presd1 09
 

Presd1 09

on

  • 412 views

 

Statistics

Views

Total Views
412
Views on SlideShare
411
Embed Views
1

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Presd1 09 Presd1 09 Presentation Transcript

    • IPv6 The Latest Security Challenge Cyber Defence Conference Tallin, Estonia 17 May 2010 Ron Broersma DREN Chief Engineer SPAWAR Network Security Manager ron@spawar.navy.mil 17-May-10 1
    • Agenda •  Brief introduction to IPv6 •  Implementing IPv6 across DREN •  New security challenges 17-May-10 2
    • Brief introduction to IPv6 17-May-10 3
    • 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 17-May-10 4
    • The piece that has changed ISO 7 Layer Model Application Internet Stack Presentation Session Sockets Transport TCP, UDP Network IPv6 IP Link Mac Layer Physical 17-May-10 5
    • 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 17-May-10 6
    • 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
    • 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. 17-May-10 8
    • IPv4 address depletion 17-May-10 9
    • Notice of IPv4 Address Depletion “Make your organization’s publicly accessible resources available via IPv6 as soon as possible” 17-May-10 10
    • 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
    • IPv6 Deployment on DREN 17-May-10 12
    • 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 17-May-10 13
    • 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
    • IPv6 Security Issues 17-May-10 15
    • IPv6 Security Review •  Independent security review performed by SAIC for DREN during 2005 –  Publicly available •  Conclusions: –  protocol is no less secure than v4 17-May-10 16
    • 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 Near certainty that we will find Denial of Service Vulnerabilities 17-May-10 17
    • 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
    • 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
    • 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
    • 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 17-May-10 21
    • 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) 17-May-10 22
    • Disabling privacy addresses •  Windows XP ipv6 -p gpu UseTemporaryAddresses no •  Windows 2003 netsh interface ipv6 set privacy state=disabled store=persistent •  Windows Vista 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 •  Windows 2008 netsh interface ipv6 set global randomizeidentifiers=disabled netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent 17-May-10 23
    • 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
    • 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
    • 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
    • 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! 17-May-10 27
    • END 17-May-10 28