IPv6 Module 5: IPv6 Security Module 5: IPv6 Security · IPv6’s RIPng, for example, relies on...

IPv6 Module 5: IPv6 Security

Jul 2008 1

© 2008 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice.

IPv6 Security IPv6 Security Module 5:Module 5:

Sampl

e


Jul 2008 2

Jul 2008 2Student Guide: X–xx

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.

ObjectivesOne 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 addressingproblems 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 2008 3

Jul 2008 3

Discussion Topics

IPsec: The Briefest of OverviewsCore Protocols and ComponentsTransport and Tunnel Modes

IPv4 versus IPv6 IPsec ImplementationIPsec Is Not a Silver Bullet

Discussion TopicsAs 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 2008 4

Jul 2008 4

IPsec Brief Overview:Core Protocols and ComponentsEndpoints agree on Security Association (SA) to define terms of VPN• Terms include:

– Security protocols– Algorithms– Cryptographic keys

IPsec Brief Overview: Core Protocols and ComponentsWhen 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 2008 5

Jul 2008 5

IPsec Brief Overview:Transport and Tunnel Modes

LAN

Security gateway

IP

Receiver station

LAN

Security gateway

IP

Sender station

Internet

IPsec

Tunnel Mode:Between security gateways

Sender Station

Internet

IPsec

Transport Mode:End-to-end communication scheme

Receiver Station

IPsec Brief Overview: Transport and Tunnel ModesIn 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 2008 6

Jul 2008 6

Discussion Topics

IPsec: The Briefest of OverviewsIPv4 versus IPv6 IPsec Implementation

Authentication HeaderIPv4 and IPv6 AH Transport ModeIPv4 and IPv6 AH Tunnel ModeEncapsulating Security PayloadIPv4 and IPv6 ESP Transport ModeIPv4 and IPv6 ESP Tunnel Mode

IPsec Is Not a Silver Bullet

Discussion TopicsIn 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 2008 7

Jul 2008 7

Authentication Header

Unique ID for each packet on an SASequence Number

Identifies the SASPI

Not used; set to zeroesReserved

Length of AH onlyPayload Length

Integrity Check Value (ICV)

Protocol number of the next header after the AH

Purpose

Authentication Data

Next Header

Field

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 2008 8

Jul 2008 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

IPv4 Transport ModeIn 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 2008 9

Jul 2008 9

IPv6 AH Tunnel Mode:Extension Headers

17UDPUL

58ICMPv6UL

6TCPUL

59No Next Header

135Mobility Header9

60Destination Options8

50Encapsulation Security Payload Header

7

51Authentication Header6

44Fragment Header5

43Routing Header4

60Destination Options (with Routing)

3

0Hop-by-Hop Options2

–Basic IPv6 Header1

CodeExtension HeaderOrder• 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.

IPv6 AH Tunnel Mode: Extension HeadersAs 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 2008 10

Jul 2008 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.

IPv6 AH Tunnel Mode IllustratedAs 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 Routingextension header.

A second such header containing options only for the final destination may also appear.


Jul 2008 11

Jul 2008 11

Similarities:• Whole IP packet secured, encapsulated in IP packet with AH

IPv4/IPv6 Tunnel Mode

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)

IPv4 and IPv6 Tunnel ModeIn 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 2008 12

Jul 2008 12

Encapsulating Security Payload

Included as needed for encryption or alignmentPadding

Contains the protocol number of the next header after the AHNext Header

Number of bytes in the Padding fieldPad Length

Encrypted higher-layer message or encapsulated IP packet; may also include an initialization vector certain encryption methods require

Payload Data

Uniquely identifies each packet on an SA via a counter fieldSequence Number

Contains the ICV from the optional authentication algorithm

Identifies the SA

Purpose

Authentication Data

SPI

Field

Auth

enticate

d

Encryp

ted

Encapsulating Security PayloadESP 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 2008 13

Jul 2008 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.

IPv4 and IPv6 ESP Transport ModeESP HeaderPlacement 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 TrailerIn both IPv4 and IPv6 scenarios, the ESP trailer (containing the Padding and Pad Lengthfields 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 DataThe 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 2008 14

Jul 2008 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.

IPv4 and IPv6 ESP Tunnel ModeIn 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 2008 15

Jul 2008 15

IPsec Reference Materials

For more on the subjects discussed thus far in this module, see the following RFCs:

The IPsec ESP protocol providing data encryption for confidentiality4303

The SHA-1 HMAC variant encryption algorithm4305

The MD5 Hash-based Message Authentication Code (HMAC) variant encryption algorithm

2403

The IPsec AH protocol, used for ensuring data integrity and origin verification

4302

The IKEv2 protocol, used to negotiate SAs and exchange keys between devices for secure communications

The architecture and general operation of IPsec (main IPsec document)

Defines…

4306

4301

RFC

IPsec Reference MaterialsFor more on the subjects discussed thus far in this module, see the RFCs listed in the table in the slide above.


Jul 2008 16

Jul 2008 16

Discussion Topics

IPsec: The Briefest of OverviewsIPv4 versus IPv6 IPsec Implementation

IPsec Is Not a Silver BulletBuilt-in Security Beyond IPsecOne Door Closes; Another Is OpenedCoexistence of IPv4 and IPv6IPv4 and IPv6 Threats: More Alike Than Not

Discussion TopicsEnd-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 2008 17

Jul 2008 17

Built-in Security Beyond IPsec

IPv6 Network

Attacker with network mapping

software

Possible addresses: Billions

2001:6289:f34e:0f15:7ac2:0013::/96

IPv4 Network

Attacker with network mapping

software

Possible addresses: 65,535

10.1.0.0/16

Built-in Security Beyond IPsecMany 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 264, 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 2008 18

Jul 2008 18

IPv6 Privacy Extensions and CGAs

IPv6 Network 1

Network prefix

Attacker

Prefix2001:fed9:2e35:7ae6

Track 2001:****:****:****:0000:0012:7905:25B9

IPv6 address2001:fed9:2e35:7ae6:0000:0012:7905:25B9

MAC address00:12:79:05:25:B9

IPv6 Network 2

Prefix2001:3267:cee9:2fe1

IPv6 address2001:3267:cee9:2fe1:0000:0012:7905:25B9

Internet

Interface ID

Network prefix Interface ID

IPv6 Privacy Extensions and CGAsPrivacy 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 2008 19

Jul 2008 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

IPv6 Scanning ConsiderationsThere 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 2008 20

Jul 2008 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

One Door Closes; A Window OpensBut 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 2008 21

Jul 2008 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.

Coexistence of IPv4 and IPv6With 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 2008 22

Jul 2008 22

IPv4 and IPv6 Threats:More Alike Than NotMany 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

IPv4 and IPv6 Threats: More Alike Than NotYou’ve seen how reconnaissance remains an issue for IPv6 networks. Many other well-established 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 2008 23

Jul 2008 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.

SummaryThis 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 well-coded 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 2008 24

Jul 2008 24

Date post:	15-Aug-2020
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

IPv6 Module 5: IPv6 Security Module 5: IPv6 Security · IPv6’s RIPng, for example, relies on...

Documents