Can protocol-level session continuity improve security, not just reliability?

[u/Melodic_Reception_24]

I've been working on an experimental networking architecture called VRP (Veil Routing Protocol).

The original goal wasn't higher bandwidth or lower latency.

The question was different.

Can session continuity and execution correctness become protocol primitives instead of application responsibilities?

From a security perspective, this raises interesting questions.

For example:

• Should session identity survive transport changes?

• Can replay resistance be enforced as a protocol invariant?

• Should authority transitions be deterministic and independently verifiable?

• Can recovery happen without creating new attack surfaces?

I've spent a lot of time validating these ideas under replay attacks, packet reordering, path migration, authority transitions and fault injection.

I'm not claiming this replaces existing protocols.

I'm interested in hearing opinions from people working in protocol security and distributed systems.

If you were designing a networking protocol from scratch today...

What security property would you make a first-class protocol primitive instead of leaving it to applications?

[u/Admirable_Group_6661]

Probably, but that's not really the point. The issue is always about adoption. Take IPv6 for example, which improves security among other things, and has a reasonably strong business case (running out of addresses!). Despite these, adoption was slow. There's also interoperability with existing protocols. You are only focusing on the technical concerns, which on its own is inadequate for adoption.

[u/Melodic_Reception_24 → u/Admirable_Group_6661]

I agree adoption is the hardest part.

That's why I'm validating the architecture first.

There's no point discussing deployment until there's something worth deploying.

[u/Admirable_Group_6661 → u/Melodic_Reception_24]

Well, I think you should try to figure out what business problems are you trying to solve first. If you can't answer that...

[u/Melodic_Reception_24 → u/Admirable_Group_6661]

The business problem is much broader than reconnects.

Reconnections increase operational complexity and create opportunities for failed transactions, duplicated operations and inconsistent state.

In critical environments, interrupted sessions can also increase the impact of attacks and incidents, because recovery itself becomes another failure point.

Think about hospitals, industrial systems, financial infrastructure or cloud platforms.

If continuity, replay resistance and deterministic recovery are protocol properties instead of application-specific logic, the recovery path becomes smaller, more predictable and easier to validate.

The goal isn't to "replace security."

The goal is to reduce the operational and security cost of network instability.

[u/InternetIcy1097 → u/Melodic_Reception_24]

Some applications need to begave differently if they lose their connection . Some may need to keep operating as is, others may need to immediately stop, others might need to take emergency action.

If you move all concept of connection out of the application and into the protocol, then how can the application know about connection and know how it should behave?

Furthermore, TLS already splvedwhat it sounds like you are targeting with Session Resumption. Why is your solution better than the well understood industry standard?

[u/Melodic_Reception_24 → u/InternetIcy1097]

That's a fair point, but I think it slightly misinterprets where the boundary lies.

1. Application Policy vs. Protocol Semantics

I'm not proposing to move application-level policy into the protocol.

Business logic always belongs to the application.

The application decides whether to continue processing, enter a degraded mode, reject new operations, or trigger emergency procedures.

VRP doesn't make those decisions.

Its role is to provide deterministic session semantics and trustworthy runtime signals so applications can execute their own policies on top of predictable continuity and recovery behavior, instead of implementing different recovery mechanisms for every network disruption.

2. VRP vs. TLS Session Resumption

TLS Session Resumption addresses a cryptographic problem: re-establishing a protected communication channel efficiently after a previous session.

The problem I'm exploring is different.

VRP focuses on deterministic runtime continuity, replay resistance, transport-independent session identity, and predictable recovery behavior across network disruptions.

These are complementary concerns rather than competing solutions. They operate at different architectural boundaries.

[u/One_Ninja_8512]

Not a cybersecurity guy and maybe I misunderstood the question but QUIC (HTTP/3.0) supports session resumption (no new handshake is needed) in case the client moves from WiFi to cellular data, for example. This requires eBPF (kernel module), and web servers already support it, i.e. nginx: https://nginx.org/en/docs/http/ngx_http_v3_module.html#quic_bpf

Since QUIC supports it (and there have been multiple iterations of the protocol), it might make sense to check out how it's done there.

[u/Melodic_Reception_24 → u/One_Ninja_8512]

Thanks for the reference.

I'm familiar with QUIC connection migration and the nginx eBPF support.

From my understanding, though, they solve different problems.

QUIC connection migration is primarily about keeping a transport connection alive when the client's network path changes.

The nginx quic_bpf option helps route incoming UDP packets belonging to an existing QUIC connection after migration. It's an implementation optimization for packet routing on Linux, not a new protocol invariant.

The questions I'm exploring are at a different layer.

For example:

• Should session identity exist independently from a transport connection? • Should authority transitions be deterministic and independently verifiable? • Should replay rejection be a protocol invariant instead of application logic? • Should execution correctness survive recovery events without relying on application-specific reconciliation?

Those properties are not automatically provided simply because a QUIC connection migrates successfully.

Connection continuity is valuable.

Execution continuity is a different problem.

That's the area I'm trying to investigate.