GRE over IPsec: The Tunnel Is Up, the Keys Are Right, and Nothing Crosses It

GRE carries anything and protects nothing. IPsec protects everything and carries only unicast IP. Putting one inside the other is the oldest compromise in enterprise WAN design and it is still the right one, because a routing protocol needs multicast and a WAN link needs confidentiality, and neither technology provides both on its own.

The modern way to combine them is a single line on the tunnel interface. No access list describing interesting traffic, no crypto map on the physical interface, no attempt to make a policy definition match what the tunnel is going to send. The tunnel is the policy: everything that enters it is protected, and everything that does not enter it is not. That simplification removed an entire category of misconfiguration and introduced a different one.

This article covers why the combination exists rather than one technology or the other, how protection is attached to a tunnel and what the alternative looked like, whether transport mode or tunnel mode is correct and what it costs, why a tunnel and its security association can disagree about being up, and the packet size problems that appear only under real traffic. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

GRE supplies the interface and the multicast capability, IPsec supplies the protection, and the failures in practice come from the routing and the packet size rather than from the cryptography.

Why Protect GRE Rather Than Using One Technology Alone?

What does each one refuse to do?

IPsec on its own carries unicast IP and nothing else. It will not carry multicast, which means no OSPF or EIGRP over it, and it presents no interface for the routing table to point at. GRE on its own creates a real interface that carries multicast, broadcast and non-IP protocols, and offers no confidentiality or integrity whatsoever. The combination gives a routable interface with a routing protocol running over it, and everything that crosses it protected. Neither technology can be dropped without losing something the design needs.

A Deeper Dive into the Combination

What an interface buys you

A tunnel interface is an ordinary interface as far as the rest of the router is concerned. It has an address, it appears in the routing table, a routing protocol can form an adjacency over it, a metric can be applied to it, a quality-of-service policy can be attached to it, and a tracked object can watch it. None of that is available when protection is expressed as a policy matched against traffic.

That is the real argument for the design and it is an operational one rather than a security one. Traffic selection through an access list means every new subnet requires a change at both ends, and a mismatch between the two lists produces a partial failure that is hard to see. An interface means routing decides what is protected, and routing is already the thing the network team manages.

The routing protocol is the point

A design with two sites and two static routes does not need GRE. The moment there are several sites, a preference between paths, or a requirement to fail over automatically, a routing protocol is needed, and a routing protocol needs to reach its neighbours by multicast. That single requirement is what rules out protection applied directly to the traffic.

It is worth being explicit about this when justifying the design, because the alternative appears simpler on the surface. It is simpler for exactly as long as the topology never changes.

What the modern configuration looks like

Five objects and one attachment. A proposal and a policy describing how the peers negotiate. A keyring holding the shared secret. A profile identifying the peer and saying how it authenticates. A transform set naming the algorithms. An IPsec profile combining the last two. And then a single line on the tunnel interface that attaches the whole thing.

! Negotiation parameters
R1(config)# crypto ikev2 proposal PROP-AES
R1(config-ikev2-proposal)# encryption aes-cbc-256
R1(config-ikev2-proposal)# integrity sha256
R1(config-ikev2-proposal)# group 14
!
R1(config)# crypto ikev2 policy POL-WAN
R1(config-ikev2-policy)# proposal PROP-AES
!
! The secret, per peer
R1(config)# crypto ikev2 keyring KR-WAN
R1(config-ikev2-keyring)# peer R2
R1(config-ikev2-keyring-peer)# address 203.0.113.2
R1(config-ikev2-keyring-peer)# pre-shared-key local KEY-A
R1(config-ikev2-keyring-peer)# pre-shared-key remote KEY-A

! Who the peer is, and how each side proves it
R1(config)# crypto ikev2 profile IKEV2-WAN
R1(config-ikev2-profile)# match identity remote address 203.0.113.2 255.255.255.255
R1(config-ikev2-profile)# identity local address 198.51.100.1
R1(config-ikev2-profile)# authentication local pre-share
R1(config-ikev2-profile)# authentication remote pre-share
R1(config-ikev2-profile)# keyring local KR-WAN
R1(config-ikev2-profile)# dpd 30 5 on-demand
!
! Algorithms, and the mode
R1(config)# crypto ipsec transform-set TS-AES esp-aes 256 esp-sha256-hmac
R1(cfg-crypto-trans)# mode transport
!
! The complete policy, as one object
R1(config)# crypto ipsec profile IPSEC-WAN
R1(ipsec-profile)# set transform-set TS-AES
R1(ipsec-profile)# set ikev2-profile IKEV2-WAN

