सामान्य साक्षात्कार: आप RPKI और BGP रूट ओरिजिन वैलिडेशन को कैसे समझाएंगे?

प्रॉम्प्ट और लागू संदर्भ

एक साक्षात्कारकर्ता गलत AS द्वारा घोषित (announced) एक प्रीफिक्स का विवरण देता है और पूछता है कि आप यह कैसे निर्धारित करेंगे कि वह घोषणा एड्रेस धारक द्वारा अधिकृत है या नहीं। RPKI, Route Origin Authorizations (ROAs), और BGP Prefix Origin Validation (ROV) को समझाएं, साथ ही यह स्पष्ट करें कि ROV पूरे AS_PATH के बजाय ओरिजिन AS को मान्य (validate) करता है। यह नेटवर्किंग, CDN, क्लाउड-प्लेटफ़ॉर्म और इन्फ्रास्ट्रक्चर भूमिकाओं के लिए उपयुक्त है।

साक्षात्कारकर्ता क्या परख रहा है

एक सशक्त उत्तर RPKI को "एन्क्रिप्टेड BGP" कहने के बजाय "कौन सा AS किस प्रीफिक्स को ओरिजिनेट करने के लिए अधिकृत है" से शुरू होता है। उम्मीदवार को यह समझाना चाहिए कि Valid, Invalid, या NotFound स्थिति उत्पन्न करने के लिए VRPs की तुलना BGP रूट प्रीफिक्स और ओरिजिन AS से कैसे की जाती है; नीतियां (policies) उन स्थितियों का उपयोग कैसे करती हैं; कैश में भिन्नता क्यों हो सकती है; और Invalid को फ़िल्टर करने से अभी भी अप्रत्याशित नुकसान (collateral damage) क्यों हो सकता है। "RPKI हर हाईजैक को रोकता है" यह दर्शाता है कि उम्मीदवार इसकी सीमाओं को समझने से चूक गया है।

पहले स्पष्ट करने योग्य प्रश्न

• क्या हम प्रीफिक्स ओरिजिन की सुरक्षा कर रहे हैं या संपूर्ण AS_PATH को मान्य कर रहे हैं? ROV केवल पहले वाले का उत्तर देता है।
• क्या हम ROA पब्लिकेशन, राउटर वैलिडेशन, या इनबाउंड पॉलिसी फ़िल्टरिंग पर चर्चा कर रहे हैं? ये अलग-अलग नियंत्रण बिंदु (control points) हैं।
• क्या हमारे पास रिडंडेंट ROA कैश और स्पष्ट कैश-आउटेज नीति है? कैश आउटेज के कारण अचानक हर रूट Invalid नहीं हो जाना चाहिए।
• क्या प्राथमिकता सुरक्षा, रीचेबिलिटी (reachability), या रोलबैक गति है? सख्त फ़िल्टरिंग के लिए चेंज विंडो और ऑब्ज़र्वेबिलिटी की आवश्यकता होती है।

30-सेकंड का उत्तर

"मैं प्रीफिक्स धारक से एक ओरिजिन AS और एक अधिकतम प्रीफिक्स लंबाई (maximum prefix length) को अधिकृत करने वाला ROA प्रकाशित करवाऊंगा। एक वैलिडेटर हस्ताक्षरित ऑब्जेक्ट्स को VRPs में प्रोसेस करता है, और एक BGP स्पीकर ASPATH के दाईं ओर स्थित ओरिजिन AS और रूट प्रीफिक्स की तुलना करता है: कवर करने और मेल खाने पर Valid, कवर करने लेकिन मेल न खाने पर Invalid, और कोई कवरिंग VRP न होने पर NotFound होता है। पॉलिसी Invalid को अस्वीकार कर सकती है और NotFound को अलग से संभाल सकती है, लेकिन यह ओरिजिन की सुरक्षा करता है, न कि प्रत्येक ASPATH हॉप की। रोलआउट से पहले मैं ROA कवरेज, कैश की ताज़गी, रोलबैक और रीचेबिलिटी की जाँच करूँगा क्योंकि एक डिस्ट्रीब्यूटेड कैश अस्थायी रूप से असंगत हो सकता है।"

चरण-दर-चरण विस्तृत उत्तर

