हमलावरों के लिए routing-आधारित VPN एक्सपोज़र संभव

 (leviathansecurity.com)
3 पॉइंट द्वारा GN⁺ 2024-05-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • TunnelVision(CVE-2024-3661) DHCP की मौजूदा सुविधा का दुरुपयोग करके यूज़र के ट्रैफ़िक को VPN टनल के बाहर मोड़ देता है, और इस दौरान पैकेट VPN से एन्क्रिप्ट नहीं होते
  • हमलावर DHCP option 121 के ज़रिए अधिक specific routes inject करके VPN virtual interface से ऊपर प्राथमिकता वाला path बना सकता है और ट्रैफ़िक को physical interface पर भेज सकता है
  • हमला तब संभव है जब लक्ष्य हमलावर-नियंत्रित DHCP lease स्वीकार करे और client option 121 को implement करता हो; परीक्षण में Windows, Linux, iOS, macOS प्रभावित पाए गए, जबकि Android इससे बाहर रहा
  • VPN control channel चलता रहता है, इसलिए यूज़र को कनेक्शन सक्रिय दिखता है; देखे गए मामलों में kill switch भी ट्रैफ़िक leak रोक नहीं पाया
  • Linux के network namespaces एक मज़बूत समाधान हो सकते हैं, लेकिन firewall-आधारित mitigation selective denial of service और traffic destination inference side channel बना सकती है

TunnelVision से होने वाला VPN decloaking

  • TunnelVision एक network technique है जो VPN encapsulation को bypass करके यूज़र के ट्रैफ़िक को ज़बरदस्ती टनल के बाहर भेजती है
  • हमलावर DHCP(Dynamic Host Configuration Protocol) का उपयोग करके लक्ष्य पैकेट को VPN से एन्क्रिप्ट हुए बिना भेजवा सकता है
  • VPN control channel बना रहता है, इसलिए यूज़र को VPN से जुड़ा होने का भ्रम बना रहता है; इसी प्रभाव को decloaking कहा जाता है
  • यह technique संभवतः 2002 तक पीछे जाती है, और इसके सार्वजनिक होने के बाद यह भी पुष्टि हुई कि DHCP option 121 और VPN प्रभाव पर पहले से कम-से-कम 2015 से शोध मौजूद था

VPN routing attack surface क्यों बनती है

  • VPN host device और दूसरे network के server के बीच ट्रैफ़िक के लिए एक tunnel बनाता है, और VPN client virtual network interface पर ट्रैफ़िक को encrypt/decrypt करता है
  • जो configuration पूरा ट्रैफ़िक VPN से भेजती है उसे full-tunnel VPN कहा जाता है, जबकि local network जैसी exceptions वाली configuration को split-tunnel VPN कहा जाता है
  • VPN को server के साथ connection बनाए रखना होता है, इसलिए VPN server IP की ओर जाने वाले ट्रैफ़िक को physical interface से भेजने वाला exception route ज़रूरी होता है
  • routing table destination के आधार पर ट्रैफ़िक path तय करती है, और अधिकांश network stacks में अधिक specific CIDR prefix length को ऊँची प्राथमिकता मिलती है
    • /32 route, /24 या /0 से ऊपर प्राथमिकता लेता है
    • कई full-tunnel VPN 0.0.0.0/0 या दो /1 routes के ज़रिए ट्रैफ़िक को VPN interface पर भेजते हैं

DHCP option 121 से route injection

  • DHCP local network devices को dynamically IP address lease देता है, और options के ज़रिए default gateway और DNS server जैसी settings भी भेजता है
  • सामान्य flow में client DHCPDISCOVER broadcast करता है और server DHCPOFFER से समय-सीमित lease प्रस्तावित करता है
  • RFC 3442 में जोड़ा गया DHCP option 121, classless static routes फीचर है, जो DHCP server को client routing table में static routes जोड़ने देता है
  • option 121 में DHCP server सीधे यह तय नहीं कर सकता कि route किस network interface device पर install होगा
    • DHCP server CIDR range और router बताता है
    • client, DHCP server से संचार कर रहे interface को उस route का interface मानकर implicitly चुनता है
  • इसी व्यवहार के कारण injected route का ट्रैफ़िक VPN virtual interface के बजाय DHCP server से बात कर रहे physical network interface से बाहर जा सकता है

