Hi, all, After reading draft-gai-intarea-ip-tunnel-node-security-00 and reviewing the Abstract, I would like to share some thoughts regarding the document's categorization and its operational assumptions, specifically concerning the "Human Factor." 1. Abstract vs. Document Reality (Category Mismatch) The Abstract positions this as a "Security Requirement" for IP tunnel nodes. However, per RFC 2026 (BCP 9) and its updates (RFC 6410), the Standards Track is reserved for defining on-wire protocol behavior. Section 1.1 explicitly states it "does not define a new tunnel encapsulation and does not change the packet format," and Section 11 confirms "no IANA actions." Suggestion: Since the substance is operational configuration and telemetry guidance rather than a protocol specification, would it be more accurate to target BCP (Best Current Practice) or Informational status? Labeling a configuration checklist as a "Requirement" on the Standards Track may cause confusion regarding its enforceability and intent. 2. The Human Factor in Telemetry Design This is my primary concern regarding operational safety. Section 10 mandates logging human-readable fields such as outer peerand tunnel identifier, while Section 12 relies on a SHOULD-level advisory to treat this as sensitive. Suggestion: In real-world operations, these logs are processed by humans—for troubleshooting, SIEM analysis, and vendor support. Humans are the most unpredictable security boundary (prone to misdirection, accidental leaks via email/IM, and excessive permissions). Relying on "SHOULD handle as sensitive" places the burden entirely on human discipline. The standard should instead guide implementations toward using irreversible tokens or hashed identifiers rather than plaintext addresses. This removes the dependency on human consistency and prevents the standardization of a data exfiltration pipeline. 3. Scope Generalization and Trust Boundaries The Abstract implies a universal solution, yet Section 1.1 applies these rules to hosts, firewalls, CE/PE devices, and middleboxes simultaneously. Suggestion: These entities operate in vastly different trust boundaries. For example, "disable decapsulation by default" is a valid hardening measure for a border PE but would break functionality for a host stack. Applying uniform MUST/SHOULD statements across such heterogeneous devices will likely lead to selective deployment. I recommend narrowing the scope strictly to managed border/relay nodes. These are my personal suggestions for the working group's consideration. Regards, Cui Yong
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
