Markdown Version | Session Recording

Session Date/Time: 03 Oct 2023 14:00

SCHC

Summary

The SCHC working group continued its discussion on the architecture document, focusing on the proposed SCHC header structure and its integration into various protocol layers, particularly IPv6. Key debates centered on the use of an IPv6 extension header versus an IP protocol number for SCHC encapsulation, the role and placement of checksums, and the need for a unified or layer-specific header format. The session also touched upon the length of the session ID and critical considerations for rule management and security.

Key Discussion Points

• SCHC Session Information Requirements:
  • Need to identify session endpoints (potentially application-level, not just IP/MAC addresses).
  • The SCHC header must convey endpoint information and distinguish between device and application roles.
  • A session ID is required to differentiate multiple sessions between the same pair of endpoints.
  • Information for session maintenance includes rule location (e.g., URL), proof of rule authenticity, and rule instantiation (e.g., dynamic updates for IP addresses).
  • Critical importance of synchronized rule states between endpoints.
• Proposed SCHC Header Structure (for IPv6 over IP):
  • Conceptually, the SCHC header should conform to an IPv6 Extension Header format in its uncompressed representation, including a Next Header field, Length, and a Checksum.
  • The SCHC checksum is intended to protect the SCHC header itself and all subsequent protocol data (e.g., ULP/TCP/UDP headers and payloads), allowing for the compression or omission of ULP-specific checksums.
  • A 2-byte Session ID was proposed for compatibility with UDP port numbers when SCHC is encapsulated over UDP.
• IPv6 Extension Header vs. IP Protocol Number Debate:
  • Using a new IPv6 Extension Header type was noted as architecturally cleaner for "inserting" SCHC before the ULP, but participants highlighted the IETF's general reluctance to define new IPv6 extension headers and the difficulty of obtaining an IANA number.
  • An alternative discussed was using a new IP Protocol Number, which would imply SCHC encapsulates the ULP, leading to a "protocol within a protocol" structure, perceived by some as less architecturally clean but potentially more feasible to register and pass through firewalls.
  • The need for both an "over IP" format (potentially as an extension header or new IP protocol) for efficiency and an "over UDP" format (using a specific UDP port for SCHC) for firewall traversal was acknowledged.
• Universal vs. Layer-Specific SCHC Header Formats:
  • While the abstract information needed for a SCHC session remains consistent, the concrete binary format of the SCHC header (before compression) may vary depending on the underlying layer (e.g., IPv6, Ethernet, PPP).
  • Layer-specific mechanisms (e.g., PPP session IDs) can implicitly provide information, potentially reducing the need to carry it explicitly in the SCHC header for that layer.
• Session ID Length:
  • The discussion explored fixed-length (e.g., 2 bytes for UDP port compatibility) versus variable-length Session IDs.
  • The idea of "universally unique" identifiers for session contexts, potentially allowing for longer IDs or well-known prefixes, was introduced.
• Rule Management and Security:
  • The importance of mechanisms for rule location, authentication, and bootstrapping was emphasized.
  • Concerns were raised regarding management of rules across different layers and how to manipulate rules securely, particularly in light of RFC 9363 (YANG data models) which suggests endpoints manage their own rules.
  • Potential attack vectors arising from rule manipulation or notification mechanisms require careful consideration.

Decisions and Action Items

• Pascal to update the SCHC architecture document to reflect the discussion points presented in the slides, aiming for a consistent draft for review.
• Pascal will initiate IANA requests for both an IPv6 Next Header/Extension Header type and a SCHC UDP port number, acknowledging the potential challenges with registering a new IPv6 extension header.
• Kirsten offered to provide references to historical IETF documents, particularly those related to ROHC discussions on IP protocol numbers, to inform the working group's approach.

Next Steps

• The working group will review the updated architecture document once published.
• Further detailed discussion on SCHC rule management, bootstrapping mechanisms, authentication, and the security implications of these processes is needed, potentially as a primary topic for the next interim meeting.
• Review of the historical IETF documents suggested by Kirsten for insights into past protocol number and extension header considerations.