要約

  • 9月29日付の draft-ietf-schc-schclet-01 は、前版で「TBD」だけだった安全性の節に、RFC 8724などの安全上の考慮を引き継ぐことと、対応するRuleがない入力を設定に従って安全に扱うことを書き加えた。
  • SCHCletという部分実装の考え方や、対応設定の明示、完全実装との条件付き相互運用性は第00版からある。第01版もなお I-D Exists のInternet-Draftであり、承認済みRFCでも導入実績の報告でもない。

Static Context Header Compressionの全機能を小型機器に載せる必要がない場合、特定の圧縮や断片化だけを切り出す設計には意味がある。SCHClet草案は当初から、その機能単位を一つのStratum、一つのSCHC Instanceで用いるものとして説明していた。個々のSCHCletを定義する文書には対応する設定を示す義務があり、完全実装とのやり取りには設定と解釈の一致が要る。この既存部分を今回の新機能と混同すべきではない。

今回変わったのは第6節である。1月の第00版には安全性の検討が残されていただけだが、第01版はRFC 8724と利用する他のSCHC仕様の安全上の考慮を継承すると明記した。さらに、対応するRuleに合致しない入力の安全な扱いを求め、拒否と通過を設定次第の例として挙げる。全実装に通用する一つの既定動作や試験結果、現場での動作を示したわけではない。

そこで問うべきは「SCHC対応か」ではなく「どこまで対応し、その外側をどう扱うか」だ。部分実装と完全実装が通信できるという草案の記述は条件付きである。Ruleの一覧、入力の種類、判断が行われる処理段階、選んだ動作、相手側の設定が異なれば、同じ技術名だけでは故障時の経路を説明できない。相互運用性は機器ごとの検証対象であって、草案の形容詞から自動的に生じる属性ではない。

「通過」の例にも注意が要る。RFC 8724の12.1.1節は、未割当てRuleIDを持つ偽造SCHCパケットが伸長側に来た場合、黙って破棄すべきだと述べる。部分実装がサポートしないRuleに合わない入力は、別種の入力や別の処理段階を指す可能性がある。第01版だけを根拠に偽造パケットの転送が許されたと読むことも、仕様間の矛盾が確定したと断じることもできない。まず入力の種類と経路を特定する必要がある。

空欄が埋まったことの意義は、責任の置き場所が検査できるようになった点にある。Daniel Kadeの編集上の提案は、対応Rule、入力区分、拒否・通過の設定、相手の設定、ソフトウェア版数、試験結果を一組の記録として残すことだ。これはIETFが新たに採択した要件ではない。規範語の説明と参考文献の整理も加わったが、直ちにIANAの登録を変える要求はない。事故、脆弱性の悪用、最終審査の完了を示す資料もない。

出典