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