題幹與適用情境
面試官給出某個前綴被錯誤 AS 宣告的情境，要求你說明如何判斷這個宣告是否得到位址持有者授權。請圍繞 RPKI、Route Origin Authorization（ROA）和 BGP Prefix Origin Validation（ROV）回答，並明確指出它只驗證起源 AS，不等同於驗證整條 AS_PATH。題目適合網路、CDN、雲端平台與基礎設施職位。
面試官考察什麼
高品質回答會從「誰被授權宣告哪個前綴」開始，而不是把 RPKI 說成替 BGP 加密。候選人應能解釋快取中的 VRP 如何與 BGP 路由前綴和起源 AS 比對，得到 Valid、Invalid 或 NotFound；也要說明策略如何使用狀態、快取不一致為何存在，以及過濾 Invalid 可能造成誤傷。只說「啟用 RPKI 就能防止所有劫持」會顯示界線意識不足。
回答前要釐清的問題
- 目標是保護前綴起源，還是驗證整條 AS_PATH？ROV 只回答前者。
- 討論的是建立 ROA、路由器驗證，還是入站策略過濾？三者是不同控制點。
- 網路是否有冗餘 ROA 快取和明確的失聯策略？快取不可用時不能把所有路由突然判為 Invalid。
- 業務優先保證安全、可達性還是回滾速度？嚴格過濾要配合變更窗口和監控。
30 秒回答框架
「我會先讓前綴持有者發布 ROA，宣告某個 AS 可以起源該前綴以及允許的最大長度。驗證器把簽名物件處理成 VRP，BGP speaker 用路由前綴和 AS_PATH 最右側起源 AS 比對：有覆蓋且匹配為 Valid，有覆蓋但不匹配為 Invalid，沒有覆蓋為 NotFound。路由策略可以拒絕 Invalid、對 NotFound 維持現狀，但這只保護起源，不驗證中間 AS。上線前我會檢查 ROA 覆蓋、快取新鮮度、變更回滾和觀測指標，因為分散式快取會短暫不一致。」
分步深入分析
- 定義授權物件。 ROA 是簽名物件，綁定 IP 前綴、最大前綴長度和允許的 origin AS；它表達「誰可以起源哪些前綴」，不是替所有 BGP 屬性簽名。
- 準備驗證資料。 RPKI 依賴資源憑證、簽名物件和分散式儲存庫。驗證器週期性取得並驗證物件，形成本地 VRP；BGP speaker 使用本地快取，不會在每條路由上執行完整憑證驗證。
- 計算三種狀態。 若 VRP 覆蓋路由前綴且 origin AS 與 VRP 匹配，狀態是 Valid；有覆蓋但沒有匹配，狀態是 Invalid；沒有任何 VRP 覆蓋，狀態是 NotFound。前綴更具體時仍須檢查最大長度。
- 接入路由策略。 在入站策略中比對驗證狀態，常見做法是拒絕 Invalid、記錄或降低 NotFound 的信任度、接受 Valid。策略必須可回滾，避免誤發 ROA 或快取異常造成大範圍不可達。
- 說明快取界線。 RFC 6811 明確指出全球 RPKI 是鬆散一致的分散式視圖；不同快取因更新時間不同可能暫時看到不同資料。監控 VRP 時間戳、快取連線和狀態分布，不要把一次路由告警直接歸因於攻擊。
- 解釋保護範圍。 ROV 能緩解錯誤起源和部分劫持，NIST 將它定位為降低相關錯誤設定和惡意攻擊的標準化平台。它不證明 AS_PATH 中間節點誠實，也不能單獨阻止所有 route leak。
- 設計上線驗證。 先在觀測模式統計 Invalid/NotFound，再對少量鄰居啟用過濾；變更前核對 ROA 最大長度、冗餘前綴和回滾指令。上線後同時看可達性、Invalid 數量、快取健康和告警延遲。
高品質範例答案
「我會把問題拆成授權、驗證和策略。前綴持有者發布 ROA，宣告允許的 origin AS 與最大前綴長度。RPKI 驗證器驗證簽名物件並產生 VRP，BGP speaker 再把收到的路由前綴和 ASPATH 的 origin AS 比對：覆蓋且匹配是 Valid，覆蓋但不匹配是 Invalid，沒有覆蓋是 NotFound。路由器可以拒絕 Invalid，對 NotFound 採用記錄或較低優先級，但這不等於驗證整條 ASPATH，也不能解決所有 route leak。上線前我會先觀測，核對 ROA 覆蓋和最大長度，監控快取新鮮度與可達性，再逐步啟用過濾並保留回滾。」
常見錯誤與改進
- 錯誤表現 →「RPKI 會驗證整條 AS_PATH。」失敗原因 → RFC 6811 的狀態只比較前綴覆蓋和起源 AS。修正方法 → 明確 ROV 是 origin validation，路徑完整性需要其他機制和策略。
- 錯誤表現 →「沒有 ROA 就一定是惡意路由。」失敗原因 → NotFound 只表示沒有覆蓋資料，不能推出錯誤。修正方法 → 把 NotFound 與 Invalid 分開處理。
- 錯誤表現 →「快取斷線就把所有路由標成 Invalid。」失敗原因 → 分散式快取可能暫時不可用或資料過期，突變過濾會擴大故障。修正方法 → 說明快取健康檢查、凍結舊資料和可回滾策略。
- 錯誤表現 →「ROA 最大長度隨便填。」失敗原因 → 過短會使合法更具體前綴變 Invalid，過長會擴大授權範圍。修正方法 → 依實際公告集合核對 maxLength。
追問
路由沒有 ROA 時為什麼不是 Invalid？
只有存在覆蓋該前綴的 VRP、但 origin AS 沒有匹配時才是 Invalid。沒有任何覆蓋資料是 NotFound；營運策略可以單獨決定如何處理，不能把缺少證據當成反證。
ROA 發布錯誤會發生什麼？
合法路由可能被判為 Invalid，嚴格過濾的鄰居會拒絕它。先撤銷或修正 ROA，再等待儲存庫和快取更新；部署應監控狀態變化並準備臨時放寬策略的回滾路徑。
RPKI 能阻止 route leak 嗎？
不一定。ROV 檢查起源 AS 是否獲授權，合法起源 AS 仍可能把前綴傳播到不應到達的鄰居。還需要前綴過濾、鄰居角色和輸出策略等控制來降低洩漏風險。
你會如何驗證過濾上線沒有誤傷？
先以記錄模式比較 Valid、Invalid、NotFound 與實際路由表，抽樣核對 ROA 和 maxLength；再分批啟用拒絕規則，觀察可達性探針、快取健康、鄰居會話和 Invalid 數量，異常時回滾到上一版策略。