1. प्राधिकरण (authorization) को परिभाषित करें। ROA एक हस्ताक्षरित ऑब्जेक्ट है जो एक IP प्रीफिक्स, एक अधिकतम प्रीफिक्स लंबाई और एक अधिकृत ओरिजिन AS को बांधता है। यह बताता है कि कौन किस प्रीफिक्स को ओरिजिनेट कर सकता है; यह हर BGP एट्रिब्यूट पर हस्ताक्षर नहीं करता है।
2. वैलिडेशन डेटा का निर्माण करें। RPKI रिसोर्स सर्टिफिकेट्स, हस्ताक्षरित ऑब्जेक्ट्स और डिस्ट्रीब्यूटेड रिपॉजिटरीज़ पर निर्भर करता है। वैलिडेटर्स स्थानीय VRPs बनाने के लिए समय-समय पर उन्हें लाते (fetch) और सत्यापित करते हैं; BGP स्पीकर्स प्रत्येक रूट के लिए पूर्ण सर्टिफिकेट वैलिडेशन करने के बजाय एक स्थानीय कैश का उपयोग करते हैं।
3. तीन स्थितियों की गणना करें। एक रूट तब Valid होता है जब कोई VRP उसके प्रीफिक्स को कवर करता है और उसके ओरिजिन AS से मेल खाता है; Invalid तब होता है जब एक कवरिंग VRP मौजूद होता है लेकिन कोई भी मेल नहीं खाता; और NotFound तब होता है जब कोई भी VRP प्रीफिक्स को कवर नहीं करता है। अधिक-विशिष्ट (more-specific) रूट को भी ROA की अधिकतम लंबाई को पूरा करना होगा।
4. पॉलिसी को कनेक्ट करें। एक इनबाउंड पॉलिसी स्थिति से मेल खा सकती है: आमतौर पर Invalid को अस्वीकार करना, NotFound के लिए लॉग करना या ट्रस्ट कम करना, और Valid को स्वीकार करना। पॉलिसी को प्रतिवर्ती (reversible) रखें ताकि गलत ROA या कैश समस्या से बड़ा आउटेज न हो।
5. कैश की सीमा बताएं। RFC 6811 वैश्विक RPKI को एक शिथिल सुसंगत (loosely consistent) डिस्ट्रीब्यूटेड व्यू के रूप में वर्णित करता है; कैश अलग-अलग समय पर रीफ़्रेश होने के कारण अस्थायी रूप से भिन्न हो सकते हैं। किसी एक रूट अलर्ट को तुरंत हमला करार देने के बजाय VRP टाइमस्टैम्प, कैश सेशन और स्थिति वितरण की निगरानी करें।
6. सुरक्षा सीमा की व्याख्या करें। ROV गलत ओरिजिन और कुछ हाईजैक्स को कम कर सकता है; NIST इसे संबंधित गलत कॉन्फ़िगरेशन और दुर्भावनापूर्ण हमलों को कम करने के लिए एक मानक-आधारित प्लेटफ़ॉर्म के रूप में वर्णित करता है। यह यह साबित नहीं करता है कि मध्यवर्ती ASes ने सही व्यवहार किया है और यह अकेले हर रूट लीक को नहीं रोक सकता है।
7. एक सुरक्षित रोलआउट की योजना बनाएं। ऑब्जर्वेशन मोड में शुरुआत करें, Invalid और NotFound का निरीक्षण करें, और पड़ोसियों (neighbors) के एक छोटे सेट के लिए रिजेक्शन सक्षम करें। प्रत्येक परिवर्तन से पहले, ROA अधिकतम लंबाई, रिडंडेंट घोषणाओं और रोलबैक कमांड्स को सत्यापित करें। इसके बाद रीचेबिलिटी, Invalid वॉल्यूम, कैश स्वास्थ्य और अलर्ट में देरी पर नज़र रखें।

उच्च गुणवत्ता वाला नमूना उत्तर

"मैं समस्या को ऑथराइजेशन, वैलिडेशन और पॉलिसी में विभाजित करूँगा। प्रीफिक्स धारक अनुमत ओरिजिन AS और अधिकतम प्रीफिक्स लंबाई बताते हुए एक ROA प्रकाशित करता है। एक RPKI वैलिडेटर हस्ताक्षरित ऑब्जेक्ट्स की जाँच करता है और VRPs बनाता है; एक BGP स्पीकर ASPATH से प्राप्त प्रत्येक प्रीफिक्स की तुलना ओरिजिन AS से करता है। कवर और मैच होना Valid है, कवर होना लेकिन मैच न होना Invalid है, और कोई कवरिंग ऑब्जेक्ट न होना NotFound है। राउटर Invalid को अस्वीकार कर सकता है और NotFound को एक अलग नीति विकल्प के रूप में मान सकता है, लेकिन यह पूरे ASPATH को मान्य नहीं करता है और न ही हर रूट लीक को हल करता है। मैं इसे ऑब्जर्वेशन मोड में रोल आउट करूँगा, ROA कवरेज और अधिकतम लंबाई को सत्यापित करूँगा, कैश की ताज़गी और रीचेबिलिटी की निगरानी करूँगा, फिर रोलबैक के साथ धीरे-धीरे फ़िल्टरिंग सक्षम करूँगा।"

