Security Requirements for IP Tunnel Nodes

Security Requirements for IP Tunnel Nodes Tsinghua University

Beijing China he-lin@tsinghua.edu.cn

Tsinghua University

Beijing China gl25@mails.tsinghua.edu.cn

Tsinghua University

Beijing China jzd25@mails.tsinghua.edu.cn

Tsinghua University

Beijing China liuying@cernet.edu.cn

Internet Area IP tunnels conceal passenger-packet fields from devices on the delivery path and create a new forwarding and policy boundary at decapsulation. If a tunnel node accepts delivery packets from an unauthorized source, or if it forwards a decapsulated passenger packet without applying the policy for the exposed packet and forwarding domain, the node can enable source-address spoofing, unauthorized transit, policy bypass, or resource-exhaustion attacks. This document specifies generic security requirements for IP tunnel ingress, egress, and relay nodes. The requirements cover explicit enablement, peer and passenger-packet authorization, source and forwarding-scope validation, nested tunneling, IPv6 extension headers, ICMP and Path MTU Discovery, resource controls, and telemetry. They apply to configured IP-in-IP, IPv6 tunneling, GRE, and enabled IPv4/IPv6 transition mechanisms. This document does not define a new encapsulation or replace protocol-specific processing rules.

Introduction IP tunneling carries a passenger packet inside a delivery packet. The delivery header is routed across a delivery network, and a tunnel egress removes that encapsulation before locally delivering, forwarding, or re-encapsulating the exposed passenger packet. This model is used by IP-in-IP , generic packet tunneling in IPv6 , Generic Routing Encapsulation (GRE) , GRE over IPv6 , and IPv4/IPv6 transition mechanisms . Encapsulation moves passenger source and destination addresses, upper-layer protocol identifiers, and ports away from their normal locations. Consequently, security devices on the delivery path may be unable to apply controls that would have been applied to native traffic. This concern is described for IP-in-IP in and more generally in . Decapsulation then creates a trust boundary: acceptance of the delivery packet is not, by itself, authorization to deliver or forward the exposed passenger packet. This document consolidates generic requirements for making that boundary explicit, bounded, and observable. It does not deprecate IP tunneling. It also does not assume that every tunnel is a point-to-point tunnel; protocol-specific mechanisms such as 6to4 require role- and direction-specific validation instead of a static peer-address check.

Scope and Relationship to Existing Specifications This document applies to hosts, routers, firewalls, tunnel brokers, customer-edge devices, provider-edge devices, and middleboxes that encapsulate, decapsulate, locally deliver, forward, or re-encapsulate IP passenger packets in IPv4 or IPv6 delivery packets. The generic requirements apply to configured tunnels and to automatic or transition mechanisms only when those mechanisms are explicitly enabled. This document specifies no new packet format, authentication exchange, key-management protocol, ICMP message, or IANA code point. It does not replace the TTL, Hop Limit, fragmentation, reassembly, ICMP, or MTU procedures in the specification for a particular tunnel. An implementation claiming conformance with this document MUST also follow the applicable tunnel and passenger protocol specifications. If a protocol-specific specification requires behavior that differs from a generic rule in this document, the protocol-specific behavior takes precedence. Link-layer tunnels, application-layer proxies, and non-IP passenger protocols are outside the normative scope. The same design principles may be useful for them. IPsec tunnel mode is not re-specified here; defines the IPsec security architecture, and discusses its use for IPv6-in-IPv4 tunnels.

Terminology

