Download and save as ppsx: Certificate Enrollment Process

, , ,

I would like to sum up important issue regarding ISAKMP and IPsec lifetimes.

ISAKMP life is always set based on the Initiator ISAKMP lifetime even if its higher then ISAKMP lifetime of the responder.

IPsec lifetime is always set to the lowest value of the IPsec peer.

IKE Phase -1 life time should be greater than IKE Phase-2 life time .

86400 sec (1 day) is a common default value for Phase 1 and 3600 (1 hour) is a common value for Phase 2.

A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying.

 

With pleasure I can share with you our first video post that shows ACS 5.3 integration with external user database based on  Microsoft Active Directory. Presentation has been shared in two parts.

Watch in 720p HD resolution for the best quality.

Part 1

Part 2

,

Zone-Based Policy Firewall (ZFW) is a new feature that has replaced the CBAC (Context-Based Access Control) – legacy firewall IOS based feature. The drawback of CBAC was just stateful inspection policy on an interface-based model due of this all traffic passing through the interface was subject to the same inspection policy.
Zone-Based Policy Firewall has changed the IOS Stateful Inspection architecture from interface-based to a more flexible zone-based configuration architecture.
In ZFW router interfaces are assigned to security zones, firewall inspection policy is applied to traffic moving between the zones. By default router cannot pass traffic to interfaces in other security zones until an explicit policy allowing traffic is defined. The firewall rule has to defined what traffic is allowed to pass between interfaces in other security zones.
Firewall policies are configured using Class-Based Policy Language (CPL), which employs a hierarchical structure to define inspection for network protocols and the groups of hosts’ traffic to which inspection will be applied. Inter-zone policies offer considerable flexibility and granularity, so different inspection policies can be applied to hosts, host groups, or subnets connected to the same router interface.

The following tasks are required to complete the ZFW configuration using the CPL:

  1. Creating class-map(s) that identify the traffic that must have policy applied as it traverses a zone-pair
  2. Define a policy-map to apply action to the traffic in a class-map
  3. Defining zones
  4. Defining zone-pairs
  5. Appling a policy-map to a zone-pair
  6. Assigning interface to zones

Now I’m going to present you short examples of ZFW.

We have 3 routers for test, connected on the row.

We have pure configuration, just OSPF is running between each other. Ping and telnet from R1 to R3 is working fine.

R1#ping 10.0.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/57/112 ms
R1#telnet 10.0.23.3
Trying 10.0.23.3 ... Open
User Access VerificationPassword:

We will configure R2 as ZB firewall router between inside network where R1 is reside and outside network where we have R3. FW will just inspect icmp traffic from inside to outside, thanks to statefull inspection traffic will be allowed back the same like in CBAC.
First, we have to create inspect class-map to match ICMP traffic.
R2(config)#class-map type inspect match-all ICMP
R2(config-cmap)# match protocol icmp

Next, create inspect policy-map and assign ICMP class-map.
R2(config-cmap)#policy-map type inspect POLICY-INSIDE>OUTSIDE
R2(config-pmap)# class type inspect ICMP
R2(config-pmap-c)# inspect

Now, we have to create zones and zone pairs, so source and destination of traffic.
R2(config-pmap-c)#zone security INSIDE
R2(config-sec-zone)#zone security OUTSIDE
R2(config-sec-zone)#zone-pair security ZONE-PAIR-INSIDE>OUTSIDE source INSIDE destination OUTSIDE
R2(config-sec-zone-pair)#service-policy type inspect POLICY-INSIDE>OUTSIDE

Last step is to assign zones to interfaces.
R2(config)#int fa0/0
R2(config-if)#zone-member security INSIDE
R2(config-if)#int fa0/1
R2(config-if)#zone-member security OUTSIDE

OK, now let’s make a test again. First ping.

R1#ping 10.0.23.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/108/188 ms

Looks fine, so what about telnet.
R1#telnet 10.0.23.3
Trying 10.0.23.3 ...
% Connection timed out; remote host not responding

Good, no response as we have expected as no telnet or tcp inspection defined. Let’s do show policy-map to see inspection statistics.

R2#show policy-map type inspect zone-pair ZONE-PAIR-INSIDE>OUTSIDE
Zone-pair: ZONE-PAIR-INSIDE>OUTSIDE
Service-policy inspect : POLICY-INSIDE>OUTSIDE
Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Packet inspection statistics [process switch:fast switch]
icmp packets: [0:10]
Session creations since subsystem startup or last reset 1
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:0]
Last session created 00:01:32
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 1
Last half-open session total 0
Class-map: class-default (match-any)
Match: any
Drop (default action)
2 packets, 48 bytes

OK let’s add next class-map with telnet.

R2(config)#class-map type inspect match-all TELNET
R2(config-cmap)# match protocol telnet
R2(config-cmap)#policy-map type inspect POLICY-INSIDE>OUTSIDE
R2(config-pmap)# class type inspect TELNET
R2(config-pmap-c)# inspect

Quick test.

R1#telnet 10.0.23.3
Trying 10.0.23.3 ... Open
User Access Verification
Password:
R3#

We are in :), so see statictis and session details.

