Repository navigation
Security Considerations: off-link basis erratum, inspection collapse, FHRP surface - #39
Closed
remcovanmook wants to merge 2 commits into
Closed
remcovanmook wants to merge 2 commits into
remcovanmook wants to merge 2 commits into
Conversation
The -01 text derived off-link unreachability from "Source=False in the IANA registry". The registry entry says Source=True, and always has, so the stated basis contradicted the table it cited. The correct basis is the forwarding prohibition in 5.3: the sentinel MUST NOT appear as source or destination in any forwarded packet, which confines it to the segment in both directions without any appeal to the Source field. Say why Source=True is right rather than leaving the reader to wonder: a first-hop router does legitimately originate interface-local ICMPv4 with the sentinel as source. What confines the address is that those messages are never forwarded. Flagged at the IETF 126 session. Closes #7 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two consequences the security section did not draw out. Inspection collapse: on a deployed segment the first-hop router is the only legitimate ARP responder and the sentinel the only address it answers for, so ARP inspection policy reduces to permitting replies from router ports alone. No snooping database and no per-host binding table are needed, because the policy never refers to host addresses. Host impersonation is not eliminated but relocated, entirely to ND, where RA Guard and ND inspection already apply: one protection stack for one resolution protocol, rather than parallel ARP and ND stacks kept consistent by hand. FHRP attack surface: where redundancy no longer needs a first-hop redundancy protocol, VRRP and HSRP spoofing and election manipulation do not become mitigated, they become impossible, because no election takes place. Stated with its condition attached, since an operator keeping conventional FHRP in front of the ARP tier keeps the surface too. Closes #18 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Owner
Author
|
Superseded by #42. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The two Security Considerations issues.
#7 - off-link property basis (erratum from -01)
The -01 text derived off-link unreachability from "Source=False in the IANA registry". The registry entry says Source=True, and always has, so the stated basis contradicted the table it cited in the same sentence.
The correct basis is the forwarding prohibition in 5.3 - the sentinel MUST NOT appear as source or destination in any forwarded packet - which confines it to the segment in both directions with no appeal to the Source field at all.
Rather than just deleting the wrong clause, the text now says why Source=True is right: a first-hop router does legitimately originate interface-local ICMPv4 with the sentinel as source. What confines the address is that no such message is ever forwarded. That should stop the same correction being proposed again by the next reviewer who checks the table against the prose.
No change to the IANA table, which was right all along.
#18 - inspection collapse and FHRP surface
Inspection collapse (added to 7.1): on a deployed segment the first-hop router is the only legitimate ARP responder, and the sentinel is the only address it answers for, so ARP inspection policy reduces to "permit ARP replies from router ports, deny elsewhere". That needs no snooping database and no per-host binding table, because the policy never refers to host addresses. Host impersonation is not eliminated but relocated - entirely to ND, where RA Guard and ND inspection already apply. One protection stack for one resolution protocol, instead of parallel ARP and ND stacks kept consistent by hand.
FHRP attack surface (new 7.2): where redundancy no longer needs an FHRP, VRRP/HSRP advertisement spoofing and election manipulation do not become mitigated - they become impossible, since no election takes place. Stated with its condition attached: an operator keeping conventional FHRP in front of the ARP tier keeps the surface for as long as it runs. Worth being explicit about, because this is the kind of claim that otherwise gets quoted without its precondition.
Closes #7, closes #18
🤖 Generated with Claude Code