Summary

  • RFC 5193 describes two materially different environments: the PaC-to-EP channel is already protected against spoofing and eavesdropping before PANA, or protection must be created after PANA. That classification changes the EAP-method assumptions and whether a secure-association protocol is required.
  • secure-before-PANA is therefore an attachment claim, not a durable property of a site, client or product. It needs evidence bound to the actual interface, lower-layer peer, EP path, protection scope and observation time. Mobility or failover must not inherit it without a new receipt.

The most consequential PANA decision can occur before the first PANA message. RFC 5193 allows PANA to operate in networks that already have a secure client-to-enforcement channel and in networks that do not. The two cases lead to different security work.

Where protection already exists, the framework says there is no need to execute a secure-association protocol after PANA. The PANA session can be associated with the channel that carried it, and the EAP-method choice can take that surrounding security into account. Where protection does not exist, PANA runs over a channel exposed to spoofing and eavesdropping. The selected EAP method must withstand those conditions and generate cryptographic keys for a later secure-association protocol.

That is not a cosmetic deployment flag. It is a branch that can remove an entire control from the future call flow.

The environment is a fact about this attachment

RFC 5193 characterizes a pre-existing secure channel by its protection against spoofing and eavesdropping. It offers two different examples. A DSL attachment may rely on physical wiring that practically limits the link to one client. A radio system may already have authenticated and authorized the client for the channel and enabled link-layer ciphering.

Those examples do not create a universal link_secure=true. Physical isolation and cryptographic peer protection are different mechanisms with different scopes. Both are claims about a concrete route between the PaC and EP, not about a model number in an asset database.

An operational receipt should therefore name the attachment: interface, link or segment, lower-layer peer where one exists, enforcement path, protection mechanism, state, scope and observation time. If the evidence is physical, say what is physically isolated. If it is cryptographic, say which peer was authenticated and which integrity or confidentiality property was observed. Unknown is not secure.

The profile that consumed that receipt also belongs in the record. Otherwise an investigator may prove the link was open without being able to prove why the client nevertheless selected a method intended for a protected channel.

Movement invalidates inherited protection

Mobility exposes the weakness of site-level classification. A client can retain an identity, address, session label or device posture while moving to an attachment whose security properties are entirely different. A failover path can change the EP. A switch reconfiguration can turn a point-to-point circuit into a shared segment. A radio reassociation can change the lower-layer peer.

RFC 5193 does not define a telemetry refresh algorithm for these changes. That absence does not make inheritance safe. The framework's dependency is enough: the environment choice controls the EAP and secure-association requirements. If the attachment changes, the input to that choice has changed.

Automation should therefore version the environment decision separately from the PANA session. An old decision may remain valuable evidence of what was believed on the previous link, but it cannot silently authorize the next one. The new attachment must either produce a qualifying secure-channel receipt or enter the secure-after branch.

Cancellation matters too. If a secure-association task was required on the old path and the client moves, the workflow should not report its later completion as protection for the new path. Task, attachment and EP identities must match.

Capability is not activation

A platform can support link encryption, IKE and IPsec while a particular attachment uses none of them. A switch can support port isolation while an operator has disabled it. A radio controller can advertise a cipher suite while the observed association belongs to another peer. Capability is inventory. Activation is configuration. Negotiation is an event. Protection is an observed state.

Collapsing those layers makes audits look stronger than the network. “IPsec capable” becomes “IPsec enabled”; “profile requires ciphering” becomes “this packet path is ciphered”; “PAA and EP are on one appliance” becomes “the client channel is secure”. None of those inferences is supplied by RFC 5193.

Colocation shortens an internal interface. When PAA and EP reside on the same node, an API can replace a network protocol between them. It says nothing about whether the PaC-facing link resists spoofing or eavesdropping. The control-plane distance inside the appliance is not the security boundary outside it.

Method selection records the consequence

In the secure-after environment, RFC 5193 requires an EAP method resilient to attacks on the insecure channel and able to create keys for the later secure-association protocol. The framework does not make every EAP method equivalent. Nor does it make key generation useful merely because key material exists somewhere.

The decision record needs the chosen method, the environment profile that permitted it, whether the method produced the required key material, and the secure-association requirement derived from that result. If a method without the needed output was chosen because an inherited profile declared the channel already secure, the failure began at classification, not at key installation.

Conversely, a key-generating method does not prove that a secure association was created. It establishes an input. The later protocol, its peer binding and its resulting security association remain separate evidence. This Article stops at that handoff; the retained RFC 5191 Article owns the later distinction between authentication, enforcement and data-plane outcome.

A defensible environment receipt

For each attachment, retain the client and interface identity, link or segment identity, lower-layer peer, intended EP, evidence mechanism, anti-spoofing scope, anti-eavesdropping scope, authentication or physical-isolation basis, observation time and freshness. Record the policy version that classified it and the operator or system responsible for the assertion.

Then retain the consequences: selected EAP method, resilience assumptions, key-generation expectation, whether a post-PANA secure association is required, the chosen link- or network-layer family, and the identity of any scheduled task. Every later receipt must point back to the same attachment version.

The evidence may honestly say that a property is unknown. That result is operationally useful because it prevents a symbolic label from silently removing controls. A system that cannot prove secure-before can choose the secure-after branch, close the attachment or request review according to local policy. RFC 5193 does not choose among those actions; the deployment must.

Heng Lu's reality-layer discipline supplies the governing restraint. A profile can describe a channel. It cannot create one. Running protection has authority over the profile precisely because the profile exists to describe running reality.

Sources

  1. RFC 5193 HTML
  2. RFC 5193 text
  3. RFC 5193 record
  4. IETF Datatracker RFC 5193
  5. RFC 5193 history
  6. RFC 5193 references
  7. RFC 5193 errata
  8. RFC 5191
  9. RFC 5191 record
  10. RFC 4058
  11. RFC 4058 record
  12. RFC 4016
  13. RFC 3748
  14. RFC 4306
  15. RFC 2409
  16. RFC 2865
  17. RFC 3588
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy