Security Requirements for IP Tunnel Nodes

Introduction IP tunneling carries an inner IP packet as the payload of an outer IP packet. The outer header is routed across a delivery network. The tunnel egress removes the outer encapsulation and then forwards or locally consumes the inner packet. This model is used by IP-in-IP , generic packet tunneling in IPv6 , Generic Routing Encapsulation (GRE) , GRE-in-IPv6 , and IPv4/IPv6 transition mechanisms . A tunnel node is not merely another router on the native forwarding path. Decapsulation creates a second forwarding decision, often in a different address family or forwarding domain. If the tunnel node accepts traffic from arbitrary outer sources, or forwards arbitrary inner packets after decapsulation, it can bypass filtering that would normally have applied on the native path. This document specifies requirements that make tunnel nodes explicit, bounded, and accountable. The intent is not to deprecate IP tunneling. The intent is to prevent tunnel nodes from operating as open relays, source spoofing enablers, or uncontrolled recursive forwarding points.

Scope This document applies to devices and software that encapsulate, decapsulate, relay, or forward IP tunnel packets, including routers, hosts, firewalls, tunnel brokers, customer edge devices, provider edge devices, and middleboxes. The requirements apply to configured tunnels and to automatic or transition mechanisms when those mechanisms are enabled. This document does not define a new tunnel encapsulation and does not change the packet format of any existing tunnel protocol.

Terminology

IP tunnel:: A mechanism that carries an inner IP packet as payload of an outer IP packet. The delivery protocol can be IPv4 or IPv6, and the passenger protocol can be IPv4 or IPv6.
Tunnel node:: A node that performs IP tunnel encapsulation, decapsulation, or tunnel relay processing. "Tunnel node" is the generic term used in this document. The following terms describe functional roles of a tunnel node. A single device can act as an ingress tunnel node for one tunnel, an egress tunnel node for another tunnel, and a relay tunnel node for a third tunnel.
Ingress tunnel node:: A tunnel node that receives a native IP packet and encapsulates it into an outer IP packet for delivery across a tunnel.
Egress tunnel node:: A tunnel node that receives an encapsulated IP packet, removes the outer tunnel encapsulation, and locally delivers or forwards the resulting inner IP packet according to tunnel policy.
Relay tunnel node:: A tunnel node that decapsulates a packet and then forwards or re- encapsulates the resulting inner packet into another routing domain, address family, tunnel, or native network.
Open tunnel node:: A tunnel node that accepts tunneled packets from sources that are not administratively configured, authenticated, or otherwise authorized.
Tunnel peer:: A remote endpoint or relay authorized to send tunneled packets to a tunnel node.
Inner source prefix set:: The set of inner source prefixes that a tunnel peer is authorized to inject through a tunnel.
Recursive encapsulation:: A packet structure in which the inner packet exposed by one decapsulation step is itself another tunneled packet.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Tunnel Node Processing Model A tunnel node compliant with this document applies the following logical processing stages:

Determine whether the addressed tunnel mechanism is enabled.
Identify the candidate tunnel policy from the outer packet and local configuration.
Validate the outer source address and tunnel peer.
Authorize decapsulation for the selected tunnel policy.
Decapsulate the packet.
Validate the exposed inner packet, including the inner source address and destination forwarding scope.
Apply recursive encapsulation limits and IPv6 extension header policy.
Forward, locally deliver, re-encapsulate, or discard the packet.
Update counters and emit rate-limited logs or control-plane responses as configured.

An implementation MAY combine these stages internally, but it MUST preserve the externally visible security properties described in this document. A packet that fails any validation stage MUST be discarded unless a later section explicitly allows a different action. The tunnel node MUST NOT forward a packet merely because a previous stage accepted the outer packet.

Default Configuration Requirements Tunnel decapsulation MUST be disabled unless a tunnel mode is explicitly enabled by configuration, authenticated control-plane state, or a standards-defined automatic tunnel mechanism. Implementations MUST NOT enable open decapsulation by default. A node that supports a permissive or automatic mode MUST require explicit administrative action to enable that mode. A tunnel node MUST provide a per-tunnel policy object containing at least:

the enabled encapsulation type;
the authorized outer peer address or peer address set, except where a standards-defined automatic mode derives this value from the packet;
the inner source prefix set authorized for each peer;
the forwarding domain or interface into which validated inner packets may be forwarded;
the maximum recursive decapsulation depth;
the IPv6 extension header policy applied after decapsulation;
logging and rate-limiting parameters.

The default maximum recursive decapsulation depth MUST be one. A higher value MUST require explicit configuration.

Peer Authorization and Authentication Configured tunnels SHOULD authenticate tunnel peers. Authentication MAY be provided by a secure control plane, IPsec, authenticated keying, cryptographic tunnel mechanisms, or another operator-approved mechanism. GRE keys, IPv6 flow labels, interface identifiers, and predictable address formats MUST NOT be treated as peer authentication by themselves. They MAY be used as selectors after the peer has already been authorized by other means. If authentication is not available for a tunnel mode, the implementation MUST provide address-based peer authorization and inner source prefix validation. Operators SHOULD prefer authenticated tunnels when the tunnel crosses an untrusted network. Operators SHOULD treat unauthenticated tunnels as explicitly exposed attack surfaces and SHOULD apply stricter rate limits and logging to them.

Source Address Validation Requirements Source Address Validation (SAV) prevents packets with invalid or unauthorized source addresses from entering or leaving a network. Tunnel processing MUST NOT bypass SAV for either the outer packet or the inner packet exposed after decapsulation.

Outer Source Address Validation A tunnel node MUST validate the outer source address before decapsulation. For configured tunnels, the outer source address MUST match the configured tunnel peer or a configured peer address set. For automatic tunnel mechanisms, the tunnel node MUST perform the source-address consistency checks specified for that mechanism. 6to4 implementations and relays MUST implement the security checks described in . Packets that fail outer source address validation MUST be discarded before decapsulation. A tunnel node MUST NOT generate an ICMP error in response to a packet discarded for failed outer source address validation unless local policy explicitly permits it and the response is rate limited.

Inner Source Address Validation After decapsulation, an egress or relay tunnel node MUST validate the inner source address against the inner source prefix set associated with the tunnel peer and tunnel mode. If the inner source address is not covered by the authorized inner source prefix set, the packet MUST be discarded. The packet MUST NOT be forwarded, re-encapsulated, reflected, or locally answered. For ingress encapsulation, a tunnel node MUST apply SAV to native packets before encapsulating them into a tunnel. SAV SHOULD be implemented using BCP 38 and BCP 84 techniques, including strict or feasible-path unicast reverse path forwarding where appropriate . For multihomed or asymmetric networks, strict uRPF can cause false drops. In those deployments, operators SHOULD use feasible-path, enhanced feasible-path, access-list, or source-prefix-list policies that preserve SAV while accounting for routing asymmetry.

Destination and Forwarding-Scope Validation A tunnel node MUST verify that the inner destination is permitted by the tunnel policy before forwarding the decapsulated packet. A tunnel node MUST NOT act as an open relay that accepts arbitrary tunneled traffic and forwards arbitrary inner destinations into the global Internet. If a tunnel is intended to provide transit service, the node MUST define the permitted source prefixes, destination scope, and forwarding domain for that service. Transit behavior MUST be disabled by default.

Recursive Encapsulation Requirements A tunnel node MUST detect when a decapsulated inner packet is itself an IP tunnel packet supported by the same node. Recursive decapsulation MUST be bounded by a configurable maximum depth. The default maximum depth MUST be one. Packets that exceed the maximum depth MUST be discarded. A tunnel node MUST apply the same peer authorization, outer source validation, inner source validation, IPv6 extension header policy, and forwarding-scope validation at each decapsulation layer. Validation at the outermost layer MUST NOT be treated as authorization for deeper layers. Automatic re-encapsulation of a decapsulated packet into another tunnel MUST be disabled by default. If re-encapsulation is enabled, it MUST be controlled by explicit routing or policy state and MUST preserve the SAV requirements in this document.

IPv6 Extension Header Requirements IPv6 extension headers are specified by . Operational considerations for forwarding packets that contain IPv6 extension headers are described in and . Tunnel nodes need explicit policy because decapsulation can expose an IPv6 packet that was not visible to previous filtering devices. After each decapsulation step, a tunnel node MUST apply its IPv6 extension header policy to the exposed inner IPv6 packet before forwarding or re-encapsulation. A tunnel node MUST be able to parse enough of the IPv6 header chain to enforce:

source and destination address validation;
fragment policy;
routing header policy;
upper-layer protocol policy where such policy is configured;
local control-plane protection.

If the tunnel node cannot parse enough of the IPv6 header chain to enforce configured policy, it MUST discard the packet or send it to a rate-limited inspection path. It MUST NOT blindly forward such a packet on the fast path. A tunnel node MUST provide configurable limits for:

the number of IPv6 extension headers;
the total length of the IPv6 extension header chain;
the number of Fragment Headers;
the use of Routing Headers;
the use of Hop-by-Hop Options.

Routing Header Type 0 packets MUST be discarded, consistent with . Segment Routing Headers and other routing headers SHOULD be accepted only when the tunnel node is part of an explicitly configured trusted domain for that routing header type. IPv6 fragments that prevent the tunnel node from enforcing configured SAV, forwarding, or upper-layer policy MUST be discarded. Implementations SHOULD provide counters that distinguish these drops from ordinary forwarding drops.

Protocol-Specific Requirements

IP-in-IP and IP6IP6 For IP-in-IP and IP6IP6 , tunnel nodes MUST enforce configured outer peer authorization and inner source prefix validation. A packet with protocol number 4 or 41 addressed to a node MUST NOT be decapsulated unless it matches an enabled tunnel policy. An IP-in-IP or IP6IP6 tunnel node MUST NOT forward a decapsulated inner packet whose source address is outside the inner source prefix set authorized for that tunnel peer.

GRE and GRE-in-IPv6 For GRE and GRE-in-IPv6 , the tunnel node MUST validate the outer peer before using GRE header fields to select a tunnel. GRE keys MAY select a tenant, virtual routing table, or tunnel policy, but a GRE key MUST NOT authorize traffic by itself. If a GRE tunnel carries multiple inner protocol families, the tunnel policy MUST define inner source prefix sets for each enabled passenger protocol family.

IPv4/IPv6 Transition Tunnels For configured IPv6-over-IPv4 and IPv4-over-IPv6 transition tunnels , the node MUST bind each tunnel peer to the inner prefixes that peer may inject. Cross-protocol encapsulation MUST NOT bypass SAV for either address family. Operators SHOULD audit transition tunnels more frequently than single-family tunnels because IPv4 and IPv6 SAV policies are often configured by different teams, devices, or routing processes.

6to4 6to4 has known operational and security problems, including the deprecation of the 6to4 anycast relay prefix described in . A node that continues to operate 6to4 MUST implement the filtering checks in and the additional requirements in this document. A 6to4 relay or border function MUST discard packets when the embedded IPv4 address in a 2002::/16 address is inconsistent with the outer IPv4 source or destination according to the direction of processing and the relay role. A 6to4 relay MUST NOT provide unrestricted transit for spoofed inner sources. Relay behavior MUST be explicitly enabled, logged, and rate limited.

ICMP, TTL, Hop Limit, MTU, and Fragmentation When a tunnel node forwards a decapsulated packet, it MUST apply the normal forwarding rules for the inner protocol, including TTL or Hop Limit processing. If a packet is dropped because TTL or Hop Limit expires after decapsulation, any generated ICMP error MUST be rate limited. ICMP errors MUST NOT be generated for packets that fail source validation, peer authorization, or extension header policy unless explicitly enabled by local policy. Tunnel nodes SHOULD rate limit ICMP Echo processing for packets exposed by decapsulation. Tunnel nodes MUST NOT allow decapsulated ICMP traffic to create amplification materially larger than the received packet stream. Tunnel nodes MUST provide MTU handling consistent with the underlying tunnel specifications. A tunnel node SHOULD avoid fragmentation where Path MTU Discovery can be used. Fragmentation behavior MUST NOT bypass validation. If a tunnel node cannot validate the inner packet because required information is split across fragments or unavailable without reassembly, the node MUST either perform safe reassembly within configured resource limits or discard the packet. Reassembly state created for tunnel validation MUST be resource limited. When resource limits are exceeded, the node MUST fail closed for packets that require reassembly for validation.

Operational Management and Telemetry Operators deploying tunnel nodes SHOULD:

inventory all enabled tunnel modes and endpoints;
disable unused tunnel protocols at borders and hosts;
bind every configured peer to authorized inner source prefixes;
align IPv4 and IPv6 SAV policy for cross-protocol tunnels;
explicitly configure recursive encapsulation depth;
apply a conservative IPv6 extension header policy at tunnel egress;
rate limit ICMP generated after decapsulation;
monitor tunnel drop counters;
periodically test that tunnel nodes are not open relays.

A tunnel node MUST provide counters for at least:

packets accepted by tunnel policy;
packets discarded for unknown tunnel mode;
packets discarded for unauthorized outer peer;
packets discarded for failed inner SAV;
packets discarded for exceeded recursive encapsulation depth;
packets discarded for IPv6 extension header policy;
packets discarded for fragment policy;
generated ICMP errors after decapsulation.

Operators SHOULD be able to export these counters through existing telemetry mechanisms. Implementations SHOULD support sampled logging for discarded packets, subject to rate limits and privacy controls. Logs SHOULD include the tunnel identifier, outer peer, tunnel mode, drop reason, and address family. Logs SHOULD NOT include payload beyond the headers required for diagnosis. Operators SHOULD treat open tunnel nodes as security defects unless they are part of a deliberate, documented, and filtered relay service.

IANA Considerations This document has no IANA actions.

Security Considerations This entire document specifies security requirements for IP tunnel nodes. The main threats are:

unauthorized use of a tunnel node as an open relay;
injection of spoofed inner source addresses;
bypass of IPv4 or IPv6 SAV through cross-protocol tunnels;
recursive encapsulation used to construct unintended forwarding paths;
IPv6 extension header chains used to evade filtering or induce expensive processing;
ICMP reflection or amplification after decapsulation;
inconsistent policy between native forwarding and tunnel forwarding.

The requirements in this document reduce these risks by requiring peer authorization, inner source prefix validation, bounded recursive decapsulation, explicit IPv6 extension header policy, and operational telemetry. These requirements do not protect against a compromised authorized peer that sends traffic from authorized source prefixes. Operators needing stronger guarantees SHOULD use authenticated and encrypted tunnel mechanisms and SHOULD apply traffic anomaly detection at the tunnel ingress and egress. Tunnel telemetry can reveal customer prefixes, tunnel peers, and traffic policy. Implementations and operators SHOULD limit log retention and SHOULD aggregate or anonymize exported telemetry when fine-grained data is not required for operations or incident response. Measurement data collected through tunnel nodes can reveal SAV gaps in specific networks. Such data SHOULD be handled as sensitive operational security information.

Contributors The following individual contributed significantly to the technical content, review, and analysis presented in this document:

Acknowledgments The author thanks the IETF community for prior work on IP tunneling, source address validation, IPv6 extension header processing, and operational security guidance.