प्रॉम्प्ट और संदर्भ
कई टेलीफोन सर्विस प्रोवाइडर्स यह गारंटी नहीं दे सकते कि SIP सिग्नलिंग PASSporT को एंड-टू-एंड ले जा सकती है। RFC 9888 के आधार पर, एक आउट-ऑफ-बैंड Call Placement Service (CPS) डिज़ाइन करें और डिस्कवरी, सबमिशन और रिट्रीवल, mTLS ऑथराइजेशन, एक्सपायरी, गेटवे इंटरऑपरेबिलिटी और प्राइवेसी जोखिमों की व्याख्या करें।
RFC 9888 उन बड़े सर्विस प्रोवाइडर्स को लक्षित करता है जो SIP के माध्यम से PASSporTs को विश्वसनीयता के साथ नहीं ले जा सकते हैं। एक OOB Authentication Service (OOB-AS) HTTP पर एक CPS को PASSporT सबमिट करती है, और एक OOB Verification Service (OOB-VS) इसे पुल (pull) करके रिट्रीव करती है या पुश (push) द्वारा प्राप्त करती है। यह इंटरव्यू ट्रस्ट सीमाओं और ऑब्जेक्ट के जीवनकाल का परीक्षण करता है, न कि किसी जेनेरिक REST बकेट का।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर STIR क्रेडेंशियल्स, PASSporTs, CPS, OOB-AS और OOB-VS के बीच स्पष्ट जिम्मेदारियों; एक विश्वसनीय CPS विज्ञापन और टेलीफोन-नंबर-रेंज ऑथराइजेशन मॉडल; जालसाजी (forgery), रीप्ले (replay) और फ्लडिंग (flooding) के खिलाफ mTLS, कोटा और छोटी फ्रेशनेस विंडो; और मल्टी-प्रोवाइडर रिट्रीवल, गेटवे कन्वर्जन, मेटाडेटा प्राइवेसी और विफलता नीतियों की एक ठोस व्याख्या की तलाश करता है।
स्पष्टीकरण के लिए प्रश्न
प्रतिभागी और नेटवर्क सीमाएं
यह पहचानें कि PASSporT पर हस्ताक्षर कौन करता है, डेस्टिनेशन प्रोवाइडर के CPS को कौन संचालित करता है, क्या OOB-VS पुल करता है या पुश की सदस्यता लेता है, और कौन से पाथ PSTN गेटवे या लीगेसी नेटवर्क को पार करते हैं।
प्रामाणिकता और प्राइवेसी लक्ष्य
स्पष्ट करें कि क्या सिस्टम को कॉलर की पहचान साबित करनी है, नंबर स्पूफिंग को कम करना है, या कॉल मेटाडेटा को भी छिपाना है। RFC 9888 के प्रोवाइडर मॉडल में, CPS को कॉल प्रतिभागी द्वारा संचालित किया जाता है, इसलिए इसके प्राइवेसी अनुमान एक ओपन इंटरनेट OOB सेवा से भिन्न होते हैं।
लेटेंसी और डेटा प्रतिधारण (Retention)
कॉल इंडिकेटर दिखाने से पहले अनुमत अधिकतम विलंब, क्लॉक स्क्यू टॉलरेंस, और क्या PASSporT की आवश्यकता केवल वेरिफिकेशन तक ही है, इसे परिभाषित करें। CPS कोई दीर्घकालिक संग्रह (archive) नहीं है।
30-सेकंड का उत्तर
“मैं एक हस्ताक्षरित CPS विज्ञापन प्रकाशित करूँगा जो एक SPC या टेलीफोन-नंबर रेंज को HTTPS URI से बांधता है। OOB-AS एक विश्वसनीय STIR क्रेडेंशियल का उपयोग करके mTLS पर PASSporTs सबमिट करेगा; CPS डेस्टिनेशन को ऑथराइज करेगा, कोटा लागू करेगा, और प्रत्येक ऑब्जेक्ट को केवल उसकी फ्रेशनेस विंडो तक ही बनाए रखेगा। OOB-VS कॉल आने के बाद पुल कर सकता है या रेंज के आधार पर पुश की सदस्यता ले सकता है। एक मल्टी-प्रोवाइडर CPS को PASSporT डेस्टिनेशन और TNAuthList का उपयोग करके रीड्स (reads) को ऑथराइज करना चाहिए। गेटवे केवल एक डेलिगेटेड स्कोप के भीतर अनुवाद करते हैं। मैं एक्सपायरी, डुप्लिकेट्स, अनधिकृत अनुरोधों और लेटेंसी को मापूँगा, और मेटाडेटा संग्रह सीमा का दस्तावेजीकरण करूँगा।”
चरण-दर-चरण समाधान
चरण 1: ट्रस्ट और डेटा प्रवाह का मानचित्रण करें
OOB-AS, PASSporT बनाता है या ले जाता है और इसे डेस्टिनेशन CPS को सबमिट करता है। CPS इसे विज्ञापन और स्थानीय नीति के तहत स्वीकार करता है। OOB-VS केवल उन डेस्टिनेशन रेंजेस को प्राप्त करता है जिन्हें सत्यापित करने के लिए वह अधिकृत है। वेरिफिकेशन अभी भी PASSporT सिग्नेचर, orig, dest और फ्रेशनेस की जांच करता है; CPS से आने पर क्रिप्टोग्राफिक वेरिफिकेशन समाप्त नहीं होता है।
चरण 2: एक सुरक्षित CPS विज्ञापन प्रकाशित करें
विज्ञापन एक SPC या टेलीफोन-नंबर रेंज को एक HTTPS CPS URI पर मैप करता है। इसे एक विश्वसनीय STIR क्रेडेंशियल द्वारा हस्ताक्षरित होना चाहिए, और रिसीवर विज्ञापन की गई रेंज के साथ हस्ताक्षरकर्ता की TNAuthList की तुलना करता है। यह किसी भी क्रेडेंशियल धारक को रेंज को हाईजैक करने से रोकता है। डिस्कवरी कॉन्फ़िगरेशन, डेटाबेस या सुरक्षित DNS का उपयोग कर सकती है, लेकिन कैश को वर्जनिंग और एक्सपायरी की आवश्यकता होती है।
चरण 3: सबमिशन को ऑथराइज करें
OOB-AS, CPS के साथ TLS (अधिमानतः mTLS) स्थापित करता है, और CPS यह जांच करता है कि सर्टिफिकेट किसी अनुमत सबमिटिंग प्रोवाइडर का है या नहीं। प्रोवाइडर, रेंज और दर (rate) के अनुसार कोटा लागू करें; अज्ञात क्रेडेंशियल्स, गलत डेस्टिनेशन और फ्लडिंग को अस्वीकार करें। आंतरिक नीति विवरणों को उजागर किए बिना स्वीकार्यता, अस्वीकृति और डुप्लिकेट स्थितियों को वापस करें, ताकि हमलावरों को सेवा की जांच करने में मदद न मिले।
चरण 4: प्रतिधारण और फ्रेशनेस लागू करें
PASSporT को केवल तब तक रखें जब तक कि रिट्रीवल की आवश्यकता हो और इसके फ्रेशनेस अंतराल से परे कभी नहीं; RFC 9888 इस प्रोवाइडर प्रवाह के लिए अधिकतम 60 सेकंड का वर्णन करता है। orig, dest, एक कॉल पहचानकर्ता और PASSporT-विशिष्ट डेटा का उपयोग करके डुप्लिकेट हटाएं ताकि एक ही ऑब्जेक्ट को अनिश्चित काल तक रीप्ले न किया जा सके। एक्सपायरी एक अनिवार्य नियम (enforced invariant) होना चाहिए, न कि केवल कभी-कभार चलने वाला क्लीनअप जॉब।
चरण 5: पुल और पुश रिट्रीवल का समर्थन करें
पुल मोड में, OOB-VS एम्बेडेड PASSporT के बिना कॉल प्राप्त करने के बाद CPS से पूछताछ करता है। पुश मोड में, यह रेंज या SPC द्वारा सदस्यता लेता है और ऑब्जेक्ट्स को सक्रिय रूप से प्राप्त करता है। एक मल्टी-प्रोवाइडर CPS किसी प्रोवाइडर को डिलीवर करने से पहले PASSporT dest की जांच करता है। पुश विफलता सिग्नेचर फ्रेशनेस को नहीं बढ़ाती है; वेरिफिकेशन को “अभी उपलब्ध नहीं है” और “अमान्य” के बीच अंतर करना चाहिए।
चरण 6: गेटवे और फॉलबैक को सीमित करें
एक गेटवे SIP INVITE से PASSporT निकाल सकता है और इसे लीगेसी PSTN प्रोवाइडर्स की सेवा करने वाले CPS को सबमिट कर सकता है, या डाउनस्ट्रीम प्रोटोकॉल के लिए एक OOB ऑब्जेक्ट का अनुवाद कर सकता है। इसके क्रेडेंशियल के पास एक स्पष्ट डेलिगेटेड स्कोप होना चाहिए और यह नेटवर्क-व्यापी अधिकार प्रदान नहीं कर सकता। CPS अनुपलब्ध होने पर असत्यापित कॉल को जारी रखना, उसमें देरी करना या उसे ब्लॉक करना एक उत्पाद और नियामक नीति का निर्णय है।
चरण 7: प्राइवेसी, संचालन और ड्रिल्स को कवर करें
CPS कॉल मेटाडेटा देखता है, इसलिए फ़ील्ड्स, प्रतिधारण और ऑडिट एक्सेस को सीमित करें। सबमिशन सफलता, अनधिकृत अनुरोध, डुप्लिकेट, एक्सपायरी, पुल लेटेंसी, पुश बैकलॉग और प्रोवाइडर द्वारा कोटा अस्वीकृति को ट्रैक करें। सर्टिफिकेट रिवोकेशन, ओवरलैपिंग रेंजेस, रीप्ले, क्रॉस-प्रोवाइडर रीड्स, बदले गए विज्ञापनों, PSTN गेटवे लॉस और आंशिक CPS आउटेज का परीक्षण करें।
मॉडल उत्तर
मैं सबसे पहले प्रतिभागियों और ऑथराइजेशन रेंजेस को पंजीकृत करूँगा। प्रत्येक डेस्टिनेशन प्रोवाइडर अपने SPC या टेलीफोन-नंबर रेंज को HTTPS URI से बांधने वाला एक STIR-हस्ताक्षरित CPS विज्ञापन प्रकाशित करता है। OOB-AS, mTLS पर PASSporTs सबमिट करता है; CPS क्रेडेंशियल, डेस्टिनेशन, रेंज और कोटा को मान्य करता है, फिर ऑब्जेक्ट को केवल फ्रेशनेस अवधि तक बनाए रखता है। RFC 9888 अधिकतम 60 सेकंड के प्रतिधारण का वर्णन करता है। OOB-VS अहस्ताक्षरित कॉल आने के बाद पुल कर सकता है या पुश की सदस्यता ले सकता है। एक मल्टी-प्रोवाइडर CPS, dest और TNAuthList का उपयोग करके रीड्स को अधिकृत करता है। एक PSTN गेटवे केवल डेलिगेटेड स्कोप के भीतर ही निष्कर्षण या अनुवाद कर सकता है। यह सेवा अनुपलब्ध, समाप्त और अमान्य क्रेडेंशियल्स के बीच अंतर करती है, एक स्पष्ट फॉलबैक नीति लागू करती है, मेटाडेटा एक्सेस का ऑडिट करती है, और फ्लडिंग, रीप्ले, लेटेंसी और कोटा अस्वीकृति को मापती है।
सामान्य गलतियाँ
- गलती: CPS को सार्वजनिक ऑब्जेक्ट स्टोरेज मानना। → यह क्यों विफल होता है: अनधिकृत राइट्स और रीड्स जालसाजी, लीकेज और फ्लडिंग को सक्षम करते हैं। → सुधार: विश्वसनीय क्रेडेंशियल्स, mTLS, रेंज ऑथराइजेशन और प्रोवाइडर कोटा का उपयोग करें।
- गलती: दीर्घकालिक जांच के लिए PASSporTs को बनाए रखना। → यह क्यों विफल होता है: लंबी विंडो रीप्ले और मेटाडेटा एक्सपोज़र को बढ़ाती है। → सुधार: वेरिफिकेशन से जुड़ा एक छोटा TTL उपयोग करें और डिलीशन लागू करें।
- गलती: केवल orig द्वारा रीड्स को ऑथराइज करना। → यह क्यों विफल होता है: मल्टी-प्रोवाइडर एक्सेस को dest और प्रोवाइडर की TNAuthList को भी सीमित करना चाहिए। → सुधार: सबमिशन और रिट्रीवल दोनों पर डेस्टिनेशन रेंज को अधिकृत करें।
- गलती: गेटवे निष्कर्षण के बाद PASSporT पर भरोसा करना। → यह क्यों विफल होता है: प्रोटोकॉल के बीच ऑब्जेक्ट को स्थानांतरित करना वेरिफिकेशन का विकल्प नहीं है। → सुधार: वेरिफिकेशन बनाए रखें और गेटवे को न्यूनतम डेलिगेशन दें।
फॉलो-अप्स और प्रतिक्रियाएं
क्या होगा यदि OOB-AS mTLS सर्टिफिकेट लीक हो जाए?
इसे रिवोक करें, इसके सबमिशन अधिकार को रोकें, और इसके प्रोवाइडर स्कोप को अलग करें। पहले से सबमिट किए गए ऑब्जेक्ट्स के लिए अभी भी PASSporT फ्रेशनेस और सिग्नेचर वैलिडेशन की आवश्यकता होती है; केवल कनेक्शन पहचान पर्याप्त नहीं है।
CPS विज्ञापन पर हस्ताक्षर क्यों करें?
विज्ञापन यह निर्धारित करता है कि PASSporT कहाँ सबमिट किया जाना चाहिए। हस्ताक्षर CPS URI को एक SPC या टेलीफोन-नंबर रेंज से बांधता है और हमलावर-नियंत्रित कलेक्टर पर रीडायरेक्शन को रोकता है।
पुल या पुश रिट्रीवल?
पुल सरल है और वास्तविक कॉल द्वारा ट्रिगर होता है। पुश वेरिफिकेशन देरी को कम कर सकता है लेकिन इसके लिए सब्सक्रिप्शन ऑथराइजेशन, बैकलॉग हैंडलिंग और रिवोकेशन की आवश्यकता होती है। बड़े परिनियोजन (deployments) प्रोवाइडर और नंबर रेंज के अनुसार दोनों को संयोजित कर सकते हैं।
क्या CPS अनुपलब्ध होने पर कॉल को ब्लॉक किया जाना चाहिए?
एक एंटी-स्पूफिंग संकेतक को एक नियामक ब्लॉक से अलग रखें। सामान्य कॉल असत्यापित लेबल के साथ जारी रह सकती हैं; उच्च जोखिम वाले प्रवाह में देरी हो सकती है या ब्लॉक किया जा सकता है, लेकिन नीति, टाइमआउट और फॉल्स-पॉजिटिव मेट्रिक्स स्पष्ट होने चाहिए।