Sample. IPv6 Security. Module 5: IPv6 Security. Module 5: Jul

Transcription

1 Module 5: IPv6 Security 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. Sample Jul

2 Objectives After completing this module, you should be able to: Describe the main features of IP Security (IPsec). Discuss similarities and differences between IPv4 and IPv6 Authentication Header (AH) and Encapsulating Security Payload (ESP) security protocols. Discuss why IPsec alone cannot completely secure a network. List threats that remain essentially the same from IPv4 to IPv6. Describe how the design of IPv6 provides security beyond IPsec. Discuss some threats with new considerations in IPv6. Jul 2008 Student Guide: X xx 2 Objectives One of the weaknesses of the original Internet Protocol was that it lacked a mechanism for ensuring the authenticity and privacy of data passed over the internetwork. As discussed in Module 1, IP was designed at a time when security wasn't the critical issue that it is today. The ARPANET, predecessor to the Internet, comprised a relatively small number of networks whose administrators often knew each other. But as the Internet evolved, went public, and became an indispensable asset to business success, maintaining network security while harnessing the Net s considerable power became a top-of-mind concern. A number of security techniques focused at the higher layers of the Open Systems Interconnection (OSI) protocol stack have evolved over the years to compensate for IP's lack of security. While valuable in their way, they are particular to various applications, and thus can't be generalized easily. Secure Sockets Layer (SSL), for example, is a security measure for World Wide Web access and File Transfer Protocol (FTP), but there are dozens of applications with which it was never intended to work. What was needed was a solution to allow security at the IP level so all higher-layer TCP/IP protocols could take advantage of it. When the decision was made, then, to develop a new version of IP IPv6 it seemed the perfect opportunity to resolve not just addressing problems but the lack of security as well. IP Security (IPsec) was the result. IPsec was developed with IPv6 in mind, but it was designed to work with IPv4 as well because the new IP version took years to develop and roll out. This module will take a look at both implementations of IPsec, comparing and contrasting, and will explore other IPv6 security considerations as well. By the time you have completed this module, you should be able to: Describe the main features of IPsec. Discuss similarities and differences between IPv4 and IPv6 Authentication Header (AH) and Encapsulating Security Payload (ESP) security protocols. Discuss why IPsec alone cannot completely secure a network. List threats that remain essentially the same from IPv4 to IPv6. Describe how the design of IPv6 provides security beyond IPsec. Discuss some new threats to consider for IPv6. Jul

3 Discussion Topics IPsec: The Briefest of Overviews Core Protocols and Components Transport and Tunnel Modes IPv4 versus IPv6 IPsec Implementation IPsec Is Not a Silver Bullet Jul Discussion Topics As mentioned in the introduction, security methods were designed to compensate for a lack of IP security. Even after IPsec was defined, such solutions remained essential, in part because support for IPsec is optional in IPv4. Thus, IPv4 s Routing Information Protocol (RIP), for example, relies on a specific RIP authentication mechanism to secure routing exchanges. In IPv6, with Network Address Translation (NAT) no longer an impediment to IPsec implementation, the end-to-end security possibilities of IPsec can be realized. IPsec is in fact required to fully implement the IPv6 standard. In such a network, every IPv6 packet travels through a VPN tunnel across the Internet. IPv6 s routing protocols are designed to take advantage of that. IPv6 s RIPng, for example, relies on IPsec s Authentication Header (AH) and Encapsulating Security Payload (ESP) security protocols discussed on upcoming slides in this module to ensure the integrity and confidentiality of routing exchanges. Similarly, authentication has been removed from the latest Open Shortest Path First (OSPF) protocol, OSPFv3. It now relies on IPv6 s AH and ESP. That important distinction aside, the security provided by IPv6 is in many ways the same as that provided by IPv4. We ll therefore begin this module with just the briefest overview of IPsec, the protocol suite network administrators can use to establish and maintain a virtual private network (VPN), creating a boundary between trusted and untrusted networks. Jul

