MD5 to SHA/AES Migration

1. Why Replace MD5?

- MD5 is vulnerable to collision attacks, allowing attackers to generate the same hash with different inputs.

- It is not resistant to brute-force attacks with modern compute power.

- Officially deprecated by IETF (RFC 6151).

Impact in Cisco Protocols:

- BGP/OSPF/HSRP: Forged packets could establish false adjacencies, hijack sessions, or disrupt routing.

- SNMPv3: MD5 + DES weakens management plane security, allowing interception/alteration of NMS traffic.

2. Cisco Cryptography Alternatives

BGP:

- Legacy: MD5 neighbor password.

- Modern: HMAC-SHA-256 key-chains or TCP-AO with SHA-256 (IOS-XE 17.x+, NX-OS 9.3+, IOS-XR 7.x+).

- For untrusted eBGP links: IPsec tunnel protection.

OSPF:

- Legacy: MD5 authentication.

- Modern: OSPFv2 with HMAC-SHA-256 key-chains, OSPFv3 with IPsec ESP/AH (SHA-2).

HSRP:

- Legacy: MD5 standby authentication.

- Modern: HSRPv2/v3 with HMAC-SHA-256 key-chains.

SNMPv3:

- Legacy: MD5 authentication with DES privacy.

- Modern: SHA authentication with AES-128/192/256 for privacy.

3. Technical Migration Principles

- Dual Authentication: Cisco supports key-chains with multiple keys/lifetimes (MD5 + SHA overlap).

- Protocol Dependency: Routing protocols (BGP, OSPF, HSRP) first; management plane (SNMPv3) last.

- Platform Considerations:

   * IOS-XE: HMAC-SHA-256 since 15.1(2)SY / XE 3.7.

   * NX-OS: SHA since 7.0(3)I7; TCP-AO in 9.3+.

   * IOS-XR: SHA/TCP-AO since 6.0+.

   * ASA/FTD: SNMPv3 with SHA/AES since 9.x.

4. Example – Dual Authentication with Key-Chain

key chain BGP_KEYS
 key 1
  key-string OLD-MD5-KEY
  cryptographic-algorithm md5
  accept-lifetime 00:00:00 Jan 1 2024 infinite
  send-lifetime 00:00:00 Jan 1 2024 23:59:59 Dec 31 2024
 key 2
  key-string NEW-SHA-KEY
  cryptographic-algorithm hmac-sha-256
  accept-lifetime 00:00:00 Jan 1 2024 infinite
  send-lifetime 00:00:00 Jan 1 2025 infinite

- During migration: both MD5 and SHA valid.
- After cutover: disable MD5 lifetime, leaving only SHA active.

5. Risks of Not Migrating

- Vulnerable to route hijacking (BGP).

- HSRP hijack: attacker takes over virtual IP.

- SNMPv3 downgrade: attacker reads/changes monitoring data.

- Non-compliance with NIST SP 800-131A, PCI-DSS, ISO 27001.

6. Operational Benefits After Migration

- Stronger compliance (SHA-256/AES-256).

- Reduced risk of cryptographic attacks.

- Consistent key rotation policies across protocols.

- Future-proof with TCP-AO, OSPFv3 IPsec, SNMP AES-256.

Part II – Migration Plan

1. Objectives

- Eliminate weak cryptography (MD5, DES/3DES).

- Standardize on SHA-256 (or higher) and AES.

- Ensure minimal disruption with staged rollout and rollback.

2. Scope

Protocols: BGP, OSPFv2/OSPFv3, HSRP, SNMPv3.

Platforms: IOS-XE (Cat9K, ISR, ASR1K), NX-OS (Nexus 9K/7K/3K), IOS-XR (ASR9K, NCS), ASA/FTD.

3. Phased Migration Approach

Phase 1 – Discovery & Assessment

1. Inventory devices (OS version, crypto configs).

2. Verify feature support for SHA-2/TCP-AO.

3. Identify OS upgrade needs.

4. Prioritize migration order: Core (BGP/OSPF), Edge (HSRP), Management (SNMPv3).

Phase 2 – Lab Validation

1. Build lab/DR setup.

2. Validate SHA-256 configs for BGP, OSPF, HSRP.

3. Validate OSPFv3 with IPsec ESP/AH.

4. Validate SNMPv3 with SHA/AES.

5. Test dual-auth fallback.

6. Check interoperability (multi-vendor if applicable).