R2#show policy-map type inspect zone-pair ZONE-PAIR-INSIDE>OUTSIDE
Zone-pair: ZONE-PAIR-INSIDE>OUTSIDE
Service-policy inspect : POLICY-INSIDE>OUTSIDE
Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Packet inspection statistics [process switch:fast switch]
icmp packets: [0:20]
Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:0]
Last session created 00:02:10
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 1
Last half-open session total 0
Class-map: TELNET (match-all)
Match: protocol telnet
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:24]
Session creations since subsystem startup or last reset 1
Current session counts (estab/half-open/terminating) [1:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:0]
Last session created 00:00:08
Last statistic reset never
Last session creation rate 1
Maxever session creation rate 1
Last half-open session total 0
Class-map: class-default (match-any)
Match: any
Drop (default action)
2 packets, 48 bytes

R2#show policy-map type inspect zone-pair ZONE-PAIR-INSIDE>OUTSIDE sessions
Zone-pair: ZONE-PAIR-INSIDE>OUTSIDE
Service-policy inspect : POLICY-INSIDE>OUTSIDE
Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Class-map: TELNET (match-all)
Match: protocol telnet
Inspect
Established Sessions
Session 666D2AEC (10.0.12.1:31763)=>(10.0.23.3:23) telnet SIS_OPEN
Created 00:02:03, Last heard 00:01:59
Bytes sent (initiator:responder) [31:71]
Class-map: class-default (match-any)
Match: any
Drop (default action)
2 packets, 48 bytes

At this stage all ICMP traffic from the inside is going thru.

R1#ping 10.0.23.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 124/152/196 ms

Now let’s be more specific. We let just ICMP from 10.0.12.0/24

R2(config)#ip access-list standard INSIDE-SUBNET
R2(config-std-nacl)# permit 10.0.12.0
R2(config-std-nacl)#class-map type inspect match-all ICMP
R2(config-cmap)#match access-group name INSIDE-SUBNET

What about now?

R1#ping 10.0.23.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)

OK is working. Now all traffic from outside to inside is blocked. Let’s add some rules like to allow telnet to 10.0.12.1 from 10.0.23.3 with inspection. We have to create new class, policy and zone-pair.

First test.
R3#telnet 10.0.12.1
Trying 10.0.12.1 ...
% Connection timed out; remote host not responding

Now configuration.

R2(config)#ip access-list extended OUTSIDE-TELNET
R2(config-ext-nacl)#permit ip host 10.0.23.3 host 10.0.12.1
R2(config-ext-nacl)#exit
R2(config)#class-map type inspect OUTSIDE-TELNET
R2(config-cmap)#match access-group name OUTSIDE-TELNET
R2(config-cmap)#exit
R2(config)#policy-map type inspect POLICY-OUTSIDE>INSIDE
R2(config-pmap)#class type inspect OUTSIDE-TELNET
R2(config-pmap-c)#zone-pair security ZONE-PAIR-OUTSIDE>INSIDE source OUTSIDE destination INSIDE
R2(config-sec-zone-pair)#service-policy type inspect POLICY-OUTSIDE>INSIDE

What about now, second try.

R3#telnet 10.0.12.1
Trying 10.0.12.1 ... Open
User Access Verification
Password:
R1#

Cool, working.

R2#show policy-map type inspect zone-pair ZONE-PAIR-OUTSIDE>INSIDE sessions
Zone-pair: ZONE-PAIR-OUTSIDE>INSIDE
Service-policy inspect : POLICY-OUTSIDE>INSIDE
Class-map: OUTSIDE-TELNET (match-all)
Match: protocol telnet
Match: access-group name OUTSIDE-TELNET
Inspect
Established Sessions
Session 666D2AEC (10.0.23.3:38211)=>(10.0.12.1:23) telnet SIS_OPEN
Created 00:00:04, Last heard 00:00:02
Bytes sent (initiator:responder) [31:71]
Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes

It was just basic ZFW configuration, there is some more advanced features besides similar to CBAC like sessions limit, max-incomplete, tcp syn or idle time, alert and audit trail we have other like limiting aggregated packet rate for the flows between security zones that I will try to show you in next post. Enjoy!

, ,

As I have promised I would present the basic configuration process of GET VPN.

In the production enviroment GET VPN technology will be deployed over MPLS WAN. In case MPLS network, CE routers exchange routing with PE routers so pure IP communications is achived between LAN to LAN (branch to branch). Additionaly each CE is aware that to route the traffic to specific CE (to CE’s MPLS interface IP) it has to push the traffic towards MPLS cloud.

We can imagine that my example presents part of MPLS WAN with Group Members (GM) as R2, R3 and Key Server (KS) as R4 that is located somewhere in Company HQ DC. To simplify the lab enviroment all GM routers are placed in one 10.0.0.0/24 subnet, GM example will be configured on R2 (R1 and R3 will be configured similar, just different keys used). The main propose of GET VPN is to establish secure, efficient on demand any to any connectivity across private WAN. In the following example we achived encryption for branch to branch traffic (assumed that 10.0.x.x/16 IP addressing is used for branches).

Below IP addressing and LAB diagram:

  • R1 (GM) – 10.0.0.1
  • R2 (GM) – 10.0.0.2
  • R3 (GM) – 10.0.0.3
  • R4 (KS) – 10.0.14.4

Here you can find basic configuration steps to properly setup GET VPN architecture:

Group Member configuration

1. Internet Key Exchange (IKE) Phase 1