Why the profile rather than a crypto map

A crypto map is applied to the physical interface and selects traffic with an access list. Making that list match exactly what a tunnel will send is possible — the list describes GRE from one endpoint address to the other — and it is fragile, because the list and the tunnel are two separate statements of the same intent that can drift apart.

Attaching a profile to the tunnel removes the second statement entirely. The tunnel's own source and destination define what is protected, so there is nothing to keep in agreement. It also allows several tunnels on one router to use different policies without any access list precedence problems, which is the arrangement a hub in a hub-and-spoke design needs.

Choosing the algorithms without over-thinking it

Use a current authenticated encryption or a strong cipher with a strong hash, a Diffie-Hellman group appropriate to the key size, and the same choice at both ends. The specific selection matters less than consistency and less than avoiding the algorithms that are known to be weak, and it should be set by a standard applied across the estate rather than decided per tunnel.

The one choice worth making deliberately is whether the platform accelerates what you have chosen in hardware. An algorithm that runs in software on a branch router will cap the throughput of the site regardless of how fast the circuit is, and that is a capacity decision rather than a security one.

How Is the Protection Attached, and What Changes When It Is?

What does the attachment do?

One command on the tunnel interface names the IPsec profile, and from that moment everything the tunnel encapsulates is protected before it leaves and verified on arrival. The tunnel's source and destination become the IPsec peers, so no traffic selector needs to be written. The security association is established on demand, when there is traffic to send, which means the tunnel interface can be up and reporting healthy before any negotiation has taken place at all.

A Deeper Dive into Attachment

The single command, and what it implies

Attaching the profile makes the tunnel endpoints the security endpoints. The source address configured on the tunnel is the local identity used in negotiation, and the destination is the peer. A change to either — moving the tunnel source to a different interface, for instance — changes the identity being presented, and the far end's identity match will reject it.

That coupling is usually what you want, and it is worth knowing about because it means the tunnel source is a security-relevant setting rather than a routing convenience. Changing it during a WAN migration will drop the tunnel even where the new address is perfectly reachable.

! The tunnel, and the one line that protects it
R1(config)# interface Tunnel0
R1(config-if)# ip address 10.0.0.1 255.255.255.252
R1(config-if)# tunnel source GigabitEthernet0/0
R1(config-if)# tunnel destination 203.0.113.2
R1(config-if)# tunnel protection ipsec profile IPSEC-WAN
!
! Sizing, which is not optional - see the last section
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360

The shared keyword, and when it is required

Where two protected tunnels leave the same source address, the router needs to know that they are meant to share one security association database entry rather than each claiming exclusive ownership. Without being told, the second tunnel's protection conflicts with the first and the result ranges from a rejected configuration to a pair of tunnels that alternate.

The keyword must be applied consistently on every tunnel that shares the source, and on both ends. It is one of the few settings here where a partial application is worse than not applying it at all, because the two ends will disagree about how many associations should exist.

! Two tunnels, one source address - both need the keyword
R1(config)# interface Tunnel0
R1(config-if)# tunnel source GigabitEthernet0/0
R1(config-if)# tunnel destination 203.0.113.2
R1(config-if)# tunnel protection ipsec profile IPSEC-WAN shared
!
R1(config)# interface Tunnel1
R1(config-if)# tunnel source GigabitEthernet0/0
R1(config-if)# tunnel destination 203.0.113.3
R1(config-if)# tunnel protection ipsec profile IPSEC-WAN shared

The front-door VRF

Where the transport network and the enterprise network must be kept apart — an internet circuit in its own table, with the enterprise routing inside the tunnels — the tunnel's outer addressing belongs in a separate table from its inner addressing. The tunnel is told which table to use for reaching its destination, while the interface address itself stays in the table the enterprise uses.

This is the standard arrangement for internet-based WAN and it also solves recursive routing structurally: the tunnel destination is looked up in a table that contains no tunnel routes at all, so it cannot resolve through itself. That property alone is a reason to use it even where table separation is not otherwise required.

! Outer lookup in the transport table, inner addressing in the global one
R1(config)# vrf definition INET
R1(config-vrf)# address-family ipv4
!
R1(config)# interface GigabitEthernet0/0
R1(config-if)# vrf forwarding INET
R1(config-if)# ip address 198.51.100.1 255.255.255.0
!
R1(config)# interface Tunnel0
R1(config-if)# ip address 10.0.0.1 255.255.255.252
R1(config-if)# tunnel source GigabitEthernet0/0
R1(config-if)# tunnel vrf INET
R1(config-if)# tunnel destination 203.0.113.2
R1(config-if)# tunnel protection ipsec profile IPSEC-WAN

The tunnel is up before anything is negotiated

A GRE tunnel's line protocol depends on its source being up and its destination being routable. Neither of those has anything to do with IPsec. So a tunnel with a misconfigured key, an unreachable peer or an incompatible proposal still shows as up, and the routing protocol over it does not form an adjacency, and the interface gives no indication why.

This is the most important operational consequence of the whole design and it catches people repeatedly. The interface state is not evidence. The session state is, and it is a different command.

! Interface state says nothing about protection
R1# show interfaces Tunnel0 | include line protocol
Tunnel0 is up, line protocol is up
!
! This is the command that actually answers the question
R1# show crypto session detail
Interface: Tunnel0
Profile: IKEV2-WAN
Session status: UP-ACTIVE
Peer: 203.0.113.2 port 500
  Session ID: 4
  IKEv2 SA: local 198.51.100.1/500 remote 203.0.113.2/500 Active
  IPSEC FLOW: permit 47 host 198.51.100.1 host 203.0.113.2
        Active SAs: 2, origin: crypto map

Watching the association rather than the interface

Three commands cover it. The session view shows whether the peer relationship is active and which interface it belongs to. The key exchange view shows whether the negotiation completed and with what parameters. The data protection view shows the counters — packets encrypted and decrypted — which is where an asymmetric failure becomes visible as one counter moving and the other not.

That asymmetry is worth checking specifically. Encrypting without decrypting means the far end is not sending, or its replies are being lost before arrival, and it narrows the investigation to one direction immediately.

! Negotiation completed? With what?
R1# show crypto ikev2 sa detailed
!
! Are both directions actually moving packets?
R1# show crypto ipsec sa | include encaps|decaps|ident
   local  ident (addr/mask/prot/port): (198.51.100.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (203.0.113.2/255.255.255.255/47/0)
    #pkts encaps: 184052, #pkts encrypt: 184052
    #pkts decaps: 183991, #pkts decrypt: 183991

Transport Mode or Tunnel Mode, and Does the Choice Matter?

Which one belongs here?

Transport mode, in almost every case. The GRE encapsulation has already added an outer IP header whose source and destination are exactly the IPsec peers, so tunnel mode would add a second, identical header for no benefit. Transport mode protects the GRE packet in place and saves those bytes on every packet. Tunnel mode is required when the IPsec peers are not the tunnel endpoints — a separate security gateway in the path — and is otherwise pure overhead.

A Deeper Dive into the Mode Choice

What each mode does to the packet

Tunnel mode treats the entire packet, including its IP header, as payload and builds a new IP header in front of it. That is the correct behaviour when the thing being protected needs its addressing hidden, or when the protecting device is not the device the packet was addressed to.

Transport mode protects the payload and leaves the original IP header in place. Applied to a GRE packet, the header left in place is the one GRE just created, carrying the tunnel source and destination. Those are the same addresses tunnel mode would have put in its new header, which is why the second header adds nothing.

What the saving is worth

Twenty bytes per packet. On a link carrying large packets that is negligible. On a link carrying a high rate of small packets — voice, telemetry, interactive traffic — twenty bytes on a sixty-byte payload is a meaningful proportion of the circuit, and the saving is real.

The stronger argument is the packet size one. Every byte of overhead reduces the largest inner packet that can cross without fragmentation, and fragmentation is where the problems in the last section come from. Twenty fewer bytes is twenty bytes of headroom in the calculation that matters most.

The negotiation, and what happens on a mismatch

The mode is proposed during negotiation. Where one end asks for transport and the other insists on tunnel, the negotiation does not usually fail — it settles on tunnel mode, which both ends support. The result is a working tunnel with more overhead than intended and a sizing calculation that was done for the wrong number.

This is a quiet failure of exactly the kind the rest of this article is about. Nothing reports it, everything works, and the MTU that was calculated carefully is now twenty bytes optimistic. Checking which mode is actually in use, rather than which one was configured, is a one-line verification worth doing after any change.

Where tunnel mode is genuinely required

When the device performing the protection is not the device terminating the GRE tunnel. A design where a firewall or dedicated gateway protects traffic on behalf of routers behind it needs the outer header, because the protected packet is addressed to the tunnel endpoint and the security association belongs to the gateway.

The same applies where the addressing of the tunnel endpoints must not be visible, which is unusual in an enterprise WAN over the internet and normal in some regulated environments. If either of those applies, tunnel mode is correct and the extra header is the price.

Address translation in the path

Where a device between the two endpoints translates addresses, the peers detect it during negotiation and encapsulate the protected traffic in UDP so it survives. This works with both modes and it adds its own header, which changes the sizing calculation again.

Two things follow. The overhead figure used for MTU must account for it where translation is present, and the transport network must permit the UDP port used, not merely the protocol that carries the protected traffic. A firewall permitting the protocol but not the port produces a negotiation that completes and traffic that never arrives. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

! What was actually negotiated - mode, and whether NAT was detected
R1# show crypto ipsec sa | include in use settings|encaps|Remote crypto
     in use settings ={Transport, }
!
R1# show crypto ikev2 sa detailed | include NAT|Status
      Status: READY
      NAT: none detected
!
! Force a renegotiation after changing the transform set
R1# clear crypto sa peer 203.0.113.2

Why Do the Tunnel and the Routing Disagree About Being Up?

What is the failure?

Recursive routing. The tunnel's destination address is learned through a routing protocol running over the tunnel itself, so the moment the tunnel comes up and the routing protocol converges, the path to the tunnel destination points into the tunnel. The router detects the loop and brings the interface down, at which point the route is withdrawn, the original path returns, and the tunnel comes back up. It oscillates permanently and the log fills with the same message.

A Deeper Dive into Recursion and Liveness

How it happens without anybody intending it

Almost always through a summary or a default. The tunnel destination is a public address; the routing protocol over the tunnel advertises a default route; the default is more specific than nothing and so becomes the path to the tunnel destination. Nobody advertised the endpoint deliberately and the effect is the same.

It also happens where the transport addressing overlaps with something advertised inside the tunnel, which is easy to arrange during a merger or a migration and very hard to spot afterwards. The symptom is identical in both cases.

The three ways to prevent it

A separate routing table for the transport is the structural fix and the one to prefer, because it makes the failure impossible rather than unlikely. The tunnel destination is looked up in a table that contains no routes learned over any tunnel, so no advertisement inside the overlay can affect it.

A specific static route to the endpoint works and depends on nobody ever advertising something more specific. Filtering the endpoint out of what the far end advertises works and depends on the filter being maintained. Both are fine and both rely on a discipline that the first option does not need.

Liveness, which is a separate problem

A tunnel interface stays up while its destination is routable, and its destination remains routable long after the far end has stopped responding. So a dead peer leaves a tunnel that is up, a routing adjacency that eventually times out, and a window during which traffic is sent into nothing.

Three mechanisms address it, and they are not interchangeable. Dead peer detection notices that the security association's peer has stopped responding. The routing protocol notices that the neighbour is gone. A dedicated fast detection mechanism notices within a fraction of a second. Which one is appropriate depends on how quickly the design must react and how tolerant the transport is of aggressive probing.

Dead peer detection and its on-demand form

Sending keepalives continuously to every peer costs something on a hub with many spokes. The on-demand form only probes when there is traffic to send and no reply has been seen, which detects a dead peer at the moment it matters and stays quiet otherwise. On a hub, that difference is substantial.

It is worth setting explicitly rather than relying on a default, and worth setting to the same values at both ends so that both sides reach the same conclusion at roughly the same time. Asymmetric detection produces a period where one end has torn down and the other has not, which resolves itself and looks alarming in the logs.

! On the IKEv2 profile, at both ends
R1(config)# crypto ikev2 profile IKEV2-WAN
R1(config-ikev2-profile)# dpd 30 5 on-demand
!
! Routing protocol timers on the tunnel, set rather than inherited
R1(config)# interface Tunnel0
R1(config-if)# ip hello-interval eigrp 100 5
R1(config-if)# ip hold-time eigrp 100 15
!
! Confirm the peer relationship is being monitored
R1# show crypto ikev2 sa detailed | include Life|DPD

Why GRE keepalives are not the answer here

A GRE tunnel can send its own keepalives, and on an unprotected tunnel they work well. On a protected tunnel they interact badly with the protection, because the keepalive that must be returned has to traverse the same security association whose health is in question. The mechanism is documented as unsupported in this combination and should not be relied upon.

Use the routing protocol, dead peer detection, or a dedicated detection mechanism instead. All three are better suited and none of them has an ambiguous support position.

Tracking, for the things routing cannot see

Where a backup path exists behind the tunnel — a second circuit, a different technology — something has to decide when to use it. A tracked object watching reachability of a known address through the tunnel, driving a static route or a routing protocol decision, makes that switch on evidence rather than on the interface state that was already established to be unreliable.

The address being watched should be something behind the far end rather than the far end itself, because the interesting failure is the one where the peer is alive and cannot forward. Watching the peer confirms only that the peer is alive, which was never the question.

What Breaks Once the Packets Get Large?

What is the sizing problem?

Encapsulation adds headers and the circuit's maximum size does not grow to accommodate them. GRE adds twenty-four bytes and the protection adds several dozen more, so an inner packet at the ordinary maximum size no longer fits once it has been wrapped. What happens next depends on fragmentation behaviour, on whether the sender is told, and on whether the notification survives the path — and in a large proportion of networks it does not. The result is small packets passing and large ones disappearing.

A Deeper Dive into Packet Size

Where the bytes go

The GRE encapsulation adds a new IP header and a small GRE header. The protection adds its own header, an initialisation vector, padding to the cipher's block size, a trailer and an integrity value. Padding means the total is not a single fixed number — it varies with the payload — which is why sizing is done with a margin rather than exactly.

The practical consequence is that you cannot compute one perfect value. You compute a conservative one, apply it, and verify with a large packet that it holds. Chasing the last few bytes produces a configuration that works for most payloads and fails for some, which is worse than a value that is slightly generous.

The two settings, and what each one does

The interface maximum size tells the router the largest packet it will place into the tunnel, so larger packets are fragmented or rejected before encapsulation rather than after. This affects all traffic.

The segment adjustment intercepts connection setup and reduces the size the two endpoints agree to use, so they never generate an oversized packet in the first place. This affects only connection-oriented traffic and is the more effective of the two for the traffic that actually matters, because it prevents the problem rather than handling it.

Both belong on the tunnel interface, at both ends, and the common pairing leaves room for the headers with a margin. Applying one without the other leaves a gap: the adjustment covers connections and not datagrams, and the interface setting handles what the adjustment missed.

! Both, on the tunnel, at both ends
R1(config)# interface Tunnel0
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360
!
! Let the router discover the path size and react to notifications
R1(config-if)# tunnel path-mtu-discovery
!
! What the interface believes, after configuration
R1# show interfaces Tunnel0 | include MTU
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
R1# show ip interface Tunnel0 | include MTU
  MTU is 1400 bytes

The notification that never arrives

The mechanism that is supposed to solve this depends on a router in the path sending a message back to the sender saying the packet was too large. That message is an ICMP type that a great many firewalls block, on the general principle that ICMP is dangerous. Where it is blocked, the sender never learns, keeps sending the same size, and the connection stalls after the initial exchange succeeds.

This is why the segment adjustment exists. It does not rely on any notification reaching anybody; it changes what the endpoints agree to at setup time. On a path crossing the internet, assuming the notification will arrive is not a safe assumption.

The fragmentation bit, and who owns it

A packet marked do-not-fragment cannot be fragmented by the router, so an oversized one is discarded and the notification is generated. Clearing that marking before encapsulation allows fragmentation to happen instead, which keeps traffic flowing at the cost of doing work on every packet and reassembly at the far end.

This is a trade rather than a fix. It is a reasonable measure where the traffic cannot be controlled and the alternative is failure, and it is not a substitute for sizing the tunnel correctly. Fragmenting every large packet on a busy hub is a measurable load.

! Allow fragmentation of protected packets, if sizing cannot be fixed
R1(config)# crypto ipsec df-bit clear
!
! Verify with the test that actually reproduces the problem
R1# ping 10.0.0.2 size 1400 df-bit
Type escape sequence to abort.
Sending 5, 1400-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
!
R1# ping 10.0.0.2 size 1500 df-bit
.....

Quality of service on a protected tunnel

A policy applied to the tunnel acts on packets before they are protected, which is what you want, because after protection the router can no longer see the markings it would classify on. Marking should be preserved from inner to outer header so that the transport network can act on it, and that copying is the default behaviour rather than something to configure.

The interaction worth knowing about is with replay protection. A policy that reorders packets significantly — deep queues with very different service rates — can deliver them outside the window the receiver accepts, and they are discarded as replays. The counter for that is visible and is otherwise a mystifying source of loss.

What to verify after any change

Four things. The session is active rather than merely the interface being up. The negotiated mode is the one intended. A large packet with the do-not-fragment bit set crosses successfully. And both the encryption and decryption counters are increasing, not just one of them.

All four are single commands and together they cover every failure described in this article. Running them as a set after any change to the tunnel, the transport or the routing takes a minute and removes the possibility of a quiet failure surviving into production.

! The four checks, in order
R1# show crypto session detail | include Session status|Peer
R1# show crypto ipsec sa | include in use settings
R1# ping 10.0.0.2 size 1400 df-bit
R1# show crypto ipsec sa | include encaps|decaps
!
! And the replay counter, if loss appears under load
R1# show crypto ipsec sa | include replay

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers tunnelling and encryption within its transport technologies and infrastructure security domains. What is asked tends to be the mechanism rather than a full build — why GRE is present when IPsec already exists, which mode belongs with it, and why a protected tunnel can be up while nothing crosses it.

Conclusion

The design exists because neither technology is sufficient alone. GRE provides an interface that a routing protocol can run over and that carries multicast; IPsec provides the protection that GRE has none of. Attaching the protection to the tunnel rather than to the traffic removes the traffic selector entirely, and with it the whole category of failures caused by two descriptions of the same intent drifting apart.

Transport mode is correct in the ordinary case because GRE has already built the outer header that tunnel mode would duplicate, and the twenty bytes saved matter less as bandwidth than as headroom in the sizing calculation. The mode is negotiated rather than imposed, so a peer that does not offer transport will quietly produce tunnel mode and a calculation that was done for the wrong number — which is one output line to confirm and frequently not confirmed.

What actually breaks these tunnels is not cryptographic. A tunnel destination learned through the tunnel produces a permanent oscillation that the circuit is blameless for, and the structural fix is a separate routing table for the transport rather than a static route somebody must remember not to override. An MTU that ignores the added headers produces connections that establish and stall, on a path where the notification that would have explained it is filtered. And the interface being up means only that the destination is routable — it says nothing at all about whether a single protected packet has ever crossed. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

External Links

• RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 4301 — Security Architecture for the Internet Protocol
• RFC 4303 — IP Encapsulating Security Payload (ESP)
• RFC 2784 — Generic Routing Encapsulation (GRE)
• RFC 3948 — UDP Encapsulation of IPsec ESP Packets
• RFC 4459 — MTU and Fragmentation Issues with In-the-Network Tunneling
• Cisco Learning Network — CCIE Enterprise Infrastructure

Reference Notes

1. RFC 2784 specifies GRE, in which a delivery header and a 4-byte GRE header encapsulate the payload packet, giving 24 bytes of overhead with an IPv4 delivery header.
2. RFC 4301 defines the IPsec security architecture, including the distinction between transport mode, which protects the payload of an IP packet, and tunnel mode, which encapsulates the entire packet in a new IP header.
3. RFC 4303 specifies ESP, whose overhead comprises the ESP header, an initialisation vector where the cipher requires one, padding to the cipher block size, the trailer and the integrity check value.
4. RFC 4303 states that the padding required varies with the payload length and the cipher block size, so ESP overhead is not a single fixed value.
5. RFC 7296 specifies IKEv2, including the negotiation of the security association's mode and algorithms between the two peers.
6. RFC 3948 specifies UDP encapsulation of ESP for traversal of network address translation, which adds a UDP header to the protected packet.
7. RFC 4459 describes the MTU and fragmentation problems created by in-network tunnelling, including the dependence of path MTU discovery on ICMP messages that are frequently filtered.
8. Cisco documentation describes tunnel protection, in which an IPsec profile is applied directly to a tunnel interface so that the tunnel endpoints become the IPsec peers and no crypto access list is required.
9. Cisco documentation describes the shared keyword on tunnel protection, required where multiple tunnel interfaces use the same tunnel source address.
10. Cisco documentation describes the tunnel VRF option, which places the lookup of the tunnel destination in a separate routing table from the tunnel interface's own addressing.
11. Cisco documentation states that GRE keepalives are not supported on tunnel interfaces configured with IPsec tunnel protection.
12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include tunnelling and encryption within the transport technologies and infrastructure security domains.