4 IPsec Brief Overview: Core Protocols and Components Endpoints agree on Security Association (SA) to define terms of VPN Terms include: Security protocols Algorithms Cryptographic keys Jul IPsec Brief Overview: Core Protocols and Components When an IPsec connection is created, the two endpoints must agree to a Security Association (SA), which defines the terms of the VPN connection. These terms include the exact set of security protocols, algorithms, and cryptographic keys that will be used to authenticate and protect the traffic transmitted across the connection. After the endpoint devices are authenticated and an SA established, the VPN tunnel is created. Defined in RFC 4301 (which obsoletes the original, 2401), the IPsec standard comprises three main parts: Internet Key Exchange (IKE) IKE is an optional standard for automatically negotiating and establishing SAs. After the encryption algorithms and keys are agreed upon in the IKE (or optionally manual) exchange, IPsec uses the AH and ESP protocols to manage the actual data encryption and authentication. Authentication Header (AH) protocol AH provides message integrity authentication. In simplest terms, it ensures data has not been tampered with en route to its destination. Encapsulating Security Payload (ESP) protocol ESP provides data encryption as well as some message integrity authentication. Jul

5 IPsec Brief Overview: Transport and Tunnel Modes Transport Mode: End-to-end communication scheme Internet Sender Station IPsec Tunnel Mode: Between security gateways Receiver Station LAN IP Internet LAN IP IPsec Sender station Security gateway Security gateway Receiver station Jul IPsec Brief Overview: Transport and Tunnel Modes In both IPv4 and IPv6, AH and ESP may be applied alone or in combination to provide a desired set of security services. In addition, IPsec can be run in either tunnel mode or transport mode: Tunnel mode is most commonly used between gateways, these gateways acting as proxies for the nodes behind them. Transport mode is used between end stations or between an end station and a gateway, if the gateway is being treated as a node. Jul

6 Discussion Topics IPsec: The Briefest of Overviews IPv4 versus IPv6 IPsec Implementation Authentication Header IPv4 and IPv6 AH Transport Mode IPv4 and IPv6 AH Tunnel Mode Encapsulating Security Payload IPv4 and IPv6 ESP Transport Mode IPv4 and IPv6 ESP Tunnel Mode IPsec Is Not a Silver Bullet Jul Discussion Topics In the next section we will take a look at the AH and ESP IPsec security protocols and their configuration in IPv4 and IPv6 tunnel and transport modes. Jul

7 Authentication Header Field Next Header Payload Length Reserved Purpose Protocol number of the next header after the AH Length of AH only Not used; set to zeroes SPI Identifies the SA Sequence Number Unique ID for each packet on an SA Authentication Data Integrity Check Value (ICV) Jul Authentication Header (AH) AH uses an authentication algorithm most commonly Message Digest 5 (MD5) or Secure Hash Algorithm 1 (SHA-1) and a key that the sender and receiver agree upon to compute an Integrity Check Value (ICV) on IP packets, and add the result as authentication data in a special header. The 32-bit Security Parameters Index (SPI) is used in combination with the destination address and the security protocol (AH or ESP) to identify the correct SA for the communication. With this information and the Authentication Data field s ICV, the destination node can compute the ICV of received packets and compare to verify packet integrity. AH can also provide an anti-replay service: that is, prevent the retransmission of captured packets. AH s Sequence Number field is initialized to zero when an SA is formed, and then incremented for each packet sent using that SA, uniquely identifying that packet. AH provides authentication for as much of the IP header as possible, as well as for upper-level protocol data. However, some IP header fields may change in transit, and thus the sender may not be able to predict the value of these fields upon their arrival at the packet s destination. These are known as mutable fields, and include the following: Type of Service (TOS), Flags, Fragment Offset, and Header Checksum All of which have been removed from IPv6 Time to Live (TTL) Known as Hop Limit in IPv6 The next several slides take a closer look at the similarities and differences between IPv4 and IPv6 IPsec integrity authentication. Jul

8 IPv4 AH Transport Mode AH is between IP header and IP data. Protocol field points to AH (protocol = 51). Next Header field contains the IP header s prior protocol value: TCP = 6 Jul IPv4 Transport Mode In IPv4 transport mode, the Authentication Header is added between the IP header and the IP data, before any higher-layer protocols. The Protocol field of the IPv4 header points to AH (the AH protocol value is 51), while its Next Header field contains the IP header s prior protocol value ( 6 in the example in the slide above, for TCP.) Jul