The same like in pure IPsec VPN we have to define ISAKMP policy on each GM and KS, so specify the encryption and hash algorithm, authentication method, Diffie-Hellman group and lifetime. As always all IKE Phase 1 parameters must match both sides to successfully established Phase 1.

I’m going to use 3DES as encryption algorithm and pre-share keys as authentication method, remaining will be default.
R2(config)#crypto isakmp policy 100
R2(config-isakmp)# encr 3des
R2(config-isakmp)# authentication pre-share
R2#show crypto isakmp policy
Global IKE policy
Protection suite of priority 100
encryption algorithm: Three key triple DES
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

It is possible to use the same pre-share key in whole GET VPN enviroment then each GM and KS needs just one kind of default pre-share key definition that looks like this one:
crypto isakmp key KEY address 0.0.0.0 0.0.0.0
Of course it is less secure solution then different key for each GM, but the best way of course is PKI architecture. For the LAB propose I use the different KEY for each GM. On R2 we have to defined KEY with peer address as KS so it will 10.0.14.4 IP address.
R2(config)#crypto isakmp key 0 R2-KEY address 10.0.14.4
The same key has to be configured on the KS with R2 as GM peer IP address 10.0.0.2.

2. Group Domain of Interpretation (GDOI) definition

After ISAKMP policy configuration we have to define GDOI on GM. Just two parameters are needed to properly define GDOI group on GM:

  • GDOI group identity number
  • KS IP address for that specific GDOI

R2(config)#crypto gdoi group GDOI-GROUP
R2(config-gdoi-group)#identity number 777
R2(config-gdoi-group)#server address ipv4 10.0.14.4

The GDOI-GROUP has been defined with identity number 777 that uniquely assign GMs to specific GDOI group on the KS and allows push the proper IPsec policy to them. Additionaly KS IP address has been configured, then GMs are aware to which KS they have to register.

3. GDOI crypto map configuration on GM
GDOI crypto map needs to be defined and GDOI-GROUP configured in point 2 is connected here.

R2(config)#crypto map GETVPN-MAP 100 gdoi
% NOTE: This new crypto map will remain disabled until a valid
group has been configured.
R2(config-crypto-map)#set group GDOI-GROUP

4. Apply GDOI crypto map to interface
The last step for GM is similar to the standard IPsec configuration, apply the crypto map to the external interface.
R2(config)#int fa0/0
R2(config-if)#crypto map GETVPN-MAP

As we see configuration of GET VPN and all IPsec parameters for GM is minimalized and thanks to this we have simply, fast and straight GET VPN deployment for CE routers. All IPsec policy is configured centrally on Key Server. Let’s take a look on the configuration of management router – Key Server.

Key Server configuration

1. Internet Key Exchange (IKE) Phase 1

As you are aware all IKE Phase 1 parameters must match both sides to successfully established Phase 1, so like on GM we have to define the same IKE policy here on KS:
R4(config)#crypto isakmp policy 100
R5(config-isakmp)# encr 3des
R4(config-isakmp)# authentication pre-share

As we have used the pre-share key authentication on GMs here we have to defined keys for each GM.
R4(config)#crypto isakmp key R1-KEY address 10.0.0.1
R4(config)#crypto isakmp key R2-KEY address 10.0.0.2
R4(config)#crypto isakmp key R3-KEY address 10.0.0.3

2. IPsec Phase 2 parameters – IPsec SA (transform-set and ipsec profile)
IPsec transofrm set defines the true IPsec encryption and authentication algorithms. 3DES and SHA with ESP have been used here. This IPsec policy will be part of GET VPN policy for specific GDOI group.
R4(config)#crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
IPsec transform set is defined under ipsec profile named GETVPN-PROFILE.
R4(config)#crypto ipsec profile GETVPN-PROFILE
R4(ipsec-profile)# set transform-set TRANSFORM-SET

3. Group Domain of Interpretation (GDOI) definition

RSA keys generation
First of all we have to generate the RSA keys. RSA key is generated only on the KS and is used to authenticate and sign rekey messages. The public key is sent to GMs at the registration. KS signs the rekeys with the private key and GMs verify the rekey messages using the public key. Additonaly public key of first KS has to be used by other KSs in case we would use redundant solution and ensure fault recovery architecture with more then one KS, this option is called as cooperative (COOP) KS. In case RSA keys need to be generated in exportable form and then imported to the redundant KSs.
R4(config)#crypto key generate rsa general-keys label GETVPN-R4-KS modulus 1024 exportable
The name for the keys will be: GETVPN-R4-KS
% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be exportable...[OK]
R4(config)#

GDOI group identity – config-gdoi-group mode
Once we have generated KS’s RSA keys we are able to start true GDOI group configuration, all configuration will be done under config-gdoi-group mode. First we have to confiugre the same identity number that we have deifned on GM, it’s 777:
R4(config)#crypto gdoi group GDOI-GROUP
R4(config-gdoi-group)#identity number 777

Local Key Server identification – gdoi-local-server mode
To designate a device as GDOI KS and enter GDOI local server configuration mode we have to enter server local command, then we will be able to configure all GDOI parameters that are related to the IPsec and rekey policy:
R4(config-gdoi-group)#server local
R4(gdoi-local-server)#