हमले की शर्तें और तरीका

  • TunnelVision हमले के लिए दो शर्तें ज़रूरी हैं
    • target host को हमलावर-नियंत्रित DHCP server की lease स्वीकार करनी होगी
    • target host के DHCP client में DHCP option 121 implement होना चाहिए
  • उसी network पर मौजूद हमलावर कई तरीकों से target का DHCP server बन सकता है
    • असली DHCP server पर DHCP starvation attack करके, फिर नए clients को जवाब देना
    • DHCPDISCOVER broadcast का पहले जवाब देकर DHCP client के first-offer selection behavior का फायदा उठाना
    • ARP spoofing से असली DHCP server और client के बीच ट्रैफ़िक intercept करना, फिर lease renewal का इंतज़ार करना
  • हमलावर target VPN user वाले उसी network पर DHCP server चलाता है और खुद को gateway सेट करता है
  • इसके बाद वह DHCP option 121 से VPN user की routing table में मनचाहे routes जोड़ता है, और VPN के /0 से अधिक specific routes डालकर उन्हें VPN virtual interface से ऊपर प्राथमिकता दिलाता है
    • कई /1 routes सेट करके अधिकतर VPN के 0.0.0.0/0 full-traffic rule को recreate किया जा सकता है
    • हमलावर चुन सकता है कि कौन से IP addresses VPN tunnel में जाएँ और कौन से addresses हमलावर DHCP server से जुड़े interface पर जाएँ
  • यह पहले से स्थापित VPN connection पर भी लागू हो सकता है, और DHCP lease time छोटा रखकर routing table updates को अधिक बार trigger किया जा सकता है

PoC और प्रयोग परिदृश्य

  • सार्वजनिक सामग्री इस प्रकार है
  • प्रयोग वातावरण को कई attack scenarios दिखाने के लिए बनाया गया था
    • जब हमलावर ने DHCP server या access point को compromise किया हो
    • जब कोई malicious admin सीधे infrastructure का मालिक हो और उसे configure करे
    • जब हमलावर café या office जैसी physical location में evil twin wireless AP लगा दे
    • भविष्य में ArcaneTrickster सार्वजनिक होने के बाद, उसी LAN पर adjacent host लेकिन non-privileged network position वाले हमलावर का भी simulation संभव होगा

प्रभावित operating systems और VPN

  • परीक्षण में वे operating systems प्रभावित पाए गए जो RFC spec के अनुसार DHCP client implement करते हैं और DHCP option 121 routes को support करते हैं
    • प्रभाव देखा गया: Windows, Linux, iOS, macOS
    • अपवाद: Android, क्योंकि वह DHCP option 121 को support नहीं करता, इसलिए प्रभावित नहीं होता
  • जो VPN host traffic protection के लिए केवल routing rules पर निर्भर करते हैं, वे vulnerable हैं
  • जो system administrators अपना VPN server खुद चलाते हैं, वे भी vulnerable हो सकते हैं अगर उन्होंने VPN client configuration को harden नहीं किया है
  • encryption algorithm की strength का इस पर कोई असर नहीं है
    • TunnelVision, WireGuard, OpenVPN, IPsec जैसे VPN protocols को स्वयं नहीं तोड़ता
    • यह operating system network stack की routing configuration बदलकर यूज़र को VPN tunnel इस्तेमाल न करने की स्थिति में ले आता है

