Loose Source and Record Route

What Loose Source and Record Route Is

Loose Source and Record Route, or LSRR, is an obsolete IPv4 packet option that let a sender name one or more waypoints while still allowing routers to choose additional hops. It was designed for path control and troubleshooting, but it also exposed routing detail and created security and operational concerns.

Because it is an IPv4 header option rather than an application-layer feature, LSRR affects packet handling inside the network stack itself. That makes it sensitive to whether routers, firewalls, and middleboxes recognise, permit, strip, or drop the option as traffic crosses trust boundaries.

Why Loose Source and Record Route Was Used

Historically, source routing options were useful when operators needed to influence packet paths for diagnostics, path validation, or workarounds in complex networks. The loose form was less restrictive than strict source routing because it did not force every hop, only the listed waypoints.

In practice, that flexibility was valuable in limited troubleshooting scenarios, but it also meant the sender could steer traffic in ways that bypassed ordinary routing assumptions. Many modern networks disable the option by default because normal forwarding policy should be determined by routing infrastructure, not by remote packet originators.

Why It Became a Security Concern

LSRR can reveal topology details and create an alternate forwarding path that defenders may not have intended to expose. Even when the packet still follows allowed routes, the option can assist reconnaissance by showing which intermediates accept or honour source-routed traffic.

It also weakens trust in routing decisions if a remote sender can influence the path a packet takes. That is why source routing options are commonly filtered at borders, ignored by routers, or removed by security devices that enforce predictable packet handling.

How Organisations Treat It Today

Most organisations handle LSRR as a legacy risk to be blocked, logged, or stripped unless a tightly controlled operational case requires it. The practical question is not whether the option exists in the protocol, but whether any business system still depends on it and whether that dependency is acceptable.

Where it appears in packet captures or perimeter logs, it is worth reviewing whether the traffic is expected, whether devices along the path actually process the option, and whether the exposure is deliberate. For general packet filtering and control hardening, NIST Cybersecurity Framework 2.0 provides a useful governance lens, while NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well with access restriction, configuration control, and monitoring expectations.

What to Watch For in Packet Handling

LSRR matters less as a modern feature than as a signal of unusual or legacy network behaviour. Its presence can indicate outdated configurations, lab traffic leaking into production, or attempts to probe how network devices respond to special IPv4 options.

That is one reason operators often review packet-option handling alongside broader network visibility and detection work. References such as CISA Industrial Control Systems are useful when path control or packet filtering matters in operational networks, and SANS Security Resources can help frame detection and incident-handling considerations around atypical traffic patterns.

Related resources from NHI Mgmt Group

• What breaks when offboarding is not tied to the source identity record?
• What breaks when organisations treat a source of truth and a system of record as the same thing?
• How should security teams route telemetry to multiple Google Cloud projects without losing control of source data?
• Identity Source of Record