![]() |
IPv6 Implementation Guide, Cisco IOS XE Release 3S
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Implementing IPsec in IPv6 Security
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Contents
Implementing IPsec in IPv6 SecurityLast Updated: August 1, 2012
Cisco IOS IPv6 security features for your Cisco networking devices can protect your network against degradation or failure and also against data loss or compromise resulting from intentional attacks and from unintended but damaging mistakes by well-meaning network users. Cisco IOS IPsec functionality provides network data encryption at the IP packet level, offering robust, standards-based security. IPsec provides data authentication and antireplay services in addition to data confidentiality services. IPsec is a mandatory component of IPv6 specification. IPv6 IPsec tunnel mode and encapsulation is used to protect IPv6 unicast and multicast traffic. This document provides information about implementing IPsec in IPv6 security. Finding Feature InformationYour software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Information About Implementing IPsec for IPv6 SecurityIPsec for IPv6IP Security, or IPsec, is a framework of open standards developed by the Internet Engineering Task Force (IETF) that provide security for transmission of sensitive information over unprotected networks such as the Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec devices (peers), such as Cisco routers. IPsec provides the following optional network security services. In general, local security policy will dictate the use of one or more of these services:
With IPsec, data can be sent across a public network without observation, modification, or spoofing. IPsec functionality is similar in both IPv6 and IPv4; however, site-to-site tunnel mode only is supported in IPv6. In IPv6, IPsec is implemented using the AH authentication header and the ESP extension header. The authentication header provides integrity and authentication of the source. It also provides optional protection against replayed packets. The authentication header protects the integrity of most of the IP header fields and authenticates the source through a signature-based algorithm. The ESP header provides confidentiality, authentication of the source, connectionless integrity of the inner packet, antireplay, and limited traffic flow confidentiality. The Internet Key Exchange (IKE) protocol is a key management protocol standard that is used in conjunction with IPsec. IPsec can be configured without IKE, but IKE enhances IPsec by providing additional features, flexibility, and ease of configuration for the IPsec standard. IKE is a hybrid protocol that implements the Oakley key exchange and Skeme key exchange inside the Internet Security Association Key Management Protocol (ISAKMP) framework (ISAKMP, Oakley, and Skeme are security protocols implemented by IKE) (see the figure below). This functionality is similar to the security gateway model using IPv4 IPsec protection. IPv6 IPsec Site-to-Site Protection Using Virtual Tunnel InterfaceThe IPsec virtual tunnel interface (VTI) provides site-to-site IPv6 crypto protection of IPv6 traffic. Native IPv6 IPsec encapsulation is used to protect all types of IPv6 unicast and multicast traffic. The IPsec VTI allows IPv6 routers to work as security gateways, establish IPsec tunnels between other security gateway routers, and provide crypto IPsec protection for traffic from internal networks when it is sent across the public IPv6 Internet (see the figure below). This functionality is similar to the security gateway model using IPv4 IPsec protection. When the IPsec tunnel is configured, IKE and IPsec security associations (SAs) are negotiated and set up before the line protocol for the tunnel interface is changed to the UP state. The remote IKE peer is the same as the tunnel destination address; the local IKE peer will be the address picked from tunnel source interface which has the same IPv6 address scope as tunnel destination address. The following figures shows the IPsec packet format. IPv6 over IPv4 GRE Tunnel ProtectionGRE Tunnels with IPsecGeneric routing encapsulation (GRE) tunnels sometimes are combined with IPSec, because IPSec does not support IPv6 multicast packets. This function prevents dynamic routing protocols from running successfully over an IPSec VPN network. Because GRE tunnels do support IPv6 multicast , a dynamic routing protocol can be run over a GRE tunnel. Once a dynamic routing protocol is configured over a GRE tunnel, you can encrypt the GRE IPv6 multicast packets using IPSec. IPSec can encrypt GRE packets using a crypto map or tunnel protection. Both methods specify that IPSec encryption is performed after GRE encapsulation is configured. When a crypto map is used, encryption is applied to the outbound physical interfaces for the GRE tunnel packets. When tunnel protection is used, encryption is configured on the GRE tunnel interface. The following figure shows encrypted packets that enter a router through a GRE tunnel interface using a crypto map on the physical interface. Once the packets are decrypted and decapsulated, they continue to their IP destination as clear text. The following figure shows encryption using tunnel protection command on the GRE tunnel interface. The encrypted packets enter the router through the tunnel interface and are decrypted and decapsulated before they continue to their destination as clear text. There are two key differences in using the crypto map and tunnel protection methods:
How to Implement IPsec for IPv6 Security
Configuring a VTI for Site-to-Site IPv6 IPsec Protection
Defining an IKE Policy and a Preshared Key in IPv6Because IKE negotiations must be protected, each IKE negotiation begins by agreement of both peers on a common (shared) IKE policy. This policy states which security parameters will be used to protect subsequent IKE negotiations and mandates how the peers are authenticated. After the two peers agree upon a policy, the security parameters of the policy are identified by an SA established at each peer, and these SAs apply to all subsequent IKE traffic during the negotiation. You can configure multiple, prioritized policies on each peer--each with a different combination of parameter values. However, at least one of these policies must contain exactly the same encryption, hash, authentication, and Diffie-Hellman parameter values as one of the policies on the remote peer. For each policy that you create, you assign a unique priority (1 through 10,000, with 1 being the highest priority). When the IKE negotiation begins, IKE searches for an IKE policy that is the same on both peers. The peer that initiates the negotiation will send all its policies to the remote peer, and the remote peer will try to find a match. The remote peer looks for a match by comparing its own highest priority policy against the policies received from the other peer. The remote peer checks each of its policies in order of its priority (highest priority first) until a match is found. A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values, and when the remote peer's policy specifies a lifetime that is less than or equal to the lifetime in the policy being compared. (If the lifetimes are not identical, the shorter lifetime--from the remote peer's policy--will be used.) If a match is found, IKE will complete negotiation, and IPsec security associations will be created. If no acceptable match is found, IKE refuses negotiation and IPsec will not be established. You should set the ISAKMP identity for each peer that uses preshared keys in an IKE policy. When two peers use IKE to establish IPsec SAs, each peer sends its identity to the remote peer. Each peer sends either its hostname or its IPv6 address, depending on how you have set the ISAKMP identity of the router. By default, a peer's ISAKMP identity is the IPv6 address of the peer. If appropriate, you could change the identity to be the peer's hostname instead. As a general rule, set the identities of all peers the same way--either all peers should use their IPv6 addresses or all peers should use their hostnames. If some peers use their hostnames and some peers use their IPv6 addresses to identify themselves to each other, IKE negotiations could fail if the identity of a remote peer is not recognized and a DNS lookup is unable to resolve the identity. Perform this task to create an IKE policy and a preshared key in IPv6. DETAILED STEPS Configuring ISAKMP Aggressive ModeYou likely do not need to configure aggressive mode in a site-to-site scenario. The default mode is typically used. DETAILED STEPS Defining an IPsec Transform Set and IPsec ProfilePerform this task to define an IPsec transform set. A transform set is a combination of security protocols and algorithms that is acceptable to the IPsec routers. DETAILED STEPS Defining an ISAKMP Profile in IPv6SUMMARY STEPS
DETAILED STEPS Configuring IPv6 IPsec VTI
SUMMARY STEPS
DETAILED STEPS Verifying IPsec Tunnel Mode ConfigurationSUMMARY STEPS
DETAILED STEPS Troubleshooting IPsec for IPv6 Configuration and OperationSUMMARY STEPS
DETAILED STEPS ExamplesThis section provides the following output examples: Sample Output from the show crypto ipsec sa CommandThe following is sample output from the show crypto ipsec sacommand:
Router# show crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 3FFE:2002::A8BB:CCFF:FE01:9002
protected vrf: (none)
local ident (addr/mask/prot/port): (::/0/0/0)
remote ident (addr/mask/prot/port): (::/0/0/0)
current_peer 3FFE:2002::A8BB:CCFF:FE01:2C02 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 133, #pkts encrypt: 133, #pkts digest: 133
#pkts decaps: 133, #pkts decrypt: 133, #pkts verify: 133
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 60, #recv errors 0
local crypto endpt.: 3FFE:2002::A8BB:CCFF:FE01:9002,
remote crypto endpt.: 3FFE:2002::A8BB:CCFF:FE01:2C02
path mtu 1514, ip mtu 1514
current outbound spi: 0x28551D9A(676666778)
inbound esp sas:
spi: 0x2104850C(553944332)
transform: esp-des ,
in use settings ={Tunnel, }
conn id: 93, flow_id: SW:93, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4397507/148)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
spi: 0x967698CB(2524354763)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
conn id: 93, flow_id: SW:93, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4397507/147)
replay detection support: Y
Status: ACTIVE
inbound pcp sas:
outbound esp sas:
spi: 0x28551D9A(676666778)
transform: esp-des ,
in use settings ={Tunnel, }
conn id: 94, flow_id: SW:94, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4397508/147)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
spi: 0xA83E05B5(2822636981)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
conn id: 94, flow_id: SW:94, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4397508/147)
replay detection support: Y
Status: ACTIVE
outbound pcp sas:
Sample Output from the show crypto isakmp peer CommandThe following sample output shows peer descriptions on an IPv6 router:
Router# show crypto isakmp peer detail
Peer: 2001:DB8:0:1::1 Port: 500 Local: 2001:DB8:0:2::1
Phase1 id: 2001:DB8:0:1::1
flags:
NAS Port: 0 (Normal)
IKE SAs: 1 IPsec SA bundles: 1
last_locker: 0x141A188, last_last_locker: 0x0
last_unlocker: 0x0, last_last_unlocker: 0x0
Sample Output from the show crypto isakmp profile CommandThe following sample output shows the ISAKMP profiles that are defined on an IPv6 router: Router# show crypto isakmp profile ISAKMP PROFILE tom Identities matched are: ipv6-address 2001:DB8:0:1::1/32 Certificate maps matched are: Identity presented is: ipv6-address fqdn keyring(s): <none> trustpoint(s): <all> Sample Output from the show crypto isakmp sa CommandThe following sample output shows the SAs of an active IPv6 device. The IPv4 device is inactive. Router# show crypto isakmp sa detail Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap. IPv6 Crypto ISAKMP SA dst: 3FFE:2002::A8BB:CCFF:FE01:2C02 src: 3FFE:2002::A8BB:CCFF:FE01:9002 conn-id: 1001 I-VRF: Status: ACTIVE Encr: des Hash: sha Auth: psk DH: 1 Lifetime: 23:45:00 Cap: D Engine-id:Conn-id = SW:1 dst: 3FFE:2002::A8BB:CCFF:FE01:2C02 src: 3FFE:2002::A8BB:CCFF:FE01:9002 conn-id: 1002 I-VRF: Status: ACTIVE Encr: des Hash: sha Auth: psk DH: 1 Lifetime: 23:45:01 Cap: D Engine-id:Conn-id = SW:2 Sample Output from the show crypto map CommandThe following sample output shows the dynamically generated crypto maps of an active IPv6 device:
Router# show crypto map
Crypto Map "Tunnel1-head-0" 65536 ipsec-isakmp
Profile name: profile0
Security association lifetime: 4608000 kilobytes/300 seconds
PFS (Y/N): N
Transform sets={
ts,
}
Crypto Map "Tunnel1-head-0" 65537
Map is a PROFILE INSTANCE.
Peer = 2001:1::2
IPv6 access list Tunnel1-head-0-ACL (crypto)
permit ipv6 any any (61445999 matches) sequence 1
Current peer: 2001:1::2
Security association lifetime: 4608000 kilobytes/300 seconds
PFS (Y/N): N
Transform sets={
ts,
}
Interfaces using crypto map Tunnel1-head-0:
Tunnel1
Sample Output from the show crypto session CommandThe following output from the show crypto session command provides details on currently active crypto sessions:
Router# show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: Tunnel1
Session status: UP-ACTIVE
Peer: 2001:1::1 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 2001:1::1
Desc: (none)
IKE SA: local 2001:1::2/500
remote 2001:1::1/500 Active
Capabilities:(none) connid:14001 lifetime:00:04:32
IPSEC FLOW: permit ipv6 ::/0 ::/0
Active SAs: 4, origin: crypto map
Inbound: #pkts dec'ed 42641 drop 0 life (KB/Sec) 4534375/72
Outbound: #pkts enc'ed 6734980 drop 0 life (KB/Sec) 2392402/72
Configuration Examples for IPsec for IPv6 SecurityExample: Configuring a VTI for Site-to-Site IPv6 IPsec Protectioncrypto isakmp policy 1 authentication pre-share ! crypto isakmp key myPreshareKey0 address ipv6 3FFE:2002::A8BB:CCFF:FE01:2C02/128 crypto isakmp keepalive 30 30 ! crypto ipsec transform-set 3des ah-sha-hmac esp-3des ! crypto ipsec profile profile0 set transform-set 3des ! ipv6 cef ! interface Tunnel0 ipv6 address 3FFE:1001::/64 eui-64 ipv6 enable ipv6 cef tunnel source Ethernet2/0 tunnel destination 3FFE:2002::A8BB:CCFF:FE01:2C02 tunnel mode ipsec ipv6 tunnel protection ipsec profile profile0 Additional ReferencesRelated Documents
MIBsRFCs
Technical Assistance
Feature Information for Implementing IPsec in IPv6 SecurityThe following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. © 2012 Cisco Systems, Inc. All rights reserved.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|