Loose Source and Record Route is an obsolete IPv4 packet option that lets the sender specify a list of waypoints for a packet to traverse. The loose form allows routers to choose other hops between listed addresses, which can expose routing information and was often filtered or disabled for security and operational reasons.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Network Integrity | LSRR is handled through network control and boundary enforcement. |
| Recommendation — Block or strip source-routing options at trust boundaries to preserve predictable network control. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Boundary controls govern whether special IPv4 options are allowed to traverse networks. |
| CM-7 — Least Functionality | Obsolete packet options should be disabled unless a specific operational need exists. | |
| Recommendation — Filter or drop LSRR at boundaries to prevent path manipulation across security zones. Disable unused IPv4 source-routing options to reduce attack surface and operational ambiguity. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Unusual IPv4 options are detectable network artefacts that warrant monitoring. |
| Recommendation — Alert on source-routed traffic to identify reconnaissance or legacy protocol use. | ||
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