IPSEC Configuration (CLI)

R4---R1(gi0/0)----(gi0/0)R2----R3---R5

Tunnel between R1 and R3

Crypto-Map:

=========

*Crypto-Map is a data-plane filter

*Traffic is matched using ACLs

            They define proxy IDs for IPSEC phase 2

            What should be encrypted

Applying Crypto-Maps:

----------------------------

*They are applied to physical interfaces

            - Only one crypto map per interface

            - Always outbound with respect to traffic direction

*One crypto map can apply to multiple interfaces

            -Entries processes top-down until ACL match occurs

            -Order is important

* Tunnel source defaults to interface ip

-Can be changed using command “crypto map MAP crypto-map local-address lo0”

* Applied to link level

            - Interface closest to destination

            -Multiple routes means multiple interfaces

Crypto-Map Order of Operations:

-----------------------------------------

*Encryption applies after routing

*Encryption applies after NAT.

*crypto, routing and NAT are independent of each other.

High Level Configuration Steps:

=======================

>> Define Phase 1 ISAKMP Policy

            crypto isakmp policy 10

>> Define Phase 2 IPsec Policy

>> Apply Crypto Map

>> Generate Interesting Traffic

Phase 1:

---------

*Define Phase 1 ISAKMP Policy

            crypto isakmp policy 10

->Authentication

            authentication pre-share

->Encryption

            encr aes 192

->Hash

            hash sha384

->DH group

            group 5

->Lifetime

*Applying isakmp peer and pre-shared key is done using :

            crypto isakmp key <pw> address <peer address>

*Policy is processes top-down until a match occurs by the responder

            -Based on policy priority (Lower value higher precedence)

Phase 2 & Applying Cryptomap:

----------------------------------------

* Define Phase 2 IPsec Policy

            crypto map MAP1 10 ipsec-isakmp

-> Who – Define peer address, hostname

            set peer 20.1.1.2

-> What – Define Proxy-ACL

            match address R1

-> How – Define Transform set

            set transform-set ESP_AES_192_SHA1

Defining Transform-set :

crypto ipsec transform-set ESP_AES_192_SHA1 esp-aes 192 esp-sha-hmac

 mode tunnel

Generate Interesting Traffic:

----------------------------------

ip access-list extended R1

 permit ip 5.1.1.0 0.0.0.255 25.1.1.0 0.0.0.255

Default Policies:

--------------------

*IOS includes default fallback policies

*It has both default isakmp and ipsec policies.

*Can be disabled using “no crypto isakmp default policy” and “no crypto ipsec      transform-set default”

*Both are active until user configured values are applied

Full Configuration:

===============

=============================

crypto isakmp policy 10

 encr aes 192

 hash sha384                                                                                     **PHASE 1**

 authentication pre-share

 group 5

crypto isakmp key cisco address 20.1.1.2    

==================================== 

crypto map MAP1 10 ipsec-isakmp

 set peer 20.1.1.2

 set transform-set ESP_AES_192_SHA1                                           **PHASE 2**

 match address R1

crypto ipsec transform-set ESP_AES_192_SHA1 esp-aes 192 esp-sha-hmac

 mode tunnel

ip access-list extended R1

 permit ip 5.1.1.0 0.0.0.255 25.1.1.0 0.0.0.255

====================================

interface GigabitEthernet0/0

 ip address 10.1.1.1 255.255.255.0

 crypto map MAP1

end

SHOW Commands:

===============

* show crypto isakmp sa  --- result of phase 1 negotiation

* debug crypto isakmp sa --- step-by-step phase 1 negotiation

* show crypto ipsec sa --- result of phase 2 negotiation

* debug crypto ipsec --- step-by-step phase 2 negotiation

* show crypto isakmp policy

* show crypto isakmp key

* show crypto ipsec transform-set

* show crypto debug-condition

* show crypto map interface


GRE With IPSEC:
=============

