ipsec s2s vpn question

Hello there.

Actually, I asked this question on another forum, but haven't yet receive an answer, so, I'm asking it here, even it's really not CCIE-level question.

I've got couple of questions concerning ipsec s2s vpn. Hope someone will
help me, because i can't get answers to my dumb questions.



Q1:

I'm just labbing a simple topology in gns3 and playing around trying to understand ipsec s2s vpn.

And i got confusedwith this:



when defining ISAKMP policy you can specify a lifetime

crypto isakmp policy 10
lifetime ?
<60-86400> lifetime in seconds




even if you define this only on one side, the lowest value would be taken and IKE phase 1 will last only 60 seconds for example.

The main question is - when 60 seconds are gone, IKE phase 2 tunnel (ipsec) feels ok, it's doesn't get purged, it passes traffic through, everything is ok



So... my confusion is - i thought that phase 2 can not exist without underlying alive and up phase 1. Am i wrong?







Q2:

Default ipsec SA lifetime is 1 hour.

After 1 hour both sides will purge ipsec SA and try to estabilish new one with the brand new key for symmetric-key enc algorithm.

Am i right?





I've got Q3, but i should get answer to one of these to correctly state my Q3.



Thanks a lot, sorry for my english.

Comments

  • 1. Yes, if we speak about IKEv1, lifetime for Phase1 state is negotiatetd to the lowest value between VPN peers. Once the IPsec tunnel is up, which means both Phase1 and Phase2, Phase2 NO longer needs Phase1 to stay up, Phase1 has done its job. Yes, in the negotiation process as the IPsec tunnel is negotiated, you cannot go to Phase2 if Phase1 negotiation fails.

    2. Before the 1 hour mark is hit, IPsec refreshes they keys, so that there is no downtime from traffic point of view.

     

  • Here i must state that we are talking about IKEv1 only to eliminate misunderstanding.

    Ok, if ike phase 2 is kinda self-confident in such a degree so it can even change the symmetric key by itself (hour passed) without help of phase 1, i can not see any reason why we actually need phase 1 to be alive after it's done it's job? Phase 1 negotiated all the params, phase 2 is up and stands straght on it's legs, why do we need waste memory or other recources for this being useless at this moment phase 1?

    Or i'm wrong? I feel like i'm missing something in theory.

  • I did not say Phase2 can do its job without the need of Phase1. Whatever needs to be negotiated at the IKE level for the IPsec tunnel needs Phase1, like key renegotiation due to lifetime expiry. Do when Phase2 negotiates the keying material, it needs Phase1 up and running, if not it will bing it back up.

  • Sorry for being lost for so long.

    I still have some questions to ask 8)

    When I was labbing, I set ISAKMP sa lifetime = 60sec, IPSEC sa lifetime 120sec. The lowest values i can get. So, everything i wanted - to see how fast new ISAKMP sa will be set up and how long will be delay in data transfer (just for fun). And I got into a situation I can not explain:

    2 or even 3 simultaneous IPSEC sa's

    [code]R3#sh cry ipsec sa | in life
            sa timing: remaining key lifetime (k/sec): (4532303/30)
            sa timing: remaining key lifetime (k/sec): (4559840/119)
            sa timing: remaining key lifetime (k/sec): (4445416/119)
            sa timing: remaining key lifetime (k/sec): (4532303/30)
            sa timing: remaining key lifetime (k/sec): (4559840/119)
            sa timing: remaining key lifetime (k/sec): (4445416/119)[/code]

    And the whole output:

    [code]R3#sh cry ipsec sa

    interface: FastEthernet1/0
        Crypto map tag: CMAP, local addr 192.168.23.3

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/0/0)
       remote ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
       current_peer 10.10.12.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 79, #pkts encrypt: 79, #pkts digest: 79
        #pkts decaps: 79, #pkts decrypt: 79, #pkts verify: 79
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.23.3, remote crypto endpt.: 10.10.12.1
         path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
         current outbound spi: 0x5CF1C49(97459273)

         inbound esp sas:
          spi: 0x20F8220A(553132554)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2001, flow_id: SW:1, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4532303/18)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0x51563089(1364603017)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2004, flow_id: SW:4, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4559839/105)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0x13DDE7A4(333309860)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2005, flow_id: SW:5, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4445416/105)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE

         inbound ah sas:

         inbound pcp sas:

         outbound esp sas:
          spi: 0xD140BA39(3510680121)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2003, flow_id: SW:3, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4532303/15)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0xD2237553(3525539155)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2002, flow_id: SW:2, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4559840/103)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0x5CF1C49(97459273)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2006, flow_id: SW:6, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4445415/103)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE

         outbound ah sas:

         outbound pcp sas:

     

    R3#sh cry isa sa det
    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

    C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.
    3     192.168.23.3    10.10.12.1               ACTIVE des  sha  psk  1  0
           Connection-id:Engine-id =  3:1(software) (deleted)

    4     192.168.23.3    10.10.12.1               ACTIVE des  sha  psk  1  00:00:30
           Connection-id:Engine-id =  4:1(software)

    [/code]

     

    I just can't explain this behaviour. I thought that IPSEC sa lifetime ticks to ZERO and then it tries to negotiate new KEY for symmetrical algo and use it for data enc/dec. But PHASE1 sa is already dead (recall, i configured it for lifetime = 60sec), thus first of all new ISAKMP sa will be negotiated. But this output is weird. Old IPSEC sa is still alive for at least 15 secs, but new ones are created. 2 new IPSEC sa's created. For what purpose does it need 2 sa's - it do not know...

  • Phase 2 negotiates 2 unidirectional SA's , which means two keys, one for encryption and one for decryption. New keys, thus SA's are negotiated before the old ones expire so that there is no packet drop. And this means so far 4 SA's. Why do you see 6? It can happen that if both peers initiate negotiation at the same time you End up with 4 SA's to begin with.

    Sent from my iPhone

    On May 15, 2015, at 16:55, curiousone <[email protected]> wrote:

    Sorry for being lost for so long.

    I still have some questions to ask 8)

    When I was labbing, I set ISAKMP sa lifetime = 60sec, IPSEC sa lifetime 120sec. The lowest values i can get. So, everything i wanted - to see how fast new ISAKMP sa will be set up and how long will be delay in data transfer (just for fun). And I got into a situation I can not explain:

    2 or even 3 simultaneous IPSEC sa's

    R3#sh cry ipsec sa | in life
            sa timing: remaining key lifetime (k/sec): (4532303/30)
            sa timing: remaining key lifetime (k/sec): (4559840/119)
            sa timing: remaining key lifetime (k/sec): (4445416/119)
            sa timing: remaining key lifetime (k/sec): (4532303/30)
            sa timing: remaining key lifetime (k/sec): (4559840/119)
            sa timing: remaining key lifetime (k/sec): (4445416/119)

    And the whole output:

    R3#sh cry ipsec sa

    interface: FastEthernet1/0
        Crypto map tag: CMAP, local addr 192.168.23.3

       protected vrf: (none)
       local  ident (addr/mask/prot/port): (3.3.3.3/255.255.255.255/0/0)
       remote ident (addr/mask/prot/port): (1.1.1.1/255.255.255.255/0/0)
       current_peer 10.10.12.1 port 500
         PERMIT, flags={origin_is_acl,}
        #pkts encaps: 79, #pkts encrypt: 79, #pkts digest: 79
        #pkts decaps: 79, #pkts decrypt: 79, #pkts verify: 79
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
        #send errors 0, #recv errors 0

         local crypto endpt.: 192.168.23.3, remote crypto endpt.: 10.10.12.1
         path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
         current outbound spi: 0x5CF1C49(97459273)

         inbound esp sas:
          spi: 0x20F8220A(553132554)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2001, flow_id: SW:1, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4532303/18)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0x51563089(1364603017)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2004, flow_id: SW:4, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4559839/105)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0x13DDE7A4(333309860)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2005, flow_id: SW:5, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4445416/105)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE

         inbound ah sas:

         inbound pcp sas:

         outbound esp sas:
          spi: 0xD140BA39(3510680121)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2003, flow_id: SW:3, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4532303/15)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0xD2237553(3525539155)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2002, flow_id: SW:2, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4559840/103)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE
          spi: 0x5CF1C49(97459273)
            transform: esp-aes esp-sha-hmac ,
            in use settings ={Tunnel, }
            conn id: 2006, flow_id: SW:6, crypto map: CMAP
            sa timing: remaining key lifetime (k/sec): (4445415/103)
            IV size: 16 bytes
            replay detection support: Y
            Status: ACTIVE

         outbound ah sas:

         outbound pcp sas:
     
    R3#sh cry isa sa det
    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

    C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.
    3     192.168.23.3    10.10.12.1               ACTIVE des  sha  psk  1  0
           Connection-id:Engine-id =  3:1(software) (deleted)

    4     192.168.23.3    10.10.12.1               ACTIVE des  sha  psk  1  00:00:30
           Connection-id:Engine-id =  4:1(software)

     

    I just can't explain this behaviour. I thought that IPSEC sa lifetime ticks to ZERO and then it tries to negotiate new KEY for symmetrical algo and use it for data enc/dec. But PHASE1 sa is already dead (recall, i configured it for lifetime = 60sec), thus first of all new ISAKMP sa will be negotiated. But this output is weird. Old IPSEC sa is still alive for at least 15 secs, but new ones are created. 2 new IPSEC sa's created. For what purpose does it need 2 sa's - it do not know...




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Also, i just can not get the whole thing of IPSEC VPN.

    It's well known, that PHASE1 IKEv1 should negotiate params:

    auth

    encr

    hash

    DH-group

     

    But in PHASE2 we also need negotiate params (not actually negotioate - these params should match in transform-sets on both sides):

    hash

    encr

     

    Ok, i found that HMAC in Phase2 is not exactly hashing. It's hashing with addition of some KEY (it's a key that we configure with 'crypto isakmp key 0 MYKEY address 1.2.3.4' ? or something different?). But encryption algo - we've already configured it in Phase1. Why again? And it can be different in comparison to the configured in Phase1. That drives me crazy.

    Another one riddle for me - DH group. DH-algo is a superthing that allows you to exch a secret shared key over a public network. Even someone's eavesdropping, he just can not guess the secret key. Thanks to MATH and so on. So, for encr/decr we use symm encr algo's, which are extremely fast and can be implemented in hardware, but you should somehow share a secret key to use. For this purpose DH-algo is used. So, am i right, supposing that this secret key we exch with DH-group is used to encr/decr user traffic in Phase2 by using symm encr algo?

     

    I just got lost in theory. I read multiple sources and i think i gopt the information, but i can not settle in down in a whole picture.

    PS: again, sorry for my rough english

  • Hi,

    You need to understand the scope of the two phases; the scope of Phase1 is to build a secure (encrypted and authenticated) communication channel between the VPN endpoints, thus the need to negotiate all of those parameters; once phase1 is done, phase2 negotiation happens protected with the algorithms negotiated in phase1 and keys derived in phase1; the scope of phase2 is to negotiate what to protect over the VPN tunnel (intersting traffic) and how to protect it (thus negotiate again encryption and hashing).

    With DH, both parties end up witht the same keying material, WITHOUT exchanging it over the wire in the negotiation process. The resulting key from Phase1 DH exchange is the master key and from the master key you derive keys for Phase2, if PFS is not enabled.

    Regards,

    Cristian.

  • Feel little bit ashamed starting this topic once again, but i'm really the curious person.
    So, i experience no problem with configuring different types of s2s vpns within my work (isakmp policy-based, isakmp profile-based when ipsec must be vrf-aware). But configuring doesn't actually mean you understand the whole process. So, i decided to start it all over again, hope you will help me.

    Look what i found on cisco's learningnetwork forum:

    [code]Big picture:   Negotiate and build IKE phase 1 tunnel, then negotiate and build IKE phase 2 tunnel.
    IKE phase 1  has 3 steps:
    1: peers negotiate (hagle)
    The term Hagle can assist you in remembering what they negotiate, which is:
    H - hash (md5 or sha)
    A - authentication (pre shared keys, rsa-sigs (digital certs))
    G- dh group (1, 2, 5 etc)
    L- lifetime for the IKE phase 1 tunnel
    E- encryption to use (des, 3des, aes)

    2: peers run the DH they agreed to use in step 1. (to generate symetrical keys)
    3: peers autheticate using method agreed to in step 1.

    IKE phase 2 (also called the IPsec tunnel)
    1: peers negotiate the lifetime, hash, encryption and perhaps even PFS (when used)
    2: peers build and use the IPsec (IKE phase 2 tunnel)[/code]

    More than that, i've found this way of explanation:

    [code]Router has a packet that is about to be forwarded, and it notices that it matches a crypto ACL.
    Router looks to see if there is an IPSec SA in place, if not....
    Router looks to see if there is an IKE Phase 1 SA in place, if not...
    Router becomes initiator, and sends over all of its IKE phase 1 policies.
    Remote router responds, by specifying which IKE phase 1 policy is a match.
    Both peers run DH, and generate shared secret keying material.
    Both peer authenticate with each other, using authentication method agreed to in IKE phase 1 negotiations. (IKE phase 1 tunnel is now up.)
    Using the IKE phase 1 tunnel as a cloak of security, they two peers negotiate the details of IKE Phase 2.
    DH is not run again, and shared secret keying material is used from the DH in IKE phase 1, unless PFS is used.
    IKE phase 2 tunnel (AKA, the IPSec tunnel) is now in place, and the data is encapsulated and sent through the tunnel.[/code]


    So, according to this, i want to ensure that i do have the right understanding. Let's start with the Phase1 confusions 8)

    After nodes agreed on HAGLE, they both run DH-algo to generate some keying material.
    Here i face first trouble - even if we're using DH1 which will generate 768-bit key, it's enough for any of those - DES(max key size = 56bits)/3DES(max key size = 168bits)/AES(max key size = 256bits). Or i'm wrong thinking that DH1 will result in 2 nodes will have same piece of secret information sized 768bits, DH2 results in 1024bits, etc.?
    I don't know how they select needed amount of bits from the big piece... Nodes have to have some agreement on how to select 56bits for DES from 768-bit sized array of 0s and 1s (DH1 as DHG and DES as encr)

  • Hi,

    For such in depth knowledge, you need to also read the RFC in the end. Here is a very good explanation of what happens in IKEv1 Phases: http://book.soundonair.ru/cisco/ch13lev1sec4.html . Further to identify how the router ends up with the proper size for the key used to encrypt last two Phase1 messages (for Main Mode) and also Phase2 negotiation (namely the SKEYID_e), read Appendix B from the RFC: https://tools.ietf.org/html/rfc2409#page-37.

     

    Regards,

    Cristian.

     

Sign In or Register to comment.