GDOI Rekey configuration
First step in GDOI policy is rekey parameters configuration, rekey authentication key pair (PKI or localy stored) and Key Server source address for rekey messages are required values to configure, additionaly we can define rekey retransmit timers.
R4(gdoi-local-server)#rekey authentication mypubkey rsa GETVPN-R4-KS
R4(gdoi-local-server)#address ipv4 10.0.14.4
R4(gdoi-local-server)#rekey retransmit 10 number 3

10.0.14.4 IP has been defined as source IP for rekey messages, localy generated RSA keys in point 3 will be used to authenticate rekey messages, additionaly rekey mechanism will be send with three retransmits at 10 second intervals.

IPsec policy configuration for the GDOI group
The IPsec policy defined under GDOI group at KS will be downloaded to all GMs. This global policy will exactly provides the IPsec parameters for phase 2. Policy defines IPsec encryption, authentication algorithms and define the crypto ACL that says interesting traffic for encryption, so it’s exactly what have been missed on GMs. So all what have been configured on each peer in case of pure IPsec site to site VPN now is confiugred only on the KS. We are able to manage and provision configuration from just one point of network to all GMs.

To configure the IPsec policy we have to first define the crypto ACL, we have to exclude the GDOI protocol and OSPF from the interesting traffic for IPsec encryption:

R4(config)#ip access-list extended CRYPTO-ACL
R4(config-ext-nacl)#deny udp any eq 848 any eq 848
R4(config-ext-nacl)#deny tcp any host 224.0.0.5
R4(config-ext-nacl)#deny tcp any host 224.0.0.6
R4(config-ext-nacl)#permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

Having ACL in place we can define the IPsec policy for GDOI group, we bind ipsec profile GETVPN-PROFILE that defines the transofrm set and crypto acl together under IPsec Security Association:

R4(config-ext-nacl)#crypto gdoi group GDOI-GROUP
R4(config-gdoi-group)#server local
R4(gdoi-local-server)# sa ipsec 1
R4(gdoi-sa-ipsec)#profile GETVPN-PROFILE
R4(gdoi-sa-ipsec)#match address ipv4 CRYPTO-ACL

That’s all GET VPN configured, up and running. Let’s see completed R4 configuration that is related to the GET VPN:
ip domain name netcontractor.pl
!
crypto isakmp policy 100
encr 3des
authentication pre-share
crypto isakmp key R1-KEY address 10.0.0.1
crypto isakmp key R2-KEY address 10.0.0.2
crypto isakmp key R3-KEY address 10.0.0.3
!
crypto ipsec transform-set TRANSFORM-SET esp-3des esp-sha-hmac
!
crypto ipsec profile GETVPN-PROFILE
set transform-set TRANSFORM-SET
!
crypto gdoi group GDOI-GROUP
identity number 777
server local
rekey retransmit 10 number 3
rekey authentication mypubkey rsa GETVPN-R4-KS
rekey transport unicast
sa ipsec 1
profile GETVPN-PROFILE
match address ipv4 CRYPTO-ACL
replay counter window-size 64
address ipv4 10.0.14.4
!
ip access-list extended CRYPTO-ACL
deny udp any eq 848 any eq 848
deny tcp any host 224.0.0.5
deny tcp any host 224.0.0.6
permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255

To see the configuration of the GDOI group:
R4#show crypto gdoi group GDOI-GROUP
Group Name : GDOI-GROUP (Unicast)
Group Identity : 777
Group Members : 2
IPSec SA Direction : Both
Active Group Server : Local
Group Rekey Lifetime : 86400 secs
Group Rekey
Remaining Lifetime : 84481 secs
Rekey Retransmit Period : 10 secs
Rekey Retransmit Attempts: 3
Group Retransmit
Remaining Lifetime : 0 secs
IPSec SA Number : 1
IPSec SA Rekey Lifetime: 3600 secs
Profile Name : GETVPN-PROFILE
Replay method : Count Based
Replay Window Size : 64
SA Rekey
Remaining Lifetime : 1682 secs
ACL Configured : access-list CRYPTO-ACL
Group Server list : Local

To see reigsitered GMs:
R4#show crypto gdoi ks members
Group Member Information :
Number of rekeys sent for group GDOI-GROUP : 1
Group Member ID : 10.0.0.2
Group ID : 777
Group Name : GDOI-GROUP
Key Server ID : 10.0.14.4
Rekeys sent : 1
Rekeys retries : 3
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 1 2 3 4
Rcvd seq num : 0 0 0 0
Group Member ID : 10.0.0.3
Group ID : 777
Group Name : GDOI-GROUP
Key Server ID : 10.0.14.4
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0

I hope this post will be helpfull to understand the base configuration steps for the GET VPN with pre-share keys.

, ,

Group Encrypted Transport (GET) VPN is called as next-generation tunnel-less VPN technology but is not replacement for old good known DMVPN. GET and DMVPN are complementary technologies and can be deployed together. 

Due to slow come up of the DMVPN spoke-to-spoke tunnels where IPSec tunnels are built dynamically based on the NHRP and multipoint GRE tunnels, tunnel negotiation time have direct impact for delay sensitive data like voice and video. In this case GET VPN is a good replacement solution where voice and video needs to be transmited between branches and faster static IPSec keys configuration and policy is in place before data go thru.

The distibuted nature of today’s network applications like voice, video and multicast traffic, constant growth of network threats and risks, local, federal and industry regulations, highly confidential traffic in financial enviroment are a key factors for efficient and secure WAN branch to branch interconnectivity.