Phase 3 – Pilot Rollout

1. Select low-risk sites.

2. Implement SHA configs in parallel with MD5.

3. Monitor adjacency/polling.

4. Rollback to MD5-only if needed.

Phase 4 – Production Migration

Step A: BGP – SHA-256 key-chain, validate, remove MD5.

Step B: OSPF – SHA-256 key-chain, validate adjacency, remove MD5.

Step C: HSRP – SHA-256, validate, remove MD5.

Step D: SNMPv3 – Add SHA/AES users, migrate NMS, remove MD5/DES users.

Phase 5 – Decommission & Hardening

1. Remove MD5/DES configs.

2. Standardize on SHA-256 and AES.

3. Update golden configs and DNAC/Prime templates.

4. Document cryptographic standards in LLD/HLD.

4. Rollback Plan

- Retain MD5 in parallel until stable.

- For BGP/OSPF, fallback to MD5-only key-chain.

- For HSRP, revert to MD5 authentication.

- For SNMPv3, retain MD5/DES users until migration confirmed.

5. Risk Mitigation

- Perform change in maintenance window.

- Stagger per protocol.

- Ensure console/OOB access.

- Monitor syslog, SNMP traps, debug logs.

6. Example Cisco Configurations

BGP (IOS-XE/NX-OS):

key chain BGP_KEYS
 key 1
  key-string <secure-key>
  cryptographic-algorithm hmac-sha-256
!
router bgp 65000
 neighbor 192.0.2.1 password keychain BGP_KEYS

OSPFv2 (IOS-XE):

key chain OSPF_KEYS
 key 1
  key-string <secure-key>
  cryptographic-algorithm hmac-sha-256
!
interface Gig0/0
 ip ospf authentication key-chain OSPF_KEYS

HSRP (IOS-XE):

key chain HSRP_KEYS
 key 1
  key-string <secure-key>
  cryptographic-algorithm hmac-sha-256
!
interface Gig0/1
 standby 1 ip 10.10.10.1
 standby 1 authentication md5 key-chain HSRP_KEYS

SNMPv3 (IOS-XE/NX-OS/ASA):

snmp-server group SECURE v3 priv
snmp-server user netops SECURE v3 auth sha <auth-pass> priv aes 256 <priv-pass>

Rogue Endpoint Detection in Cisco ACI

 🔐 Rogue Endpoint Detection in Cisco ACI

⚠️ Problem Addressed

Rogue endpoints or misconfigured devices can cause frequent MAC/IP moves across leaf switches, leading to:

• Network instability
• High CPU usage
• Crashes in endpoint mapper (EPM) and client (EPMC)
• Rapid log rollover, making debugging difficult

---

🛡️ How Rogue Endpoint Control Works

The feature helps mitigate these issues by:

• Detecting rapidly moving endpoints (MAC/IP)
• Quarantining them by making their entries static
• Deleting the unauthorized MAC/IP after a set interval
• Raising a fault for visibility
• Generating a host tracking packet to re-learn the endpoint

---

🔄 Behavior Based on Software Version

Version	Quarantine Behavior	Traffic Handling	Final Action
Before 3.2(6)	Endpoint is made static	Traffic is dropped during quarantine	MAC/IP is deleted after the interval
3.2(6) and later	Endpoint is made static	Traffic is allowed during quarantine	MAC/IP is deleted after the interval

✅ Improvement: From 3.2(6) onwards, the system is less disruptive, allowing traffic to continue while still monitoring rogue behavior.

---

📝 Rogue/COOP Exception List

✅ Purpose

Allows higher tolerance for endpoint movement before marking as rogue.

📋 Behavior

• Endpoints in the list are marked rogue only after 3,000 moves in 10 minutes
• Once marked:
• Endpoint is made static
• Deleted after 30 seconds

🆕 From APIC 6.0(3) Onwards

• You can:
• Create global exception lists
• Exclude MACs from rogue detection across all bridge domains or L3Outs
• Exclude all MACs for a specific bridge domain or L3Out

 

Cisco ACI Mis-Cabling Protocol (MCP) – Loop Detection Simplified

Cisco ACI uses Mis-Cabling Protocol (MCP) to detect and mitigate Layer 2 loops, replacing traditional STP participation. MCP sends special Layer 2 packets across access ports, VPCs, and virtual ports. If the fabric receives its own MCP packet, it identifies a loop and can either log the event or error-disable the port.