सामान्य गलतियाँ

• लक्षण → "RPKI संपूर्ण AS_PATH को मान्य करता है।" यह क्यों विफल होता है → RFC 6811 की स्थिति प्रीफिक्स कवरेज और ओरिजिन AS की तुलना करती है। सुधार → ROV को ओरिजिन वैलिडेशन कहें और पाथ इंटीग्रिटी के लिए अलग नियंत्रणों का उल्लेख करें।
• लक्षण → "बिना ROA वाला रूट दुर्भावनापूर्ण होता है।" यह क्यों विफल होता है → NotFound का अर्थ है कि कोई कवरिंग डेटा नहीं है, न कि यह कि घोषणा झूठी है। सुधार → NotFound और Invalid को अलग-अलग पॉलिसी इनपुट के रूप में मानें।
• लक्षण → "कैश आउटेज हर रूट को Invalid बना देता है।" यह क्यों विफल होता है → डिस्ट्रीब्यूटेड कैश अनुपलब्ध या पुराने हो सकते हैं; अचानक फ़िल्टरिंग घटना को बढ़ा सकती है। सुधार → कैश हेल्थ चेक, पुराने डेटा को सुरक्षित रूप से संभालने और रोलबैक का वर्णन करें।
• लक्षण → "कोई भी ROA अधिकतम लंबाई सेट कर देना।" यह क्यों विफल होता है → बहुत छोटा मान वैध more-specific घोषणाओं को अमान्य करता है; बहुत लंबा मान ऑथराइजेशन को अत्यधिक विस्तृत करता है। सुधार → वास्तविक घोषणा सेट से maxLength प्राप्त करें।

अनुवर्ती प्रश्न और उत्तर

ROA के बिना रूट Invalid के बजाय NotFound क्यों होता है?

Invalid के लिए एक कवरिंग VRP की आवश्यकता होती है जिसका अधिकृत ओरिजिन मेल नहीं खाता हो। बिना किसी कवरिंग VRP के स्थिति NotFound होती है। पॉलिसी यह चुन सकती है कि अनुपलब्ध साक्ष्य को कैसे संभालना है, लेकिन साक्ष्य की अनुपस्थिति खराब ओरिजिन का प्रमाण नहीं है।

क्या होता है जब कोई ROA गलत तरीके से प्रकाशित हो जाता है?

वैध रूट्स Invalid हो सकते हैं और सख्त पड़ोसियों द्वारा अस्वीकार किए जा सकते हैं। ROA को रद्द (revoke) करें या ठीक करें, फिर रिपॉजिटरी और कैश रीफ़्रेश की प्रतीक्षा करें; स्थिति परिवर्तन की निगरानी करें और एक अस्थायी पॉलिसी रोलबैक पाथ बनाए रखें।

क्या RPKI किसी रूट लीक को रोक सकता है?

आवश्यक रूप से नहीं। ROV यह जाँचता है कि क्या ओरिजिन AS अधिकृत है; वह AS अभी भी किसी अनाधिकृत पड़ोसी को प्रीफिक्स प्रोपेगेट कर सकता है। लीक को कम करने के लिए प्रीफिक्स फ़िल्टर, नेबर रोल्स (neighbor roles) और एक्सपोर्ट पॉलिसी की आवश्यकता होती है।

आप यह कैसे सत्यापित करेंगे कि फ़िल्टरिंग ने रीचेबिलिटी को बाधित नहीं किया है?

लॉगिंग मोड में शुरुआत करें और ROAs व अधिकतम लंबाई का नमूना लेते हुए राउटिंग टेबल के साथ Valid, Invalid और NotFound की तुलना करें। बैचों में रिजेक्शन सक्षम करें, रीचेबिलिटी प्रोब्स, कैश हेल्थ, नेबर सेशन्स और Invalid वॉल्यूम पर नज़र रखें, और यदि कोई भी संकेत ख़राब होता है तो पॉलिसी को वापस रोलबैक करें।