WAN architecture demands has changed over years from the point-to-point and point-to-multipoint to full mesh connectivity. In today WAN network infrastructure where MPLS technology provides full mesh network connectivity between all branches most companies are still using centralized point-to-multipoint model with not efficient and slow dynamic tunnel negotiation process.

GET VPN is recomended solution when time sensitive data has to be encrypted in addition to multicast appliction and dynamic routing is needed over MPLS WAN architecture with full mesh connectivity.

Following are key fetures of GET VPN that have advantage over traditional IPSec VPN:

  • WAN transport full mesh encryption services on demand
  • Tunnel-Less Any-to-Any IPSec VPNs
  • Native routing
  • IP header preservation
  • Centralized key and policy management
  • Advanced QoS
  • Multicast connectivity
  • Reliability and redundancy of architecture

The key components of GET VPN are GDOI protocol, Key Server and Group Member.

Group Domain of Interpretation (GDOI) (RFC 3547)

  • Uses UDP 848
  • Cryptographic protocol for group policy/key management and distribution
  • Works based on ISAKMP
  • Establishes security associations between authorized group member routers
  • Uses two different encryption keys: Key Encryption Key (KEK) – key used to secure the control plane, Traffic Encryption Key (TEK) – key used to encrypt data traffic

Key Server (KS)

  • Authenticates Group Member (GM)
  • Distributes IPSec keys and policies to all registered and authenticated GMs
  • Perform rekey process

Group Member (GM)

  • Registers with KS to download IPSec VPN policy
  • Encrypts/decrypts traffic between among GMs in the same Group

GET VPN process can be divided on the following 5 steps.

  • Registration of GMs in the KS
  • Authentication and authorization of GMs by the KS
  • IPSec SA policy propagation from KS to GMs
  • GM encrypt/decrypt traffic based on group policy
  • Rekey process – IPSec SA keys replacement propagation 

In next post I’m going to provide you more process details and configuration example with GET VPN.

, ,

Brand new Cisco router or switch has just console access enabled, so by default you can log go in to the console over rollover cable without any passwords.

Before we start with the authentication and authorization let’s fast recall the background. Cisco IOS CLI has two base following command modes:

  • User EXEC mode – Router> (angle bracket sign)
  • Privileged EXEC mode (enable mode) – Router# (pound sign)

We will configure AAA fetures on R1 and then telnet from R2 to R1 to test the impact on the authentication and authorization process to Console and VTY and AUX lines. First we have to enable the AAA access control system, new system, btw I haven’t seen old one yet :).
R1 con0 is now available
Press RETURN to get started.
R1#en
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#aaa new-model
R1(config)#

From the Console perspective no change, still no authentication and authorization, just click Enter twice unltil enable secret password is not defined, for VTY and AUX LOCAL authentication is enabled for privilege level 1 (based on the router’s local usernames database). Username and password needs to be defined on the router, enable secret password is needed for level 15, if not defined “% Error in authentication.” message will be displayed.

OK so let’s add below on R1 and look what is going on once we telnet from R2:
R1(config)#username netcontractor privilege 15 secret netcontractor
R1(config)#enable secret netcontractor
R1#debug aaa authentication

R2#telnet 10.0.0.1
Trying 10.0.0.1 ... Open
User Access Verification
Username:

R1#
*Mar 1 02:35:50.723: AAA/BIND(0000002A): Bind i/f
*Mar 1 02:35:50.731: AAA/AUTHEN/LOGIN (0000002A): Pick method list 'Permanent Local'

Router takes ‘Permanent Local’ – default method that has been enabled once we enter aaa new-model command.
Username: netcontractor
Password:
R1>en
Password:

Once we click enter we get prompt for enable password, below output from R1 after enter has clicked
R1#
*Mar 1 02:35:59.911: AAA: parse name=tty66 idb type=-1 tty=-1
*Mar 1 02:35:59.915: AAA: name=tty66 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=66 channel=0
*Mar 1 02:35:59.919: AAA/MEMORY: create_user (0x647AD6E0) user='netcontractor' ruser='NULL' ds0=0 port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 initial_task_id='0', vrf= (id=0)
*Mar 1 02:35:59.923: AAA/AUTHEN/START (2046019537): port='tty66' list='' action=LOGIN service=ENABLE
*Mar 1 02:35:59.927: AAA/AUTHEN/START (2046019537): non-console enable - default to enable password
*Mar 1 02:35:59.927: AAA/AUTHEN/START (2046019537): Method=ENABLE
*Mar 1 02:35:59.931: AAA/AUTHEN(2046019537): Status=GETPASS

Router starts authentication process for user netcontractor using default method as enable password (Method=ENABLE). Default is taken because aaa authentication enable command has not been defined. Next router sends a GETPASS request to prompt for the password.
Enable password: netcontractor, click enter.
Password:
R1#