✅ Key Highlights:

• Global MCP policies are disabled by default; port-level policies are enabled.
• Global MCP Policy:
  This is the master switch that controls whether MCP is active across the entire fabric.
• Disabled by default: Even though individual ports may be configured to support MCP, no MCP packets are sent unless this global policy is explicitly enabled.
• Port-Level MCP Policy:
  These are the interface-specific settings that determine how each port behaves when MCP is active.
• Enabled by default: Ports are ready to participate in MCP loop detection, but they won’t actually send or process MCP packets unless the global policy is turned on.

• MCP works complementarily with STP on external switches.
• BPDU filtering or disabling loopguard on external switches helps prevent loop-related issues.
• Endpoint move loop detection is available but disabled by default.
• MCP supports native VLAN mode and per-VLAN mode (from APIC 2.0(2)) for granular loop detection.
• Faster detection introduced in APIC 3.2(1) with transmission intervals as low as 100 ms.
• Scalability limits: 256 VLANs per interface and 2000 logical ports per leaf switch. Per-VLAN MCP will only run on 256 VLANs per interface. If there are more than 256 VLANs, then the first numerical 256 VLANs are chosen.

🔐 MCP Modes:

• Non-Strict Mode: Allows traffic while monitoring for loops; default detection time is 7 seconds.
• Strict Mode (from APIC 5.2(4)):
• Performs early loop detection before allowing data traffic.
• Uses initial delay and grace period timers for STP convergence and aggressive MCP checks.
• Requires port flap to activate on already-up ports.

⚠️ Strict Mode Guidelines:

• Not supported on FEX or QinQ edge ports.
• Requires APIC 5.2(4) or later on all participating leaf switches.
• May impact vPC convergence time.
• Must be disabled before downgrading the fabric.
• Can cause both ports to error-disable if loops are detected simultaneously.

MCP Mode Comparison Table

Feature	Non-Strict Mode	Strict Mode
Traffic Acceptance	Accepts data and control traffic immediately	Initially blocks data traffic; only control packets allowed
Loop Detection Timing	MCP packets sent every 2 seconds; loop detection in ~7 seconds	Aggressive MCP packet transmission during grace period (default 3 sec)
Early Loop Detection	Not performed	Performed before allowing data traffic
Port Behavior on Loop Detection	Port is error-disabled	Port is error-disabled and shut down
Activation Requirement	Active immediately	Requires port flap to activate if port is already up
Timers Used	Global MCP instance policy	Initial delay timer + grace period timer
Default Initial Delay	Not applicable	0 seconds (can be set to 45–60 sec for STP convergence)
Default Grace Period	Not applicable	3 seconds
STP Compatibility	Works with STP	Accepts STP BPDUs even if VLAN is not enabled
Use Case	General loop detection	Early and aggressive loop prevention before traffic forwarding

 

Cisco ACI, Storm Control : Drop and Shutdown

 In Cisco ACI, Storm Control is a feature used to mitigate traffic storms caused by excessive broadcast, multicast, or unknown unicast traffic. It can be configured with two types of actions: Drop and Shutdown.

---

⚙️ Storm Control Actions in Cisco ACI

1. Drop (Default Action)

• When traffic exceeds the configured threshold (either in packets per second or percentage of bandwidth), the excess traffic is dropped.
• The port remains up and operational.
• This is a non-disruptive method to suppress storm traffic.
• Suitable for most environments where you want to limit traffic without affecting port availability 

2. Shutdown

• When traffic exceeds the threshold:
• Traffic is dropped for a soaking interval (default: 3 seconds).
• If the storm persists, the port is administratively shut down at the end of the interval.
• You can configure the soaking interval between 3 to 10 seconds.
• This action is more aggressive and is used when dropping traffic alone is insufficient to protect the network 

---

🔍 Behavioral Differences

Feature	Drop	Shutdown
Traffic Handling	Drops excess traffic	Drops traffic, then shuts down port
Port Status	Remains up	Goes down if storm persists
Faults/Traps	Can raise SNMP traps	Interface traps raised; storm traps may be unreliable 1
Use Case	Mild suppression	Severe storm mitigation

---

🛠️ Configuration Notes

• Storm Control is configured via Access Policies in ACI:
• Fabric > Access Policies > Interface > Storm Control
• You can apply it to:
• Physical interfaces
• Port channels
• Monitoring policies can be added to raise alerts when thresholds are exceeded