9 IPv6 AH Tunnel Mode: Extension Headers IPv4 Options are not distinct entities. IPv6 Options are distinct entities. They appear one after the other, in an agreed-upon order, following the main header. AH and ESP are both extension headers. Order Extension Header Basic IPv6 Header Hop-by-Hop Options Destination Options (with Routing) Routing Header Fragment Header Authentication Header Encapsulation Security Payload Header Destination Options Mobility Header No Next Header Code UL UL UL TCP UDP ICMPv Jul IPv6 AH Tunnel Mode: Extension Headers As with IPv4, in IPv6 transport mode the Authentication Header is added between the IP header and the IP data, before any higher-layer protocols. As you ll recall from Module 2, however, although IPv4 options are not distinct entities, they are distinct in IPv6. And when included in an IPv6 packet, they appear one after the other, in a specified order, following the main header: The Next Header field in the main header contains a reference number for the first extension header type. The Next Header field in the first extension header contains the number of the second extension header type, if there is a second one, and so on. The Next Header field of the final extension header contains the protocol number of the encapsulated higher-layer protocol. This still applies when IPsec is in play: in fact, AH and ESP are two of the established IPv6 extension headers. Jul

10 IPv6 AH Tunnel Mode AH as end-to-end payload Added after : Hop-by-Hop Routing Fragmentation AH can precede or follow Destination Options: Can be last in chain, before Routing header, or both. Jul IPv6 AH Tunnel Mode Illustrated As mentioned earlier, with NAT no longer a roadblock to IPsec implementation in IPv6, IPv6 AH is viewed as an end-to-end payload, and thus should appear after Hop-by-Hop, Routing, and Fragmentation extension headers. It may appear before or after the Destination Options extension header, however. As illustrated in the previous slide, the Destination Options extension header is the only extension header that can appear more than once in the same packet: Normally, Destination Options appears as the final extension header. However, the Destination Options header may contain options that must be examined by devices en route to the destination. In this case, it is placed before the Routing extension header. A second such header containing options only for the final destination may also appear. Jul

11 IPv4/IPv6 Tunnel Mode Similarities: Whole IP packet secured, encapsulated in IP packet with AH Differences: IPv4 options vs. IPv6 extension headers IPv4 = Next Header value of 4 (for IPv4 ); IPv6 = Next Header value of 41 (value of the encapsulated IPv6 packet) Jul IPv4 and IPv6 Tunnel Mode In IPv4 and IPv6 tunnel mode the entire original IP packet is secured and then encapsulated within another IP packet that includes the AH header. The differences between IPv4 options and IPv6 extension headers apply in this scenario as well. In addition, note in IPv4 tunnel mode the AH header s use of the Next Header value of 4 as in IPv4. In IPv6, on the other hand, the AH header s Next Header value of 41 is the value for the encapsulated IPv6 packet. Jul

12 Encapsulating Security Payload Encrypted Authenticated Field SPI Sequence Number Payload Data Padding Pad Length Next Header Purpose Identifies the SA Uniquely identifies each packet on an SA via a counter field Encrypted higher-layer message or encapsulated IP packet; may also include an initialization vector certain encryption methods require Included as needed for encryption or alignment Number of bytes in the Padding field Contains the protocol number of the next header after the AH Authentication Data Contains the ICV from the optional authentication algorithm Jul Encapsulating Security Payload ESP uses the keys calculated during the last phase of IKE and an agreed-upon encryption algorithm to encrypt IP data. Data Encryption Standard-Cipher Block Chaining (DES)-CBC, Triple DES-CBC (3DES-CBC), and Advanced Encryption Standard-CBC (AES-CBC) are the most widely used. This protocol can also provide authentication and anti-replay service, but its authentication capabilities are more limited than those of AH. An AH header authenticates both the packet payload and the IP header. An ESP header only authenticates the payload. Encryption really should not be applied without data integrity, because there can be no assurance that the encryption was performed by a legitimate party. But while combining the two protocols offers more security than ESP with its authentication capabilities alone, the processing overhead involved may outweigh the benefit. If applied together, the AH header precedes the ESP header to verify authenticity and integrity before the packet is decrypted. If both headers are used, it is not necessary to use the authentication in the ESP header. Jul