fixes और mitigations

  • Linux के network namespaces इस व्यवहार को पूरी तरह ठीक कर सकते हैं
    • WireGuard documentation दिखाती है कि VPN उपयोग करने वाले application traffic को अलग namespace में handle करके, फिर उसे physical interface वाले दूसरे namespace में कैसे भेजा जाए
    • Windows, macOS और अन्य operating systems में इसी स्तर का robust समाधान मौजूद है या नहीं, यह स्पष्ट नहीं है
  • कुछ VPN providers physical interface के सभी inbound/outbound traffic को firewall rules से block करने वाली mitigation का उपयोग करते हैं
    • LAN और VPN server connectivity बनाए रखने के लिए DHCP और VPN server IP exceptions की ज़रूरत होती है
    • deep packet inspection से केवल DHCP और VPN protocols को allow किया जा सकता है, लेकिन इससे performance penalty हो सकती है
  • firewall mitigation, DHCP routes इस्तेमाल करने वाले ट्रैफ़िक पर selective denial of service पैदा करती है और side channel भी जोड़ती है
    • हमलावर VPN-encrypted traffic volume में बदलाव का विश्लेषण करके सांख्यिकीय रूप से साबित कर सकता है कि target user किसी खास destination पर ट्रैफ़िक भेज रहा है या नहीं
    • वह predefined lists से मिलान कर सकता है, censorship mechanism के तौर पर selective blocking कर सकता है, या IP space blocking को binary search की तरह इस्तेमाल करके मौजूदा connections को logarithmic time में ढूँढ सकता है
  • VPN उपयोग के दौरान option 121 को ignore करना भी एक तरीका है, लेकिन यह फीचर वैध network connectivity के लिए ज़रूरी हो सकता है, इसलिए इससे connection issues पैदा हो सकते हैं
    • यदि यह mitigation optional है, तो हमलावर network access deny करके VPN या user को option 121 फिर से enable करने के लिए मजबूर कर सकता है
  • hotspot या VM भी mitigation में मदद कर सकते हैं
    • cellular device द्वारा नियंत्रित password-locked LAN, हमलावर की local network access रोकने में मदद कर सकता है
    • VM भी ऐसा ही व्यवहार कर सकता है, बशर्ते network adapter bridged mode में न हो

users और operators के लिए ज़रूरी कदम

  • sensitive traffic के लिए untrusted networks से बचना चाहिए, और यदि यह संभव न हो तो ऐसे VPN provider का उपयोग करना चाहिए जिसके पास TunnelVision के प्रभावी mitigations हों
  • VPN decloak होने पर भी HTTPS websites तक पहुँचने की स्थिति में अधिकांश user data local network attacker को दिखाई नहीं देता, लेकिन destination और protocol उजागर हो सकते हैं
  • यदि enterprise VPN का उपयोग café, hotel, airport जैसी जगहों पर होता है, तो network administrators को इस जोखिम के बारे में बताना चाहिए और जहाँ तक संभव हो इससे बचने की सलाह देनी चाहिए
    • यदि यह व्यावहारिक न हो, तो mitigation या fixes लागू किए गए VPN के उपयोग का मार्गदर्शन देना चाहिए
    • trusted hotspot का उपयोग करने के बाद VPN से जुड़ना, या virtual DHCP server से lease लेने वाले VM के भीतर VPN चलाना भी संभव है
  • जो कंपनियाँ अपना network या site-to-site VPN चलाती हैं, उन्हें switches की जाँच करनी चाहिए और DHCP snooping तथा ARP protection जैसे Layer 2 security features enable करने चाहिए
    • ये protections rogue DHCP servers को कम करने में मदद करती हैं, लेकिन malicious admin scenario को खत्म नहीं कर पातीं
    • internal resources पर HTTPS या अन्य encryption protocols लागू करना, untrusted networks से जुड़े VPN users के data leakage को रोकने में मदद कर सकता है
  • VPN providers client में ऐसा firewall feature जोड़ सकते हैं जो network interface पर जाने वाले outbound packets को block करे, लेकिन तब user local network resources के साथ interact नहीं कर पाएगा
  • Linux के लिए full-tunnel VPN clients को network namespaces-आधारित isolation पर विचार करना चाहिए
  • operating system maintainers को Linux के बाहर के operating systems में network namespaces जैसी सुविधाएँ जोड़ने या मज़बूत करने पर विचार करना चाहिए
  • ArcaneTrickster नाम की एक adversarial infrastructure library, LAN security research और वास्तविक हमले के demo के लिए विकसित की जा रही है और बाद में सार्वजनिक करने की योजना है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-07
Hacker News टिप्पणियाँ

  • यह 2016 में Samy Kamkar के PoisonTap अटैक का थोड़ा बदला हुआ रूप है। USB/Thunderbolt नेटवर्क अडैप्टर के साथ यही काम किया जा सकता है, और अगर इसे पीड़ित डिवाइस में लगाकर 0.0.0.0/1 और 128.0.0.0/1 जैसे दो अधिक विशिष्ट रूट advertise किए जाएँ, तो इंटरफ़ेस क्रम की परवाह किए बिना यह दूसरे सिस्टम इंटरफ़ेसों पर प्राथमिकता लेकर सारा ट्रैफ़िक अपनी ओर खींच सकता है: https://github.com/samyk/poisontap
    शायद इसके और भी पुराने उदाहरण हों, लेकिन यह काफ़ी जाना-माना उदाहरण है। शीर्षक में कहा गया है कि सभी VPN client प्रभावित होते हैं, लेकिन जैसा कि लेख के मुख्य भाग में भी माना गया है, कई VPN client ऐसे firewall rules सेट करते हैं जो physical interface से आने-जाने वाले ट्रैफ़िक को रोकते हैं
    जो VPN anonymity का दावा करते हैं, या जहाँ anonymity महत्वपूर्ण है, वे आम तौर पर इसे लागू करते हैं। कई बार यह setting default से चालू नहीं होती, लेकिन अगर प्रमुख personal/commercial/enterprise VPN solutions में से कितने प्रतिशत इसे default से चालू रखते हैं, यह दस्तावेज़ित किया जाता, तो वह ज़्यादा उपयोगी होता
    आम पाठकों के लिए व्याख्या अच्छी है, लेकिन जब इतने client ऐसे firewall rules के कारण अधिकांश data leak रोक लेते हैं, और इस क्षेत्र के पुराने काम का भी ठीक से उल्लेख नहीं है, तो शीर्षक थोड़ा बढ़ा-चढ़ा लगता है

    • सही बात पकड़ी। बुनियादी firewall rules भी न होने के कारण शायद पहले से बहुत कुछ लीक कर रहे VPN को छोड़ दें, तो यह कोई ख़ास vulnerability नहीं है
      “side-channel attack” वाला शब्द देखकर तो लगभग मेरा पेय बाहर निकल गया
      संपादन: अब देखा कि NordVPN कम-से-कम mac पर ऐसे default firewall rules नहीं लगाता, इसलिए वह इस अटैक के प्रति vulnerable लगता है

  • समझ नहीं आता यह लेख इतना लंबा क्यों है
    DHCP Option 121 DHCP server को किसी विशेष CIDR range के लिए routing rules सेट करने देता है, और लंबा prefix होने के कारण यह default 0.0.0.0/0 rule से ऊँची priority ले लेता है

    • मैं इस लेख के लेखकों में से एक हूँ। मेरा इरादा था कि non-technical background वाले पाठक भी आएँगे, इसलिए पहले संबंधित विषय समझा दूँ
      इंटरनेट पर VPN के बारे में आधी जानकारी VPN providers द्वारा लिखी हुई होती है, और वह वास्तव में यह समझाने के लिए या तो सटीक नहीं होती या काफ़ी तकनीकी नहीं होती कि चीज़ें काम कैसे करती हैं
      मैंने शुरुआत में “अगर यह सब पहले से पता है तो POC section पर जाएँ” जैसी पंक्ति को link करने का सोचा था, लेकिन इसे और स्पष्ट दिखने लायक अपडेट करूँगा
    • और इस अटैक को trigger करने के लिए attacker को पीड़ित के समान layer 2 network पर होना पड़ेगा
      यह सिर्फ़ ऊपर की टिप्पणियाँ देखकर लगाया गया अनुमान है, लेख पढ़े बिना

  • मुझे लगा यह अटैक मैंने पहले किसी और लेखक से पढ़ा था, इसलिए खोजा, और search results में भरे पड़े VPN vendor spam को पार करके पुराना काम [1] मिला
    यह लेख flaw के exploitation को ज़्यादा गहराई से कवर करता है, और proof of concept के लिए मददगार code भी देता है
    1: https://www.usenix.org/conference/usenixsecurity23/presentat...

    • उस paper का संदर्भ appendix में दिया गया है
      लेकिन 2023 के अगस्त वाले paper में दिए गए दोनों techniques DHCP option 121 के ज़रिए routes push नहीं करते थे। DHCP से routes push करने पर, attacker की वही स्थिति होने पर भी असर कहीं ज़्यादा बढ़ जाता है। उदाहरण के लिए, ऐसी स्थिति जहाँ non-RFC1918 range के IP lease बाँटे जा सकते हों या DNS responses spoof किए जा सकते हों
    • यह “अटैक” व्यापक रूप से जाना-पहचाना है, और OpenVPN client के configuration option redirect-gateway def1 में भी इस्तेमाल होता है

  • threat model यह है कि कोई भी attacker किसी तरह मेरे LAN पर DHCP server बन सके; संभावना कम है, लेकिन असंभव नहीं
    दूसरी ओर, अगर आप ISP द्वारा दिया गया gateway device इस्तेमाल कर रहे हैं, तो बात अलग है

    • अगर “कोई भी attacker मेरे LAN पर DHCP server बन जाए” सिर्फ़ कम संभावना वाला लेकिन संभव परिदृश्य है, तो क्या cafe Wi‑Fi ठीक वैसी ही स्थिति नहीं है?
      ज़्यादातर VPN products का पहला selling point तो वही होता है
      इस मामले में सही प्रतिक्रिया 4G/5G connection इस्तेमाल करना है, और अविश्वसनीय, संदिग्ध नेटवर्क से न जुड़ना है
    • “that DHCP server” कहना यह मानकर चलता है कि नेटवर्क में कोई अलग विशेष डिवाइस है, लेकिन वही धारणा ग़लत है। DHCP एक broadcast protocol है, और डिवाइस पहला offer स्वीकार कर लेता है
      साधारण घरों में DHCP router से मिलता है और इसलिए वह आम तौर पर सबसे पहले जवाब देता है, लेकिन वह केवल एक द्वितीयक तथ्य है। नेटवर्क में मौजूद कोई भी malicious device इस vulnerability का इस्तेमाल कर सकता है
    • क्या VPN का एक बड़ा उपयोग-मामला यही नहीं है कि जिस नेटवर्क से मैं जुड़ा हूँ, उस पर भरोसा नहीं किया जा सकता?
    • या वह स्थिति जहाँ मैं जिस third-party Wi‑Fi से जुड़ा हूँ, वहीं DHCP server मौजूद हो
    • अविश्वसनीय Wi‑Fi नेटवर्क पर सुरक्षा देना, VPN के आम प्रचार कारणों में से एक है

  • Linux पर VPN interface को VRF में डालकर भी mitigation किया जा सकता है। उदाहरण के लिए systemd-networkd इसे default रूप से support करता है
    ध्यान देने वाली बात यह है कि VRF चालू होने पर l3mdev के लिए ip rule entry 1000 पर आती है, लेकिन local traffic rule 0 पर रहता है। local rule को 1000 या उससे ऊपर ले जाना होगा

    • क्या आजकल apps को किसी विशेष VRF में चलाने का तरीका है?

  • यह “अटैक” बस DHCP option 121 का चतुर उपयोग है। बुरी तरह टूटी हुई client configuration पर यह एक वैध अटैक है
    default route बदलना या उसे दो /1 routes से override करना और VPN endpoint तक host route जोड़ना सुरक्षित नहीं है। encapsulated traffic को निचले नेटवर्क से सही तरह isolate करने के लिए policy-based routing इस्तेमाल करनी चाहिए। जैसे Linux network namespaces, FreeBSD vnet, OpenBSD rdomains
    packet filter और user-space “kill switch” को ज़बरदस्ती जोड़कर कुछ बनाने की कोशिश डिज़ाइन से ही टूटी हुई है, और यह दिखाती है कि आम VPN hosting providers अपने तथाकथित मुख्य कौशल को कितना कम समझते हैं या उसकी कितनी कम परवाह करते हैं। यह फिर वही पुरानी “बुरी चीज़ों की सूची बनाना” वाली समस्या है

  • इसमें कुछ नया नहीं है
    मुझे तो उन लोगों की ज़्यादा चिंता है जिनके सिस्टम में IPv6 चालू है लेकिन वे IPv4-only VPN service इस्तेमाल करते हैं
    वहाँ चीज़ें वाक़ई बहुत बुरी तरह गड़बड़ा सकती हैं

  • क्लाइंट डिवाइस पर VPN को bypass करने के बहुत से तरीके होते हैं। इसलिए जब VPN की ज़रूरत होती है, तो मैं क्लाइंट और इंटरनेट के बीच ऐसा router रखना पसंद करता हूँ जो VPN tunnel को terminate करे और जिसके अलावा कोई दूसरा route न हो
    ऐसे travel router को बहुत आसानी से configure किया जा सकता है और कहीं भी साथ ले जाया जा सकता है, और मैं वास्तव में ऐसा करता भी हूँ

    • घर पर मैं इस बात की ज़ोरदार सिफारिश करता हूँ कि हर router का अपना Wi‑Fi network रखने वाला dedicated VPN router हो। मुझे लगता है कि हर डिवाइस पर लोकल में VPN software चलाने की तुलना में यह connect करना आसान और ज़्यादा stable है
      उदाहरण के लिए, एक “work” Wi‑Fi router हो सकता है जो office intranet के लिए VPN connection हमेशा चालू रखता है, एक “Australia” Wi‑Fi हो सकता है जो हर बार ऑस्ट्रेलियाई TV देखना हो तब Australia server से VPN जोड़ता है, और अंत में सामान्य घरेलू internet Wi‑Fi हो सकता है
      कुछ पुराने Wi‑Fi routers हों तो यह बहुत आसानी से किया जा सकता है, और आजकल सस्ते home routers भी कुछ हद तक VPN support देते दिखते हैं। VPN configuration को centralize करके गलती की गुंजाइश कम करने के अलावा, इसका एक बड़ा फायदा यह है कि कोई भी डिवाइस बस उस Wi‑Fi से जुड़कर VPN इस्तेमाल कर सकता है
      मैं कई पुराने routers के साथ ऐसा इस्तेमाल कर रहा हूँ, लेकिन सच कहूँ तो शायद ऐसे products का market भी होगा जहाँ एक ही home router दुनिया के अलग-अलग locations पर VPN बनाकर location के हिसाब से अलग Wi‑Fi networks दे सके। इसका उपयोग TV/Roku/iPad को आसानी से ऐसे दिखाने के लिए होगा जैसे वे किसी दूसरे region से connect हुए हों
    • यह attack तभी संभव है जब local LAN पर कोई untrusted device मौजूद हो। अगर आप पहले से VPN चालू gateway को सीधे अपने साथ ले जा रहे हैं, तो untrusted LAN devices बहुत बड़ी चिंता नहीं लगते
      लेकिन अगर LAN पर untrusted device है और DHCP इस्तेमाल हो रहा है, तो वह device इस technique से unencrypted* traffic की जासूसी कर सकता है। फिर भी gateway उसे छिपा देता है, इसलिए वह असली IP नहीं ढूँढ पाएगा
      यह attack सबसे यथार्थ रूप से cafe Wi‑Fi जैसी स्थितियों में लागू होता है। ऐसे स्थानों पर अपना router साथ ले जाने की संभावना कम होती है
      यहाँ “unencrypted traffic” से मतलब उस traffic से है जो VPN provider तक भेजे जाने के लिए encapsulate नहीं किया गया है। आजकल ज़्यादातर चीज़ें HTTPS हैं, इसलिए उस traffic का content खुद अभी भी encrypted ही रहेगा
    • अगर कोई कुछ उपयोगी hardware और software की सूची दे दे, तो मेहनत बच सकती है
    • ज़्यादातर travel routers भी शायद अभी तक इस समस्या के प्रति vulnerable होंगे

  • तकनीकी लोगों के लिए यह बात काफ़ी स्पष्ट होनी चाहिए थी, लेकिन networking और VPN का परिचय देने वाली व्याख्या के रूप में यह अच्छी है। मैंने Linux VPN gateway VM कई बार configure किए हैं, और सिर्फ routing table पर निर्भर रहने वाली संरचना हमेशा असुरक्षित-सी लगी, खासकर जब वही connection उसी machine पर चल रही processes भी इस्तेमाल करती हों
    network namespace और physical VPN gateway router के अलावा, VM-based architecture भी इस समस्या का समाधान कर सकती है। मेरे homelab में firewall VPN gateway VM से निकलने वाले अप्रत्याशित traffic को block करता है। VPN VLAN के devices सीधे बाहर connect नहीं कर सकते, और gateway VM के पास बाहरी connections के लिए अलग VLAN होता है
    व्यक्तिगत समाधान के रूप में QubesOS इसी तरह की configuration काफ़ी कम friction के साथ सेट करने देता है, लेकिन फिर भी इसमें सामान्य OS की तुलना में ज़्यादा technical knowledge चाहिए

  • “Android पर DHCP option 121 support implement नहीं किया गया था, इसलिए वही एकमात्र platform था जो प्रभावित नहीं हुआ” वाला हिस्सा दिलचस्प है
    यह जानने की उत्सुकता है कि Google ने यह फैसला इस समस्या को जानते हुए जानबूझकर लिया था, या यह पूरी तरह संयोग था

    • https://issuetracker.google.com/issues/117544989 को देखकर लगता है कि Google ने इस feature request को बिना कोई कारण दिए मोटे तौर पर नज़रअंदाज़ किया। मुझे भी यही बात जानने की जिज्ञासा है। शायद कोई Google कर्मचारी जिसे internal Buganizer तक access हो, ज़्यादा जानता हो
      मेरा अनुमान है कि Android networking team IPv6 के प्रति बहुत अनुकूल है। लगता है कि IPv4 की छूटी हुई niche features में उसकी खास दिलचस्पी नहीं है। IPv6 को लेकर भी शायद उनकी एक खास vision है कि उसे कैसे इस्तेमाल किया जाना चाहिए, और इसी वजह से stateful DHCPv6 जैसी चीज़ों को जानबूझकर support नहीं किया गया
    • DHCP options बहुत सारे होते हैं, इसलिए Android जैसे platform के लिए पहले न्यूनतम support से शुरुआत करना और फिर किसी option की मांग आने पर ही अतिरिक्त support जोड़ना एक उचित रणनीति है
      यह DHCP option आम तौर पर इस्तेमाल नहीं होता, इसलिए ऐसी रणनीति अपनाने पर सुरक्षा चिंताओं से अलग भी इसका unsupported रह जाना काफ़ी संभव है
    • Android ने 21 साल पहले परिभाषित किए गए नए DHCP version तक को implement नहीं किया है: https://www.rfc-editor.org/rfc/rfc3315
      इसलिए इसमें बहुत हैरानी की बात नहीं है