IPsec VPN Dynamic Crypto Map With RRI, X-Auth

(1) Routing Consideration in Dynamic Crypto Maps

Underlay’s control plane packets shouldn’t go inside IPsec Tunnel

• These control plane packets need to be explicitly denied first on Crypto ACL
• So they will not encrypted/dropped unnecessarily

RRI (Reverse Route Injection)

• Feature to dynamically inject routes on dynamic crypto map endpoints
  • From remote endpoints into IPsec VPN gateways’s routing table
  • Which can subsequently be redistributed into IGP domain
• Benefits
  • To keep the routing table size manageable
  • Scale the IGP of an IPsec VPN implementation

RRI and Dynamic Crypto Maps illustration (Figure 1)

• 155.0.0.0/8 attempts to connect to 100.0.0.0 via default route towards R2
• R2 sees the traffic, successfully matches it against its crypto ACL
  • Initiates ISAKMP SA negotiation
• R1 receives the request and finds a matched configured ISAKMP
  • Creates a temporary crypto map entry
  • IKE negotiation continue until finishing Phase 2 SA
• R1 uses RRI to dynamically inject route “155.0.0.0/8 via Tu11” into its routing table
  • Redistribute the route into IGP
• No need for routing protocol adjacency between R1 and R2
  • 155.0.0.0/8 network use default route to reach 100.0.0.0/8
  • 100.0.0.0/8 network use redistributed RRI route to reach 155.0.0.0/8

(2) Security Consideration in Dynamic Crypto Maps

Peering restriction and traffic flow restriction

• By default, dynamic crypto maps allow
  • Peering sessions from any peer IP address
  • All traffic to be protected by IPsec
• Both of these areas can be secured by
  • Restricting peering sessions
  • Restricting traffic using dynamic crypto map ACLs

Key administration and scalability of dynamic crypto map authentication

• Using preshared key
  • Difficult to scale and maintain unique key for each peer
• Using wildcard preshared key
  • Present a security risk
• IKE X-Auth in conjunction with radius AAA server
  • Highly scalable, centralized credential database
  • More secure than wildcard preshared key

X-Auth (Extended Authentication)

IKE X-Auth negotiation occurs in IKE Phase 1.5

• After an IKE Phase 1 SA has been created
  • Doesn’t replace IKE itself, but an additional to it
• Before IKE Phase 2 start

IKE Phase 1 using X-Auth illustration (Figure 2)

• R2 initiates IKE Phase 1 negotiation
• R1 responds IKE Phase 1 negotiation until finishing IKE Phase 1 SA
• R1 sends a radius access-request message to the AAA server
• AAA server responds with either an access-accept or access-reject message
  • Depends on peer authentication is success or not
• If successfully authenticated, R1 install a temporary crypto map entry
• R1 & R2 continue to negotiate IKE Phase 2