13 IPv4/IPv6 ESP Transport Mode For IPv4 and IPv6: ESP header placed similarly to AH. ESP trailer appended to data to be encrypted. Payload and ESP trailer are both encrypted, with any IP headers. ESP Authentication Data field placed at the end. Jul IPv4 and IPv6 ESP Transport Mode ESP Header Placement of the ESP header in IPv4 and IPv6 transport mode is similar to that of AH: In IPv4, the ESP header (containing the SPI and Sequence Number fields) is placed after the original IPv4 header. In IPv6, it is inserted into the IP packet as an extension header, following the IPv6 rules for such: after Hop-by-Hop, Routing, and Fragmentation extension headers, and before or after the Destination Options extension header. ESP Trailer In both IPv4 and IPv6 scenarios, the ESP trailer (containing the Padding and Pad Length fields used to align the encrypted data, as well as the Next Header field) is appended to the data to be encrypted. The payload and the ESP trailer are both encrypted, as are any other IP headers including the Destination Options extension header in IPv6 that appear between the ESP header and the payload. The ESP header itself, however, is not encrypted. ESP Authentication Data The ESP Authentication Data field (containing an ICV and used to authenticate the rest of the encrypted datagram after encryption) is placed at the end. Jul

14 IPv4/IPv6 ESP Tunnel Mode In IPv4 and IPv6: ESP header and trailer bracket the entire encapsulated IPv6 packet. Notice Encryption and authentication coverage How Next Header field in ESP trailer references the packet. Jul IPv4 and IPv6 ESP Tunnel Mode In IPv4 and IPv6 tunnel mode, the ESP header and trailer bracket the entire encapsulated IPv6 packet. Note the encryption and authentication coverage, and also how the Next Header field in the ESP trailer references the packet. Jul

15 IPsec Reference Materials For more on the subjects discussed thus far in this module, see the following RFCs: RFC Defines 4301 The architecture and general operation of IPsec (main IPsec document) 4302 The IPsec AH protocol, used for ensuring data integrity and origin verification 2403 The MD5 Hash-based Message Authentication Code (HMAC) variant encryption algorithm 4305 The SHA-1 HMAC variant encryption algorithm 4303 The IPsec ESP protocol providing data encryption for confidentiality 4306 The IKEv2 protocol, used to negotiate SAs and exchange keys between devices for secure communications Jul IPsec Reference Materials For more on the subjects discussed thus far in this module, see the RFCs listed in the table in the slide above. Jul

16 Discussion Topics IPsec: The Briefest of Overviews IPv4 versus IPv6 IPsec Implementation IPsec Is Not a Silver Bullet Built-in Security Beyond IPsec One Door Closes; Another Is Opened Coexistence of IPv4 and IPv6 IPv4 and IPv6 Threats: More Alike Than Not Jul Discussion Topics End-to-end IPsec is one of the major advantages of IPv6, but while a very good security mechanism, it is not the proverbial silver bullet. In fact, because most security breaches occur at the application level, even the successful, comprehensive deployment of IPsec with IPv6 does not guarantee any additional security for many attacks, beyond of course the valuable ability to determine the source. And just as in the IPv4 world, there will always be hackers seeking new ways to break into IPv6 networks. The changes made to the IP protocol can even offer new inroads for these attackers. In addition, the inevitable coexistence of IPv4 and IPv6 could offer new venues to exploit security holes and circumvent the defenses of one protocol to attack the other. This section takes a look at the security threats facing an IPv6 infrastructure while highlighting IPv4 similarities and differences. An exhaustive discussion of the various and sundry security concerns in an IPv6 network is outside the scope of this course, but the next several slides will give you a feel for the IPv6 security landscape. Jul

17 Built-in Security Beyond IPsec IPv4 Network /16 Attacker with network mapping software Possible addresses: 65,535 IPv6 Network 2001:6289:f34e: 0f15:7ac2:0013::/96 Attacker with network mapping software Possible addresses: Billions Jul Built-in Security Beyond IPsec Many features of IPv6 are attractive from a security standpoint. In particular, its huge address space and subnet size render it highly resistant to malicious scans and inhospitable to automated, scanning and self-propagating worms and hybrid threats. On an IPv4 network, for example, attackers can complete a reconnaissance scan with network mapping software within seconds. The software systematically scans every possible address on the target network s subnet typically a class C IPv4 subnet, with 8 bits allocated for the host address: a mere 65,535 possible hosts to quickly map the devices on that network. Note the use of an Internet Engineering Task Force (IETF) IPv6 reserved address (::/96) in the example above. In general, assigned IPv6 addresses would have a 64-bit designation which means an even-greater 2 64, or approximately 18 quintillion, possible host addresses. Scanning every address on such a subnet could take years rather than seconds. For this reason, Network Mapper (Nmap), commonly used to identify active devices in an IPv4 network, does not even support ping sweeps on IPv6 networks. Jul

