- वेनेज़ुएला के CANTV(AS8048) नेटवर्क में कई बार BGP route leak हुए, जिनसे कुछ नेटवर्क पथ असामान्य रूप से प्रचारित हुए
- Cloudflare Radar डेटा के अनुसार दिसंबर के बाद से 11 leak events की पुष्टि हुई है, और यह routing policy की कमी से हुई तकनीकी गलती होने की प्रबल संभावना है
- इस घटना में AS8048 ने अपने upstream provider AS6762(Sparkle) से प्राप्त पथों को दूसरे provider AS52320(V.tal GlobeNet) को फिर से भेज दिया, जो एक विशिष्ट Type 1 hairpin leak संरचना है
- RPKI-आधारित Route Origin Validation(ROV) इस मामले में प्रभावी नहीं है, और ऐसे leaks को रोकने के लिए ASPA(Autonomous System Provider Authorization) तथा RFC9234 जैसे नए मानकों की आवश्यकता है
- BGP की trust-based संरचना के कारण ऐसी घटनाएं आम हैं, और ASPA·Peerlock·RFC9234 जैसी तकनीकों को अपनाना सुरक्षित इंटरनेट संचालन के लिए महत्वपूर्ण है
BGP route leak की अवधारणा
- BGP(Route Gateway Protocol) इंटरनेट पर autonomous systems(AS) के बीच पथों का आदान-प्रदान करने वाला प्रोटोकॉल है
- नेटवर्क के बीच संबंध customer-provider या peer-peer रूप में होते हैं
- route leak को RFC7908 में “इच्छित दायरे से बाहर routing जानकारी का प्रसार” के रूप में परिभाषित किया गया है
- उदाहरण: जब कोई customer, provider से प्राप्त पथ को किसी दूसरे provider तक फिर से प्रचारित कर देता है
- ऐसे leaks, valley-free routing नियम का उल्लंघन करते हैं, जिससे ट्रैफिक असामान्य पथों से गुजरता है
- परिणामस्वरूप नेटवर्क congestion, latency और traffic loss जैसी समस्याएं हो सकती हैं
AS8048(CANTV) के route leak का मामला
- Cloudflare Radar ने पुष्टि की कि AS8048(CANTV) ने AS6762(Sparkle) से प्राप्त पथों को AS52320(V.tal GlobeNet) तक फिर से भेजा
- यह स्पष्ट रूप से route leak का मामला है
- leak हुए पथों का origin AS21980(Dayco Telecom) था, जो AS8048 का customer network है
- दोनों AS के बीच संबंध Cloudflare Radar और bgp.tools डेटा में provider-customer relationship के रूप में दिखाया गया है
- पथ में AS8048 को कई बार prepend किया गया था
- prepend एक तकनीक है जिसमें पथ को कम आकर्षक बनाया जाता है ताकि ट्रैफिक किसी दूसरे पथ की ओर जाए
- इसलिए जानबूझकर किए गए MITM(मैन-इन-द-मिडल अटैक) की संभावना कम है
- यह leak 2 जनवरी 2026 को 15:30~17:45 UTC के बीच कई बार हुआ, और इसके पीछे network policy error या convergence issue होने की संभावना है
- Cloudflare Radar रिकॉर्ड के अनुसार दिसंबर के बाद से 11 समान leaks दोहराए गए हैं, जिससे लगातार policy की कमी का संकेत मिलता है
तकनीकी कारण और नीतिगत समस्या
- संभव है कि AS8048 ने provider AS52320 के लिए routing export policy को बहुत ढीला कॉन्फ़िगर किया हो
- यदि customer BGP community tags की जगह केवल IRR-आधारित prefix list का उपयोग हुआ हो, तो गलत पथ retransmit हो सकते हैं
- ऐसी policy errors को RFC9234 के Only-to-Customer(OTC) attribute के जरिए रोका जा सकता है
- OTC, BGP roles(customer, provider, peer) को स्पष्ट रूप से परिभाषित करता है और गलत route propagation को रोकता है
RPKI और ASPA की भूमिका
- Sparkle(AS6762) ने RPKI Route Origin Validation(ROV) को पूरी तरह लागू नहीं किया है,
- लेकिन यह घटना path anomaly की है, इसलिए इसे ROV से रोका नहीं जा सकता
- ASPA(Autonomous System Provider Authorization) path-based verification प्रदान करता है
- हर AS अपने अधिकृत upstream providers की सूची घोषित करता है, जिससे असामान्य पथों को स्वतः ब्लॉक किया जा सकता है
- उदाहरण: यदि AS6762 यह घोषित करे कि “कोई upstream provider नहीं है”, तो अन्य नेटवर्क AS6762 को शामिल करने वाले गलत पथों को अस्वीकार कर सकते हैं
- ASPA, RPKI-आधारित तरीके से काम करता है और route leak रोकने में सीधे प्रभावी है
सुरक्षित BGP के निर्माण के लिए सुझाव
- BGP मूल रूप से एक trust-based protocol है, इसलिए policy error या मानवीय गलती से leaks अक्सर होते हैं
- यदि ASPA, RFC9234, और Peerlock/Peerlock-lite जैसी तकनीकों को साथ में लागू किया जाए, तो
- path validation मजबूत होगी
- गलत route propagation रुकेगा
- नेटवर्क स्थिरता बेहतर होगी
- RIPE पहले से ASPA object creation को समर्थन दे रहा है,
- और operators को network equipment vendors से RFC9234 implementation की मांग करनी चाहिए
- ऐसे सहयोगात्मक standards को अपनाना वेनेज़ुएला जैसे BGP incidents की रोकथाम का प्रमुख तरीका है
अभी कोई टिप्पणी नहीं है.