The Missing Trust Decision in Encapsulation
Open tunnelling hosts are dangerous for a precise reason: the endpoint may know how to unwrap a packet without knowing whether the sender is entitled to have it unwrapped. This section focuses on that first security failure in the open-tunnelling-host problem. By separating delivery, decapsulation, and forwarding, we can trace why a victim may see the tunnel endpoint as the sender—and why that one-way path still falls short of bidirectional access.
The distinction is easy to miss because the word tunnel suggests a completed relationship between two trusted ends. In practice, a tunnel interface is also a packet-processing component. It receives an outer packet, interprets an encapsulation header, exposes an inner packet, and passes that result to the host’s routing or local-delivery machinery. Every one of those transitions can be legitimate. The security question is whether the component makes a trustworthy decision before allowing an arbitrary sender to trigger them.
Separate delivery from authorization
A normal packet has a header that helps the network deliver it to the next place. An encapsulated packet has another layer around it. The outer layer identifies the delivery path to the tunnel endpoint. The inner layer contains the packet that the endpoint is expected to serve or forward after it removes the outer wrapper. The outer destination and the inner destination can therefore describe different stages of the journey.
This arrangement is useful whenever two networks need to exchange traffic across a network that does not otherwise carry the desired payload. A site can send an inner network packet through an outer IP path. A remote-access system can use an endpoint as a gateway. A router can carry traffic for a network that is not directly connected. In each case, encapsulation solves the problem of getting the payload to a place where it can be processed.
It does not, by itself, solve the problem of deciding who may submit the payload. That decision belongs to the tunnel configuration, an authentication layer, filtering rules, or the surrounding network architecture. Once the endpoint removes the outer header, the inner source, inner destination, and inner protocol become meaningful inputs to ordinary forwarding. If no control has established that the outer sender is an approved peer, the endpoint has converted a public delivery event into an unverified request to process an inner packet.
The ordering of these decisions matters at a system boundary. A perimeter control may approve an outer packet because its destination is the public address of a tunnel host. After decapsulation, however, the routing layer is evaluating a different source and destination, potentially against different interfaces and rules. That does not mean every firewall overlooks inner traffic; it means the policy must be attached to the stage where the security decision is needed. The RFC’s distinction between routing and packet filtering is therefore operational, not merely descriptive: forwarding can remain ordinary while the contents being forwarded require additional inspection or a trusted termination point.
RFC 2784 makes this division clear by keeping its contract narrow. Generic Routing Encapsulation, or GRE, places a payload packet behind a GRE header and carries the result through an outer delivery protocol. The GRE header identifies the payload’s protocol type and includes fields such as a version value and an optional checksum. The RFC describes how a receiver should process the encapsulated format; it does not decide when a packet should be encapsulated or which remote system is allowed to send one.
That last omission is not a defect in a general encapsulation format. A protocol that can carry many kinds of payload has to leave deployment choices open. But it means that a working GRE header is not evidence of a legitimate peer. The RFC’s security considerations say that routing over GRE remains similar to ordinary IPv4 routing, while packet filtering may need to look inside the GRE packet or terminate the tunnel at a firewall. The message is practical: the outer protocol does not make the inner traffic trustworthy.
An optional checksum illustrates the same boundary. It can help detect corruption in the GRE header and payload, but it does not identify the sender or authorize the packet. Nor should an implementation-specific or extended field be treated as equivalent to a complete cryptographic trust relationship. The paper’s experiments focus on IPIP and GRE configurations that do not provide authentication or encryption by default. The relevant question is therefore what effective peer and payload controls the deployed endpoint actually has, not what security someone might add around the format.
The paper gives “open tunnelling host” a narrower meaning than “host that uses an unauthenticated tunnel protocol.” An open host has a tunnelling interface without authentication or encryption and without a specified remote tunnelling endpoint. Leaving the remote address empty permits the host to decapsulate packets from any source. The combination is important. A tunnel protocol may lack protection by default while a deployment still restricts the remote endpoint, filters the outer traffic, validates sources, or limits what the inner packet can reach. Those controls can prevent arbitrary Internet hosts from making useful use of the interface.
Conversely, the presence of a legitimate business purpose does not make an endpoint closed. A device may have been configured to connect a branch, support a VPN, or reach a private service. If the interface accepts encapsulated packets from arbitrary sources, the intended purpose and the effective input boundary have diverged. The endpoint is still doing the work its operator wanted—decapsulating and forwarding—but it is also offering that work to senders who were never part of the design.
Decapsulation is the point where this divergence becomes operational. Before the transition, the endpoint sees an outer packet addressed to itself. After the transition, it sees a new object with its own source, destination, and protocol. If the host sends that object into normal forwarding without first binding it to an authorized peer, the inner packet inherits the host’s position in the network. A private route, a firewall exception, or a gateway interface can then become relevant to traffic that originated with an arbitrary outer sender.
This is why a review of an open tunnel should ask more than whether the interface is reachable. It should ask what happens after the outer header disappears. Does the endpoint validate the remote source before decapsulation? Does it filter the inner source and destination? Does it forward the result, deliver it locally, or inject it into a bridge? Does the surrounding host attach state or policy to the inner packet as though it came from a trusted interface? These questions describe the actual boundary more accurately than the tunnel’s intended name.
The basic path can be represented as a sequence of transitions:
The sequence deliberately separates the endpoint’s two roles. It is a receiver for the outer packet and a sender for the inner packet. The victim’s view is shaped by the second role. The sender’s ability to receive anything depends on additional routing, translation, and filtering behavior that is not guaranteed by decapsulation.
How an open endpoint becomes a one-way proxy
The simplest abuse follows directly from that sequence. A remote sender constructs an encapsulated packet whose outer destination is the public tunnel host. The inner packet has a source and destination selected by the sender. When the open host accepts the outer packet, removes its header, and forwards the inner packet, the victim receives traffic through the host’s network position.
From the victim’s perspective, the endpoint may now look like the origin of the traffic. In the paper’s abstract model, the sender can choose an inner source that appears to be the tunnel host and an inner destination that is the victim. The endpoint forwards the inner packet without verifying that the sender is the endpoint or an authorized tunnel peer. If the surrounding network permits source spoofing, the endpoint can also forward a packet whose source is deliberately misleading.
That is the meaning of a one-way proxy in this setting. The host is not necessarily running a proxy application, and the sender does not need credentials for a service on the host. The host becomes a proxy because its decapsulation and forwarding behavior lets someone else borrow its position. The proxy’s function is at the packet layer: accept an outer packet, reveal the inner traffic, and send that traffic onward.
The consequence is especially useful for denial-of-service traffic. A victim can be made to process or respond to traffic that appears to come from an intermediary, while the sender’s direct address is absent or obscured from the victim’s view. The endpoint can therefore serve as a forwarding vessel. Earlier work cited by the paper had already shown that large populations of open tunnelling hosts could be abused for one-way-proxy denial-of-service attacks. The paper’s contribution is to ask what additional reachability appears when the same type of endpoint is also attached to a NAT or a private LAN.
There are two limits to keep in view. First, source appearance is conditional. A network may apply egress filtering, ingress filtering, reverse-path checks, or other source-validation rules that prevent a particular forged packet from being forwarded. The open-tunnel definition identifies a missing peer restriction; it does not guarantee that every inner source and destination will survive all later controls.
Second, forwarding toward a victim is not the same as receiving the victim’s response. The packet may take a route that ends at the victim while the reply follows a different path, is blocked by a firewall, is addressed to the apparent source rather than the sender, or is dropped because no translation state exists for it. A one-way proxy can conceal the sender or amplify unwanted traffic without giving that sender a readable conversation with the target.
This boundary matters for both threat assessment and language. It is accurate to say that an open endpoint can let an attacker send traffic through it under conditions supported by the forwarding path. It is not accurate to jump from that observation to “the attacker can read the private network.” Reading replies requires a return channel. Reaching a private service requires the endpoint to interact with a different kind of state. Manipulating a LAN requires a different payload domain altogether.
The difference also explains why ordinary perimeter reasoning can fail. A firewall may block a direct Internet packet whose destination is a private address. But the open endpoint can receive an outer packet addressed to the public host, remove the wrapper, and produce an inner packet after the first perimeter decision has already succeeded. Whether the firewall then blocks the inner traffic is a separate question. If it does not inspect or constrain that traffic, the tunnel has become an alternate entrance into the forwarding path.
A useful operator’s test follows from the mechanism. Identify the authorized remote peers, then observe what the endpoint does with an encapsulated packet from outside that set. Trace the inner source and destination after decapsulation. Check whether forwarding preserves, rewrites, or rejects them. Finally, examine the return path independently rather than assuming that a successful forward implies a successful conversation. This test keeps the analysis tied to transitions and conditions instead of treating “tunnel enabled” as a complete security assessment.
The next boundary appears when the endpoint is not just a forwarder but also a stateful gateway. NAT connection tracking is supposed to remember how a private client initiated a connection and use that record to handle replies. If an open tunnel can feed crafted inner traffic into that state machine, the one-way proxy’s apparent origin can become something more consequential: a path toward discovering and contacting a private client. That is where forwarding turns into state manipulation.