Delivery packet and delivery header:: The packet transmitted across a tunnel and the header used to deliver it to a tunnel egress. These are also commonly called the outer packet and outer header.
Passenger packet and passenger header:: The packet carried by the tunnel and the header exposed by decapsulation. These are also commonly called the inner packet and inner header.
Tunnel node:: A node that performs tunnel encapsulation, decapsulation, local delivery of a decapsulated packet, forwarding, or tunnel relay processing.
Ingress tunnel node:: A tunnel node that receives or originates a passenger packet and encapsulates it for delivery across a tunnel.
Egress tunnel node:: A tunnel node that receives a delivery packet, removes one tunnel encapsulation, and locally delivers or forwards the exposed passenger packet according to tunnel policy.
Relay tunnel node:: A tunnel node that decapsulates a packet and then forwards or re-encapsulates the exposed packet into another forwarding domain, address family, or tunnel.
Tunnel peer:: A remote tunnel ingress, egress, or relay that is authorized by a tunnel policy. Authorization can be based on authenticated identity, configured topology, protocol-specific derivation, or a combination of these.
Tunnel policy:: The configuration and authenticated control-plane state that bind a delivery-packet selector and peer authorization context to permitted passenger packets, dispositions, forwarding domains, and resource limits.
Nested encapsulation:: Encapsulation in which a passenger packet is itself a tunnel packet, as defined by .
Recursive encapsulation:: Encapsulation in which a packet reenters a tunnel before exiting it, as defined by . Recursive encapsulation is a hazardous special case of nested encapsulation.
Decapsulation depth:: The number of tunnel headers removed from a packet during a local processing sequence.

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.

Threat Model and Security Objectives The assets protected by this document are: (1) authorization of decapsulation, local delivery, forwarding, and re-encapsulation; (2) source-address validity and accountability for passenger traffic; (3) consistency between policy for native traffic and policy for traffic exposed by decapsulation; (4) separation among forwarding domains; and (5) data-plane and control-plane availability at the tunnel node. The attacker is assumed to be able to send delivery packets to an address of the tunnel node and to choose passenger headers, extension headers, fragments, and nested encapsulations. Where source address spoofing is possible on the delivery network, the attacker may also choose a forged delivery source address. The attacker may instead be an authorized tunnel peer that sends a passenger packet outside its authorized source, destination, protocol, or forwarding scope. The principal trust boundaries are the transition from the delivery network into tunnel processing, the transition from tunnel processing into a passenger forwarding domain, and every subsequent decapsulation or re-encapsulation boundary. Successful attack events include unauthorized decapsulation, local delivery, forwarding, or re-encapsulation; acceptance of an unauthorized passenger source; placement of a packet in the wrong forwarding domain; bypass of a configured policy selector; and exhaustion of parsing, reassembly, logging, or control-plane resources. Administrative compromise of the tunnel node, compromise of cryptographic keys or authenticated control-plane state, and attacks on the cryptographic algorithms themselves are out of scope. This document does not prevent an authorized peer from sending harmful traffic that remains within its authorized passenger scope. Address-based peer checks do not provide cryptographic data-origin authentication when delivery source addresses can be spoofed.

Tunnel Node Processing Model A tunnel node compliant with this document applies the following logical stages to each candidate tunnel packet:

Determine whether the addressed tunnel mechanism is enabled.
Select a candidate tunnel policy using the local delivery address, delivery protocol, receiving interface or forwarding domain, and authenticated control-plane state.
Validate the delivery source and destination and authorize the candidate peer for that policy.
Perform delivery-packet processing required by the applicable IP and tunnel specifications, subject to resource limits.
Authorize and perform exactly one decapsulation step.
Validate the exposed passenger packet, including its address validity, authorized source, permitted destination and forwarding scope, fragmentation state, and any configured upper-layer policy.
Apply the policy for the first processing depth at which each required selector is visible.
Authorize local delivery, forwarding, re-encapsulation, or an additional decapsulation step.
Update counters and emit any permitted, rate-limited logs or control messages.

An implementation MAY combine these stages internally or execute them in a different order, but it MUST preserve their externally visible security properties. In particular, a fast path MUST NOT forward, locally deliver, or re-encapsulate a packet solely because its delivery header matched a tunnel policy. Unless a protocol-specific specification requires another action, a packet that fails authorization or a configured validation rule MUST be discarded. Failure of logging or telemetry export MUST NOT cause an otherwise unauthorized packet to be accepted.

Default Configuration and Policy Requirements Tunnel decapsulation and tunnel relay behavior MUST be disabled unless enabled by explicit configuration or authenticated control-plane state. Support for an automatic tunnel mechanism does not constitute enablement. A permissive, multipoint, or automatic mode MUST require explicit administrative action and MUST NOT be enabled merely by enabling IP forwarding. A tunnel policy MUST identify at least:

the delivery and passenger address families and enabled encapsulation type;
the local tunnel endpoint address or other local delivery selector;
the expected receiving interface or delivery forwarding domain where that selector is stable;
the authorized peer address set, authenticated peer identity, or protocol-specific peer-derivation rule;
the passenger source prefixes, destination scope, and passenger protocols authorized for each peer or peer class;
the permitted disposition and passenger forwarding domain;
the permitted next tunnel policy, maximum decapsulation depth, and re-encapsulation behavior;
IPv6 extension-header, fragmentation, ICMP, and PMTU handling policy; and
per-peer, per-tunnel, and global resource, logging, and rate limits.

By default, a policy MUST authorize removal of only the tunnel header that matched that policy. A further decapsulation or re-encapsulation step MUST require an explicitly configured next policy. This default is a local authorization rule; it does not replace the Tunnel Encapsulation Limit mechanism in . When authenticated control-plane state is required to authorize a peer or passenger prefix, loss or expiration of that state MUST NOT authorize new decapsulation state. Implementations SHOULD provide a bounded, operator-configurable behavior for existing state during control-plane failure.

Peer Authentication and Packet Authorization Peer authentication and packet authorization are distinct. Authentication establishes an identity or data origin. Authorization determines which delivery packets and passenger packets that identity may inject and where those packets may be delivered or forwarded. A configured tunnel crossing a network in which delivery source spoofing or on-path modification is within the threat model SHOULD use cryptographic data-origin authentication and integrity protection. If a security decision depends on a peer identity that cannot be reliably established by the delivery topology, the tunnel node MUST use an authenticated mechanism. IPsec is one such mechanism; this document does not mandate a single mechanism. An address match, receiving interface, IPv6 Flow Label, local interface identifier, or predictable address format MUST NOT be represented as cryptographic peer authentication. The GRE Key field defined by identifies a logical traffic flow. Absent an additional specification and protected secret provisioning, it MUST NOT be treated as cryptographic authentication. Such fields MAY be used as authorization selectors after the applicable peer check has succeeded. Successful peer authentication MUST NOT, by itself, authorize every passenger source, destination, protocol, local service, forwarding domain, or deeper tunnel layer. The tunnel node MUST bind the authenticated or configured peer to the complete tunnel policy used for the packet. This requirement applies equally to packets that will be forwarded and packets addressed to a local service after decapsulation. Where the selected authentication mechanism provides anti-replay protection and replay is relevant to the deployment, operators SHOULD enable that protection. Replay protection does not replace passenger-packet authorization.

Address and Forwarding-Scope Validation

Delivery-Packet Validation Before decapsulation, a configured tunnel egress MUST verify that the delivery destination identifies a local enabled tunnel endpoint and that the delivery protocol, source address, receiving context, and any authentication result match the selected policy. For a configured IPv6-over-IPv4 tunnel, the IPv4 source-address check required by applies. A node receiving packets for a standards-defined automatic or multipoint mechanism MUST apply that mechanism's role- and direction-specific consistency checks. It MUST NOT substitute a static point-to-point source-address rule when the mechanism explicitly permits packets from a broader peer set. Delivery-source validation SHOULD also use the receiving interface and routing information where doing so is compatible with multihoming and asymmetric routing. BCP 38 and BCP 84 describe applicable source-address validation techniques. A packet that fails delivery-source, peer, or tunnel-policy validation MUST be discarded before its passenger packet is admitted to a forwarding or local-delivery path. Unless an applicable specification requires an error, such a discard SHOULD be silent to avoid reflection and information disclosure.

Passenger Source Validation After each decapsulation step, the tunnel node MUST validate the exposed passenger source address using the passenger address family's validity rules and the authorized source-prefix set or other source rule bound to the peer and tunnel policy. An authenticated delivery packet does not exempt the passenger packet from this check. If the passenger source is invalid or outside its authorized scope, the packet MUST NOT be forwarded, re-encapsulated, reflected, or delivered to a local service. The packet MUST be discarded unless an applicable protocol specification requires a different action. Before encapsulating a packet received from another node, a tunnel ingress MUST apply source-address validation appropriate to the passenger forwarding domain. Operators SHOULD select strict, feasible-path, enhanced feasible-path, access-list, or equivalent validation according to the routing properties of the deployment. Strict uRPF SHOULD NOT be used where legitimate multihoming or asymmetry would cause unacceptable false drops.

Destination, Local-Delivery, and Forwarding-Scope Validation Before locally delivering or forwarding a decapsulated packet, a tunnel node MUST verify that the passenger destination, passenger protocol, requested disposition, and destination forwarding domain are permitted by the tunnel policy. A forwarding domain or tenant context MUST NOT be selected solely from an unauthenticated packet field. A tunnel node MUST NOT provide arbitrary transit merely because a delivery packet reached an enabled tunnel endpoint. A node intentionally providing transit MUST explicitly configure the authorized peer class, passenger source scope, passenger destination scope, and destination forwarding domain for that service. Policy that depends on passenger fields MUST be applied at the first processing depth at which those fields are visible. If a later decapsulation step exposes a new passenger packet or new policy selectors, the node MUST perform a new authorization decision. Authorization of a carrier packet MUST NOT be inherited as authorization of a newly exposed passenger flow.

Nested and Recursive Tunneling A tunnel node that supports more than one local decapsulation step MUST maintain the decapsulation depth and selected policy chain for the packet. It MUST perform another decapsulation only when the exposed packet matches an explicitly configured next tunnel policy. Recognition of an IP protocol number or GRE header alone is not sufficient authorization for the next step. An implementation MUST provide a configurable upper bound on local decapsulation depth and on the work performed for a nested packet. A packet that exceeds either bound MUST be discarded. The bounds MUST be applied across fast and slow paths and MUST NOT be reset by a local forwarding-domain or interface transition. For IPv6 tunnel encapsulation, an implementation MUST process the Tunnel Encapsulation Limit option as specified in Section 4.1.1 of . In particular, a tunnel ingress examines an existing option, rejects a zero limit with the specified ICMPv6 Parameter Problem behavior, decrements a nonzero limit when adding an encapsulation, and inserts a configured limit when required. A local decapsulation-depth limit complements, but does not replace, this on-wire mechanism. Implementations MUST prevent loopback and routing-loop encapsulation. IP-in-IP implementations MUST follow the routing failure checks in , and IPv6 tunnel implementations SHOULD implement the configuration and packet checks in Sections 4.1.2 and 4.1.3 of . Automatic re-encapsulation of a decapsulated packet MUST be disabled unless an explicit route and tunnel policy authorize it. Peer authorization, passenger source validation, destination and forwarding-scope validation, extension-header policy, and resource accounting MUST be applied independently at every applicable layer.

IPv6 Extension Headers and Fragmentation Policy Decapsulation can expose an IPv6 header chain that was not visible to devices on the delivery path. A tunnel node MUST therefore apply any configured passenger IPv6 policy after each decapsulation and before local delivery, forwarding, or re-encapsulation. The policy and parser MUST conform to and . Decapsulation by itself is not justification for a blanket discard of packets containing standard IPv6 extension headers. Consistent with , a forwarding node that operates as a firewall MUST discard a packet containing a standard extension header only as the result of an intentionally configured policy and MUST be capable of permitting standard extension headers when configured to do so. If a configured policy requires an upper-layer selector, the tunnel node MUST parse the IPv6 header chain far enough to locate that selector or determine that it is unavailable. It MUST NOT treat an unavailable selector as an implicit match for an allow rule. The node MAY discard the packet or send it to a resource-limited inspection path. The operational tradeoffs of these choices are described in . Implementations MUST provide configurable processing limits for IPv6 header-chain length, parsing work, and slow-path admission. Such limits are resource controls, not permission to process standard extension headers contrary to . A node that cannot enforce its configured policy within the limit MUST fail closed for that policy decision. Routing Header Type 0 MUST be rejected as specified by . Segment Routing Header processing and SR domain-boundary filtering MUST follow . Other routing-header types MUST be handled according to their defining specifications and configured policy. IPv6 fragmentation and reassembly MUST follow . A First Fragment that does not contain the complete IPv6 header chain is handled as specified by . If fragmentation prevents enforcement of a configured policy, the tunnel node MUST either perform validated, resource-bounded reassembly or discard the fragments associated with that policy decision. It MUST NOT admit later fragments as a means of bypassing a decision made on the First Fragment.

Protocol-Specific Requirements

IP-in-IP and IPv6 Tunneling For IP-in-IP and IPv6 tunneling , a packet using IP protocol number 4 or 41 MUST NOT be decapsulated merely because it is addressed to a local IP address. It MUST match an enabled tunnel policy and the delivery-source and peer checks for that policy. The TTL in an IPv4 passenger header is decremented during encapsulation when encapsulation is performed as part of forwarding, but it is not changed merely by decapsulation, as specified in . The analogous passenger Hop Limit or TTL processing for IPv6 delivery tunnels is specified by . Subsequent forwarding performs the normal decrement for the passenger protocol. An implementation MUST NOT add an extra decrement solely because a packet was decapsulated.

GRE and GRE over IPv6 GRE implementations MUST validate GRE header fields according to and, when implemented, the Key and Sequence Number extensions according to . GRE over IPv6 implementations MUST also follow . A tunnel node MUST complete the applicable delivery-peer check before using a GRE Key or passenger Protocol Type to select a forwarding domain. A GRE Key MAY select a tunnel policy, tenant, or virtual routing table, but it does not remove the requirement to authorize the peer and passenger packet as described in . A GRE policy MUST enumerate the permitted passenger Protocol Types and MUST define source, destination, and forwarding-scope rules for every enabled IP passenger address family. Unknown or unauthorized passenger Protocol Types MUST be discarded.

Configured IPv4/IPv6 Transition Tunnels A configured IPv6-over-IPv4 tunnel MUST perform the delivery IPv4 source-address and passenger IPv6 validity checks specified in Section 3.6 of . The configured delivery peer MUST also be bound to the passenger prefixes and forwarding scope that it is authorized to inject. Cross-protocol encapsulation MUST NOT bypass source-address validation for either address family. Operators SHOULD audit IPv4 and IPv6 policy together because the delivery and passenger forwarding paths can be administered by different systems.

6to4 6to4 is an automatic multipoint mechanism; its authorized delivery-peer set cannot be modeled as a single configured peer. A 6to4 router or relay that remains enabled MUST perform all role- and direction-applicable encapsulation, decapsulation, and address sanity checks in Section 5 of . The implementation MUST apply the exact role-specific rules rather than a generalized equality test between every delivery and passenger address. As required by , anycast 6to4 and unicast 6to4 in hosts, and 6to4 in routers, MUST be disabled by default. Enabling IPv6 forwarding MUST NOT automatically enable 6to4. The basic unicast 6to4 mechanism and 2002::/16 are not themselves deprecated by ; the anycast relay mechanism and 192.88.99.1 are deprecated. A 6to4 relay service MUST be deliberately configured, monitored, and rate limited. Its forwarding behavior MUST be restricted by the checks in and by the role-specific service policy; it MUST NOT be treated as an authenticated point-to-point tunnel.

ICMP, TTL, Hop Limit, MTU, and Fragmentation

TTL and Hop Limit A tunnel node MUST follow the TTL and Hop Limit rules in the applicable delivery, passenger, and tunnel specifications. Decapsulation alone MUST NOT cause an additional passenger TTL or Hop Limit decrement. If the exposed packet is subsequently forwarded, normal passenger-protocol forwarding rules apply.

ICMP Generation and Processing ICMP and ICMPv6 errors generated or relayed by a tunnel node MUST follow the applicable requirements of , , and the tunnel specification. Error generation MUST be rate limited. A security-policy discard SHOULD be silent unless an applicable specification requires an error or an operator deliberately enables one. A tunnel node MUST NOT generate an error to a passenger source that failed passenger-source validation. It MUST NOT generate a response to a delivery source that failed peer or delivery-source validation unless a protocol-specific requirement applies and the response is safe under the deployment's reflection threat model. Before an incoming ICMP or ICMPv6 error changes tunnel PMTU, reachability, or other forwarding state, the tunnel ingress MUST validate that the quoted packet and available context identify an active tunnel and a packet that the node could have sent. Unmatched or insufficiently quoted errors MUST NOT update tunnel state. Accepted updates SHOULD be scoped to the identified tunnel and SHOULD have bounded lifetimes. Examples of forged ICMP attacks and validation techniques for TCP are discussed in .

MTU and Path MTU Discovery A tunnel ingress MUST account for encapsulation overhead and MUST implement the MTU, fragmentation, and ICMP translation or relay behavior required by its tunnel specification. Relevant procedures are specified by , , , and . The operational tradeoffs for in-the-network tunneling are described in . IPv4 Path MTU Discovery is specified by , and IPv6 Path MTU Discovery is specified by . A tunnel implementation using these mechanisms MUST follow the applicable specification together with the ICMP handling rules of its tunnel protocol. An implementation MUST NOT use a reported PMTU outside the bounds permitted by the applicable IP and tunnel specifications. It SHOULD expose accepted and rejected PMTU updates through counters. Packetization Layer PMTUD MAY be used where supported by the packetization layer and deployment.

Fragmentation and Reassembly Resources Fragmentation MUST NOT be used to bypass delivery-peer or passenger policy. Where a tunnel specification requires delivery-packet reassembly at an egress, the egress MUST perform that reassembly before decapsulation and MUST apply the reassembly rules of the delivery IP version. Reassembly and fragment-tracking state MUST be bounded per source or peer, per tunnel, and globally. Implementations MUST bound at least the number of incomplete datagrams, bytes retained, fragment count per datagram, and retention time. When resources are exhausted, the node MUST fail closed for packets that require reassembly or fragment state to complete authorization. Operators and implementers SHOULD avoid fragmentation where a compliant MTU or PMTUD strategy is available. The fragility and denial-of-service implications of IP fragmentation are described in BCP 230 .

Resource-Exhaustion Controls Tunnel nodes MUST provide independent, configurable limits for work performed before peer authorization and work performed after peer authorization. An unauthorized source MUST NOT be able to consume an unbounded amount of decapsulation, parsing, reassembly, cryptographic, ICMP-generation, logging, or control-plane work. Implementations MUST support limits for at least:

candidate tunnel packets and bytes per peer or source class and per tunnel;
nested decapsulation depth and total parsing work per packet;
fragment-tracking and reassembly state;
IPv6 extension-header slow-path or inspection admission;
ICMP and ICMPv6 generation and accepted state updates; and
log generation and telemetry export.

Resource exhaustion MUST NOT cause the implementation to bypass a mandatory authorization or validation step. Implementations SHOULD isolate management and routing-control traffic from data-plane tunnel processing and SHOULD provide a bounded recovery path after a limit is reached.

Operational Management and Telemetry Operators deploying tunnel nodes SHOULD:

inventory enabled tunnel mechanisms, endpoint addresses, peer identities, and passenger forwarding domains;
disable unused tunnel mechanisms on hosts, borders, and intermediate systems;
bind every configured peer or peer class to explicit passenger and forwarding scopes;
review IPv4 and IPv6 source-validation policy together for cross-protocol tunnels;
configure and test nested-tunnel, extension-header, fragment, ICMP, PMTU, and resource limits;
protect tunnel configuration and telemetry using access control and authenticated management channels; and
periodically verify, using authorized testing, that tunnel nodes do not provide unintended local delivery, transit, or re-encapsulation.

A tunnel node MUST provide counters for at least:

packets and bytes accepted by tunnel policy and resulting disposition;
unknown or disabled tunnel mechanisms;
delivery-source, receiving-context, peer-authentication, and replay failures;
passenger source, destination, protocol, local-delivery, and forwarding-scope failures;
nested-policy and decapsulation-depth failures;
IPv6 extension-header, fragment, reassembly, and resource-limit failures;
ICMP or ICMPv6 errors generated, rate limited, accepted for state update, and rejected; and
PMTU updates accepted and rejected.

Implementations SHOULD support rate-limited, sampled event logging. When available, a log entry SHOULD identify the tunnel policy and version, receiving context, decapsulation depth, peer or peer class, delivery and passenger address families, disposition, and specific failure reason. Logs SHOULD NOT contain passenger payload and SHOULD minimize capture of headers not needed for diagnosis. Tunnel configuration changes and authenticated control-plane changes that alter peer or passenger authorization SHOULD be auditable. Telemetry loss SHOULD be reported, but it MUST NOT weaken packet authorization.

IANA Considerations This document has no IANA actions.

Security Considerations This entire document specifies security requirements. The principal threats are unauthorized tunnel use, forged delivery or passenger source addresses, unintended local delivery or transit, forwarding- domain confusion, policy bypass at a decapsulation boundary, recursive or looping encapsulation, extension-header or fragment evasion, forged ICMP state changes, and exhaustion of parsing, reassembly, cryptographic, control-plane, or logging resources. The requirements reduce these threats by binding an authorized peer and delivery context to permitted passenger traffic and disposition, applying policy at every visibility and decapsulation boundary, bounding work, and making security-relevant outcomes observable. They do not prove that a tunnel is safe for every deployment. Address-based peer authorization remains vulnerable where an attacker can spoof a permitted delivery source. Cryptographic peer authentication reduces that risk but does not authorize arbitrary passenger traffic. Conversely, passenger source validation does not authenticate the delivery peer. Deployments requiring both properties need both controls. A compromised authorized peer can still send harmful traffic within its assigned passenger and forwarding scope. An encrypted passenger may prevent a tunnel node from applying upper-layer policy; an operator MUST either rely on an authorized endpoint that can enforce that policy or restrict the encrypted traffic to a scope where the missing visibility is acceptable. Resource limits reduce but do not eliminate denial-of-service risk. Incorrect source-prefix, destination-scope, interface, or uRPF configuration can cause either unauthorized acceptance or legitimate traffic loss, particularly with multihoming, mobility, and asymmetric routing. Operators need change control and tests that cover both security failure and legitimate reachability. Tunnel telemetry can reveal customer prefixes, peer relationships, forwarding domains, policy, and traffic patterns. Implementations and operators SHOULD restrict access, minimize collection, protect export, define retention limits, and aggregate or pseudonymize data when exact identifiers are not required. Measurement results that identify source-validation gaps SHOULD be handled as sensitive operational security information.

Contributors The following individuals contributed to this document: Tsinghua University

BeijingChina cdg22@mails.tsinghua.edu.cn

Tsinghua University

BeijingChina wct24@mails.tsinghua.edu.cn

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

References Normative References Informative References

Changes from -00

Added an explicit threat model, trust boundaries, security objectives, and exclusions.
Clarified scope and the precedence of protocol-specific processing rules.
Separated peer authentication from delivery- and passenger-packet authorization.
Corrected nested and recursive encapsulation terminology and aligned limits with RFC 2473.
Aligned IPv6 extension-header policy with RFC 7045 and added fragment-policy requirements.
Expanded protocol-specific requirements for IP-in-IP, GRE, configured transition tunnels, and 6to4.
Reworked TTL, Hop Limit, ICMP, PMTU, fragmentation, and reassembly requirements to defer to the applicable RFCs.
Added explicit resource-exhaustion controls and expanded operational telemetry.
Added and corrected RFC references, including RFCs 1191, 2890, 4301, 4459, 6169, 7112, 7526, 8201, 8754, 8899, and 8900.