要約

  • RFC 5345は、capture hostのchecksum offloadが実際のwire上では正常なpacketを異常に見せる場合を明記する。無効判定には、capture位置、NIC設定、補正方針、IP再構成、parser versionという別々の証拠が必要である。
  • raw pcap、詳細なXML、選択的なCSV、filter/anonymization、analysisは同じものではない。CSVはSNMPv1 trapの理解に必要な情報を保持せず、匿名化は分析可能性とprivacyの双方を変える。format namespaceやerror-statusだけで完全性・権限・結果を証明できない。

パケットは二つの時点を通った

アプリケーションはSNMPメッセージを作り、OSはtransport headerを準備し、NICが一部の処理を引き受ける。capture toolがNIC処理前のbufferを読むと、checksum欄は未完成に見える。

その後wireへ出たpacketには正しい値が入るかもしれない。したがってcapture内の不正checksumと、相手が受信した不正packetは別の主張である。

RFC 5345は、可能ならoffloadを止めること、あるいは後段の変換でchecksumを補正または無視することを挙げる。三つの運用は同じ結果を出すとは限らない。

補正を行ったなら、元値と規則を残す必要がある。無視したなら、検証しなかったことを残す必要がある。offloadを止めたなら、capture性能やdropへの影響も確認する必要がある。

「bad checksum」という一列だけでは、wire、host、NIC、capture、converterのどこに原因があったか判定できない。

fragmentはparserの外で消える

SNMPメッセージがIP fragmentationを受けた場合、上位の解釈にはreassemblyが必要になる。ひとつのfragmentを見失えば、完全なmessageは構成できない。

この失敗をagentのprotocol errorと数えるのは誤りである。probe loss、filter、時間切れ、overlap処理、reassembly実装など、別の原因がある。

逆に、誤ったreassemblyが存在しなかったPDUを作る可能性もある。parserがXMLを生成できたことは、元のpacket集合が正しく再構成された証明ではない。

再現可能なpipelineは、fragment数、欠落、重複、拒否理由、reassembly policy、tool versionを保持する。後からRFCや実装知識が変わったとき、同じ判断を検証できるからだ。

probeが見ないVLANは統計に現れない

captureの前提はchecksumより早い段階にある。RFC 5345は、bridged LANではmanagement trafficを運ぶ全VLANにprobeが届くことを確認し、bridgeのmonitoring制約を調べて記録するよう求める。

mirror portが片方向だけ、容量不足、特定VLAN除外なら、traceは構造的に欠ける。ゼロ件は「起きなかった」ではなく「この観測面には届かなかった可能性を含む」。

filter expressionもpopulationを決める。UDP 161/162は典型例であり、将来や特定環境の全transportを保証しない。暗号化transportやproxy経路が別の場所を通れば、同じserviceの一部だけが見える。

snap lengthが短い場合、headerは数えられてもvalueが切れる。高負荷時のdropは、負荷を測るべき瞬間ほど多くなる。この自己選択性を隠して平均だけ出してはいけない。

一週間は完全な時間ではない

文書は日内変動と週周期を見るため、少なくとも一週間のcaptureを推奨する。長期間も奨励する。

これは「一週間で十分」という認証ではない。月次作業、障害対応、年次棚卸し、稀なtrap、移行作業はwindow外になり得る。

trace metadataには採取場所、時期、規模、特別イベント、故障、主要変更を含めるべきだとRFCは述べる。グラフの形をネットワーク習慣と呼ぶには、その期間の出来事が必要である。

さらにcapture timestampとdevice状態の時刻は同じとは限らない。内部instrumentationがadaptiveに更新されるなら、読み取った瞬間に物理値が更新された証拠はない。

raw pcapは変換をやり直す権利

RFC 5345はraw pcapを長期保存し、tool bugの発見後に元へ戻れるよう勧める。XML/CSVだけを残すと、変換で失われたfieldや誤解釈を修復できない。

pcapはこのchainで最もauthenticな情報源とされる。ただしprobeが見たbyteに対してである。見えないVLAN、drop、window外、filter外は含まれない。

rawにはcommunity string、user、address、object value、topologyが含まれ得る。暗号化保管、access control、保持期限が必要であり、法令やoperator保護のため削除が正当な場合もある。

削除後にderived dataがrawと同等になるわけではない。どの再検証が不可能になったかを記録して初めて、privacy決定と証拠責任が両立する。

XMLは詳細、CSVは選択

XML representationはSNMPv1/v2c/v3を表せ、messageの関連詳細と一部のASN.1/BER lengthを保持する。namespaceはurn:ietf:params:xml:ns:snmp-trace-1.0である。

CSVは処理速度とcompactさのため選択されたfieldのみを保持する。request/response結合やoperation集計には使えるが、SNMPv1 trapを理解する情報は残さない。

RFC 3584に従ってtrapを新しい形式へ変換できるが、実行はuser choiceである。変換後のrecordは比較しやすくなる一方、original representationではない。

同じdatasetにnative trapとconverted trapが混在するなら、conversion flagと規則が必要になる。そうでなければformat policyの違いがdevice behaviorに見える。

IANA namespace登録は語彙衝突を避けるcoordinateであり、fileの完全性、parser correctness、deployment、研究結果を認証しない。

anonymizationは分析構造も変える

SNMP traceはauthentication情報、table index、address、valueを含む。capture pointのmetadataだけでも攻撃対象の位置を推定できる。

RFC 5345のfilter-in原則は、typeと適切な変換が分かるvalueだけ残す。未知のoctetを安全と仮定しない。

table indexのlexicographic orderを残す変換は分析に便利だが、通常は匿名化強度が低い。order、prefix、repeatがcorrelationの手掛かりになる。

anonymization runごとのkeyも重要である。別々に処理したtraceのpseudonymは同じnamespaceとは限らない。単純joinは偽の同一性を作る。

privacy reviewは「読めない」だけでなく、どの不変量が残り、外部dataと結合できるかを評価しなければならない。

counterの差にはepochがある

Counter32やCounter64の二値からrateを計算するには、同じ連続期間に属する証拠が必要である。reset、wrap、interface再生成、instrumentation変更は連続性を切る。

RFC 5345はsysUpTimeやifCounterDiscontinuityTimeを挙げる。これらを捨ててvalueだけ保持すると、正確な応答から誤ったrateが生まれる。

agent内部のcounter更新が周期的でもon-demandでもない場合、response timestampはmeasurement freshnessを保証しない。

error-status 0も同様である。protocol responseが成功したことと、設定が永続化したこと、actuatorが動いたこと、human authorityがあったことは別々のreceiptだ。

Informational RFCを認証markにしない

RFC 5345はIRTF NMRGのInformational文書である。IESG noteはInternet Standard候補ではなく、IETFがfitnessを保証しないと述べる。

IANAによるXML URI登録もformat nameのcoordinationにすぎない。現在の採用率、operator conformance、file validity、privacy adequacyを示さない。

文書から言えるのは方法と形式である。deploymentには実装・設定・生成fileが必要で、operational outcomeにはnetwork側の別証拠が必要になる。

有効な結論はchainを短縮しない

必要なreceiptは次の通りである。

  1. 対象populationと質問；
  2. probe位置・interface・VLAN；
  3. filter・snap length・drop・window；
  4. raw pcap hashと保持；
  5. checksum/reassembly policy；
  6. converterとschema；
  7. filter/anonymization；
  8. analysis code；
  9. denominator・uncertainty；
  10. physical stateやauthorityの独立確認。

checksumが壊れて見えた理由を切り分けられるのは、このchainが残っているからである。ひとつの「clean data」badgeでは代替できない。

情報源