R1#
*Mar 1 02:36:10.855: AAA/AUTHEN/CONT (2046019537): continue_login (user='(undef)')
*Mar 1 02:36:10.859: AAA/AUTHEN(2046019537): Status=GETPASS
*Mar 1 02:36:10.859: AAA/AUTHEN/CONT (2046019537): Method=ENABLE
*Mar 1 02:36:10.955: AAA/AUTHEN(2046019537): Status=PASS
*Mar 1 02:36:10.955: AAA/MEMORY: free_user (0x647AD6E0) user='NULL' ruser='NULL' port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 vrf= (id=0)
Router takes entered password for enable method and confirm with PASS response to indicate a successfull login.
Once we add below to the R1:
R1(config)#aaa authentication enable default nonethen after username and password authentication no propmpt for Password is send from the R1
R2#telnet 10.0.0.1
Trying 10.0.0.1 ... Open
User Access Verification
Username: netcontractor
Password:
R1>en
R1#

Router uses defined default list with NONE method – so once user enter enable command will be taken to the privilage level 15.
R1#
*Mar 1 03:05:10.447: AAA/BIND(0000002E): Bind i/f
*Mar 1 03:05:10.459: AAA/AUTHEN/LOGIN (0000002E): Pick method list 'Permanent Local'
R1#
*Mar 1 03:05:20.695: AAA: parse name=tty66 idb type=-1 tty=-1
*Mar 1 03:05:20.695: AAA: name=tty66 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=66 channel=0
*Mar 1 03:05:20.699: AAA/MEMORY: create_user (0x647AD6E0) user='netcontractor' ruser='NULL' ds0=0 port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 initial_task_id='0', vrf= (id=0)
*Mar 1 03:05:20.703: AAA/AUTHEN/START (1933181644): port='tty66' list='' action=LOGIN service=ENABLE
*Mar 1 03:05:20.707: AAA/AUTHEN/START (1933181644): using "default" list
*Mar 1 03:05:20.711: AAA/AUTHEN/START (1933181644): Method=NONE
*Mar 1 03:05:20.711: AAA/AUTHEN(1933181644): Status=PASS
R1#
*Mar 1 03:05:20.711: AAA/MEMORY: free_user (0x647AD6E0) user='netcontractor' ruser='NULL' port='tty66' rem_addr='10.0.0.2' authen_type=ASCII service=ENABLE priv=15 vrf= (id=0)

In case we would authenticate and authorize access to the console (as I have mentioned console means connection over serial – rollover cable) we have to enable authentication for line 0 explicity not just enter aaa new-model (local authentication after aaa new-model command works for all lines beside console line 0 = CTY). Below commands are enough to place user on the level 15 once enter username and password.
R1(config)#aaa authentication login default local
R1(config)#aaa authorization console

What about VTY lines authorization? We would achieve authorization for user, so once we log on over VTY lines (telnet or ssh) to the router with username and password we will be placed in the privileged EXEC mode level 15 automatically. Solution is simple, we have to configure exec authorization with local method – just one line.
R1(config)#aaa authorization exec default local
R1#debug aaa authorization
AAA Authorization debugging is on

Once we log on and enter username and password router takes default authorization list and with local method, user use placed on to the respective privilage level based on the username netcontractor privilege command.
R1#
*Mar 1 03:22:49.691: AAA/AUTHOR (0x30): Pick method list 'default'
*Mar 1 03:22:49.707: AAA/AUTHOR/EXEC(00000030): processing AV cmd=
*Mar 1 03:22:49.707: AAA/AUTHOR/EXEC(00000030): processing AV priv-lvl=15
*Mar 1 03:22:49.707: AAA/AUTHOR/EXEC(00000030): Authorization successful

Above are basic but very important issues to understand AAA.

As I have promised here you are next post from the PKI scope. Following example presents way of communication between user A and B with digital certificates. It will be one way communication example so user A sends data to user B. The same process takes place in opposite direction. It’s not easy and smooth but rather hardcore and kiler theme 😉 so it’s good to have fresh and open mind to read it. Are you read? Please go ahead.

The following process diagram will be very helpfull to understand the clue, step by step description below:

 

 

  1. User has own keys pair (public/private keys). Public key A (related to private key A) has been signed and authorized by the CA before (certificate enrolment process that is has been described Public Key Infrastructure – certificate enrolment post).
  2. User A uses public key B and encrypts Message that will be sent to the user B. Public key B has been taken from B’s certificate.
  3. Additionally, user A takes the same clear Message as input and does SHA (or MD5) hash function – Message# is output of this algorithm.
  4. Message# is then encrypted by the Private key A. Digital Signature of the user A Message is output of this process.
  5. The Digital Signature is added to the encrypted message.
  6. Above decrypted message and User A Certificate is send to the User B. User B gets a encrypted message and start decryption and authentication process. First user needs to be sure that Public key A that will be used for user’s A message authentication is true Public key of user A.
  7. To verify it, User B takes the Public key CA from the CA Certificate (that has signed User A’s Data, CA has issued the User A Certificate during certificate enrolment process) and decrypt the Digital Signature CA that is embedded into User A Certificate, Data# A is output of this process. Additionally user B downloads most up to date Certificate Revocation List (CRL) from CA to verify if User A Certificate has not been canceled and is still valid.  
  8. User B takes User A Certificate a does the same hash function (like CA has done for User A Data), Data# A is output of this process. User B takes this output and compares with Data# A (that has been produced in point 7) to confirm User A identity. If the hash outputs are the same it means that User A Certificates is real so Public key A is confirmed and can be use for communication.
  9. User B takes Public key A and decrypts Encrypted Message that has received. Clear, unencrypted message is output.
  10. To confirm that Message is real and has not been changed on way, User B does the same hash function (encryption and authentication functions have been negotiated at the beginning of the communications process, for example in case of IPsec it takes place in Phase 2 of IKE negotiation), so unencrypted Message is a input and Message# is output of this process.
  11. Then User B takes own Private key B and decrypts Digital Signature of the Message that has been added by the User A. Message# is output of this process.
  12. Message# from point 10 and Message# from point 11 is compare and if are the same then User B is sure that Message has not been changed and is exactly the same like User A has sent.
,

Some time ago when I was learning about PKI (Public Key Infrastructure) I searched for any process diagram that shows and visualyze step by step ceriticate enrolment process by CA or other encryption or authentication steps in the PKI enviroment in simple and detail manner. Because I have not found any have decided to draw it and explain the process, hope will help to understand the issue.

Before we will discuss the ceriticate enrolment process we have to explain the background shortly. OK so let’s start.

The base of the PKI is the concept of Asynchronous Keys. Asynchronous Keys is the encryption algorithm that can be use to secure transport data over unsecure connectivity, additonaly due to the nature of algorithm authenticate identity.
The idea of algorithm is based on two differtent keys (public and private key) that are mathematical related to each other, where private key derived from the public key. Message encrypted by recipient’s public key can only be decrypted by the corresponding private key (we can encrypt the message only by related key), and vice-versa, message encrypted by the owner’s private key can be only decrypted by the owner’s public key that is commonly available. Based on first case we achive data intergrity and confidential because only owener of private key will be able to decrypt the message and properly read the data, based on second one, reciver of the message can authenticate the sender because once decrypt the message and properly read a data, he knows that data have been sent by proper source (owner of private key). Above algorithm has revolutionized the encryption and authentication way. The only one problem was a public key distribution, this what the PKI is about.

Once we generate public/private key pair, we have to make the private key public available and the get global authority confirmation that the private key belong to as (at least it’s good to have confirmation from globally trusted source). Here Certificate Authority (CA) comes in to play. We have a lot of nice institution like VeriSign or GlobalSign and others that we can trust. The primary task of them is to confirm that generated public key belongs to us so can be used to exchange message in secure way.

Ceriticate enrolment process
I will explain the process based on the following example with user A (instead of user we can have any device: router or server, simple end point that will physically encrypt data).

 

1. User A generates pair of keys: public key A and private key A.
2. User A sends to the CA, own public key A with additional details that will identify user A like name, surname, departament city, country, e-mail address etc.
3. CA verifies user A data, next takes user A data and public key A as input and do SHA (or MD5) hash function – Data# A is output of this alghorith.
4. CA then uses own Private key CA and encrypts Data# A, Digital signature of the CA is output of this process.
5. User A Data, Public key of A, Digital signature of the CA, and specific details assigned by the CA like certificate serial number, issued and valid date, point of CRL distribution (and many more) creates User A Certificates.
6. Users A can get certificate and start use it to encrypt and authenticate data.

I hope this post will helpfull and clarify certificate enrolment process. If you have any comments please let me know. In next post I will discuss the encryption and authentication based on the digital certificate.

,

MAC Address Spoofing is a kind of Man-in-the-Middle Attack where attacker tries to redirect frames destined for authorized host to the attacker PC instead. To redirect traffic attacker needs to overwrite CAM table entry with actual true destination host’s MAC address. Be aware that is is not possible to have two the same MAC addresses in the CAM table on the switch, once switch detects this kind of strange behaviour will log the following error on the console:
*Mar 1 00:30:41: %SW_MATM-4-MACFLAP_NOTIF: Host 0000.1111.1111 in vlan 10 is flapping between port Fa0/1 and port Fa0/2

Another way to spoof MAC address is to use Address Resolution Protocol (ARP). When host sends a broadcast ARP request to figure out a MAC address of target host’s MAC address, target host response thru ARP reply.

Once the CAM table will be overwritten, packets to the true destination PC will be redirected to the attacker PC. If the true PC sends traffic once again CAM table will be rewritten again, moving the traffic back to the true PC’s port.

DHCP snooping feature is one of the method of mitigating IP Address Spoofing Attacks but with additional fetures like IP Source Guard and Dynamic ARP Inspection can fight with MAC Address Spoofing.

Using DHCP server attacker can prevent normal communications for the hosts or simply redirect the traffic to own PC. The plan is simple: connect DHCP server to the network and assign IP addresses to the clients without default gateway IP address what will successful prevent hosts to communicate with oustside world or just define default gateway’s or DNS server IP of hacker own PC. We can prevent this with DHCP Snooping. Here we are configuration step by step to configure the feature.

First we need to enable DHCP Snooping feature globally on the switch, next enable for specific VLAN, then configure trusted port where DHCP server will be connected or expected traffic from the DHCP server will be received like over trunk interfaces:
SW(config)#ip dhcp snooping
SW(config)#ip dhcp snooping vlan 10
SW(config)#int fa0/5
SW(config-if)#description DHCP-Server
SW(config-if)#ip dhcp snooping trust

Let’s see what we have configured already:

SW#sh ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3
Interfaces:Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
FastEthernet0/5 yes unlimited

