要約

  • RFC 5153は2008年のInformational実装ガイドであり、参照先のRFC 5101とRFC 5102は後にRFC 7011とRFC 7012に置き換えられた。
  • IPFIX Data Recordは値を運び、Templateがその順序、長さ、型と意味を与える。
  • 対応するTemplateがなければ、Set IDが正しくてもCollectorはData Recordを解釈できない。
  • Collectorは未知のTemplate IDを持つData Setsを待機させられるが、受信済みバイトはまだ利用可能なFlow recordではない。
  • RFC 5153は設定可能な待機と30分の既定値を勧め、Templateが来なければログと破棄、SCTP/TCPではsession resetも勧める。
  • 30分は歴史的な推奨値であり、現在の全実装に共通する必須値ではない。
  • Template IDの一意性はTransport SessionとObservation Domainの組に限られ、同じ数字が別の定義を持てる。
  • Collectorは以前のTransport Sessionで得たTemplateを次のSessionのData Setに使ってはならない。
  • SCTPの複数streamはData、Template、Withdrawalの全体順序を自動的には作らない。
  • UDPではTemplate Withdrawalが使えず、refresh、expiry、遅延reuseで世代を管理する。
  • 遅れて届いたTemplateが別世代なら、失敗ではなくもっともらしい誤decodeが生まれ得る。
  • 監査には認証相手、Session、Observation Domain、Template定義hash、世代境界、Data範囲、decodeとapplication受領が必要である。

256という数字は定義ではない

IPFIXはTemplate IDをData SetのSet IDとして使う。小さな数字で何度も同じ構造を参照できるため、各Data Recordに型や長さを繰り返す必要がない。効率は高いが、その数字は自己記述的ではない。

RFC 7011はTemplate IDの一意性をTransport SessionとObservation Domainの内部に限定する。同じSessionでも、二つのObservation Domainが同じ番号を異なるTemplateに使ってよい。割り当て順に制約はなく、Collectorは番号から内容を推測してはならない。

したがって、グローバルな表で「256 → フィールド列」と保存する設計は、プロトコルが分離した権威を統合してしまう。実際のkeyは少なくともExporter/Session、Observation Domain、Template ID、定義世代を含む。

Session終了はTemplateの権威終了でもある

SCTP associationまたはTCP connectionが終わると、そのSessionで使われたTemplateは暗黙にwithdrawされる。次のSessionではTemplateを再送し、新しい文脈を作る必要がある。

同じExporterが接続し直し、同じ番号を使ったとしても、以前の定義を持ち越せない。RFC 7011は、あるTransport SessionのTemplateで後続SessionのData Setsをdecodeすることを禁止している。

接続再開を「同じ装置が戻っただけ」と扱うと、古い意味が新しいバイトへ侵入する。endpoint identityは連続していても、Template authorityはSession境界で切れている。

Dataが先に届けば、意味は保留される

Exporterは関連Data Setsより先にTemplateを送るよう努める。しかしreordering、loss、Collector restartなどで順序は崩れる。Collectorは未知TemplateのDataをbufferして待てる。

RFC 5153は待機を設定可能にし、既定値30分を勧める。Templateが現れなければeventを記録してData Recordsを破棄し、SCTPとTCPではTransport Session resetも勧める。

buffer中のバイトは、欠損でも完成recordでもない。正しい状態名は「意味待ち」である。この状態を受信成功へ丸めると、後のdashboardは観測があったのか、解釈できなかったのかを区別できない。

待つほど回復しやすく、世代を誤りやすい

待機を長くすればlate Templateを回収できる可能性が増す。代わりにmemory使用量が増え、withdrawal、redefinition、expiry、ID reuseをまたぐDataが増える。

RFC 7011は、Template withdrawalと再定義がある状況で未知TemplateのDataをbufferすると、誤った解釈につながり得ると警告する。後から同じ番号のTemplateを見つけるだけでは不十分である。

Collectorは、その定義が当該Dataの生成時点に同じSessionとDomainで有効だったことを証明しなければならない。明示的な失敗より危険なのは、別世代を使って正常なfield列が生成されることだ。

SCTPのreliable messageは全streamの順番を証明しない

SCTPは複数streamを使い、head-of-line blockingを減らせる。IPFIX Exporterはどの種類のSetもどのstreamにも送れる。Collectorはすべてを処理できなければならないが、streamの用途はprotocol内で通知されず、out-of-bandで調整される。