crypto isakmp policy 10
 encr aes 192
 hash sha384
 authentication pre-share
 group 5
crypto isakmp key cisco address 3.3.3.3      
!
!
crypto ipsec transform-set ESP_SA esp-aes 192
 mode tunnel
!
!
!
crypto map MAP1 local-address Loopback0
crypto map MAP1 10 ipsec-isakmp
 set peer 3.3.3.3
 set transform-set ESP_SA

 match address GRE

interface Tunnel0
 ip address 13.1.1.1 255.255.255.0
 ip mtu 1416
 tunnel source Loopback0
 tunnel destination 3.3.3.3

interface GigabitEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 ip ospf 1 area 0
 crypto map MAP1

ip access-list extended GRE
 permit gre any any

IPSEC VTI:
========

crypto isakmp policy 10
 encr aes 192
 hash sha384
 authentication pre-share
 group 5
crypto isakmp key cisco address 3.3.3.3

crypto ipsec profile PFI
 set transform-set ESP_SA

crypto map MAP1 local-address Loopback0

interface Tunnel0
 ip address 13.1.1.1 255.255.255.0
 tunnel source Loopback0
 tunnel mode ipsec ipv4
 tunnel destination 3.3.3.3
 tunnel protection ipsec profile PFI
!

interface GigabitEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 ip ospf 1 area 0
 media-type gbic
 speed 1000
 duplex full
 negotiation auto
end

BFD

https://www.youtube.com/watch?v=iv-vubxkhTI

IPSEC basic

IPSEC Control Plane:
-------------------------
ISAKMP & IKE negotiation

IPSEC Data Plane:
----------------------
ESP & AH encapsulations

IPSEC Features:
-------------------
->Authentication
          Who did the packet come from
->Integrity
          Was the packet changed in the transit
->Confidentiality
         Can anyone read packet during transit
-> Anti-Replay
         Did I already receive the packet

*Tunnels are dynamically created by IKE.

IPSEC use 2 data structures to build a tunnel
-----------------------------------------------------

->Security Associations:
         &An agreement of IPsec Parameters
         &Maintains encryption and authentication keys on peers
->Security Parameter Index (SPI):
        &Field in packet header to identify SA on receiver
        &Similar to vlan header or MPLS label



ISAKMP vs IKE:
--------------------

*they are negotiation protocols used to form SA's

->ISKAMP:
       ISKAMP is the framework
       Says that authentication and keying should occur

->IKE:
       IKE is the actual implementation
       Defines how authentication and keying occurs

IKEv1 vs IKEv2 Negotiation:
-----------------------------------

->IKEv1 was the original implementation
->IKEv2 adds new improvements

Affects only control plane not dataplane


IPSEC Tunnel Negotiation with IKE:
===========================

Goal of IPSEC exchange is to establish SA's. It has 2 phases

->Phase 1:
Authenticates endpoints and build a secure tunnel for further negotiation and result is called ISAKMP SA

->Phase 2:
Establish the tunnel to protect actual data traffic and result is IPsec SA.

Negotiating the ISAKMP SA(Phase 1):
----------------------------------------------

*Authentication Method
       Pre Shared Key(PSK)/X.509 Certificates(PKI)
*Diffie-Hellman Group - To exchange crypto keys
       Result of DH is what 3DES,AES etc use as their symmetric keys
      1/2/5 ....
*Encryption Type
      DES/3 DES/AES
*HASH Algorithm
     MD5/SHA1

-> Combination of above parameters are ISKAMP policy
   & IKE initiator send all its policies through proposal
   & IKE responder checks received policies against its own.
   & First match is used.

After phase 1 completes, an encrypted tunnel exists between the peers.
   *Phase 2 negotiation can now be hidden from devices in transit.

Negotiating IPsec SA (Phase 2):
--------------------------------------

Phase 2 parameters:

*Security Protocol (ESP/AH)
*Encapsulation Mode (Tunnel/Transport)
* Encryption (DES/3 DES/AES)
*Authentication(MD5/SHA/SHA-256)

Combination of all the above is called IPsec transform set

->AH vs ESP

& AH supports only authentication
& ESP supports both Authentication and Encryption

->Tunnel vs Transport

& Transport:
      * Original IP Header retained
& Tunnel
      * Adds new Header

AH With transport mode:
----------------------------

https://tools.ietf.org/html/rfc4302#section-3.1

Section 3.1.1

In transport mode, AH is inserted after the IP header and before a
   next layer protocol (e.g., TCP, UDP, ICMP, etc.) or before any other
   IPsec headers that have already been inserted.  In the context of
   IPv4, this calls for placing AH after the IP header (and any options
   that it contains), but before the next layer protocol.  (Note that
   the term "transport" mode should not be misconstrued as restricting
   its use to TCP and UDP.)  The following diagram illustrates AH
   transport mode positioning for a typical IPv4 packet, on a "before
   and after" basis.

                   BEFORE APPLYING AH
             ----------------------------
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

                   AFTER APPLYING AH
             -------------------------------------------------------
       IPv4  |original IP hdr (any options) | AH | TCP |    Data   |
             -------------------------------------------------------
             |<- mutable field processing ->|<- immutable fields ->|
             |<----- authenticated except for mutable fields ----->|

ESP and AH headers can be combined in a variety of modes.  The IPsec
   Architecture document describes the combinations of security
   associations that must be supported.

AH With Tunnel Mode:

----------------------------

In tunnel mode, the "inner" IP header carries the ultimate (IP)
   source and destination addresses, while an "outer" IP header contains
   the addresses of the IPsec "peers," e.g., addresses of security
   gateways.  Mixed inner and outer IP versions are allowed, i.e., IPv6
   over IPv4 and IPv4 over IPv6.  In tunnel mode, AH protects the entire
   inner IP packet, including the entire inner IP header.  The position
   of AH in tunnel mode, relative to the outer IP header, is the same as
   for AH in transport mode.  The following diagram illustrates AH
   tunnel mode positioning for typical IPv4 and IPv6 packets.

        ----------------------------------------------------------------
   IPv4 |                              |    | orig IP hdr*  |   |      |
        |new IP header * (any options) | AH | (any options) |TCP| Data |
        ----------------------------------------------------------------
        |<- mutable field processing ->|<------ immutable fields ----->|
        |<- authenticated except for mutable fields in the new IP hdr->|

        --------------------------------------------------------------
   IPv6 |           | ext hdrs*|    |            | ext hdrs*|   |    |
        |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
        --------------------------------------------------------------
        |<--- mutable field -->|<--------- immutable fields -------->|
        |       processing     |
        |<-- authenticated except for mutable fields in new IP hdr ->|

          * = if present, construction of outer IP hdr/extensions and
              modification of inner IP hdr/extensions is discussed in
              the Security Architecture document.

ESP With Transport Mode:
--------------------------------

https://www.ietf.org/rfc/rfc4303.txt

In transport mode, ESP is inserted after the IP header and before a
   next layer protocol, e.g., TCP, UDP, ICMP, etc.  In the context of
   IPv4, this translates to placing ESP after the IP header (and any
   options that it contains), but before the next layer protocol.  (If
   AH is also applied to a packet, it is applied to the ESP header,
   Payload, ESP trailer, and ICV, if present.)  (Note that the term
   "transport" mode should not be misconstrued as restricting its use to
   TCP and UDP.)  The following diagram illustrates ESP transport mode
   positioning for a typical IPv4 packet, on a "before and after" basis.
   (This and subsequent diagrams in this section show the ICV field, the
   presence of which is a function of the security services and the
   algorithm/mode selected.)

                  BEFORE APPLYING ESP
             ----------------------------

       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

                  AFTER APPLYING ESP
             -------------------------------------------------
       IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
             |(any options)| Hdr | TCP | Data | Trailer | ICV|
             -------------------------------------------------
                                 |<---- encryption ---->|
                           |<-------- integrity ------->|

ESP With Tunnel Mode:
----------------------------

In tunnel mode, the "inner" IP header carries the ultimate (IP)
   source and destination addresses, while an "outer" IP header contains
   the addresses of the IPsec "peers", e.g., addresses of security
   gateways.  Mixed inner and outer IP versions are allowed, i.e., IPv6
   over IPv4 and IPv4 over IPv6.  In tunnel mode, ESP protects the
   entire inner IP packet, including the entire inner IP header.  The
   position of ESP in tunnel mode, relative to the outer IP header, is
   the same as for ESP in transport mode.  The following diagram
   illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
   packets.

                 BEFORE APPLYING ESP
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

                 AFTER APPLYING ESP

            -----------------------------------------------------------
      IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
            |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
            -----------------------------------------------------------
                                |<--------- encryption --------->|
                          |<------------- integrity ------------>|


                      BEFORE APPLYING ESP
            ---------------------------------------
      IPv6  |             | ext hdrs |     |      |
            | orig IP hdr |if present| TCP | Data |
            ---------------------------------------

                     AFTER APPLYING ESP

            ------------------------------------------------------------
      IPv6  | new* |new ext |   | orig*|orig ext |   |    | ESP   | ESP|
            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer| ICV|
            ------------------------------------------------------------
                                |<--------- encryption ---------->|
                            |<------------ integrity ------------>|

            * = if present, construction of outer IP hdr/extensions and
                modification of inner IP hdr/extensions is discussed in
                the Security Architecture document.

IPSEC Control Plane vs Data Plane:
------------------------------------

IPSEC control plane (phase 1) - UDP 500, UDP 4500 for NAT
IPSEC data plabe (phase 2) - ESP(50) or AH(51), ESP over UDP 4500 if NAT

MST

Why MST?

1 vlan = 1 spanning tree
so if we have 1000 vlans we need 1000 spanning trees which will load CPU

Alternate 802.1Q: All Vlans on 1 spanning tree but no load balancing.

MST:
====

Flexible load-balancing
Need to handle few spanning tree instances

Instance:
---------

-> Vlans are placed into groups and the groups are called instances.

Region:
---------

Group of switches running same mst configuration.

Switch(config)#spanning-tree mode mst
Switch(config)#spanning-tree mst configuration
Switch(config-mst)#name cisco

By default Once mst region creates Instance-0(IST - Internal Spanning Tree) and all vlans are in this instance.

Switch# show spanning-tree mst configuration
Name    []
Revision 0
Instance     Vlans Mapped
----------     ------------------------------------------------
0                 1-4094(IST)
--------------------------------------------------------------

As you create additional instances (and place VLANS into these new instanes), the different bridges need to have a consistent vlan to "instance" mapping

An MST region is a group of switches having the same configuration

MST Region Configuration:(Must be same on all switches)

       -Name(32 bytes)
       -Revision Number(16 bits)
       -Vlan to Instance Table

Instances created manually are called Multiple Spanning Tree Instances(MSTIs).

Upto 65 instances can be created

=> MST ALWAYS SENDS ONLY ONE BPDU WHICH CONTAINS OF THE FOLLOWING DETAILS

->Region Information
         Region Name
         Revision Number
->A Configuration Digest of all VLANS and instances
         
   (Instance - Vlan Information) + Formula = Configration Digest

->One or more MRecords for each MSTI
         -All STP Parameters for the instance like Root BID, Sending BID, Root cost etc
         -MSTIs are RSTP instances that only exist inside the region
         -They don't directly interact with outside of the region.
         -Only one instance has timer related parameters(IST instance)
         -One MST BPDU per interface based on the vlans configured for that interface.