18 IPv6 Privacy Extensions and CGAs IPv6 Network 2 IPv6 Network 1 Prefix 2001:fed9:2e35:7ae6 Prefix 2001:3267:cee9:2fe1 Internet IPv6 address 2001:3267:cee9:2fe1:0000:0012:7905:25B9 Network prefix Interface ID MAC address 00:12:79:05:25:B9 IPv6 address 2001:fed9:2e35:7ae6:0000:0012:7905:25B9 Network prefix Interface ID Attacker Track 2001:****:****:****:0000:0012:7905:25B9 Jul IPv6 Privacy Extensions and CGAs Privacy extensions can also make reconnaissance less effective. As you now know, IPv6 addresses are created using a network-specific prefix and an interface identifier that is unique to each device and typically based on the device s MAC address. EUI- 64 is a standard method of deriving the EUI field, the lower 64 bits of the IPv6 address, from the 48-bit MAC address of the associated network interface. Unfortunately, using a static interface identifier, such as a MAC address, in conjunction with a set autoconfiguration process may encourage certain attacks: An attacker may be able to find a network address pattern that allows a successful network attack. An attacker may be able to track a particular device no matter where or how it is connected to the Internet. The IETF addressed this issue by specifying that an address may be identified by a dynamic, privacy-protecting, pseudo-random EUI chosen in such a way as to never collide with an autoconfigured EUI. These interface identifiers are generated via an MD5 hash. To patch the security hole, you can also use Cryptographically Generated Addresses (CGAs) with the SEcure Neighbor Discovery (SEND) protocol (RFC 3971). You ll recall from Module 3 that RFC 3972 describes a method for binding a public signature key to an IPv6 address. The basic idea is to generate the interface identifier (the rightmost 64 bits) of the IPv6 address by computing a cryptographic hash of the public key. The resulting IPv6 address is called a CGA. The corresponding private key can then be used to sign messages sent from the address. The protection works without a certification authority or any security infrastructure, protecting the Neighbor Discovery traffic without the complexity and vulnerabilities of IPsec. Jul

19 IPv6 Scanning Considerations Public servers still need to be DNS-reachable. Administrators may adopt easy-to-remember easy-to-guess addresses. Multicasts offer inroads onto the network. No broadcast flooding, but amplification attacks still a threat Jul IPv6 Scanning Considerations There are, however, other considerations when it comes to IPv6 scanning: Public servers will still need to be DNS reachable, for example, which provides a means of attack. Administrators may adopt easy-to-remember and easy-to-guess addresses. IPv6 multicast addresses (all routers [FF05::2]. all DHCP servers [FF05::1:3]), might enable attackers to identify and compromise key resources on a network. In addition to filtering for unnecessary multicast traffic at the border, all stacks should properly implement RFC 4443, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 4443 states that an ICMP reply should not be generated for packets that have a multicast destination address. Jul

20 One Door Closes; A Window Opens IPv6 architecture closes security doors, but new windows open. ND immune to off-link spoofing, but vulnerable to new on-link spoofing, DoS: Router Advertisement Duplicate Address Discovery Address Resolution Jul One Door Closes; A Window Opens But for every security door that is closed, a vulnerability window opens. For example, IPv6 s Neighbor Discovery (ND) provides both a defense against old attacks as well as new paths to invasion or disruption. Although immune to spoofing attacks that originate from off-link nodes (because its messages have a hop limit of 255 upon receipt), ND spoofing remains a possibility, including new ND-specific spoofs. ND is also susceptible to redirect attacks and Denial-of-Service (DoS) attacks. In a redirect attack, a malicious node redirects packets away from legitimate receivers such as a last-hop router to another node on the link. In a DoS attack, the malicious node can prevent communication between the victim and all other nodes, or it can redirect traffic destined for other hosts to the victim node, thereby creating a flood of traffic to the victim. For example: Router Advertisement (RA) redirect The attacker announces new routers that do not exist, pretends to be a new router, changes lifetimes, deprecates valid prefixes, and so on. Duplicate Address Discovery DoS The attacker constantly responds to all attempts to join a link, claiming to already own any address that is proposed for use. Address Resolution DoS The attacker forges Solicitation and Advertisement messages, thereby corrupting the host neighbor cache with invalid link-layer addresses, which prevents the host from reaching that neighbor. For more information about ND and possible threats, see RFC 3756, IPv6 Neighbor Discovery (ND) Trust Models and Threats. Jul