Template Set、Data Set、Template Withdrawalが別streamにあれば、各messageが可靠に届いても一つのglobal orderは自動的に得られない。あるstreamのWithdrawalが、別streamで送られたTemplateを失効させることもある。

RFC 5153はwithdraw後のID再利用までおよそ1分待つことを勧める。RFC 7011は管理actionのsequencingをさらに定める。どちらもmessage receiptとsemantic orderを分離している。

UDPでは撤回できず、期限で意味を交代させる

UDP上ではTemplate Withdrawalを送ってはならない。Exporterはactive Templateを定期的に再送し、Collectorはrefreshされない定義を期限で捨てる。ID reuseは十分な遅延後に新Templateを送ることで進む。

RFC 5153は時間based refreshを10分、packet-based refreshを20 data packetsとする既定値を勧め、それぞれ広い設定範囲を示す。さらにexpiryをrefreshの3倍、帯域外設定がなければ初期60分とする案を出す。

RFC 7011は現在のprotocol境界を明確化し、defaultはdeploymentとapplication固有とする。3倍のobserved retransmission rateという関係は残る。重要なのは古い数字を守ることではなく、refresh、expiry、buffer deadline、reuse delayを同じモデルで整合させることだ。

refreshを増やせばよいとは限らない

RFC 5153はpacket intervalが短すぎる場合の自己阻害を説明する。すべてのTemplatesやOptions Dataを送り終える前にintervalが満了すると、Exporterはまた最初からcontrol materialを送り続け、Dataを送れなくなる可能性がある。

Template availabilityは改善し、Data availabilityは悪化する。片方のmetricだけなら成功に見える。運用はTemplate rate、Data rate、Sequence gap、unknown buffer、decode rateを同時に見る必要がある。

保護mechanismが対象を進めたかを確認しなければ、実行回数は成果ではない。これはRFC 5153の実装上の注意を超えて、control plane全般に通じる証拠規律である。

TCPの順序もCollectorの記憶を代替しない

TCPは一つのordered byte streamを提供する。しかしExporterはconnection中にTemplateを再送する義務がない。Collectorはconnectionの期間、Template stateを保持する必要がある。

Collectorが再起動またはstate lossを起こし、TCP自体は継続しているなら、その後のDataはtransport上正しくてもdecodeできない。逆に古いstateを誤って新connectionへ持ち越せば、decodeできるように見えてauthorityがない。

session resetは新しいcontextを作る回復actionであり、失われたrecordを復元しない。正常接続という表示と、解釈可能recordという表示は別にすべきである。

認証は名前空間を一つにしない

TLSまたはDTLSのmutual authenticationは、どのendpointがSessionを開いたかを制約し、Flow情報を盗聴や改変から保護する。内部topology、firewall drop、address translationを含む場合に重要である。

認証されたExporterでも複数Observation Domainを持ち、Sessionを再開し、IDを再利用する。正しい相手であることは、同じ数字が常に同じ定義だという保証にならない。

監査はcertificate/session receiptとTemplate namespace receiptを分離しなければならない。組織へのtrustを、software内の一時的番号すべてへの無制限trustへ拡張してはならない。

decode完了はネットワーク結果の完了ではない

正しいTemplateでField Valuesを解釈できれば、Exporterのassertionは構造化される。しかしObservation Point、Flow key、sampling、aggregation、clock、counter reset、middlebox前後の位置が、そのassertionの範囲を決める。

Sequence Numberはlossやreorderingの兆候を示せるが、失われたTemplateやpacketを再構成しない。Flow recordが「forwarded」と読めても、利用者への到達やapplication outcomeを独立に証明したことにはならない。

証拠chainはtransport receipt、namespace内のTemplate generation、decode、application ingestion、実際のservice observationを別々に結ぶ必要がある。

出典

  1. RFC 5153 HTML
  2. RFC 5153 text
  3. RFC Editor record
  4. IETF Datatracker record
  5. RFC 5153 history
  6. RFC 5153 references
  7. RFC 5153 errata
  8. RFC 5101
  9. RFC 5102
  10. RFC 7011
  11. RFC 7012
  12. RFC 3917
  13. RFC 5470
  14. RFC 5471
  15. RFC 5473
  16. RFC 4960
  17. RFC 3758
  18. RFC 8085
  19. RFC 4346
  20. RFC 4347
  21. RFC 8446
  22. RFC 9147
  23. RFC 3954
  24. IANA IPFIX registry
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy