Summary

  • RFC 791's type-130 option was a fixed eleven-octet label containing security, compartment, handling-restriction and transmission-control fields; later RFCs kept the type value but replaced that format.
  • RFC 1108's Basic Security Option made classification and protection authorities inputs to per-interface acceptance policy, with explicit or implicit labels depending on the deployment.
  • Although RFC 1108 became Historic and such packets should not normally appear on the public Internet, later guidance warned generic equipment not to strip or drop them by default because doing so can mislabel data inside a closed MLS network.

Removing the label can change the information

The most consequential act in this story is not adding a security field. It is deleting one. RFC 7126 warns that if a Basic Security Option is stripped in transit, a receiver may reject the packet because it is no longer properly labelled. In some circumstances it may accept the data but associate the wrong sensitivity with it.

The error can run in either direction. Treating information as more sensitive than it is—upgrading—can block legitimate use and contaminate higher-level systems. Treating it as less sensitive—downgrading—can expose information to a domain that should not receive it. The firewall that removed a “security-looking” field has not neutralized a threat. It has changed a policy input without knowing the receiver's replacement rule.

That is the lens through which type 130 should be read. The option is not cryptography. It does not encrypt a payload, authenticate a sender or prove clearance. It is a label consumed by trusted systems whose configuration supplies the authority the packet itself lacks.

The first format tried to carry four kinds of control

RFC 791 defined Security as option type 130 with a fixed length of eleven octets. After type and length came four fields: sixteen bits of Security, sixteen bits of Compartments, sixteen bits of Handling Restrictions and twenty-four bits of Transmission Control Code.

The Security field selected one of a set of named levels. The Compartments field separated traffic into controlled categories. Handling Restrictions referred to control and release markings. TCC defined controlled communities of interest. The header therefore did more than say “secret” or “not secret”; it tried to carry several dimensions of an external information-control regime.

The option had its copy bit set. Fragmentation placed it in every fragment, and a datagram could contain it at most once. A fragment was not meant to escape the label merely because IPv4 divided the packet.

RFC 791 also made an unusually broad statement about options: their presence in a particular datagram was optional, but their implementation by IP modules was not. It noted that some environments could require the Security option in every datagram. The global packet format was accommodating a rule whose necessity depended entirely on the attached security environment.

None of those fields supplied cryptographic integrity. Copying the label did not make it true. Its effect depended on trusted sources, trusted intermediaries, configuration and protected networks.

Type continuity concealed a format replacement

In 1988, RFC 1038 revised type 130 into a variable-length Basic Security Option. It replaced the fixed compartments, handling and TCC layout with a classification level and protection-authority flags. The same numerical option type now introduced a different body.

That distinction is essential for parsers and historians. A value in a registry can remain constant while its specification changes incompatibly. Identifying a byte as 130 is not enough; the length and the governing RFC determine how the rest should be read.

RFC 1038 described the label as something trusted components could use to validate source transmission, ensure that a route and destination were protected to the required level, and provide information-control models with a common label. The claim depended on security-aware routing and accredited components, not merely on the option's presence.

The revision was itself transitional. RFC 1108 obsoleted RFC 1038 and specified the DoD Basic and Extended Security Options. Type 130 remained the Basic Security Option, but even the minimum length changed: RFC 1108 permits three octets when the Protection Authority field is absent.

Classification values were deliberately bad arithmetic

RFC 1108 devoted one octet to Classification Level. The valid patterns were sparse: particular bit strings meant Top Secret, Secret, Confidential or Unclassified, while other listed strings remained reserved.

Their numeric order was not the classification order. The table defined the ordering. An implementation could test equality with a bit-string comparison, but it could not decide that a byte fell between Confidential and Secret by applying an ordinary arithmetic range test. Such a range would include invalid or unassigned patterns.

The encodings were chosen to maintain a minimum Hamming distance of four between valid values. A small number of flipped bits would be less likely to turn one valid classification directly into another. This is error-detecting distance, not encryption or authenticity. An attacker or faulty sender can still write a valid code; the field offers no proof of origin.

The design placed policy order outside numeric order. Software had to know the assigned table rather than infer meaning from magnitude. A label was a controlled vocabulary encoded in a byte, not an integer whose size represented sensitivity.

Authority flags named rules, not credentials

Following the classification byte, RFC 1108 allowed a variable Protection Authority field. The first seven bits of each octet were flags; the low-order bit said whether another octet followed. Multiple authorities could apply to one datagram, and minimally compliant implementations had to be able to process at least two octets of flags.

The flags identified programs whose protection rules applied to the information. RFC 1108 explicitly warned that they were not accreditation authorities, despite superficially similar semantics. They did not certify a host or grant a user clearance.

The encoding had to be minimal: no trailing all-zero continuation octets. The indicated flag-field length also had to agree with the option length. A malformed extension was a protocol error, not a harmless list of unknown badges.

The extensible field exposes another source of authority outside the packet. Somebody had to approve and publish flag assignments. The option carried selections from that managed namespace; it did not create the rules it invoked.

Every interface could be a classification boundary

RFC 1108 described system-wide and per-port security parameters. Here “port” means a network attachment or interface policy boundary, not a TCP or UDP port number. Configuration could require a Basic Security Option on transmit, on receive, both or neither.

Systems processing classified data generally had to generate the option. The exception was a dedicated or system-high network where traffic could receive an implicit label from the interface instead of carrying an explicit one in each datagram. If local policy allowed an unlabelled packet, the receiving port's configured implicit label supplied the missing context.

That substitution explains why stripping is dangerous. The same unlabelled packet can mean “ordinary Unclassified traffic” on one interface and “traffic implicitly at this protected level” on another. Removing an explicit label does not produce a neutral value; it can cause policy to select a different label source.

Input processing first validates that the classification byte is assigned. It then checks the datagram level against the receiving port's maximum and verifies that the authority flags are permitted inbound. Output policy similarly requires the datagram level to lie between the port's configured minimum and maximum and the flags to fit the outbound authority set.

The packet provides proposed label data. The interface supplies the admissible range. Acceptance emerges from their comparison.

Errors were security decisions too

If an interface required BSO and received none, RFC 1108 specified an ICMP Parameter Problem response using Code 1 for a missing required option. Malformed labels used the ordinary parameter-problem form; out-of-range labels could produce an administratively prohibited destination-unreachable response.

Yet these were the least restrictive permitted actions. Local policy could require logging, alert a security officer or forbid any response. Even the diagnostic path had to respect the classification of the interface on which a reply would leave.

This is not a reusable claim that all missing IPv4 options trigger the same response. It is a policy-rich environment in which silence, error and reply labelling were controlled decisions. The earlier article about ICMP's missing-option code studied that error grammar; here it matters only as evidence that a label was part of an enforced admission system.

Hosts called the old formats obsolete while routers retained the revised one

RFC 1122 said the security options described by RFC 791 and RFC 1038 were obsolete. It did not say every security-labelled environment had ceased to exist. For DoD applications it directed vendors to the revised guidance that became RFC 1108.

RFC 1812 made the distinction operational. It repeated that the RFC 791 and RFC 1038 versions were obsolete, yet said routers should implement the revised RFC 1108 option. Routers intended for multiple security levels should support filtering on IPSO labels.

Its model assigned each interface a lower and upper sensitivity limit. A packet outside that range should be silently dropped, and a counter should record the out-of-range event. This was not generic source routing or a path list. The router applied a local admissibility test at each boundary.

Standards status therefore cannot be read as a single switch. One format becomes obsolete; its replacement remains a conditional router feature; the protocol document later becomes Historic; the operational need persists in a restricted domain.

Historic did not mean absent

RFC 7126 says these labels should not normally appear on the global public Internet. It also records a crucial exception: private multi-level-secure networks used Basic and Extended Security Options on commercial and open-source systems. The document judged that MLS deployment, and therefore IPSO deployment, might be greater than when the IESG removed the option from the Standards Track.

That is the inverse of a simple deprecation story. A mechanism can retreat from the public standards mainstream while growing inside a specialized operational enclave. “Historic” describes the RFC's standards status; it is not a measurement of zero packets or a command to erase the registration.

The same commercial router or firewall can be installed in either environment. The device cannot know in advance whether type 130 is meaningless public-Internet baggage or a mandatory label inside a closed network. Product defaults therefore have to preserve optionality for the administrator who does know.

The default was preservation, not universal processing

RFC 7126's advice is carefully conditional. Because dropping or stripping causes real failures where BSO is required, while merely carrying it causes no specific new harm where it is not needed, default configuration should not remove the option or drop a packet solely because it contains BSO.

An administrator in an environment known not to use IPSO may configure a drop. Equipment should support logging BSO packet counts per interface and should be able to filter both on presence and on values. The policy is not “the public Internet must understand classified labels.” It is “a generic box should not silently destroy a label before deployment policy has spoken.”

Presence alone creates no specific new threat according to the document, though exceptional IPv4 option processing still deserves architectural attention. The label's security comes from correct enforcement. Passing it unchanged through a system that does not interpret it is different from trusting it.

TCP kept the fossil in a conditional appendix

RFC 9293, the modern TCP specification, records the awkward inheritance. Older TCP logic had treated IP security/compartment information as part of connection processing. By 2022, RFC 1108 was Historic, but RFC 791 itself had not been revised to remove the Security Option.

The document places the remaining discussion in implementation notes. References to security/compartment information may still matter to MLS implementers and can be ignored by non-MLS implementations. That boundary is more honest than pretending one universal behavior fits both environments.

It also notes that resetting connections when security compartment or precedence values do not match has been recognized as a possible attack vector. A security label can protect admission when the surrounding trust model is sound and become a disruption surface when old cross-layer rules are applied mechanically.

What type 130 can and cannot establish

A captured type-130 option establishes that a packet contains bytes in a historically assigned label slot. Length and format can help identify which specification the sender appears to follow. A valid RFC 1108 classification code and well-formed authority field show structural conformity.

They do not prove the sender's clearance, the label's truth, payload confidentiality, route protection or acceptance by the next interface. Those conclusions require protected assignment, trusted endpoints and intermediaries, configured ranges and evidence about the actual network.

Conversely, an absent label does not always mean Unclassified. On a port configured for implicit labelling, absence can acquire a locally specified level. A capture detached from interface policy therefore cannot recover the full security decision.

Type 130's durable lesson is not that security belongs in every IP header. It is that metadata removal is a semantic operation. When a packet field participates in mandatory-access control, stripping it without understanding the receiving environment can be more dangerous than carrying an unfamiliar option unchanged.

Sources and evidence limits

The closed evidence set is RFC 791, RFC 1038, RFC 1108, RFC 1122, RFC 1812, RFC 7126 and RFC 9293. They establish the changing formats, processing model, standards history and conditional filtering advice. They do not disclose classified deployments, measure current traffic, verify vendor compliance or establish the label on any observed packet as truthful.