21 Coexistence of IPv4 and IPv6 Unique threats for 6to4 transition networks Address spoofing through protocol tunneling External packet uses spoofed address from internal network Ingress filtering cannot prevent IPv6 address spoofing Possible mitigation Relays must perform proper decapsulation checks. RFC 4891 proposes the use of IPsec. Transition networks the norm for near future Security implications extend beyond spoofing. RFC 3964 explains issues and mitigation efforts. Jul Coexistence of IPv4 and IPv6 With regard to 6to4 transition networks (IPv6 transported by IPv4), protocol tunneling could also lead to address spoofing in this case, if the spoofed address is used to masquerade an external packet as one that originated from the inside network. Anyone can, regardless of ingress filtering, spoof a native IPv6 address to a 6to4 node. If the relays perform proper decapsulation checks, on the other hand, the spoofing can only be achieved when the IPv4 address is spoofable as well. In addition, RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels, proposes the use of IPsec to help prevent such threats and provide integrity, confidentiality, replay protection, and origin protection between tunnel endpoints. 6to4 security issues extend beyond spoofing, and are of concern because transition networks are likely to be the norm for some time to come. Most organizations will not migrate to IPv6 completely in the near future. The potentially multi-year coexistence of IPv4 and IPv6 could offer attackers new opportunities for attacks in addition to offering administrators the headache of two infrastructures with their own unique security concerns. RFC 3964, Security Considerations for 6to4, documents many of the issues to be tackled and the possibilities for mitigation. Jul

22 IPv4 and IPv6 Threats: More Alike Than Not Many IPv4 attacks are an issue for IPv6 Some attacks are IP-version agnostic: Flooding Sniffing Application-layer attacks Man-in-the-middle attacks Rogue devices Other attacks are IPv6-specific IPv4 and IPv6 threats are more similar than different Until IPsec is optimized, use proven security best practices and tools Jul IPv4 and IPv6 Threats: More Alike Than Not You ve seen how reconnaissance remains an issue for IPv6 networks. Many other wellestablished IPv4 threats do as well. Some attacks are very similar regardless of IP version flooding, sniffing, application-layer attacks, man-in-the-middle attacks, and rogue devices, for example while others have adapted to the unique design of IPv6. With regard to the latter, we have already illustrated some of the ways in which IPv6 s Neighbor Discovery protocol and multicast architecture have become a target for attackers. Chained and large-size extension headers that must be processed by all stacks are also useful to an attacker. Large-size extension headers or a large number of extension headers can drain the resources of the devices that must deal with these. And chaining a large number of these headers forces a network s security devices and mechanisms to perform long lookups into a packet, possibly to a degree beyond their capabilities, to try get to the information that reveals an attack. Thus, this last can be an effective means of hiding such an attack. New threat venues aside, however, in the end IPv4 and IPv6 threats are characterized by more similarities than differences. Until end-to-end IPsec and a reliable key-distribution protocol is consistently deployed for IPv6, the proven IPv4 security best practices and tools remain the optimal line of defense. Jul

23 Summary IPv6 is now part of the base IP specification. Minor modifications have been made to AH and ESP in transport and tunnel mode. Overall, the changes to IPsec are minor. IPv6 does offer some security advantages that extend beyond integrated IPsec. These same benefits can be leveraged by attackers. In the end, IPv4 and IPv6 are on the same page with security. The IPv4 best practices and tools are indispensable IPv6 assets. Jul Summary This module opened with an examination of the benefits and architecture of IPsec. You learned that, in addition to being a component of the base IPv6 specification (as opposed to an option as with IPv4), a few modifications have been made to the architecture of IPsec to accommodate the design updates of IPv6 itself. Overall, however, the changes to IPsec are minor. The same is true for IPv6 security in general. Because IPsec is mandated for full IPv6 implementation, IPv6 is often presumed to be more secure than IPv4. And ideally, with wellcoded applications, a robust identity infrastructure, and efficient key management, this statement will one day be true. Despite that, however, there will always be threats both old and new with which to contend. In fact, most security breaches occur at the application level, outside the sphere of influence of even the most successful deployment of IPsec. Of course, you did learn in this module that IPv6 offers some security advantages that extend beyond integrated IPsec but you also learned that these same benefits can be leveraged by attackers if the network is not properly secured against such threats. And in the end, you discovered that, security improvements and new venues for attacks aside, at this point in time IPv4 and IPv6 are largely on the same page when it comes to security. The IPv4 best practices and tools are indispensable assets in an IPv6 environment. Jul

24 Jul Jul