So we enable globaly and for VLAN 10 DHCP Snooping feature, additionaly we have configured Fa0/5 as trust interface, so DHCP server will be connected here. In case you will not trust any interface once switch gets DHCP Discover message it will drop the frame and log the following error on console:
*Mar 1 01:32:06: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (10)
*Mar 1 01:32:06: DHCP_SNOOPING_SW: bridge packet output port set is null, packet is dropped.

Let’s see what we have now on the switch, we will debug DHCP Snooping process with above configuration:
SW#debug ip dhcp snooping
*Mar 1 00:12:44: DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/1)
*Mar 1 00:12:44: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Fa0/1, MAC da: ffff.ffff.ffff, MAC sa: 0000.1111.1111, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.1111.1111
*Mar 1 00:12:44: DHCP_SNOOPING: add relay information option.
*Mar 1 00:12:44: DHCP_SNOOPING_SW: Encoding opt82 CID in vlan-mod-port format
*Mar 1 00:12:44: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format
*Mar 1 00:12:44: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0xA 0x0 0x0 0x2 0x8 0x0 0x6 0x0 0xB 0x5F 0x7E 0x7A 0x80
*Mar 1 00:12:44: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (10)
*Mar 1 00:12:44: DHCP_SNOOPING_SW: bridge packet send packet to port: FastEthernet0/5, vlan 10.

One important note, once you enabled IP DHCP Snooping feature Cisco switch by default add to the DHCP Discover packet DHCP Option 82 and is working as kind of relay agent, we can observe it on the console, the begining is DHCP_SNOOPING: add relay information option.
What exactly the 82 options is?
Options 82 has two suboptions: Remote-ID suboption is the switch’s MAC address and Circuit-ID suboption is the port identifier so exactly interface where client is connected to . The idea is simple, switch adds this option and thanks to this DHCP server assign proper IP address, so it’s a kind of client’s distinction mechanism. We can observe a related issue to this switch’s feature if we have DHCP server configured on the router:

R5-DHCP#debug ip dhcp server packet
*Mar 1 00:30:55.545: DHCPD: inconsistent relay information.
*Mar 1 00:30:55.545: DHCPD: relay information option exists, but giaddr is zero

So what exactly this error means? Router sees inconsistent information, why? What is exactly happening when relay agent like router with ip helper-address options gets DHCP Discover packet from the client and sends it forward to the DHCP server. We have to look in to the DHCP Discover packet. Router gets DHCP Discover (broadcast) from client and based on it generates new DHCP Discover (unicast) packets with LAN IP as source and DHCP Server IP as destiantion, additionaly modifies giaddr field known as Relay agent IP address in the BOOTP packet from 0.0.0.0 to own IP (the same like source IP = LAN IP). What about the switch? Problem is that switch by default adds kind of relay option to the packet but doesn’t change the giaddr field so routers treats it as inconsistent information and drops packet.

We have two options to work around this issue:
first one – disable adding of DHCP Option 82 on the switch:
SW(config)#no ip dhcp snooping information option
second one – allow DHCP server (on the router) receives DHCP packets that contain relay info option with zero giaddr:
R5-DHCP(config)#ip dhcp relay information trust-all

Let’s back to snooping. Switch watches two-way DHCP address allocation process and learns about IP address that has been assigned to the client, switch builds IP DHCP Snooping Binding table where adds MAC address of the client, IP that has been assigned by the server, lease time, vlan where clients resides and interface where is connected to:
SW#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:00:11:11:11:11 10.0.1.1 83572 dhcp-snooping 10 FastEthernet0/1
Total number of bindings: 1

Based on the sh ip dhcp snooping output IP DHCP Snooping verify only the MAC address based on the binding table (Verification of hwaddr field is enabled). Really? What about Cisco Configuration Guide says:

“When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, the switch compares the source MAC address and the DHCP client hardware address. If the addresses match (the default), the switch forwards the packet. If the addresses do not match, the switch drops the packet.”

I don’ agree with it. Let’s make a small test to proof it. We have two routers R1 and R3 connected to the same switch (second one is DHCP server that has assigned the IP address 10.0.1.1 to R1’s MAC: 00:00:00:11:11:11). We can ping R3 from R1:
R1#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.1.1 YES DHCP up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
R1#
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms

good, is working fine as expected :), let disconnect the R1 from the switch and see how the binding table looks like:
SW#
*Mar 1 01:37:50: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
SW#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:00:11:11:11:11 10.0.1.1 86290 dhcp-snooping 10 FastEthernet0/1
Total number of bindings: 1

nothing changed, switch remembers binding even if we disconnected R1, nice. So lets connect the R1 back but before we do it we change R1’s IP to 10.0.1.2, then we ping R3 again:
R1(config-if)#int fa0/0
R1(config-if)#ip add 10.0.1.2 255.255.255.0
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

no issue with ping, working fine even if we have changed IP, so let’s changed the MAC now to different one for example 00:00:00:22:22:22

R1(config)#int fa0/0
R1(config-if)#mac-address 0000.2222.2222
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
LOL, we can still ping even if we have changed IP and MAC. So where is a issue. As we have see in the simplest form DHCP Snooping just filter unwanted DHCP Offer packets, to let the switch filter traffic based on the MAC or IP that’s resides in the DHCP Snooping binding table we have to employ other fetures like IP Source Guard (to filter based on the IP) or IP Source Guard with Port Security to filter based on the MAC and IP. We will discusse about it in one of the future post.

,