Upgrade to Pro — share decks privately, control downloads, hide ads and more …

IPsec

 IPsec

Presentation about IPsec and site-to-site VPNs. Both IKEv1 and IKEv2 are covered, as well as policy-based and route-based VPNs (GRE over IPsec, VTI, DMVPN, FlexVPN). Also configuration examples for site-to-site policy-based VPNs, GRE over IPsec and DVTI are included.

Avatar for Dmitry Figol

Dmitry Figol

July 01, 2017
Tweet

More Decks by Dmitry Figol

Other Decks in Technology

Transcript

  1. Overview • Virtual Private Network (VPN) extends a private network

    across a public network • VPN does not imply encryption • IPsec VPN allows to securely send and receive data over insecure network • Can be used for site-to-site tunnels as well as remote-access • Tunnels are point-to-point (exception: GETVPN) 4
  2. IPsec Provides: • Confidentiality – data is encrypted • Integrity

    – check that data was not modified in transit • Origin Authentication – verify identity of the data source • Anti-replay protection – the same data is not accepted if received again 5
  3. Operation • IPsec creates Security Association (SA) – a secure

    session between two peers • SA is unidirectional • Identified by Security Parameter Index (SPI) • Uses Security Policy Database (SPD) and Security Association Database (SAD) 6
  4. IKE • Used by IPsec to establish SA • Consists

    of 3 parts: • Internet Security Association and Key Management Protocol (ISAKMP) is a framework for authentication and key exchange • Oakley describes a series of key exchanges (Diffie-Hellman) • Secure Key Exhange for Internet (SKEME) provides support for public-key-based key exchange, key distribution centres and manual installation as well as fast re- key • Two versions of IKE are used: IKEv1 and IKEv2 7
  5. IKEv1 Phases • Phase 1 and Phase 2 • Phase

    1 – establishes secure bidirectional control channel • Phase 2 – establishes unidirectional encrypted channels for data: two for each pair of identities • Uses UDP 500 by default • Switches to UDP 4500 if NAT is detected (NAT-T) 8
  6. IKEv1 Phase 1 • Either Main Mode (MM) or Aggressive

    Mode (AM) can be used • Main Mode • 6 packet exchange • Full identity protection • Better anti-DOS protection • Aggressive mode • 3 packet exchange • Identities are passed in clear • Trivial to cause DOS 9
  7. IKEv1 Phase 1 • To establish Phase 1 ISAKMP policies

    should match • ISAKMP policy defines a set of parameters used for control ISAKMP SA negotiations: • Authentication method • Hash algorithm (e.g. MD5, SHA) • Encryption algorithm (e.g. 3DES, AES) • Diffie Hellman group • Lifetime 10
  8. IKEv1 Authentication • Pre-shared key (PSK) • Easy to deploy

    • Not scalable – need to change the key everywhere if compromised • Certificates (PKI) • Administrative burden • Scalable – certificate of the specific device can be revoked 13
  9. IKEv1 Diffie-Hellman key exchange • DH allows to establish a

    secure secret key over insecure channel • DH is asymmetric (public key) cryptography • Based on modular arithmetic properties • Calculated shared secret can be used for different purposes (e.g. derive a symmetric key for encryption) 14
  10. IKEv1 DH key exchange (cont.) • Two numbers are selected

    beforehand: prime p and base g • Alice and Bob select their private numbers: a and b • Alice calculates = and sends it to Bob • Bob calculates = and sends it to Alice • Alice calculates shared secret = • Bob calculates shared secret = • Shared secret is the same because = = = = 16
  11. IKEv1 Phase 1 operations The following operations occur over Phase

    1 SA: • Dead Peer Detection (DPD) – keepalive • Negotiation and establishment of Phase 2 SA • Notifications (tear down/delete) • Xauth and Mode-CFG for Remote Access • NAT detection 17
  12. IKEv1 Phase 1 states (IOS) Can be checked using #

    show crypto isakmp sa • MM_NO_STATE – after sending MM1 by the initiator • MM_SA_SETUP – after sending MM3 by the initiator or MM2 by the responder • MM_KEY_EXCH – after sending MM5 by the initiator or MM4 by the responder • QM_IDLE – after sending MM6 by the responder and receiving MM6 by the initiator. Indicates successful SA establishment NAT is detected during MM3/4, switch to UDP 4500 during MM5/6 18
  13. IKEv1 Phase 2 • Establishes unidirectional SA for each subnet

    pair • Called Quick Mode • 3 packet exchange • Negotiation is done over secure Phase 1 SA • Carries a transform-set which defines Phase 2 parameters (IPsec protocol, mode, cryptographic algorithms) that should match • Proxy identities (crypto ACL) should match • Perfect Forward Secrecy (PFS) may be used 19
  14. IPsec modes • Tunnel – adds new header, can be

    used for IPsec between gateways (subnet-to-subnet) • Transport – used for host-to-host IPsec communication 21
  15. IPsec security protocols • Authentication Header (AH) – provides authenticated

    integrity • Encapsulating Security Payload (ESP) – provides authenticated integrity and confidentiality with the use of encryption 22
  16. IKEv2 overview • 4 packet exchange • Strong cryptographic algorithms

    (Suite B) support • New authentication method: Extensible Authentication Protocol (EAP) • Authentication is unidirectional – different authentication methods can be configured on both sides • For example, PSK on one side and certificates on another side • Identity is not limited to IP address: can also be FQDN or email 25
  17. IKEv2 overview (cont.) • Enforces Continuous Channel Mode – IPsec

    SA can’t exist without IKEv2 SA • In IOS is used extensively as part of FlexVPN solution • Smart defaults on IOS (most parameters are pre-selected) • Granular configuration per peer or set of peers • Proposals instead of isakmp policies: • Several algorithms included in one proposal • Most secure match is selected 26
  18. Crypto map based site-to-site VPN • Also called policy-based VPN

    • Traffic is encrypted based on policy: • The packet is routed according to the routing table • If outgoing interface has crypto map applied, check crypto ACL from top to bottom • If there is a match in crypto ACL, build IPsec tunnel to the peer defined in the crypto map and encrypt the traffic • Return traffic that comes to an interface with crypto map is matched against Security Policy Database (SPD) to check if it should be decrypted • Considered to be legacy, because requires careful selection of Proxy ACL • Not as flexible as route-based VPN 29
  19. Route-based VPN • GRE over IPsec • VTI • DMVPN

    (mGRE over IPsec) * • FlexVPN * * Not the main focus in this presentation 30
  20. GRE over IPsec • Packets are GRE encapsulated first, then

    encrypted with IPsec • Transport mode is (usually) a better choice: • GRE already added a new IP header and it is host-to-host communication from IPsec perspective • Crypto IPsec profile is configured and applied on GRE tunnel interface • The packet will be encrypted based on the routing via Tunnel interface in contrast to policy (crypto ACL) used in crypto maps • Multicast support • Line protocol goes up, if IPsec SA (Phase 2) is up (new) • Previously: line protocol is up if the tunnel destination is in RIB 31
  21. Static Virtual Tunnel Interface (VTI) • Similar to GRE, a

    new tunnel interface is created, but with tunnel mode ipsec ipv4 • IPsec profile is applied on VTI • Multicast support • Line protocol goes up, if IPsec SA (Phase 2) is up 32
  22. GRE over IPsec vs SVTI GRE over IPsec • Supports

    both IPv4 and IPv6 over a single tunnel (IPv4 or IPv6 underlay) • Additional overhead • GRE is not supported on ASA SVTI • Separate tunnels are required if both IPv4 and IPv6 overlays are needed • Less overhead • Supported on ASA since 9.7.1 and interoperable with other vendors 33
  23. Dynamic VTI (DVTI) • Hub-and-Spoke topologies • Allows the hub

    to build tunnels with spokes without knowing their IP address • Uses Virtual templates on the hub • Spoke-to-spoke tunnel support only with IKEv2 (FlexVPN) 34
  24. Dynamic Multipoint VPN (DMVPN) • Hub-and-Spoke topologies • Allows the

    hub to build tunnels with spokes without knowing their IP address • Uses multipoint GRE (mGRE) • Multicast support (head-end replication) • Allows to build spoke-to-spoke tunnels 35
  25. FlexVPN • Framework that supports different VPNs: Remote Access, Site-to-Site

    (including hub-and-spoke, spoke-to-spoke) • Supports only IKEv2 • Uses Virtual templates • Multicast support (head-end replication) • Lower overhead than DMVPN • Can push attributes and some configuration to spokes 36
  26. Show and debug commands on IOS • show crypto isakmp

    sa • show crypto ipsec sa • show crypto ikev2 sa • debug crypto condition peer ipv4 <remote-peer-ip> • debug crypto isakmp • debug crypto ipsec • debug crypto ikev2 37
  27. Show and debug commands - ASA • show crypto ikev1

    sa • show crypto ipsec sa • show crypto ikev2 sa • debug crypto ikev1 127 • debug crypto condition peer <remote-peer-ip> • debug crypto ipsec 127 • debug crypto ikev2 platform 127 • debug crypto ikev2 protocol 127 38
  28. Configuration examples • Crypto map site-to-site VPN between ASA and

    IOS • GRE over IPsec between two IOS routers • DVTI (Hub) and SVTI (Spoke) on two IOS routers 39
  29. References • Book IKEv2 IPsec Virtual Private Networks by Amjad

    Inamdar, Graham Bartlett • CLUS2017 BRKSEC-3001: Advanced IKEv2 Protocol by Jay Young • CLUS2018 BRKSEC-2881: Designing Remote-Access and Site-to-Site IPSec networks with FlexVPN by Piotr Kupisiewicz • CLUS2018 BRKSEC-3054: IOS FlexVPN Remote Access, IoT and Site-to- Site advanced Crypto VPN Designs by Frederic Detienne and Piotr Kupisiewicz • LabMinutes FlexVPN videos 40