Internet Engineering Task Force (IETF)
Request for Comments: 8445
Yerine Geçen: 5245
Kategori: Standartlar İzleme
ISSN: 2070-1721
Yazarlar:
- A. Keränen (Ericsson)
- C. Holmberg (Ericsson)
- J. Rosenberg (jdrosen.net)
Temmuz 2018
#Özet
Bu belge, UDP tabanlı iletişim için Ağ Adresi Çeviricisi (NAT) geçişine yönelik bir protokolü açıklamaktadır. Bu protokol Etkileşimli Bağlantı Kurulumu (Interactive Connectivity Establishment - ICE) olarak adlandırılır. ICE, NAT için Oturum Geçiş Yardımcı Programları (Session Traversal Utilities for NAT - STUN) protokolünü ve onun uzantısı olan NAT Etrafında Aktarım Kullanımı (Traversal Using Relay around NAT - TURN) mekanizmasını kullanır.
Bu belge RFC 5245’in yerine geçmektedir.
#1. Giriş
Eşler arasında iletişim oturumları kuran protokoller genellikle veri kaynakları ve hedefleri için IP adresleri ve portların değişimini içerir. Ancak bu durum, Ağ Adresi Çeviricileri (NAT’ler) [RFC3235] üzerinden çalıştırıldığında zorluklar ortaya çıkarır. Bu protokoller ayrıca, katılımcılar arasında doğrudan bir veri akışı sağlamayı hedefler; böylece aralarında uygulama katmanı aracısı bulunmaz. Bu yaklaşım, veri gecikmesini azaltmak, paket kaybını düşürmek ve uygulamanın devreye alınmasının işletimsel maliyetlerini azaltmak amacıyla benimsenir. Ne var ki, NAT’ler üzerinden bunu başarmak zordur. Bunun nedenlerine ilişkin kapsamlı bir inceleme bu şartnamenin kapsamı dışındadır.
Bu protokollerin NAT’ler üzerinden çalışmasına olanak tanımak için çok sayıda çözüm tanımlanmıştır. Bunlar arasında Uygulama Katmanı Ağ Geçitleri (Application Layer Gateways - ALG’ler), Middlebox Control Protocol [RFC3303], NAT Üzerinden UDP’nin Basit Geçişi (Simple Traversal of UDP Through NAT - STUN) özgün şartnamesi [RFC3489] (RFC 3489’un RFC 5389 tarafından geçersiz kılındığı not edilmelidir) ve bunların çalışmasını sağlamak için gerekli oturum tanımı uzantılarıyla birlikte Realm Specific IP [RFC3102] [RFC3103] yer alır; örneğin Gerçek Zamanlı Kontrol Protokolü (RTCP) [RFC3605] için Oturum Tanım Protokolü (SDP) özniteliği [RFC4566]. Ne yazık ki, bu tekniklerin her birinin, bazı ağ topolojilerinde en uygun olmalarını sağlayan avantajları ve diğerlerinde zayıf bir tercih olmalarına yol açan dezavantajları vardır. Sonuç olarak, yöneticiler ve uygulayıcılar çözümlerinin devreye alınacağı ağların topolojileri hakkında varsayımlarda bulunmaktadır. Bu durum, sisteme karmaşıklık ve kırılganlık ekler.
Bu şartname, UDP tabanlı veri akışları için NAT geçişi tekniği olarak Etkileşimli Bağlantı Kurulumu (ICE)’ni tanımlar (ICE, TCP [RFC6544] gibi diğer taşıma protokollerini ele alacak şekilde de genişletilmiştir). ICE, çok sayıda IP adresi ve portu değiş tokuş ederek çalışır; ardından bunlar, eşler arası bağlanırlık denetimleri ile test edilir. IP adresleri ve portlar, ICE kullanımına özgü mekanizmalarla (örneğin bir Teklif/Yanıt değişimi içinde) aktarılır ve bağlanırlık denetimleri STUN [RFC5389] kullanılarak gerçekleştirilir. ICE ayrıca, STUN’un bir uzantısı olan NAT Etrafında Aktarım Kullanımı (TURN) [RFC5766] mekanizmasından yararlanır. ICE, her bir ortam akışı için çok sayıda IP adresi ve port değiş tokuş ettiğinden, çoklu bağlantılı (multihomed) ve çift yığınlı (dual-stack) ana makineler için adres seçimine de olanak tanır. Bu nedenle, RFC 5245 [RFC5245], daha önce RFC 4091 [RFC4091] ve RFC 4092 [RFC4092]’de tanımlanan çözümleri kullanım dışı bırakmıştır.
Ek B, ICE tasarlanırken alınan tasarım kararlarına ilişkin arka plan bilgileri ve gerekçeler sunar.
#2. ICE’ye Genel Bakış
Tipik bir ICE dağıtımında, iletişim kurmak isteyen iki uç nokta (ICE aracısı) bulunur. ICE’nin, sinyalizasyon protokolü için NAT geçişi sağlamayı amaçlamadığına dikkat edilmelidir; sinyalizasyonun başka bir mekanizma aracılığıyla sağlandığı varsayılır. ICE, aracıların birbirleri arasında bir sinyalizasyon bağlantısı kurabildiklerini kabul eder.
Başlangıçta, aracıların kendi topolojileri hakkında bilgisi yoktur. Özellikle, aracıların NAT’lerin arkasında olup olmadıkları (veya birden fazla NAT katmanının arkasında bulunup bulunmadıkları) bilinmeyebilir. ICE, aracıların, bir veri oturumu kurabilecekleri bir veya daha fazla yolu potansiyel olarak bulmalarına yetecek kadar topoloji bilgisini keşfetmelerine olanak tanır.
Şekil 1 tipik bir ICE dağıtımını göstermektedir. Aracılar L ve R olarak etiketlenmiştir. Hem L hem de R kendi NAT’lerinin arkasındadır; ancak bunun farkında olmayabilirler. NAT türü ve özellikleri de bilinmemektedir. L ve R, L ile R arasında bir veri oturumu kurmayı amaçlayan bir aday değişim sürecine katılabilecek durumdadır. Tipik olarak bu değişim, bir sinyalizasyon sunucusu (örneğin bir SIP proxy) üzerinden gerçekleşir.
Aracılara, bir sinyalizasyon sunucusuna ve NAT’lere ek olarak, ICE genellikle ağdaki STUN veya TURN sunucuları ile birlikte kullanılır. Her bir aracının kendi STUN veya TURN sunucusu olabilir ya da bunlar aynı sunucu olabilir.
+---------+
+--------+ |Sinyalizasyon| +--------+
| STUN | |Sunucusu | | STUN |
| Sunucu | +---------+ | Sunucu |
+--------+ / \ +--------+
/ \
/ \
/ <- Sinyalizasyon -> \
/ \
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
/ \
/ \
+-------+ +-------+
| Aracı | | Aracı |
| L | | R |
+-------+ +-------+
Şekil 1: ICE Dağıtım SenaryosuICE’nin temel fikri şudur: her aracının, diğer aracıyla iletişim kurmak için kullanabileceği çeşitli aday taşıma adresleri vardır (bu şartnamede her zaman UDP olan belirli bir taşıma protokolü için IP adresi ve port birleşimi). Bunlar şunları içerebilir:
- Doğrudan bağlı bir ağ arabirimi üzerindeki bir taşıma adresi
- Bir NAT’in genel tarafındaki çevrilmiş bir taşıma adresi (sunucu-yansıtmalı adres)
- Bir TURN sunucusundan tahsis edilmiş bir taşıma adresi (aktarımlı adres)
Potansiyel olarak, L’nin aday taşıma adreslerinden herhangi biri, R’nin aday taşıma adreslerinden herhangi biriyle iletişim kurmak için kullanılabilir. Ancak pratikte, birçok kombinasyon çalışmayacaktır. Örneğin, L ve R her ikisi de NAT’lerin arkasındaysa, doğrudan bağlı arabirim adreslerinin doğrudan iletişim kurabilmesi olası değildir (zaten ICE’ye ihtiyaç duyulmasının nedeni budur). ICE’nin amacı, hangi adres çiftlerinin çalışacağını keşfetmektir. ICE bunu, olası tüm çiftleri (dikkatle sıralanmış bir düzende) sistematik olarak deneyerek, çalışan bir veya daha fazla çift bulana kadar yapar.
2.1. Adayların Toplanması
ICE’yi yürütmek için bir ICE aracısı, bir veya daha fazla adres adayını belirler ve toplar. Bir aday, bir taşıma adresine sahiptir — belirli bir taşıma protokolü için IP adresi ve port birleşimi (burada yalnızca UDP belirtilmiştir). Farklı aday türleri vardır; bazıları fiziksel veya mantıksal ağ arabirimlerinden türetilir, diğerleri ise STUN ve TURN aracılığıyla keşfedilebilir.
Adayların ilk kategorisi, doğrudan yerel bir arabirimden elde edilen bir taşıma adresine sahip olanlardır. Böyle bir aday ana makine adayı olarak adlandırılır. Yerel arabirim Ethernet veya Wi‑Fi olabilir ya da Sanal Özel Ağ (Virtual Private Network - VPN) veya Mobil IP (Mobile IP - MIP) gibi bir tünelleme mekanizması üzerinden elde edilmiş olabilir. Tüm durumlarda, böyle bir ağ arabirimi aracıya, portların (ve dolayısıyla adayların) tahsis edilebildiği bir yerel arabirim olarak görünür.
Ardından, aracı STUN veya TURN kullanarak ek adaylar elde eder. Bunlar iki türdedir: bir NAT’in genel tarafındaki dönüştürülmüş adresler (sunucu-yansıtmalı adaylar) ve TURN sunucularındaki adresler (aktarılan adaylar). TURN sunucuları kullanıldığında, her iki aday türü de TURN sunucusundan elde edilir. Yalnızca STUN sunucuları kullanıldığında ise, bunlardan sadece sunucu-yansıtmalı adaylar elde edilir. Bu adayların ana makine adayıyla ilişkisi Şekil 2’de gösterilmiştir. Bu şekilde, her iki aday türü de TURN kullanılarak keşfedilmektedir. Şekilde, X:x gösterimi IP adresi X ve UDP portu x anlamına gelir.
İnternete
|
|
| /------------ Aktarılan
Y:y | / Adres
+--------+
| |
| TURN |
| Sunucu |
| |
+--------+
|
|
| /------------ Sunucu-
X1':x1'|/ Yansıtmalı
+------------+ Adres
| NAT |
+------------+
|
| /------------ Yerel
X:x |/ Adres
+--------+
| |
| Aracı |
| |
+--------+
Şekil 2: Aday İlişkileriAracı, IP adresi ve portu X:x olan bir TURN Allocate isteği gönderdiğinde, NAT (varsayım olarak varsa) X1':x1' bağlamasını oluşturur ve bu sunucu-yansıtmalı adayı ana makine adayı X:x ile eşler. Ana makine adayından gönderilen giden paketler NAT tarafından sunucu-yansıtmalı adaya dönüştürülür. Sunucu-yansıtmalı adaya gönderilen gelen paketler NAT tarafından ana makine adayına dönüştürülür ve aracıya iletilir. Belirli bir sunucu-yansıtmalı adayla ilişkili ana makine adayı tabandır.
Not: "Taban", bir aracı tarafından belirli bir aday için gönderim yapılan adresi ifade eder. Dolayısıyla, dejenere bir durum olarak, ana makine adaylarının da bir tabanı vardır, ancak bu taban ana makine adayının kendisiyle aynıdır.
Aracı ile TURN sunucusu arasında birden fazla NAT bulunduğunda, TURN isteği her NAT üzerinde bir bağlama oluşturur; ancak yalnızca en dıştaki sunucu-yansıtmalı aday (TURN sunucusuna en yakın olan) aracı tarafından keşfedilir. Aracı bir NAT arkasında değilse, taban aday sunucu-yansıtmalı adayla aynı olacaktır ve sunucu-yansıtmalı aday gereksizdir ve elenir.
Allocate isteği daha sonra TURN sunucusuna ulaşır. TURN sunucusu, yerel IP adresi Y üzerinden bir port y ayırır ve aracıya bu aktarılan adayı bildiren bir Allocate yanıtı üretir. TURN sunucusu ayrıca, Allocate isteğinin kaynak taşıma adresini Allocate yanıtına kopyalayarak aracıya sunucu-yansıtmalı aday X1':x1' bilgisini bildirir. TURN sunucusu bir paket aktarıcı olarak davranır ve L ile R arasındaki trafiği iletir. L’ye trafik göndermek için R, Y:y adresindeki TURN sunucusuna trafik gönderir ve TURN sunucusu bunu X1':x1' adresine iletir; bu trafik NAT’tan geçerken X:x adresine eşlenir ve L’ye teslim edilir.
Yalnızca STUN sunucuları kullanıldığında, aracı STUN sunucusuna bir STUN Binding isteği [RFC5389] gönderir. STUN sunucusu, Binding isteğinin kaynak taşıma adresini Binding yanıtına kopyalayarak aracıya sunucu-yansıtmalı aday X1':x1' bilgisini bildirir.
2.2. Bağlanırlık Kontrolleri
L tüm adaylarını topladıktan sonra, bunları en yüksekten en düşüğe önceliğe göre sıralar ve sinyalleşme kanalı üzerinden R’ye gönderir. R, L’den adayları aldığında, aynı toplama sürecini gerçekleştirir ve kendi aday listesini gönderir. Bu sürecin sonunda, her ICE aracısı hem kendi adaylarının hem de eşinin adaylarının tam bir listesine sahip olur. Bunları eşleştirerek aday çiftlerini oluşturur. Hangi çiftlerin çalıştığını görmek için her aracı bir dizi bağlanırlık kontrolü planlar. Her kontrol, yerel adaydan uzak adaya bir STUN isteği gönderilerek belirli bir aday çifti üzerinde gerçekleştirilen bir STUN istek/yanıt işlemidir.
Bağlanırlık kontrollerinin temel ilkesi basittir:
- Aday çiftlerini öncelik sırasına göre sırala.
- Aday çiftlerinin her biri üzerinde öncelik sırasına göre kontroller gönder.
- Diğer aracının gönderdiği kontrolleri onayla.
Her iki aracının da bir aday çifti üzerinde kontrol gerçekleştirmesiyle sonuç, dört yönlü bir el sıkışmadır:
L R
- -
STUN isteği -> \ L’nin
<- STUN yanıtı / kontrolü
<- STUN isteği \ R’nin
STUN yanıtı -> / kontrolü
Şekil 3: Temel Bağlanırlık KontrolüSTUN isteklerinin, veri için kullanılacak olan IP adresleri ve portlarla (ör. RTP, RTCP veya diğer protokoller) birebir aynı adreslere gönderilip alındığını belirtmek önemlidir. Bu nedenle, aracılar STUN ve veriyi, alındıkları porta göre değil paketlerin içeriğine göre ayırır.
Bağlanırlık kontrolü için bir STUN Binding isteği kullanıldığından, STUN Binding yanıtı aracının, aracı ile eşi arasındaki herhangi bir NAT’in genel tarafındaki dönüştürülmüş taşıma adresini içerecektir. Bu taşıma adresi, aracının daha önce öğrendiği diğer adaylardan farklıysa, yeni bir adayı (eş-yansıtmalı aday) temsil eder ve bu aday da ICE tarafından diğer adaylarla aynı şekilde test edilir.
Yukarıdaki algoritma tüm aday çiftlerini aradığından, çalışan bir çift mevcutsa, adayların hangi sırayla denendiğinden bağımsız olarak algoritma sonunda onu bulacaktır. Daha hızlı (ve daha iyi) sonuçlar üretmek için adaylar belirli bir sıraya göre sıralanır. Ortaya çıkan sıralı aday çifti listesine kontrol listesi denir.
Aracı, listedeki bir sonraki aday çifti için periyodik olarak bir STUN isteği göndererek kontrol listesi üzerinde ilerler. Bunlara olağan kontroller denir. Bir STUN işlemi başarılı olduğunda, bir veya daha fazla aday çifti geçerli çiftler olarak adlandırılır ve geçerli liste adı verilen bir aday-çifti listesine eklenir.
Bir iyileştirme olarak, R, L’nin kontrol mesajını alır almaz, aynı aday çifti üzerinde L’ye gönderilecek bir bağlanırlık kontrolü mesajı planlar. Buna tetiklenmiş kontrol denir ve geçerli çiftlerin bulunma sürecini hızlandırır.
Bu el sıkışmanın sonunda, hem L hem de R, uçtan uca her iki yönde de mesaj gönderebildiklerini (ve alabildiklerini) bilir.
Genel olarak, öncelik algoritması, benzer türdeki adayların benzer öncelikler alacak şekilde tasarlanmıştır; böylece daha doğrudan yollar (yani veri aktarıcıları veya NAT’ler içermeyen yollar), dolaylı yollara (veri aktarıcıları veya NAT’ler içeren yollar) tercih edilir. Ancak bu yönergeler çerçevesinde, aracılar algoritmalarını ayarlama konusunda önemli ölçüde takdir yetkisine sahiptir.
Bir veri akışı birden fazla bileşenden oluşabilir (ör. RTP ve RTCP gibi, kendi aday kümelerini gerektiren bir veri akışının parçaları).
2.3. Aday Çiftlerinin Aday Gösterilmesi ve ICE’in Sonlandırılması
ICE, ICE aracılarından birine denetleyici aracı, diğerine ise denetlenen aracı rolünü atar. Bir veri akışının her bir bileşeni için denetleyici aracı, veri için kullanılacak geçerli bir çifti (geçerli listeden) aday gösterir. Aday göstermenin kesin zamanlaması yerel politikaya bağlıdır.
Aday gösterme sırasında, denetleyici aracı, bir veri akışının her bir bileşeni için en az bir geçerli çift bulunana kadar kontrollerin devam etmesine izin verir ve ardından bir geçerli çifti seçer; bu çift üzerinde, denetlenen eşe aday gösterildiğini belirtmek için bir öznitelik kullanarak bir STUN isteği gönderir. Bu durum Şekil 4’te gösterilmiştir.
L R
- -
STUN isteği -> \ L’nin
<- STUN yanıtı / kontrolü
<- STUN isteği \ R’nin
STUN yanıtı -> / kontrolü
STUN isteği + öznitelik -> \ L’nin
<- STUN yanıtı / kontrolü
Şekil 4: Aday GöstermeDenetlenen aracı, öznitelik içeren STUN isteğini aldığında, (kontrol daha önce yapılmamışsa) aynı çifti kontrol eder. Yukarıdaki işlemler başarılı olursa, aracılar çiftler için aday gösterildi bayrağını ayarlar ve veri akışının o bileşeni için gelecekteki tüm kontrolleri iptal eder. Bir aracı, bir veri akışının her bileşeni için aday gösterildi bayrağını ayarladığında, bu çiftler seçilen çiftler haline gelir. Bundan sonra, yalnızca seçilen çiftler, o veri akışıyla ilişkili verilerin gönderilmesi ve alınması için kullanılır.
2.4. ICE Yeniden Başlatma
ICE sonlandırıldıktan sonra, ICE aracılarından herhangi biri tarafından, veri akışlarının biri veya tümü için herhangi bir zamanda yeniden başlatılabilir. Bu, yeniden başlatmayı belirten güncellenmiş aday bilgilerinin gönderilmesiyle yapılır.
2.5. Lite Uygulamalar
Bazı ICE aracılarının her zaman genel İnternet’e bağlı olduğu ve herhangi bir muhataptan paket alabileceği genel bir IP adresine sahip olduğu durumlar vardır. Bu cihazların ICE’i desteklemesini kolaylaştırmak için, ICE, normal tam uygulamanın aksine "lite" adı verilen özel bir uygulama türü tanımlar. Lite aracılar yalnızca ana makine adaylarını kullanır ve bağlanırlık kontrolleri üretmez veya durum makineleri çalıştırmaz; ancak bağlanırlık kontrollerine yanıt verebilmeleri gerekir.
#3. ICE Kullanımı
Bu belge, ICE aracılarının aday bilgilerini değiştirmesine olanak sağlayan protokollerle ICE’in genel kullanımını belirtir. ICE kullanan farklı protokoller ("kullanan protokol" olarak anılır) için özel ayrıntılar (yani aday bilgisinin nasıl kodlanacağı ve gerçek aday değişim süreci) ayrı kullanım belgelerinde açıklanmaktadır.
Aday bilgilerini değiştirmeye olanak tanıyan bir mekanizma, SIP protokolünün [RFC3261] bir parçası olarak Offer/Answer anlambiliminin ([RFC3264]’e dayalı) kullanılmasıdır [ICE-SIP-SDP].
[RFC7825], Gerçek Zamanlı Akış Protokolü (RTSP) için bir ICE kullanımını tanımlar. Ancak, ICE kullanımının RFC 5245’e dayandığını unutmayın.
#4. Terimler
Bu belgede yer alan "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, yalnızca ve yalnızca burada gösterildiği gibi tümü büyük harflerle göründüklerinde, BCP 14 [RFC2119] [RFC8174]’te açıklandığı şekilde yorumlanacaktır.
Okuyucuların [RFC5389]’da tanımlanan terminolojiye ve UDP için NAT Davranışsal gereksinimlerine [RFC4787] aşina olması gerekir.
Bu belirtim aşağıdaki ek terminolojiyi kullanır:
ICE Oturumu: Bir ICE oturumu, adayların toplanmasıyla başlayan ve tüm adaylar serbest bırakılana veya bir ICE yeniden başlatması tetiklenene kadar ICE aracılarının arasındaki etkileşimleri (aday değişimi, bağlanırlık kontrolleri, aday gösterme ve canlı tutma) izleyen, ICE ile ilgili tüm eylemleri kapsar.
ICE Aracısı, Aracı: Bir ICE aracısı (bazen kısaca "aracı" olarak anılır), ICE aday değişimine dahil olan protokol uygulamasıdır. Tipik bir aday değişiminde iki aracı yer alır.
Başlatan Eş, Başlatan Aracı, Başlatıcı: Başlatan aracı, ICE aday değişim sürecini başlatan ICE aracısıdır.
Yanıtlayan Eş, Yanıtlayan Aracı, Yanıtlayıcı: Yanıtlayan aracı, başlatan aracı tarafından başlatılan aday değişim sürecini alan ve yanıtlayan ICE aracısıdır.
ICE Aday Değişimi, Aday Değişimi: ICE’i gerçekleştirmek için gereken bilgilerin (ör. adaylar ve parolalar) ICE aracılarının arasında değiştirildiği süreçtir. SDP kodlamasıyla Offer/Answer [RFC3264], aday bilgisini değiştirmek için kullanılabilecek protokollere bir örnektir.
Eş: Bir oturumdaki ICE aracılarından birinin bakış açısından, eşi diğer aracıdır. Özellikle, başlatan aracının bakış açısından eş, yanıtlayan aracıdır. Yanıtlayan aracının bakış açısından ise eş, başlatan aracıdır.
Taşıma Adresi: Bir IP adresi ile taşıma protokolü (UDP veya TCP gibi) portunun birleşimi.
Veri, Veri Akışı, Veri Oturumu: ICE veri oturumlarını kurmak için kullanıldığında, veri bazı protokoller kullanılarak taşınır. Medya genellikle RTP üzerinden, bir RTP paketleri akışı olarak taşınır. Veri oturumu, ICE ile oluşturulan ve test edilen yol üzerinde eşler arasında değiş tokuş edilen veri paketlerini ifade eder.
Aday, Aday Bilgisi: Verinin alınması için potansiyel bir temas noktası olan bir taşıma adresi. Adayların ayrıca özellikleri vardır — türleri (sunucu-yansıtmalı, aktarılan veya ana makine), öncelik, temel (foundation) ve taban.
Bileşen: Bir bileşen, bir veri akışının bir parçasıdır. Bir veri akışı, tamamının çalışabilmesi için her birinin çalışması gereken birden fazla bileşen gerektirebilir. RTP/RTCP veri akışları için, RTP ve RTCP aynı portta çoklanmadıkça, veri akışı başına iki bileşen vardır — biri RTP için, diğeri RTCP için. Bir bileşenin bir aday çifti vardır ve bu çift diğer bileşenler tarafından kullanılamaz.
Ana Makine Adayı: Ana makine üzerindeki bir IP adresinden belirli bir porta bağlanarak elde edilen aday. Buna fiziksel arayüzlerdeki IP adresleri ve VPN’ler aracılığıyla elde edilenler gibi mantıksal adresler dahildir.
Sunucu-Yansıtmalı Aday: Bir ICE aracısı bir sunucuya (ör. bir STUN sunucusu) NAT üzerinden bir paket gönderdikten sonra, NAT tarafından ayrılan bir bağlama olan IP adresi ve porttan oluşan aday.
Eş-Yansıtmalı Aday: Bir ICE aracısı, eşine NAT üzerinden bir paket gönderdikten sonra, NAT tarafından ayrılan bir bağlama olan IP adresi ve porttan oluşan aday.
Aktarılan Aday: Bir TURN sunucusu gibi bir aktarıcı sunucudan elde edilen aday.
Taban: Bir ICE aracısının belirli bir aday için gönderim yaptığı taşıma adresi. Ana makine, sunucu-yansıtmalı ve eş-yansıtmalı adaylar için taban, ana makine adayıyla aynıdır. Aktarılan adaylar için taban, aktarılan adayla aynıdır (yani TURN sunucusunun gönderim yaptığı taşıma adresi).
İlişkili Adres ve Port: Tanılama ve diğer amaçlar için yararlı olan, bir adayla ilişkili bir taşıma adresi. Bir aday sunucu veya eş-yansıtmalı ise, ilişkili adres ve port o sunucu veya eş-yansıtmalı aday için tabana eşittir. Aday aktarılan ise, ilişkili adres ve port, istemciye bu aktarılan adayı sağlayan Allocate yanıtındaki eşlenmiş adrese eşittir. Aday bir ana makine adayı ise, ilişkili adres ve port ana makine adayıyla özdeştir.
Foundation: Dondurma algoritmasında benzer adayları gruplamak için kullanılan isteğe bağlı bir dizge. Aynı türe, aynı temel IP adresine, aynı protokole (UDP, TCP vb.) ve aynı STUN veya TURN sunucusuna sahip iki aday için aynıdır. Bunlardan herhangi biri farklıysa, foundation da farklı olacaktır.
Yerel Aday (Local Candidate): Bir ICE aracısının elde ettiği ve eşine gönderebileceği aday.
Uzak Aday (Remote Candidate): Bir ICE aracısının eşinden aldığı aday.
Varsayılan Hedef/Aday (Default Destination/Candidate): Bir veri akışının bir bileşeni için varsayılan hedef, ICE farkındalığı olmayan bir ICE aracısının kullanacağı taşıma adresidir. Bir bileşen için varsayılan aday, taşıma adresi o bileşen için varsayılan hedefle eşleşen adaydır.
Aday Çifti (Candidate Pair): Bir yerel aday ve bir uzak aday içeren çift.
Kontrol, Bağlantı Kontrolü, STUN Kontrolü (Check, Connectivity Check, STUN Check): Bağlantıyı doğrulamak amacıyla yapılan bir STUN Binding isteği. Bir kontrol, bir aday çiftindeki yerel adayın tabanından uzak adaya gönderilir.
Kontrol Listesi (Checklist): Bir ICE aracısının kontrolleri üretmek için kullanacağı sıralı aday çiftleri kümesi.
Olağan Kontrol (Ordinary Check): Periyodik olarak tetiklenen bir zamanlayıcının, bir kontrol gönderilmesini talimatlandırması sonucunda bir ICE aracısı tarafından üretilen bağlantı kontrolü.
Tetiklenmiş Kontrol (Triggered Check): Eşten bir bağlantı kontrolü alınmasının sonucu olarak üretilen bağlantı kontrolü.
Geçerli Çift (Valid Pair): Yerel adayı, başarılı bir bağlantı kontrolü yanıtının eşlenen adresine eşit olan ve uzak adayı, bağlantı kontrolü isteğinin gönderildiği hedef adrese eşit olan aday çifti.
Geçerli Liste (Valid List): Başarılı bir STUN işlemiyle doğrulanmış, bir veri akışı için sıralı aday çiftleri kümesi.
Kontrol Listesi Kümesi (Checklist Set): Tüm kontrol listelerinin sıralı listesi. Sıra, her bir ICE kullanımı tarafından belirlenir.
Tam Uygulama (Full Implementation): Bu belirtimde tanımlanan işlevlerin tümünü yerine getiren bir ICE uygulaması.
Lite Uygulama (Lite Implementation): Bazı işlevleri dışarıda bırakan, ICE olmayan bir eşin ICE’in faydalarını elde etmesi için gerekli olan kadarını uygulayan bir ICE uygulaması. Lite uygulamalar herhangi bir durum makinesini sürdürmez ve bağlantı kontrolleri üretmez.
Denetleyici Aracı (Controlling Agent): Bir aday çiftini aday gösteren ICE aracısı. Her oturumda her zaman bir denetleyici aracı ve bir denetlenen aracı vardır.
Denetlenen Aracı (Controlled Agent): Denetleyici aracının bir aday çiftini aday göstermesini bekleyen ICE aracısı.
Aday Gösterme (Nomination): Denetleyici aracının, ICE aracılarının veri gönderme ve alma için hangi aday çiftini kullanacağını denetlenen aracıya bildirmesi süreci. Bu belirtimde tanımlanan aday gösterme süreci, RFC 5245’te “regular nomination” olarak adlandırılmıştır. RFC 5245’te “aggressive nomination” olarak adlandırılan aday gösterme süreci bu belirtimde kullanımdan kaldırılmıştır.
Aday Gösterilmiş, Aday Gösterme Bayrağı (Nominated, Nominated Flag): Bir aday çiftinin aday gösterilmesi başarıyla tamamlandığında, aday çifti aday gösterilmiş olur ve aday gösterme bayrağının değeri true olarak ayarlanır.
Seçilmiş Çift, Seçilmiş Aday Çifti (Selected Pair, Selected Candidate Pair): Bir veri akışının bir bileşeni için veri gönderme ve alma amacıyla kullanılan aday çiftine “seçilmiş çift” denir. Bir veri akışı için seçilmiş çiftler üretilmeden önce, veri akışının bir bileşeniyle ilişkili herhangi bir geçerli çift, bileşen için veri gönderme ve alma amacıyla kullanılabilir. Bir veri akışının her bir bileşeni için aday gösterilmiş çiftler oluştuğunda, aday gösterilmiş çiftler veri akışı için seçilmiş çiftler haline gelir. Seçilmiş çiftlerle ilişkili adaylara “seçilmiş adaylar” denir.
Kullanan Protokol, ICE Kullanımı (Using Protocol, ICE Usage): NAT geçişi için ICE kullanan protokol. Bir kullanım belirtimi, burada tanımlanan yordamların o protokole nasıl uygulandığına ilişkin protokole özgü ayrıntıları tanımlar.
Zamanlayıcı Ta (Timer Ta): Yeni STUN veya TURN işlemleri üretmek için kullanılan zamanlayıcı.
Zamanlayıcı RTO (Yeniden İletim Zaman Aşımı) (Timer RTO, Retransmission Timeout): Belirli bir STUN veya TURN işlemi için yeniden iletim zamanlayıcısı.
#5. ICE Adaylarının Toplanması ve Değişimi
ICE işlemenin bir parçası olarak, hem başlatan hem de yanıtlayan aracılar adayları toplar, önceliklendirir ve gereksiz adayları eler; ayrıca, kullanan protokol (ICE kullanımı) tarafından tanımlandığı şekilde aday bilgilerini eşle değiş tokuş eder. Aday kodlama mekanizmasının ayrıntıları ve aday bilgisi değişiminin anlambilimi bu belirtimin kapsamı dışındadır.
5.1. Tam Uygulama
5.1.1. Adayların Toplanması
Bir ICE aracısı, iletişimin yakın olduğuna inandığında adayları toplar. Başlatan bir aracı bunu bir kullanıcı arayüzü ipucuna veya bir oturumu başlatmak için yapılan açık bir isteğe dayanarak yapabilir. Her adayın bir taşıma adresi vardır. Ayrıca bir türü ve bir tabanı vardır. Bu belirtim tarafından tanımlanan ve toplanan dört tür vardır: ana bilgisayar (host) adayları, sunucu-yansıtmalı (server-reflexive) adaylar, eş-yansıtmalı (peer-reflexive) adaylar ve yönlendirilmiş (relayed) adaylar. Sunucu-yansıtmalı adaylar STUN veya TURN kullanılarak toplanır ve yönlendirilmiş adaylar TURN üzerinden elde edilir. Eş-yansıtmalı adaylar, ICE’in daha sonraki aşamalarında, bağlantı kontrollerinin bir sonucu olarak elde edilir.
Yanıtlayan aracıda adayların toplanması süreci, başlatan aracıdaki süreçle aynıdır. Yanıtlayan aracının, ICE oturumuyla ilişkili uygulamanın kullanıcısını uyarmadan önce, aday bilgilerini alır almaz bu süreci başlatması TAVSİYE EDİLİR.
5.1.1.1. Ana Bilgisayar Adayları
Ana bilgisayar adayları, ana bilgisayardaki bir arabirime (fiziksel veya sanal, VPN arabirimleri dahil) bağlı bir IP adresi üzerindeki portlara bağlanarak elde edilir.
ICE aracısının kullanmak istediği her veri akışının her bir bileşeni için, aşağıda listelenen istisnalar dışında, ana bilgisayarın sahip olduğu her IP adresi üzerinde bir aday elde edilmesi GEREKİR. Aracı, her bir adayı belirli IP adresi üzerindeki bir UDP portuna bağlanarak elde eder. Bir ana bilgisayar adayı (ve aslında her aday) her zaman aday olduğu belirli bir bileşenle ilişkilidir.
Her bileşene “bileşen kimliği” (component ID) adı verilen bir kimlik atanır. RTP/RTCP veri akışları için, RTP ve RTCP aynı UDP portunda çoğullanmıyorsa (RTP/RTCP çoğullama), RTP’nin bileşen kimliği 1’dir ve RTCP’nin bileşen kimliği 2’dir. RTP/RTCP çoğullama durumunda, hem RTP hem de RTCP için bileşen kimliği olarak 1 kullanılır.
Adaylar elde edildiğinde, aracı RTP/RTCP çoğullamanın kesinlikle kullanılacağını bilmiyorsa (yani, diğer aracının da RTP/RTCP çoğullamayı desteklediğini ve kullanmaya istekli olduğunu biliyorsa) ya da aracı yalnızca RTP/RTCP çoğullamayı destekliyorsa, RTCP için ayrı bir aday elde ETMEK ZORUNDADIR. Bir aracı RTCP için bir aday elde etmişse ve sonunda RTP/RTCP çoğullamayı kullanıyorsa, RTCP adayı üzerinde bağlantı kontrolleri yapmasına gerek yoktur. Bileşen kimliği 2’nin yokluğu, RTCP/RTP çoğullamanın kullanıldığı anlamına gelmez; bu durum RTCP’nin kullanılmadığı anlamına da gelebilir.
Bir aracı RTP ve RTCP için ayrı adaylar kullanıyorsa, K IP adresine sahip bir aracı için sonuçta 2*K ana bilgisayar adayı olacaktır.
Yanıtlayan aracının, adaylarını elde ederken, genellikle diğer aracının RTP/RTCP çoğullamayı destekleyip desteklemediğini bileceği ve bu durumda RTCP için ayrı bir aday elde etmesine gerek kalmayacağı unutulmamalıdır. Ancak bileşen kimliği 2’nin yokluğu, RTCP/RTP çoğullamanın kullanıldığı anlamına gelmez; bu durum RTCP’nin kullanılmadığı anlamına da gelebilir.
RTP/RTCP akışları dışındaki birden fazla bileşenin kullanımı, ICE işlemenin karmaşıklığını artırdığı için caydırılır. Birden fazla bileşen gerekiyorsa, bileşen kimlikleri 1’den başlamalı ve her bileşen için 1 artmalıdır.
Her ana bilgisayar adayının tabanı, adayın kendisi olarak ayarlanır.
Ana bilgisayar adayları, aşağıdaki istisnalarla tüm IP adreslerinden toplanır:
- Loopback arabiriminden gelen adresler aday adreslerine DAHİL EDİLMEMELİDİR.
- Kullanımdan kaldırılmış IPv4-uyumlu IPv6 adresleri [RFC4291] ve IPv6 site-yerel tekil adresler [RFC3879] adres adaylarına DAHİL EDİLMEMELİDİR.
- IPv4-eşlemeli IPv6 adresleri, ICE kullanan uygulama IPv4’ü desteklemiyorsa (yani yalnızca IPv6 kullanan bir uygulamaysa [RFC4038]) adres adaylarına DAHİL EDİLMEMELİDİR.
- Konum takibini engelleyen bir mekanizma kullanılarak üretilmiş bir IPv6 adresine karşılık gelen bir veya daha fazla ana bilgisayar adayı toplanıyorsa [RFC7721], konum takibine izin veren, aynı arabirim üzerinde yapılandırılmış ve aynı ağ önekine ait IPv6 adreslerine karşılık gelen ana bilgisayar adayları TOPLANMAMALIDIR. Benzer şekilde, konum takibini engelleyen bir mekanizma kullanılarak üretilmiş bir IPv6 adresine karşılık gelen ana bilgisayar adayları toplandığında, IPv6 bağlantı-yerel adreslerine [RFC4291] karşılık gelen ana bilgisayar adayları TOPLANMAMALIDIR.
IPv6 varsayılan adres seçimi belirtimi [RFC6724], geçici adreslerin [RFC4941] kalıcı adreslere tercih edilmesi gerektiğini belirtir.
5.1.1.2. Sunucu-Yansıtmalı ve Yönlendirilmiş Adaylar
Bir ICE aracısının sunucu-yansıtmalı ve yönlendirilmiş adayları toplaması TAVSİYE EDİLİR. Ancak, bazı ağlarda STUN ve TURN sunucularının kullanımı gereksiz olabilir ve TURN sunucularının kullanımı maliyetli olabilir; bu nedenle bazı dağıtımlar bunları kullanmamayı tercih edebilir. Bir aracı sunucu-yansıtmalı veya yönlendirilmiş adayları toplamıyorsa, işlevselliğin uygulanmış olması ve yalnızca yapılandırma yoluyla devre dışı bırakılması TAVSİYE EDİLİR; böylece gelecekte koşullar değişirse yapılandırma yoluyla yeniden etkinleştirilebilir.
Aracı, her ana bilgisayar adayını yapılandırılmış olduğu veya bir şekilde keşfettiği STUN veya TURN sunucularıyla eşleştirir. Bir alan adının yapılandırılması, STUN sunucusunu keşfetmek için [RFC5389]’daki DNS yordamlarının (“stun” hizmetiyle SRV kayıtları kullanılarak) ve TURN sunucusunu keşfetmek için [RFC5766]’daki DNS yordamlarının (“turn” hizmetiyle SRV kayıtları kullanılarak) kullanılması TAVSİYE EDİLİR.
Birden fazla STUN veya TURN sunucusu mevcut olduğunda (ya da DNS kayıtları aracılığıyla öğrenildiklerinde ve birden fazla sonuç döndüğünde), aracı bunların tümü için adaylar toplayabilir ve en az biri için (bir STUN sunucusu ve bir TURN sunucusu) adaylar toplamalıdır. Bunu, ana bilgisayar adaylarını STUN veya TURN sunucularıyla eşleştirerek yapar ve her bir çift için aracı, ana bilgisayar adayından sunucuya bir Binding veya Allocate isteği gönderir. STUN sunucusuna gönderilen Binding istekleri kimlik doğrulamalı değildir ve yanıttaki herhangi bir ALTERNATE-SERVER özniteliği yok sayılır. Aracılar, [RFC5389]’da tanımlanan Binding isteği için geriye dönük uyumluluk kipini desteklemek ZORUNDADIR. Allocate istekleri, istemci tarafından başka yollarla elde edilen uzun süreli bir kimlik bilgisi kullanılarak kimlik doğrulamalı OLMALIDIR.
Toplama süreci Ta zamanlayıcısı kullanılarak denetlenir. Ta her sona erdiğinde, aracı yeni bir STUN veya TURN işlemi üretebilir. Bu işlem, kurtarılabilir bir hatayla (kimlik doğrulama hatası gibi) başarısız olmuş önceki bir işlemin yeniden denenmesi ya da yeni bir ana bilgisayar adayı ile STUN veya TURN sunucusu çifti için bir işlem olabilir. Aracı, her Ta sona ermesi başına bir kereden daha sık işlem üretmemelidir. Ta’nın ve STUN yeniden iletim zamanlayıcısı RTO’nun nasıl ayarlanacağına ilişkin yönlendirme için Bölüm 14’e bakınız.
Aracı bir Binding veya Allocate yanıtı alacaktır. Başarılı bir Allocate yanıtı, aracıyı sunucu-yansıtmalı bir adayla (eşlenen adresten elde edilen) ve XOR-RELAYED-ADDRESS özniteliğinde bir yönlendirilmiş adayla sağlar. Allocate isteği, sunucunun bunu karşılayacak kaynaklara sahip olmaması nedeniyle reddedilirse, aracı bunun yerine bir sunucu-yansıtmalı aday elde etmek için bir Binding isteği göndermelidir. Bir Binding yanıtı, aracıyı yalnızca bir sunucu-yansıtmalı adayla (yine eşlenen adresten elde edilen) sağlar. Sunucu-yansıtmalı adayın tabanı, Allocate veya Binding isteğinin gönderildiği ana bilgisayar adayıdır. Yönlendirilmiş adayın tabanı, adayın kendisidir. Bir yönlendirilmiş aday bir ana bilgisayar adayıyla aynıysa (nadir durumlarda olabilir), yönlendirilmiş aday ATILMALIDIR.
Yalnızca IPv6 kullanan bir aracı, NAT64 [RFC6146] ve DNS64 [RFC6147] teknolojilerini kullanan bir ağdaysa, yalnızca IPv4 kullanan STUN veya TURN sunucularından IPv4 sunucu-yansıtmalı ve/veya yönlendirilmiş adaylar da toplayabilir. Yalnızca IPv6 kullanan aracılar ayrıca, NAT64 tarafından kullanılan IPv6 önekini (varsa) keşfetmek için IPv6 önek keşfini [RFC7050] kullanmalı ve buna göre her IPv6-yalnız arabirim için sunucu-yansıtmalı adaylar üretmelidir. NAT64 sunucu-yansıtmalı adayları, IPv4 sunucu-yansıtmalı adaylar gibi önceliklendirilir.
5.1.1.3. Foundation’ların Hesaplanması
ICE aracısı her adaya bir foundation atar. Aşağıdakilerin tümü doğruysa iki aday aynı foundation’a sahiptir:
- Aynı türe sahiptirler (ana bilgisayar, yönlendirilmiş, sunucu-yansıtmalı veya eş-yansıtmalı).
- Tabanlarının IP adresi aynıdır (portlar farklı olabilir).
- Yansıtmalı ve yönlendirilmiş adaylar için, bunları elde etmekte kullanılan STUN veya TURN sunucularının IP adresleri aynıdır (aracının STUN veya TURN sunucusuna ulaşmak için kullandığı IP adresi).
- Aynı taşıma protokolü (TCP, UDP) kullanılarak elde edilmişlerdir.
Benzer şekilde, türleri farklıysa, tabanlarının IP adresleri farklıysa, bunları elde etmekte kullanılan STUN veya TURN sunucularının IP adresleri farklıysa (aracının STUN veya TURN sunucusuna ulaşmak için kullandığı IP adresleri) veya taşıma protokolleri farklıysa, iki adayın foundation’ları farklıdır.
5.1.1.4. Adayların Canlı Tutulması
Sunucu-yansıtmalı ve yönlendirilmiş adaylar tahsis edildikten sonra, Bölüm 8.3’te açıklandığı üzere, ICE işlemi tamamlanana kadar canlı tutulmak ZORUNDADIR. Binding isteği aracılığıyla öğrenilen sunucu-yansıtmalı adaylar için, bağlamalar sunucuya ek Binding istekleri gönderilerek canlı tutulmalıdır. Tahsislerin yenilenmesi, [RFC5766]’da açıklandığı üzere Refresh işlemi kullanılarak yapılır. Refresh istekleri ayrıca sunucu-yansıtmalı adayı da yeniler.
Ana bilgisayar adayları zaman aşımına uğramaz; ancak aday adresleri çeşitli nedenlerle değişebilir veya ortadan kalkabilir. Bir ICE aracısının kullandığı arabirimleri izlemesi, tabanı ortadan kalkan adayları geçersiz kılması ve yeni IP adresleri (yeni veya halihazırda kullanılan arabirimlerde) ortaya çıktığında uygun şekilde yeni adaylar edinmesi TAVSİYE EDİLİR.
5.1.2. Adayların Önceliklendirilmesi
Önceliklendirme süreci, her adaya bir öncelik atanmasıyla sonuçlanır. Bir veri akışı için her adayın, 1 ile (2**31 - 1) arasında pozitif bir tamsayı olan ve benzersiz olması GEREKEN bir önceliği OLMALIDIR. Bu öncelik, ICE tarafından bağlantı kontrollerinin sırasını ve adaylar arasındaki göreli tercihleri belirlemek için kullanılacaktır. Daha yüksek öncelik değerleri, daha düşük değerlere göre daha fazla öncelik verir.
Bir ICE aracısı, bu önceliği Bölüm 5.1.2.1’deki formülü kullanarak HESAPLAMALI ve parametrelerini Bölüm 5.1.2.2’deki yönergeleri kullanarak SEÇMELİDİR. Bir aracı farklı bir formül kullanmayı tercih ederse, aracılar denetimlerinde koordine olmayacağından ICE’nin yakınsaması daha uzun sürebilir.
Adayların önceliklendirilmesine ilişkin süreç, başlatıcı ve yanıtlayıcı aracı için ortaktır.
5.1.2.1. Önerilen Formül
Önerilen formül, aday türüne (sunucu yansıtmalı, eş yansıtmalı, yönlendirilmiş ve ana makine), adayın elde edildiği IP adresine yönelik bir tercihe ve bir bileşen kimliğine yönelik bir tercihi aşağıdaki formülü kullanarak birleştirir:
priority = (2^24)(type preference) + (2^8)(local preference) + (2^0)*(256 - component ID)
Tür tercihi, 0 (en düşük tercih) ile 126 (en yüksek tercih) arasında, sınırlar dahil olmak üzere, bir tamsayı OLMALIDIR; aynı türdeki tüm adaylar için AYNI OLMALI ve farklı türdeki adaylar için FARKLI OLMALIDIR. Eş-yansıtmalı adaylar için tür tercihi, sunucu-yansıtmalı adaylarınkinden daha yüksek OLMALIDIR. Değerin 0 olarak ayarlanması, bu türdeki adayların yalnızca son çare olarak kullanılacağı anlamına gelir. Bölüm 5.1.1’deki yordamlar temel alınarak toplanan adayların hiçbir zaman eş-yansıtmalı adaylar olmayacağını unutmayın; bu tür adaylar, ICE tarafından gerçekleştirilen bağlantı denetimlerinden öğrenilir.
Yerel tercih, 0 (en düşük tercih) ile 65535 (en yüksek tercih) arasında, sınırlar dahil olmak üzere, bir tamsayı OLMALIDIR. Yalnızca tek bir IP adresi olduğunda, bu değer 65535 olarak AYARLANMALIDIR. Belirli bir veri akışı için belirli bir bileşene ait ve aynı türe sahip birden fazla aday varsa, yerel tercih her biri için BENZERSİZ OLMALIDIR. Bir ICE aracısı çift yığınlıysa, yerel tercih [RFC8421]’de açıklanan mevcut en iyi uygulamaya göre AYARLANMALIDIR.
Bileşen kimliği, 1 ile 256 arasında, sınırlar dahil olmak üzere, bir tamsayı OLMALIDIR.
5.1.2.2. Tür ve Yerel Tercihlerin Seçilmesine Yönelik Yönergeler
Tür tercihleri için ÖNERİLEN değerler; ana makine adayları için 126, eş-yansıtmalı adaylar için 110, sunucu-yansıtmalı adaylar için 100 ve yönlendirilmiş adaylar için 0’dır.
Bir ICE aracısı çoklu-ağ bağlantılıysa ve birden fazla IP adresine sahipse, [RFC8421]’deki öneriler İZLENMELİDİR. Birden fazla TURN sunucusu kullanılıyorsa, TURN sunucularından elde edilen adaylar için yerel öncelikler, çoklu-ağ bağlantılı yerel adaylarda olduğu gibi benzer bir biçimde seçilir: yerel tercih değeri, farklı sunucular arasındaki tercihi belirtmek için kullanılır; ancak her biri için tercih BENZERSİZ OLMALIDIR.
Tür tercihleri seçilirken, aracılar gecikme, paket kaybı, maliyet, ağ topolojisi, güvenlik, gizlilik ve diğerleri gibi etmenleri dikkate alabilir.
5.1.3. Yinelenen Adayların Elenmesi
Sonraki adımda, ICE aracılar (başlatıcı ve yanıtlayıcı) yinelenen adayları eler. İki aday aynı taşıma adresine ancak farklı tabanlara sahip olabilir ve bunlar yinelenen olarak kabul edilmez. Çoğu zaman, bir sunucu-yansıtmalı aday ile bir ana makine adayı, aracı bir NAT arkasında olmadığında yinelenen olacaktır. Bir aday, ancak ve ancak taşıma adresi ve tabanı başka bir adayınkilerle eşitse yinelendir. Aracı, daha düşük önceliğe sahip yinelenen adayı ELEME LİDİR.
5.2. Lite Uygulama Yordamları
Lite uygulamalar yalnızca ana makine adaylarını kullanır. IP adresi ailesinden bağımsız olarak, her IP adresi için sıfır ya da bir aday OLMALIDIR. Lite uygulamada, adaylar arasında dinamik olarak seçim yapmak için ICE kullanılamaz. Bu nedenle, belirli bir IP adresi ailesinden birden fazla adayın dahil edilmesi ÖNERİLMEZ; çünkü hangi adresin kullanılacağını gerçekten belirleyebilen yalnızca bir bağlantı denetimidir. Bunun yerine, birden fazla genel IP adresine sahip aracılara, adreslerini en iyi şekilde kullanmayı sağlamak için tam ICE uygulamalarını çalıştırmaları ÖNERİLİR.
Her bileşene, bileşen kimliği olarak adlandırılan bir kimlik atanır.
RTP/RTCP veri akışları için, RTCP RTP ile aynı portta çoklanmadıkça, RTP’nin kendisi 1 bileşen kimliğine, RTCP ise 2 bileşen kimliğine sahiptir. Bir aracı, çoklama olmadan RTCP kullanıyorsa, bunun için adaylar elde ETMELİDİR. Ancak, 2 numaralı bir bileşen kimliğinin bulunmaması, RTCP/RTP çoklamasının kullanıldığı anlamına gelmez; bu durum RTCP’nin hiç kullanılmadığı anlamına da gelebilir.
Her adaya bir temel (foundation) atanır. Farklı IP adreslerinden tahsis edilen iki aday için temel FARKLI OLMALIDIR; aksi halde AYNI OLMALIDIR. Her IP adresi için artan basit bir tamsayı yeterlidir. Buna ek olarak, her aday, aynı veri akışı için tüm adaylar arasında BENZERSİZ bir önceliğe atanmalıdır. Bölüm 5.1.2.1’deki formül önceliği hesaplamak için kullanılıyorsa, tür tercih değeri 126 olarak AYARLANMALIDIR. Bir ana makine yalnızca IPv4 ise, yerel tercih değeri 65535 olarak AYARLANMALIDIR. Bir ana makine IPv6 ise veya çift yığınlıysa, yerel tercih değeri RFC 6724’te [RFC6724] açıklanan IP adresleri için öncelik (precedence) değeri olarak AYARLANMALIDIR.
Sonraki adımda, bir aracı her veri akışının her bileşeni için varsayılan bir aday seçer. Bir ana makine yalnızca IPv4 ise, her veri akışının her bileşeni için yalnızca bir aday olacaktır; dolayısıyla bu aday varsayılandır. Bir ana makine yalnızca IPv6 ise, varsayılan aday tipik olarak genel kapsamlı bir IPv6 adresi olacaktır. Çift yığınlı ana makineler, varsayılan aday için IPv4 mü yoksa IPv6 mı kullanılacağını yapılandırmaya İZİN VERMELİDİR ve bu yapılandırma, yöneticisinin mevcut ağ ortamında hangisinin daha yüksek başarı şansına sahip olduğuna inandığına dayanmalıdır.
Bu bölümdeki yordamlar, başlatıcı ve yanıtlayıcı aracılar için ortaktır.
5.3. Aday Bilgilerinin Değişimi
ICE aracılarının (başlatıcı ve yanıtlayıcı) adaylar hakkında aşağıdaki bilgilerin değişimini yapması gerekir. Her ICE kullanımı, bilgilerin kullanılan protokol ile nasıl değişileceğini TANIMLAMALIDIR. Bu bölüm, değişilmesi gereken bilgileri açıklar.
Adaylar: Bir veya daha fazla aday. Her aday için:
- Adres: Adayın IP adresi ve taşıma protokolü portu.
- Taşıma: Adayın taşıma protokolü. Kullanılan protokol yalnızca tek bir taşıma protokolü üzerinde çalışıyorsa bu ALAN ATLANABİLİR.
- Temel (Foundation): En fazla 32 karakterden oluşan bir dizi.
- Bileşen Kimliği: Adayın bileşen kimliği. Kullanılan protokol bileşen kavramını kullanmıyorsa bu ALAN ATLANABİLİR.
- Öncelik: Adayın 32 bitlik önceliği.
- Tür: Adayın türü.
- İlişkili Adres ve Port: Adayın ilişkili IP adresi ve portu. Aracı bunları açıklamak istemiyorsa (örneğin gizlilik nedenleriyle) bunlar ATLANABİLİR veya geçersiz değerlere AYARLANABİLİR.
- Genişletilebilirlik Parametreleri: Kullanılan protokol, gelecekte aday başına yeni ICE parametreleri eklemek için yöntemler tanımlayabilir.
Lite veya Tam: Aracının lite aracı mı yoksa tam aracı mı olduğu.
Bağlantı Denetimi Hız Ayarı Değeri: Aracının kullanmak istediği bağlantı denetimleri için hız ayarı değeri. Aracı tanımlı bir varsayılan değeri kullanmak istiyorsa bu ATLANABİLİR.
Kullanıcı Adı Parçası ve Parola: Bağlantı denetimlerini gerçekleştirmek için kullanılan değerler. Değerler tahmin edilemez OLMALIDIR; parolanın üretilmesi için en az 128 bitlik rastgele sayı üreteci çıktısı ve kullanıcı adı parçasının üretilmesi için en az 24 bitlik çıktı kullanılmalıdır.
Uzantılar: Yeni ortam akışı veya oturum düzeyi öznitelikler (ICE seçenekleri).
Kullanılan protokol ICE uyumsuzluğuna (Bölüm 5.4) karşı savunmasızsa ve bunu algılayabiliyorsa, algılayan aracının bu bilgiyi eşine iletebilmesi için bir yol gereklidir. Bu bir boole bayrağıdır.
Kullanılan protokol, ICE’yi desteklemeyen eski uygulamalarla geriye dönük uyumlulukla ilgilenmek zorunda olabilir (ya da olmayabilir). ICE dışı bir geri dönüş mekanizması destekleniyor ve kullanılıyorsa, muhtemelen kullanılan protokol, ICE parametrelerine ek olarak varsayılan adayı (IP adresi ve portu) iletmenin bir yolunu sağlar.
Bir aracı aday bilgilerini gönderdikten sonra, her aday üzerinde hem STUN hem de veri paketlerini almaya HAZIR OLMALIDIR. Bölüm 12.1’de tartışıldığı üzere, veri paketleri, bir aday veri için varsayılan hedef olarak görünmeden önce o adaya gönderilebilir.
5.4. ICE Uyumsuzluğu
ALG’ler gibi bazı ara kutular, ICE’yi bozan biçimlerde sinyalizasyon bilgilerini değiştirebilir (örneğin SDP’de IP adreslerini yeniden yazarak). Bu durum ICE uyumsuzluğu olarak adlandırılır. Kullanılan protokol ICE uyumsuzluğuna karşı savunmasızsa, yanıtlayıcı aracının bunu algılayabilmesi ve eş ICE aracısını ICE uyumsuzluğu hakkında bilgilendirebilmesi gerekir.
Her kullanılan protokol, ICE uyumsuzluğuna karşı savunmasız olup olmadığını, ICE uyumsuzluğunun nasıl algılandığını ve ICE uyumsuzluğu algılandığında belirli eylemlerin gerekip gerekmediğini tanımlamalıdır.
#6. ICE Aday İşleme
Bir ICE aracısı adaylarını topladıktan ve adayları eşiyle değiştirdikten sonra (Bölüm 5), kendi rolünü belirler. Buna ek olarak, tam uygulamalar kontrol listeleri oluşturacak ve eş ile bağlantı denetimleri gerçekleştirmeye başlayacaktır.
6.1. Tam Uygulama İçin Yordamlar
6.1.1. Rolün Belirlenmesi
Her oturum için, her ICE aracısı (başlatıcı ve yanıtlayıcı) bir rol üstlenir. İki rol vardır — kontrol eden ve kontrol edilen. Kontrol eden aracı, iletişim için kullanılacak nihai aday çiftlerinin seçilmesinden sorumludur. Aşağıdaki bölümler, kontrol eden ve kontrol edilen aracılar tarafından izlenen gerçek yordamları ayrıntılı olarak açıklar.
Rolün belirlenmesine ve davranış üzerindeki etkilerine ilişkin kurallar aşağıdaki gibidir:
- Her iki aracı da tam: ICE işlemini başlatan başlatıcı aracı, kontrol eden rolünü ALMALIDIR ve diğeri kontrol edilen rolünü ALMALIDIR. Her iki aracı da kontrol listeleri oluşturacak, ICE durum makinelerini çalıştıracak ve bağlantı denetimleri üretecektir. Kontrol eden aracı, Bölüm 8.1’deki mantığı kullanarak, (adaylıklarla ilişkili bağlantı denetimleri başarılı olursa) seçilmiş çiftler haline gelecek çiftleri aday gösterecek ve ardından her iki aracı da Bölüm 8.1.2’de açıklandığı gibi ICE’yi sonlandıracaktır.
- Bir aracı tam, biri lite: Tam aracı kontrol eden rolünü ALMALIDIR ve lite aracı kontrol edilen rolünü ALMALIDIR. Tam aracı kontrol listeleri oluşturacak, ICE durum makinelerini çalıştıracak ve bağlantı denetimleri üretecektir. Bu aracı, Bölüm 8.1’deki mantığı kullanarak, (adaylıklarla ilişkili bağlantı denetimleri başarılı olursa) seçilmiş çiftler haline gelecek çiftleri aday gösterecek ve Bölüm 8.1.2’deki mantığı kullanarak ICE’yi sonlandıracaktır. Lite uygulama yalnızca bağlantı denetimlerini dinleyecek, bunları alıp yanıtlayacak ve ardından Bölüm 8.2’de açıklandığı gibi ICE’yi sonuçlandıracaktır. Lite uygulama için, her veri akışı için ICE işleme durumu Çalışıyor olarak kabul edilir ve ICE’nin genel durumu Çalışıyor’dur.
- Her ikisi de lite: ICE işlemini başlatan başlatıcı aracı, kontrol eden rolünü ALMALIDIR ve diğeri kontrol edilen rolünü ALMALIDIR. Bu durumda, hiçbir zaman bağlantı denetimi gönderilmez. Bunun yerine, adaylar değişildikten sonra her aracı, bağlantı denetimleri olmadan Bölüm 8’de açıklanan işlemleri gerçekleştirir. Her iki aracının da kendisinin kontrol edilen veya kontrol eden olduğuna inanması mümkündür. İkinci durumda, çakışma, aday değişimini mümkün kılan sinyalizasyon protokolündeki parlama (glare) algılama yetenekleri aracılığıyla çözülür. Her veri akışı için ICE işleme durumu Çalışıyor olarak kabul edilir ve ICE’nin genel durumu Çalışıyor’dur.
Bir oturum için roller belirlendikten sonra, oturumun yaşam süresi boyunca devam ederler. Roller, bir ICE yeniden başlatmasının (Bölüm 9) parçası olarak yeniden belirlenebilir; ancak bir ICE aracısı, aşağıdaki ölçütlerden biri veya daha fazlası sağlanmadıkça bir ICE yeniden başlatmasının parçası olarak rolü YENİDEN BELİRLEMEMELİDİR:
- Tam lite’a dönüşür: Kontrol eden aracı tam ise ve lite’a geçerse, eş aracı da tam ise roller YENİDEN BELİRLENMELİDİR.
- Rol çakışması: ICE yeniden başlatması bir rol çakışmasına neden olursa, Bölüm 7.3.1.1’deki rol çakışması yordamları nedeniyle roller yeniden belirlenebilir.
NOT: Bir ICE yeniden başlatmasının rol çakışmasına neden olabileceği bazı Üçüncü Taraf Çağrı Kontrolü (3PCC) [RFC3725] senaryoları vardır.
NOT: Roller belirlenmeden önce, aracılar birbirlerine tam mı yoksa lite mı olduklarını bildirmelidir. Bunun mekanizması sinyalizasyon protokolüne özgüdür ve belgenin kapsamı dışındadır.
Bir aracı, bunu yapmak için ölçütler sağlanmamış olsa bile, eş rolün yeniden belirlenmesini başlatırsa BUNU KABUL ETMELİDİR. Bu durum, eş RFC 5245 ile uyumluysa meydana gelebilir.
6.1.2. Kontrol Listelerinin Oluşturulması
Her veri akışı için bir kontrol listesi vardır. Bir kontrol listesi oluşturmak için, başlatıcı ve yanıtlayıcı ICE aracılar aday çiftleri oluşturur, çift önceliklerini hesaplar, çiftleri önceliğe göre sıralar, çiftleri budar, daha düşük öncelikli çiftleri kaldırır ve kontrol listesi durumlarını ayarlar. Kontrol listesine adaylar eklenirse (örneğin eş-yansıtmalı adayların algılanması nedeniyle), aracı güncellenmiş kontrol listesi için bu adımları yeniden gerçekleştirir.
6.1.2.1. Kontrol Listesi Durumu
Her kontrol listesinin, kontrol listesiyle ilişkili veri akışı için ICE denetimlerinin durumunu yakalayan bir durumu vardır. Durumlar şunlardır:
- Çalışıyor: Kontrol listesi henüz Ne Tamamlandı ne de Başarısız oldu durumundadır. Kontrol listeleri başlangıçta Çalışıyor durumuna ayarlanır.
- Tamamlandı: Kontrol listesi, veri akışının her bileşeni için aday gösterilmiş bir çift içerir.
- Başarısız: Kontrol listesi, veri akışının her bileşeni için geçerli bir çifte sahip değildir ve kontrol listesindeki tüm aday çiftleri ya Başarısız ya da Başarılı durumundadır. Başka bir deyişle, kontrol listesindeki en az bir bileşenin tüm aday çiftleri Başarısız durumundadır; bu da bileşenin başarısız olduğu ve dolayısıyla kontrol listesinin başarısız olduğu anlamına gelir.
6.1.2.2. Aday Çiftlerinin Oluşturulması
ICE aracısı, aynı veri akışının aynı bileşeni için ve aynı IP adresi ailesine sahip her yerel adayı her uzak adayla eşleştirir. Bazı yerel adayların uzak adaylarla eşleştirilmeyebileceği ve bazı uzak adayların da yerel adaylarla eşleştirilmeyebileceği mümkündür. Bu durum, bir aracının bir veri akışı için tüm bileşenler adına adayları dahil etmemesi halinde meydana gelebilir. Bu gerçekleşirse, o veri akışı için bileşen sayısı fiilen azaltılır ve her iki aracının da veri akışı için tüm bileşenler genelinde sağladığı en yüksek bileşen kimliğinin minimumuna eşit kabul edilir.
RTP durumunda bu, bir aracının RTCP için adaylar sağlaması ve diğerinin sağlamaması halinde gerçekleşir. Başka bir örnek olarak, başlatıcı aracı RTP ve RTCP’yi aynı port üzerinde çoklayabilir [RFC5761]. Ancak, başlatıcı aracı karşı uç aracının bu tür bir çoklama yapıp yapamayacağını bilmediğinden, RTP ve RTCP için ayrı portlarda adaylar ekler. Karşı uç aracı bu tür bir çoklama yapabiliyorsa, her aday için yalnızca tek bir bileşen — birleşik RTP/RTCP mux için — ekler. ICE, bu aday için sanki yalnızca tek bir bileşen varmış gibi davranır.
IPv6 ile birlikte, bir ana bilgisayarın her bir arayüz için birden fazla ana bilgisayar adayı bulundurması yaygındır. Ortaya çıkan aday çiftlerinin sayısını makul düzeyde tutmak ve çalışması son derece düşük olasılıklı aday çiftlerinden kaçınmak için, IPv6 bağlantı-yerel adresleri bağlantı-yerel adresler dışındaki adreslerle EŞLEŞTİRİLMEMELİDİR.
Yerel ve uzak adayları belirli bir bileşen için her ikisi de varsayılan aday olan aday çiftlerine, o bileşen için varsayılan aday çifti denir. Bu, her iki aracı da ICE farkındalığına sahip olmasaydı veri iletmek için kullanılacak çift olurdu.
Şekil 5, taşıma adresleri, adaylar, aday çiftleri ve kontrol listeleri arasındaki özellikleri ve ilişkileri göstermektedir.
+--------------------------------------------+
| |
| +---------------------+ |
| |+----+ +----+ +----+ | +Tür |
| || IP | |Port| |Tran| | +Öncelik |
| ||Adr | | | | | | +Temel |
| |+----+ +----+ +----+ | +Bileşen Kimliği |
| | Taşıma | +İlişkili Adres |
| | Adr | |
| +---------------------+ +Taban |
| Aday |
+--------------------------------------------+
* *
* *************************************
* *
+-------------------------------+
| |
| Yerel Uzak |
| +----+ +----+ +varsayılan?|
| |Aday| |Aday| +geçerli? |
| +----+ +----+ +aday gösterildi mi?|
| +Durum |
| |
| |
| Aday Çifti |
+-------------------------------+
* *
* ************
* *
+------------------+
| Aday Çifti |
+------------------+
+------------------+
| Aday Çifti |
+------------------+
+------------------+
| Aday Çifti |
+------------------+Kontrol Listesi
Şekil 5: Bir Kontrol Listesinin Kavramsal Diyagramı
6.1.2.3. Çift Önceliğinin Hesaplanması ve Çiftlerin Sıralanması
ICE aracısı her aday çifti için bir öncelik hesaplar. G, kontrol eden aracının sağladığı adayın önceliği olsun. D, kontrol edilen aracının sağladığı adayın önceliği olsun. Bir çiftin önceliği aşağıdaki şekilde hesaplanır:
çift önceliği = 2^32 * MIN(G, D) + 2 * MAX(G, D) + (G > D ? 1 : 0)Aracı, her kontrol listesini aday çifti önceliğinin azalan sırasına göre sıralar. İki çiftin önceliği aynıysa, aralarındaki sıralama keyfidir.
6.1.2.4. Çiftlerin Budanması
Bu sıralanmış aday çiftleri listesi, gerçekleştirilecek bağlantı denetimlerinin sırasını belirlemek için kullanılır. Her denetim, yerel bir adaydan uzak bir adaya bir istek gönderilmesini içerir. Bir ICE aracısı yansıtmalı bir adaydan (sunucu yansıtmalı veya eş yansıtmalı) doğrudan istek gönderemediği, yalnızca onun tabanından gönderebildiği için, aracı bir sonraki adımda sıralanmış aday çiftleri listesini dolaşır. Yerel adayın yansıtmalı olduğu her çift için, aday MUTLAKA kendi tabanı ile değiştirilmelidir.
Aracı her kontrol listesini budar. Bu, aynı kontrol listesinde daha yüksek öncelikli bir aday çiftiyle gereksiz yere yinelenen bir aday çiftinin kaldırılmasıyla yapılır. İki aday çifti, yerel adaylarının aynı tabana sahip olması ve uzak adaylarının özdeş olması durumunda gereksiz kabul edilir. Sonuç, kontrol listesi olarak adlandırılan sıralı bir aday çiftleri dizisidir.
6.1.2.5. Daha Düşük Öncelikli Çiftlerin Kaldırılması
Bölüm 19.5.1’de açıklanan saldırıları sınırlamak amacıyla, bir ICE aracısı tüm kontrol listeleri genelinde gerçekleştirdiği toplam bağlantı denetimi sayısını MUTLAKA sınırlandırmalıdır. Bu, kontrol listesi kümesindeki toplam aday çifti sayısının sınırlandırılmasıyla yapılır. Kontrol listesi kümesi için varsayılan aday çifti sınırı 100’dür, ancak bu değer MUTLAKA yapılandırılabilir olmalıdır.
Sınır, her bir kontrol listesi içinde, kontrol listesi kümesindeki toplam aday çifti sayısı sınır değerinden küçük olana kadar daha düşük öncelikli aday çiftlerinin elenmesiyle uygulanır. Eleme işlemi, her kontrol listesindeki aday çifti sayısı aynı miktarda azaltılacak şekilde dengeli olarak YAPILMALIDIR.
Mümkün olduğunda varsayılan değerden daha düşük bir sınır değerinin seçilmesi ve değerin, gerçek bir dağıtım yapılandırmasında ortaya çıkabilecek makul aday çiftlerinin azami sayısına ayarlanması ÖNERİLİR. Yapılandırma gereksinimi, dağıtımdan sonra sorunlu olduğu saptanırsa bu değerin sahada düzeltilmesini sağlayacak bir araç sunmayı amaçlar.
6.1.2.6. Aday Çifti Durumlarının Hesaplanması
Kontrol listesindeki her aday çiftinin bir temeli (çiftteki yerel ve uzak adayların temellerinin birleşimi) ve aşağıdaki durumlardan biri vardır:
- Waiting (Beklemede): Bu çift için bir denetim gönderilmemiştir, ancak çift Frozen değildir.
- In-Progress (Devam Ediyor): Bu çift için bir denetim gönderilmiştir, ancak işlem devam etmektedir.
- Succeeded (Başarılı): Bu çift için bir denetim gönderilmiştir ve başarılı bir sonuç üretmiştir.
- Failed (Başarısız): Bu çift için bir denetim gönderilmiştir ve başarısız olmuştur (denetime bir yanıt hiç alınmamış ya da bir hata yanıtı alınmıştır).
- Frozen (Dondurulmuş): Bu çift için bir denetim gönderilmemiştir ve çift çözülüp Waiting durumuna taşınana kadar gönderilemez.
Çiftler, Şekil 6’da gösterildiği gibi durumlar arasında geçiş yapar.
+-----------+
| |
| |
| Frozen |
| |
| |
+-----------+
|
| çöz
|
V
+-----------+ +-----------+
| | | |
| | gerçekleştir | |
| Waiting |-------->|In-Progress|
| | | |
| | | |
+-----------+ +-----------+
/ |
// |
// |
// |
/ |
// |
başarısız // | başarılı
// |
/ |
// |
// |
// |
V V
+-----------+ +-----------+
| | | |
| | | |
| Failed | | Succeeded |
| | | |
| | | |
+-----------+ +-----------+Şekil 6: Çift Durum Sonlu Durum Makinesi (FSM)
Bir kontrol listesindeki her çift için başlangıç durumları, aşağıdaki adımlar dizisi uygulanarak hesaplanır:
- Kontrol listeleri, kontrol listesi kümesi olarak adlandırılan sıralı bir listeye yerleştirilir (sıra, her bir ICE kullanımına göre belirlenir).
- ICE aracısı başlangıçta tüm aday çiftlerini Frozen durumuna yerleştirir.
- Aracı, kontrol listesi kümesindeki tüm kontrol listelerini Running durumuna ayarlar.
- Her bir temel için, aracı tam olarak bir aday çiftinin durumunu Waiting olarak ayarlar (çözerek). Çözülecek aday çifti, o temele sahip olan ve ilk kontrol listesinde (kullanıma göre tanımlanan kontrol listesi kümesi sırasına göre), en düşük bileşen kimliğine sahip olan (bileşen kimlikleri eşitse en yüksek önceliğe sahip olan) ilk aday çifti bulunarak seçilir.
NOT: Yukarıdaki yordamlar, yalnızca ilk kontrol listesindeki aday çiftlerinin başlangıçta Waiting durumuna yerleştirildiği RFC 5245’ten farklıdır. Artık, kontrol listesi kümesinde ilk kontrol listesi olmasa bile, o temele sahip olan ilk kontrol listesindeki aday çiftlerine uygulanır.
Aşağıdaki tablo bir örneği göstermektedir.
Tablo Açıklaması
- Her satır (m1, m2, ...) bir veri akışıyla ilişkili bir kontrol listesini temsil eder. m1, kontrol listesi kümesindeki ilk kontrol listesini temsil eder.
- Her sütun (f1, f2, ...) bir temeli temsil eder. Belirli bir sütundaki tüm aday çiftleri aynı temeli paylaşır.
- f-cp, Frozen durumundaki bir aday çiftini temsil eder.
- w-cp, Waiting durumundaki bir aday çiftini temsil eder.
Adım 1
Aracı, kontrol listesi kümesindeki tüm çiftleri Frozen durumuna ayarlar.
f1 f2 f3 f4 f5
--------------------------------
m1 | f-cp f-cp f-cp
|
m2 | f-cp f-cp f-cp f-cp
|
m3 | f-cp f-cpAdım 2
Her bir temel için, en düşük bileşen kimliğine sahip aday çifti Waiting durumuna yerleştirilir; ancak kontrol listesi kümesinde incelenen diğer kontrol listelerinden birinde aynı temelle ilişkili bir aday çifti zaten Waiting durumuna konmuşsa bu yapılmaz.
f1 f2 f3 f4 f5
--------------------------------
m1 | w-cp w-cp w-cp
|
m2 | f-cp f-cp f-cp w-cp
|
m3 | f-cp w-cpTablo 1: Çift Durum Örneği
İlk kontrol listesinde (m1), aynı temeller için henüz Waiting durumuna yerleştirilmiş bir çift bulunmadığından, her temel için aday çifti Waiting durumuna yerleştirilir.
İkinci kontrol listesinde (m2), f4 temeli için aday çifti Waiting durumuna yerleştirilir. f1, f2 ve f3 temelleri için aday çiftleri Frozen durumunda tutulur; çünkü bu temeller için aday çiftleri zaten Waiting durumuna yerleştirilmiştir (m1 kontrol listesi içinde).
Üçüncü kontrol listesinde (m3), f5 temeli için aday çifti Waiting durumuna yerleştirilir. f1 temeli için aday çifti Frozen durumunda tutulur; çünkü bu temel için bir aday çifti zaten Waiting durumuna yerleştirilmiştir (m1 kontrol listesi içinde).
Her kontrol listesi işlendiğinde, kontrol listesi kümesindeki her temel için bir aday çifti Waiting durumuna yerleştirilmiş olur.
6.1.3. ICE Durumu
ICE aracısının durumu, kontrol listelerinin durumuna göre belirlenir. Tüm kontrol listeleri Completed ise durum Completed, tüm kontrol listeleri Failed ise Failed, aksi halde Running’dir.
6.1.4. Denetimlerin Zamanlanması
6.1.4.1. Tetiklenen Denetim Kuyruğu
ICE aracısı, Bölüm 6.1.2’de açıklandığı gibi kontrol listelerini hesaplayıp kontrol listesi kümesini oluşturduktan sonra, bağlantı denetimlerini (normal ve tetiklenen) gerçekleştirmeye başlar. Tetiklenen bağlantı denetimleri için, aracı her kontrol listesi için bir FIFO kuyruğu tutar; bu kuyruk tetiklenen denetim kuyruğu olarak adlandırılır ve bir sonraki uygun fırsatta denetim gönderilecek aday çiftlerini içerir. Tetiklenen denetim kuyruğu başlangıçta boştur.
6.1.4.2. Bağlantı Denetimlerinin Gerçekleştirilmesi
Normal ve tetiklenen bağlantı denetimlerinin üretilmesi Ta zamanlayıcısı tarafından yönetilir. Kontrol listesi kümesindeki aday çiftleri için başlangıç durumları ayarlanır ayarlanmaz, Running durumundaki ilk kontrol listesi içindeki bir aday çifti için, Bölüm 7’deki yordamlar izlenerek bir denetim gerçekleştirilir. Bundan sonra, Ta her tetiklendiğinde, kontrol listesi kümesinde Running durumundaki bir sonraki kontrol listesi seçilir ve o kontrol listesi içindeki bir aday için bir denetim gerçekleştirilir. Kontrol listesi kümesindeki Running durumundaki son kontrol listesi işlendiğinde, yeniden ilk kontrol listesi seçilir ve süreç bu şekilde devam eder.
Ta her tetiklendiğinde, ICE aracısı seçilen kontrol listesi içindeki bir aday çifti için aşağıdaki adımları uygulayarak bir denetim gerçekleştirir:
- Kontrol listesiyle ilişkili tetiklenen denetim kuyruğu bir veya daha fazla aday çifti içeriyorsa, aracı kuyruğun başındaki çifti çıkarır, bu çift üzerinde bir bağlantı denetimi gerçekleştirir, aday çiftinin durumunu In-Progress olarak ayarlar ve sonraki adımları iptal eder.
- Waiting durumunda bir aday çifti yoksa ve Frozen durumunda bir veya daha fazla çift varsa, aracı Frozen durumundaki her çiftle ilişkili temeli denetler. Belirli bir temel için, kontrol listesi kümesindeki herhangi bir kontrol listesinde Waiting veya In-Progress durumunda bir çift yoksa, aracı aday çiftinin durumunu Waiting olarak ayarlar ve bir sonraki adımla devam eder.
- Waiting durumunda bir veya daha fazla aday çifti varsa, aracı Waiting durumundaki en yüksek öncelikli aday çiftini seçer (aynı önceliğe sahip birden fazla çift varsa, en düşük bileşen kimliğine sahip olan seçilir), bu çift üzerinde bir bağlantı denetimi gerçekleştirir, aday çiftinin durumunu In-Progress olarak ayarlar ve sonraki adımları iptal eder.
- Bu adıma ulaşılmışsa, seçilen kontrol listesi için hiçbir denetim gerçekleştirilememiş demektir. Bu nedenle, Ta zamanlayıcısının yeniden dolmasını beklemeden, Running durumundaki bir sonraki kontrol listesini seçin ve 1. adıma geri dönün. Bu durum Running durumundaki her bir kontrol listesi için gerçekleşirse, yani bağlantı denetimi yapılacak başka aday çifti kalmamışsa, bu adımları sonlandırın.
Aracı, bir bağlantı denetimi gerçekleştirilecek aday çiftini seçtiğinde, bir denetim başlatır ve Bölüm 7.2.4’te açıklandığı gibi, çiftin yerel adayına bağlı tabandan uzak adayına doğru Binding isteğini gönderir.
Yerel politikaya bağlı olarak, bir aracı kontrol listesi kümesindeki bir veya daha fazla kontrol listesi için bağlantı denetimlerini herhangi bir zamanda sonlandırmayı SEÇEBİLİR. Ancak, ICE’yi sonuçlandırmaya (Bölüm 8) yalnızca kontrol eden aracı yetkilidir.
Denetim için ileti bütünlüğünü hesaplamak amacıyla, aracı karşı uçtan elde edilen aday bilgilerinden öğrenilen uzak kullanıcı adı parçasını ve parolayı kullanır. Yerel kullanıcı adı parçası, aracının kendi adayı için doğrudan kendisi tarafından bilinir.
6.2. Lite Uygulama Yordamları
Lite uygulamalar, karşı ucun ICE desteğini doğrulamak ve ICE işlemedeki rolünü belirlemek dışında, Bölüm 6’daki adımların çoğunu atlar.
Lite uygulama kontrol eden aracıysa (bu yalnızca karşı uç ICE aracısı da bir lite uygulama olduğunda gerçekleşir), aday değişimindeki adaylara dayanarak bir aday çifti seçer (IPv4 için her zaman yalnızca bir çift vardır) ve ardından gerekirse bu seçimi yansıtan yeni aday bilgileriyle karşı ucu günceller (yalnızca IPv4 kullanan bir ana bilgisayar için buna asla gerek yoktur).
#7. Bağlantı Denetimlerinin Gerçekleştirilmesi
Bu bölüm, bağlantı denetimlerinin nasıl gerçekleştirildiğini açıklar.
Bir ICE ajanı [RFC5389] ile uyumlu OLMALIDIR. Tam bir uygulama hem STUN istemcisi hem de STUN sunucusu olarak çalışır; lite bir uygulama ise yalnızca STUN sunucusu olarak çalışır (bağlantı denetimleri üretmediği için).
7.1. STUN Uzantıları
ICE, STUN’u şu özniteliklerle genişletir: PRIORITY, USE-CANDIDATE, ICE-CONTROLLED ve ICE-CONTROLLING. Bu öznitelikler resmi olarak Bölüm 16.1’de tanımlanmıştır. Bu bölüm, özniteliklerin kullanımını açıklar.
Bu öznitelikler yalnızca ICE bağlantı denetimleri için geçerlidir.
7.1.1. PRIORITY
PRIORITY özniteliği bir Binding isteğine DAHİL EDİLMELİ ve yerel aday için Bölüm 5.1.2’deki algoritma tarafından hesaplanan değere ayarlanmalıdır; ancak eş-yansıtmalı (peer-reflexive) adayların aday türü tercihi kullanılarak.
7.1.2. USE-CANDIDATE
Denetleyici ajan, bir aday çiftini aday göstermek için (Bölüm 8.1.1) USE-CANDIDATE özniteliğini DAHİL ETMELİDİR. Denetlenen ajan, bir Binding isteğine USE-CANDIDATE özniteliğini DAHİL ETMEMELİDİR.
7.1.3. ICE-CONTROLLED ve ICE-CONTROLLING
Denetleyici ajan, bir Binding isteğine ICE-CONTROLLING özniteliğini DAHİL ETMELİDİR. Denetlenen ajan, bir Binding isteğine ICE-CONTROLLED özniteliğini DAHİL ETMELİDİR.
Her iki özniteliğin içeriği de, bir ICE rolü çakışması oluştuğunda bağlayıcı (tiebreaker) değerleri olarak kullanılır (Bölüm 7.3.1.1).
7.2. STUN İstemci Prosedürleri
7.2.1. Aktarılan Adaylar için İzinlerin Oluşturulması
Bağlantı denetimi, aktarılan bir yerel aday kullanılarak gönderiliyorsa, istemci daha önce zaten bir izin oluşturmadıysa önce bir izin OLUŞTURMALIDIR. Daha önce bir izin oluşturmuş olurdu; eğer TURN sunucusuna, verilen aktarılan aday için uzak adayın IP adresine doğru bir izin oluşturmasını söylemişse. İzni oluşturmak için ICE ajanı [RFC5766]’da tanımlanan prosedürleri izler. İzin, uzak adayın IP adresine doğru OLUŞTURULMALIDIR. Ajanın, ICE tamamlanana kadar bir TURN kanalı oluşturmayı ertelemesi ÖNERİLİR; bu durumda bağlantı denetimleri için izinler normalde bir CreatePermission isteği kullanılarak oluşturulur. Kurulduktan sonra ajan, ICE sonuçlanana kadar izni etkin tutmak ZORUNDADIR.
7.2.2. Kimlik Bilgilerinin Oluşturulması
Bir bağlantı denetimi Binding isteği, STUN kısa süreli kimlik bilgisi mekanizmasını KULLANMALIDIR.
Kimlik bilgisi için kullanıcı adı, eş tarafından sağlanan kullanıcı adı parçasının, isteği gönderen ICE ajanının kullanıcı adı parçası ile iki nokta üst üste (":") ile ayrılarak birleştirilmesiyle oluşturulur.
Parola, eş tarafından sağlanan parolaya eşittir.
Örneğin, ICE ajanı L’nin başlatıcı ajan ve ICE ajanı R’nin yanıtlayıcı ajan olduğu durumu ele alalım. Ajan L, adayları için LFRAG kullanıcı adı parçasını ve LPASS parolasını dahil etmiştir. Ajan R, RFRAG kullanıcı adı parçasını ve RPASS parolasını sağlamıştır. L’den R’ye bir bağlantı denetimi, RFRAG:LFRAG kullanıcı adını ve RPASS parolasını kullanır. R’den L’ye bir bağlantı denetimi, LFRAG:RFRAG kullanıcı adını ve LPASS parolasını kullanır. Yanıtlar, isteklerle aynı kullanıcı adlarını ve parolaları kullanır (USERNAME özniteliğinin yanıtta bulunmadığına dikkat edin).
7.2.3. Diffserv İşlemi
Ajan, göndereceği veri paketlerinde Farklılaştırılmış Hizmetler Kod Noktası (DSCP) işaretlemelerini [RFC2475] kullanıyorsa, göndereceği Binding istekleri ve yanıtlarına da aynı işaretlemeleri UYGULAMALIDIR.
Veri paketlerinde birden fazla DSCP işaretlemesi kullanılıyorsa, ajan bağlantı denetimi için bunlardan birini SEÇMELİDİR.
7.2.4. İsteğin Gönderilmesi
Bir bağlantı denetimi, yerel bir adayla ilişkili tabandan uzak bir adaya bir Binding isteği gönderilerek üretilir. [RFC5389], Binding isteklerinin nasıl oluşturulduğunu ve üretildiğini açıklar.
Bağlantı denetimleri gerçekleştirilirken RFC 3489 ile geriye dönük uyumluluk desteği varsayılmamalıdır. Bağlantı denetimleri için FINGERPRINT mekanizması KULLANILMALIDIR.
7.2.5. Yanıtın İşlenmesi
Bu bölüm, ICE bağlantı denetimlerine özgü Binding yanıtlarının işlenmesi için ek prosedürleri tanımlar.
Bir Binding yanıtı alındığında, [RFC5389]’daki işlem kimliği (transaction ID) kullanılarak ilgili Binding isteğiyle ilişkilendirilir; bu da yanıtı, Binding isteğinin gönderildiği aday çiftiyle ilişkilendirir. Bundan sonra yanıt, aşağıdaki prosedürlere göre bir rol çakışması, bir başarısızlık veya bir başarı durumuna göre işlenir.
7.2.5.1. Rol Çakışması
Binding isteği bir 487 (Rol Çakışması) hata yanıtı üretirse (Bölüm 7.3.1.1) ve ICE ajanı isteğe bir ICE-CONTROLLED özniteliği dahil etmişse, ajan denetleyici role GEÇMELİDİR. Ajan isteğe bir ICE-CONTROLLING özniteliği dahil etmişse, ajan denetlenen role GEÇMELİDİR.
Ajan rolünü değiştirdikten sonra, 487 hata yanıtını üreten denetimi olan aday çiftini, çiftin ait olduğu kontrol listesiyle ilişkili tetiklenen-denetim kuyruğuna EKLEMELİ ve aday çiftinin durumunu Waiting olarak AYARLAMALIDIR. Tetiklenen bağlantı denetimi daha sonra gerçekleştirildiğinde, Binding isteğinin ICE-CONTROLLING/ICE-CONTROLLED özniteliği ajanın yeni rolünü gösterecektir. Ajan bağlayıcı (tiebreaker) değerini DEĞİŞTİRMELİDİR.
NOT: Bir rol değişimi, öncelik değerleri role bağlı olduğundan, ajanın çift önceliklerini yeniden hesaplamasını gerektirir (Bölüm 6.1.2.3).
NOT: Bir rol değişimi ayrıca, ajanın aday çiftlerini aday göstermeden sorumlu olup olmadığını ve ICE sonuçlandığında güncellenmiş aday bilgisinin eşle değişimini başlatmaktan sorumlu olup olmadığını da etkiler.
7.2.5.2. Başarısızlık
Bu bölüm, aday çifti durumunun Failed olarak ayarlandığı durumları açıklar.
NOT: ICE ajanı, bir bağlantı denetimi hatası sonucunda aday çifti durumunu Failed olarak ayarladığında, aynı temele (foundation) sahip diğer aday çiftlerinin durumlarını değiştirmez.
7.2.5.2.1. Simetrik Olmayan Taşıma Adresleri
ICE ajanı, Binding isteği ve yanıtındaki kaynak ve hedef taşıma adreslerinin simetrik olduğunu KONTROL ETMELİDİR. Yani, yanıtın kaynak IP adresi ve portu, Binding isteğinin gönderildiği hedef IP adresi ve portuna eşit OLMALIDIR; ve yanıtın hedef IP adresi ve portu, Binding isteğinin gönderildiği kaynak IP adresi ve portuna eşit OLMALIDIR. Adresler simetrik değilse, ajan aday çifti durumunu Failed olarak AYARLAMALIDIR.
7.2.5.2.2. ICMP Hatası
Bir ICE ajanı, bağlantı denetimleri için ICMP hatalarının işlenmesini DESTEKLEYEBİLİR. Ajan ICMP hatalarının işlenmesini destekliyorsa ve bir Binding isteği sert (hard) bir ICMP hatası üretirse, ajan aday çiftinin durumunu Failed olarak AYARLAMALIDIR. Uygulayıcıların, ICMP hatalarının Hizmet Reddi (DoS) saldırıları için bir yöntem olarak kullanılabileceğinin farkında olmaları ve ICMP hatalarının nasıl ve işlenip işlenmeyeceğine karar verirken bunu dikkate almaları gerekir.
7.2.5.2.3. Zaman Aşımı
Binding isteği işlemi zaman aşımına uğrarsa, ICE ajanı aday çifti durumunu Failed olarak AYARLAMALIDIR.
7.2.5.2.4. Kurtarılamaz STUN Yanıtı
Binding isteği kurtarılamaz bir STUN hata yanıtı üretirse [RFC5389], ICE ajanı aday çifti durumunu Failed olarak AYARLAMALIDIR.
7.2.5.3. Başarı
Aşağıdaki ölçütlerin her biri doğruysa bir bağlantı denetimi başarılı kabul edilir:
- Binding isteği bir başarı yanıtı üretmiştir; ve
- Binding isteği ve yanıtındaki kaynak ve hedef taşıma adresleri simetriktir.
Bir denetim başarılı kabul edilirse, ICE ajanı (sırayla) aşağıdaki bölümlerde açıklanan eylemleri gerçekleştirir.
7.2.5.3.1. Eş-Yansıtmalı Adayların Keşfedilmesi
ICE ajanı, STUN yanıtındaki eşlenmiş adresi KONTROL ETMELİDİR. Taşıma adresi, ajanın bildiği yerel adaylardan herhangi biriyle eşleşmiyorsa, eşlenmiş adres yeni bir adayı temsil eder: eş-yansıtmalı bir aday. Diğer adaylar gibi, eş-yansıtmalı bir adayın da bir türü, tabanı, önceliği ve temeli vardır. Bunlar aşağıdaki gibi hesaplanır:
- Tür, eş-yansıtmalıdır.
- Taban, Binding isteğinin gönderildiği aday çiftinin yerel adayıdır.
- Öncelik, Binding isteğindeki PRIORITY özniteliğinin değeridir.
- Temel, Bölüm 5.1.1.3’te açıklandığı gibidir.
Eş-yansıtmalı aday daha sonra veri akışı için yerel adaylar listesine EKLENİR. Kullanıcı adı parçası ve parola, o veri akışı için diğer tüm yerel adaylarla aynıdır.
ICE ajanının, eş-yansıtmalı adayı uzak adaylarla eşleştirmesine gerek yoktur; çünkü Bölüm 7.2.5.3.2’deki prosedürler nedeniyle geçerli bir çift oluşturulacaktır. Bir ajan, eş-yansıtmalı adayı, üretilecek geçerli çifte dahil olan aday dışındaki uzak adaylarla eşleştirmek isterse, eş-yansıtmalı adayı içeren güncellenmiş aday bilgisini eşe SAĞLAYABİLİR. Bu, eş-yansıtmalı adayın diğer tüm uzak adaylarla eşleştirilmesine neden olur.
7.2.5.3.2. Geçerli Bir Çiftin Oluşturulması
ICE ajanı, yerel adayı yanıtın eşlenmiş adresine eşit olan ve uzak adayı isteğin gönderildiği hedef adrese eşit olan bir aday çifti OLUŞTURUR. Buna "geçerli çift" denir.
Geçerli çift, bağlantı denetimini üreten çiftle aynı olabilir, kontrol listesindeki farklı bir çift olabilir veya şu anda kontrol listesinde olmayan bir çift olabilir.
Ajan, "geçerli liste" olarak adlandırılan ayrı bir liste tutar. Kontrol listesi kümesindeki her kontrol listesi için bir geçerli liste vardır. Geçerli liste, geçerli çiftleri içerir. Başlangıçta her geçerli liste boştur.
Geçerli listedeki her geçerli çiftin, "aday gösterildi" bayrağı (nominated flag) olarak adlandırılan bir bayrağı vardır. Bir geçerli çift geçerli listeye eklendiğinde, bayrak değeri false olarak ayarlanır.
Geçerli çift, aşağıdaki şekilde bir geçerli listeye eklenir:
- Geçerli çift, denetimi üreten çiftle aynıysa, çift, ait olduğu kontrol listesiyle ilişkili geçerli listeye eklenir; veya
- Geçerli çift, bir kontrol listesindeki başka bir çiftle aynıysa, o çift, kendi kontrol listesinin geçerli listesine eklenir. Denetimi üreten çift, geçerli bir listeye eklenmez; veya
- Geçerli çift herhangi bir kontrol listesinde değilse, ajan Bölüm 6.1.2’deki algoritmayı kullanarak her adayın önceliğine dayanarak çift için önceliği hesaplar. Yerel adayın önceliği, türüne bağlıdır. Tür eş-yansıtmalı değilse, öncelik aday değişiminde o aday için sinyallenen önceliğe eşittir. Tür eş-yansıtmalıysa, öncelik, ajanın az önce tamamlanan Binding isteğine koyduğu PRIORITY özniteliğine eşittir. Uzak adayın önceliği, eşin aday bilgisinden alınır. Aday orada görünmüyorsa, denetim yeni bir uzak adaya tetiklenen bir denetim olmuştur. Bu durumda öncelik, az önce tamamlanan tetiklenen denetimi başlatan Binding isteğindeki PRIORITY özniteliğinin değeri olarak alınır. Çift daha sonra geçerli listeye eklenir.
NOT: Geçerli çiftin herhangi bir kontrol listesinde olmaması çok yaygın olacaktır. Kontrol listesinin, yerel adayları asla yansıtmalı olmayan çiftler içerdiğini hatırlayın; bu çiftlerin yerel adayları yansıtmalı adayların tabanına dönüştürülmüş ve ardından gereksizler budanmıştır. Binding isteğine yanıt geldiğinde, arada bir NAT varsa eşlenmiş adres yansıtmalı olacaktır. Bu durumda geçerli çift, kontrol listesindeki çiftlerden hiçbiriyle eşleşmeyen bir yerel adaya sahip olacaktır.
7.2.5.3.3. Aday Çifti Durumlarının Güncellenmesi
ICE ajanı, hem denetimi üreten aday çiftinin hem de oluşturulan geçerli çiftin (farklı olabilir) durumlarını Succeeded olarak AYARLAR.
Ajan, aynı temele sahip tüm kontrol listelerindeki diğer tüm Frozen durumundaki aday çiftlerinin durumlarını Waiting olarak AYARLAMALIDIR.
NOT: Belirli bir kontrol listesi içinde, aynı temellere sahip aday çiftleri genellikle farklı bileşen kimliği (component ID) değerlerine sahip olacaktır.
7.2.5.3.4. Aday Gösterildi Bayrağının Güncellenmesi
Denetleyici ajan, USE-CANDIDATE özniteliği ayarlanmış bir Binding isteği gönderirse ve ICE ajanı isteğe başarılı bir yanıt alırsa, ajan çiftin aday gösterildi bayrağını true olarak AYARLAR. İstek başarısız olursa (Bölüm 7.2.5.2), ajan aday çiftini geçerli listeden KALDIRMALI, aday çifti durumunu Failed olarak AYARLAMALI ve kontrol listesi durumunu Failed olarak AYARLAMALIDIR.
Denetlenen ajan, ajanın gönderdiği bir Binding isteğine başarılı bir yanıt alırsa ve bu Binding isteği, USE-CANDIDATE özniteliği ayarlanmış alınan bir Binding isteği tarafından tetiklendiyse (Bölüm 7.3.1.4), ajan çiftin aday gösterildi bayrağını true olarak AYARLAR. Tetiklenen istek başarısız olursa, ajan aday çiftini geçerli listeden KALDIRMALI, aday çifti durumunu Failed olarak AYARLAMALI ve kontrol listesi durumunu Failed olarak AYARLAMALIDIR.
Bir veri akışının bir bileşeni için aday gösterildi bayrağı ayarlandığında, o bileşen için ICE işlemi sonuçlanır (Bölüm 8).
7.2.5.4. Kontrol Listesi Durum Güncellemeleri
Bir bağlantı denetiminin başarılı ya da başarısız olmasından bağımsız olarak, denetimin tamamlanması kontrol listesi durumlarının güncellenmesini gerektirebilir. Kontrol listesi kümesindeki her kontrol listesi için, tüm aday çiftleri ya Failed ya da Succeeded durumundaysa ve kontrol listesiyle ilişkili veri akışının her bileşeni için geçerli listede bir geçerli çift yoksa, kontrol listesinin durumu Failed olarak ayarlanır. Geçerli listede her bileşen için bir geçerli çift varsa, kontrol listesinin durumu Succeeded olarak ayarlanır.
7.3. STUN Sunucu Prosedürleri
Bir ICE ajanı (lite veya tam), en son aday değişiminde dahil ettiği her adayın tabanı üzerinde Binding isteklerini almaya HAZIR OLMALIDIR.
Ajan, isteğin kimliğini doğrulamak ve bir mesaj bütünlüğü denetimi gerçekleştirmek için kısa süreli kimlik bilgisi mekanizmasını (yani MESSAGE-INTEGRITY özniteliğini) KULLANMALIDIR. Benzer şekilde, yanıt için de kısa süreli kimlik bilgisi mekanizması KULLANILMALIDIR. Ajan, kullanıcı adının iki nokta üst üste ile ayrılmış iki değerden oluşması durumunda geçerli olduğunu KABUL ETMELİDİR; burada ilk değer, devam eden bir oturum için aday değişiminde ajan tarafından üretilen kullanıcı adı parçasına eşittir.
Başlatıcı ajanın, eşinden adayları almadan önce bir Binding isteği alması mümkündür (ve aslında oldukça olasıdır). Bu durum gerçekleşirse, ajan DERHAL bir yanıt üretmelidir (Bölüm 7.3.1.2’de tanımlandığı şekilde eşlenen adresin hesaplanması dahil). Ajanın bu noktada yanıtı üretmek için yeterli bilgisi vardır; eşten gelen parola gerekli değildir. Yanıt alındıktan sonra, kalan gerekli adımlarla DEVAM ETMELİDİR; yani tam uygulamalar için Bölüm 7.3.1.3, 7.3.1.4 ve 7.3.1.5’e bakılmalıdır. Yanıt alınmadan önce birden fazla STUN isteğinin alınması durumlarında, bu durum tetiklenen-denetim kuyruğunda birden fazla çiftin sıraya alınmasına neden olabilir.
Bir ajan ALTERNATE-SERVER mekanizmasını KULLANMAMALI ve RFC 5389’da tanımlanan geriye dönük uyumluluk mekanizmalarını (RFC 3489’daki protokolle çalışmak için) DESTEKLEMEMELİDİR. FINGERPRINT mekanizmasını KULLANMALIDIR.
Ajan, veri paketlerinde DSCP işaretlemelerini [RFC2475] kullanıyorsa, Binding yanıtlarına da aynı işaretlemeleri UYGULAMALIDIR. Aynı durum, uç noktanın veri paketlerine uyguluyor olabileceği herhangi bir Katman 2 işaretlemesi için de geçerlidir.
7.3.1. Tam Uygulamalar için Ek Prosedürler
Bu alt bölüm, tam uygulamanın Binding isteğini kabul ettiği durumlarda, tam uygulamalara uygulanabilir ek sunucu prosedürlerini tanımlar.
7.3.1.1. Rol Çakışmalarının Tespiti ve Giderilmesi
ICE’in belirli kullanım biçimlerinde (örneğin 3PCC), her iki ICE ajanı da aynı rolü seçebilir ve bu da bir rol çakışmasına yol açar. Bu bölüm, rol çakışmalarını tespit etmek ve gidermek için bir mekanizmayı açıklar. Kullanım belgesi, bu mekanizmanın gerekli olup olmadığını BELİRTMELİDİR.
Bir ajan, Binding isteğini ICE-CONTROLLING veya ICE-CONTROLLED özniteliği açısından incelemelidir. Aşağıdaki prosedürleri İZLEMELİDİR:
- Ajan denetleyici roldeyse ve istekte ICE-CONTROLLING özniteliği mevcutsa:
- Ajanın bağlayıcı kırıcı (tiebreaker) değeri, ICE-CONTROLLING özniteliğinin içeriğinden büyük veya ona eşitse, ajan bir Binding hata yanıtı üretir ve değeri 487 (Role Conflict) olan bir ERROR-CODE özniteliği ekler, ancak rolünü korur.
- Ajanın bağlayıcı kırıcı değeri, ICE-CONTROLLING özniteliğinin içeriğinden küçükse, ajan denetlenen role geçer.
- Ajan denetlenen roldeyse ve istekte ICE-CONTROLLED özniteliği mevcutsa:
- Ajanın bağlayıcı kırıcı değeri, ICE-CONTROLLED özniteliğinin içeriğinden büyük veya ona eşitse, ajan denetleyici role geçer.
- Ajanın bağlayıcı kırıcı değeri, ICE-CONTROLLED özniteliğinin içeriğinden küçükse, ajan bir Binding hata yanıtı üretir ve değeri 487 (Role Conflict) olan bir ERROR-CODE özniteliği ekler, ancak rolünü korur.
- Ajan denetlenen roldeyken istekte ICE-CONTROLLING özniteliği mevcutsa veya ajan denetleyici roldeyken istekte ICE-CONTROLLED özniteliği mevcutsa, herhangi bir çakışma yoktur.
Rollerdeki bir değişiklik, önceliklerin role bağlı bir fonksiyon olması nedeniyle, ajanın çift önceliklerini yeniden hesaplamasını gerektirir (Bölüm 6.1.2.3). Rol değişikliği ayrıca, ICE’in sonuçlanmasının ardından güncellenmiş aday bilgileriyle değişimi başlatma ve aday gösterilmiş çiftleri seçme sorumluluğunun ajana ait olup olmadığını da etkiler.
Bölüm 7.3.1’deki kalan alt bölümler, ajan Binding isteğine başarılı bir yanıt üretmişse, ajan rollerini değiştirmiş olsa bile izlenir.
7.3.1.2. Eşlenen Adreslerin Hesaplanması
Aktarımlı (relayed) bir aday üzerinde alınan istekler için, STUN işlemede kullanılan kaynak taşıma adresi (yani XOR-MAPPED-ADDRESS özniteliğinin üretilmesi) TURN sunucusu tarafından görülen taşıma adresidir. Bu kaynak taşıma adresi, Binding isteği bir Data Indication aracılığıyla iletildiyse, bir Data Indication mesajının XOR-PEER-ADDRESS özniteliğinde bulunacaktır. Binding isteği bir ChannelData mesajı aracılığıyla iletildiyse, kaynak taşıma adresi kanala bağlanmış olan adrestir.
7.3.1.3. Eş-Yansıtmalı Adayların Öğrenilmesi
İsteğin kaynak taşıma adresi mevcut herhangi bir uzak adayla eşleşmiyorsa, bu durum yeni bir eş-yansıtmalı uzak adayı temsil eder. Bu aday aşağıdaki şekilde oluşturulur:
- Türü eş-yansıtmalıdır.
- Önceliği, Binding isteğindeki PRIORITY özniteliğinin değeridir.
- Temeli (foundation), diğer tüm uzak adayların temellerinden farklı olan rastgele bir değerdir. Daha sonraki herhangi bir aday değişimi bu eş-yansıtmalı adayı içerirse, bu durum aday için gerçek temeli işaret edecektir.
- Bileşen kimliği, isteğin gönderildiği yerel adayın bileşen kimliğidir.
Bu aday, uzak adaylar listesine eklenir. Ancak ICE ajanı bu adayı herhangi bir yerel adayla eşleştirmez.
7.3.1.4. Tetiklenen Denetimler
Ardından, ajan, yerel adayı STUN isteğinin alındığı taşıma adresine (ajan tarafından görüldüğü şekliyle) sahip olan ve uzak adayı isteğin geldiği kaynak taşıma adresine eşit olan (az önce öğrenilmiş olabilecek eş-yansıtmalı uzak aday dahil) bir çift oluşturur. Yerel aday, isteğin bir röle üzerinden alınmadığı durumlarda bir ana makine adayı, bir röle üzerinden alındığı durumlarda ise aktarımlı bir aday olacaktır. Yerel aday asla sunucu-yansıtmalı bir aday olamaz.
Her iki aday da ajan tarafından bilindiğinden, ajan bunların önceliklerini elde edebilir ve aday çifti önceliğini hesaplayabilir. Bu çift daha sonra kontrol listesinde aranır. Birkaç olası sonuç vardır:
- Çift zaten kontrol listesinde olduğunda:
- Bu çiftin durumu Succeeded ise, başka hiçbir işlem yapılmaz.
- Bu çiftin durumu In-Progress ise, ajan In-Progress işlemini iptal eder. İptal, ajanın bağlantı denetimi işlemiyle ilişkili Binding isteklerini yeniden iletmeyeceği, yanıt alınmamasını bir hata olarak değerlendirmeyeceği, ancak bir yanıt için işlem zaman aşımı süresi boyunca bekleyeceği anlamına gelir. Buna ek olarak, ajan, kontrol listesiyle ilişkili tetiklenen kontrol listesine çifti KUYRUKLAMALI ve çifti yeni bir bağlantı denetimini tetiklemek üzere durumunu Waiting olarak AYARLAMALIDIR. Yeni bir bağlantı denetimi oluşturmak, In-Progress çiftlerin mümkün olan en kısa sürede doğrulanmasını sağlar ve özgün bağlantı denetimi işlemine ait Binding isteklerinin yeniden iletilmesini bekleme gereksinimini ortadan kaldırır.
- Bu çiftin durumu Waiting, Frozen veya Failed ise, ajan (zaten mevcut değilse) kontrol listesiyle ilişkili tetiklenen kontrol listesine çifti KUYRUKLAMALI ve çifti yeni bir bağlantı denetimini tetiklemek üzere durumunu Waiting olarak AYARLAMALIDIR. Çiftin durumunun Failed’den Waiting’e değişmesinin, ilişkili kontrol listesinin durumunda da bir değişikliği tetikleyebileceğine dikkat edin.
Bu adımlar, her iki ajanın da NAT arkasında olduğu durumlarda ICE’in hızlı tamamlanmasını kolaylaştırmak için yapılır.
- Çift henüz kontrol listesinde değilse:
- Çift, önceliğine göre kontrol listesine eklenir.
- Durumu Waiting olarak ayarlanır.
- Çift, tetiklenen-denetim kuyruğuna eklenir.
Bir tetiklenen denetim gönderileceği zaman, Bölüm 7.2.4’te açıklandığı şekilde oluşturulur ve işlenir. Bu prosedürler, ajanın eş için taşıma adresini, kullanıcı adı parçasını ve parolayı bilmesini gerektirir. Uzak aday için kullanıcı adı parçası, az önce alınan Binding isteğindeki USERNAME’in iki noktadan sonraki kısmına eşittir. Bu kullanıcı adı parçası kullanılarak, ajan eşinden alınan adayları (çatallanma durumlarında birden fazla olabilir) kontrol edebilir ve bu kullanıcı adı parçasını bulabilir. Ardından karşılık gelen parola seçilir.
7.3.1.5. Aday Gösterme Bayrağının Güncellenmesi
Denetlenen ajan, USE-CANDIDATE özniteliği ayarlı bir Binding isteği alırsa ve ICE ajanı isteği kabul ederse, aşağıdaki eylem Bölüm 7.3.1.4’te hesaplanan çiftin durumuna bağlıdır:
- Bu çiftin durumu Succeeded ise, bu, bu çift tarafından daha önce gönderilen denetimin başarılı bir yanıt ürettiği ve geçerli bir çift meydana getirdiği anlamına gelir (Bölüm 7.2.5.3.2). Ajan, geçerli çiftin aday gösterme bayrağı değerini true olarak ayarlar.
- Alınan Binding isteği, tetiklenen-denetim kuyruğuna yeni bir denetimin eklenmesini tetiklediyse (Bölüm 7.3.1.4), denetim gönderildikten sonra ve başarılı bir yanıt üretir ve geçerli bir çift meydana getirirse, ajan çiftin aday gösterme bayrağını true olarak ayarlar. İstek başarısız olursa (Bölüm 7.2.5.2), ajan aday çiftini geçerli listeden KALDIRMALI, aday çifti durumunu Failed olarak AYARLAMALI ve kontrol listesi durumunu Failed olarak AYARLAMALIDIR.
Denetlenen ajan, denetleyici ajandan gelen isteği kabul etmezse, denetlenen ajan uygun bir hata kodu yanıtı (örneğin, 400) ile aday gösterme isteğini REDDETMELİDİR [RFC5389].
Bir veri akışının bir bileşeni için aday gösterme bayrağı ayarlandığında, bu, o bileşen için ICE işlemesini sonlandırır. Bölüm 8’e bakın.
7.3.2. Lite Uygulamalar için Ek Prosedürler
Denetlenen ajan, USE-CANDIDATE özniteliği ayarlı bir Binding isteği alırsa ve ICE ajanı isteği kabul ederse, ajan, yerel adayı isteğin alındığı taşıma adresine sahip olan ve uzak adayı alınan isteğin kaynak taşıma adresine eşit olan bir aday çifti oluşturur. Bu aday çiftine rastgele bir öncelik atanır ve ilişkili kontrol listesinin geçerli listesine yerleştirilir. Ajan, bu çift için aday gösterme bayrağını true olarak ayarlar.
Bir veri akışının bir bileşeni için aday gösterme bayrağı ayarlandığında, bu, o bileşen için ICE işlemesini sonlandırır. Bölüm 8’e bakın.
#8. ICE İşlemesinin Sonlandırılması
Bu bölüm, bir ICE ajanının ICE’i nasıl tamamladığını açıklar.
8.1. Tam Uygulamalar için Prosedürler
ICE’in sonlandırılması, denetleyici ajan tarafından çiftlerin aday gösterilmesini ve durum makinelerinin güncellenmesini içerir.
8.1.1. Çiftlerin Aday Gösterilmesi
Aday göstermeden önce, denetleyici ajan, bazı durdurma ölçütleri karşılanana kadar bağlantı denetimlerinin devam etmesine izin verir. Daha sonra, bir değerlendirme ölçütüne dayanarak, denetleyici ajan geçerli listedeki geçerli çiftler arasından aday gösterilecek bir çift seçer.
Denetleyici ajan, aday gösterme için geçerli bir çift seçtiğinde, bu geçerli çifti üreten bağlantı denetimini tekrarlar (denetimi üreten çifti tetiklenen-denetim kuyruğuna ekleyerek); bu kez USE-CANDIDATE özniteliği ile (Bölüm 7.2.5.3.4). Denetlenen ajan için prosedürler Bölüm 7.3.1.5’te açıklanmıştır.
Sonunda, aday göstermeler başarılı olursa, hem denetleyici hem de denetlenen ajan, veri akışının her bir bileşeni için geçerli listede tek bir aday gösterilmiş çifte sahip olacaktır. Bir ICE ajanı, kontrol listesinin durumunu Completed olarak ayarladığında (veri akışının her bir bileşeni için aday gösterilmiş bir çift olduğunda), bu çift o ajan için seçilmiş çift haline gelir ve veri akışının o bileşeni için veri gönderme ve alma amacıyla kullanılır.
Bir ajan, bir veri akışının her bir bileşeni için seçilmiş çiftler üretemezse, ajan diğer ajanı bilgilendirmek için uygun eylemleri ALMALIDIR; örneğin, akışı kaldırarak. Kesin eylemler bu belirtimin kapsamı dışındadır.
Bağlantı denetimlerini durdurma ve aday gösterme için bir çift seçme ölçütleri bu belirtimin kapsamı dışındadır. Bunlar yerel optimizasyon meselesidir. Tek gereksinim, ajanın sonunda bir ve yalnızca bir aday çifti SEÇMESİ ve bu çift için USE-CANDIDATE özniteliği ayarlı bir denetim ÜRETMESİDİR.
Denetleyici ajan bir aday çiftini başarıyla aday gösterdikten sonra (Bölüm 7.2.5.3.4), ajan, ICE oturumu içinde veri akışının aynı bileşeni için başka bir çifti ADAY GÖSTERMEMELİDİR. Bunu yapmak bir ICE yeniden başlatması gerektirir.
Bu belirtimi desteklemeyen (yani RFC 5245’e göre uygulanmış) bir denetleyici ajan, birden fazla aday çiftini aday gösterebilir. Bu durum RFC 5245’te agresif aday gösterme olarak adlandırılmıştır. Denetleyici ajan tarafından birden fazla aday çifti aday gösterilirse ve denetlenen ajan birden fazla aday gösterme isteğini kabul ederse, ajanlar seçilmiş çiftleri ÜRETMELİ ve en yüksek önceliğe sahip çiftleri kullanmalıdır.
Bu belirtimi destekleyen uç noktalar tarafından ice2 ICE seçeneğinin (Bölüm 10) kullanımı, RFC 5245’e göre uygulanmış denetleyici ajanların agresif aday gösterme kullanmasını engellemesi beklenir.
NOT: RFC 5245’te, agresif aday göstermenin kullanımı, bir çift sonunda seçilmeden önce, bu çiftler üzerinde veri gönderimine izin vermek amacıyla ajanların sürekli olarak çiftleri aday göstermesine olanak tanıyordu. Bu belirtimde ise, aday gösterme olmaksızın, herhangi bir geçerli çift üzerinde her zaman veri gönderilebilir. Dolayısıyla, agresif aday göstermeye artık gerek yoktur.
8.1.2. Kontrol Listesi ve ICE Durumlarının Güncellenmesi
Hem denetleyici hem de denetlenen bir ajan için, bir veri akışının bir bileşeni için bir aday çifti aday gösterildiğinde, bu durum veri akışıyla ilişkili kontrol listesindeki diğer çiftleri etkileyebilir. Ayrıca kontrol listesinin durumunu da etkileyebilir:
- Bir veri akışının bir bileşeni için bir aday çifti aday gösterildiğinde ve veri akışıyla ilişkili kontrol listesinin durumu Running ise, ICE ajanı aynı bileşen için tüm aday çiftlerini kontrol listesinden ve tetiklenen-denetim kuyruğundan KALDIRMALIDIR. Bir çiftin durumu In-Progress ise, ajan In-Progress işlemini iptal eder. İptal, ajanın bağlantı denetimi işlemiyle ilişkili Binding isteklerini yeniden iletmeyeceği, yanıt alınmamasını bir hata olarak değerlendirmeyeceği, ancak bir yanıt için işlem zaman aşımı süresi boyunca bekleyeceği anlamına gelir.
- Bir veri akışının her bir bileşeni için aday çiftler aday gösterildiğinde ve veri akışıyla ilişkili kontrol listesinin durumu Running ise, ICE ajanı kontrol listesinin durumunu Completed olarak ayarlar.
- Bir veri akışının bir bileşeni için bir aday çifti aday gösterildikten sonra, bir ajan, aday gösterilmiş çift ve veri akışıyla ilişkili kontrol listesindeki kalan tüm aday çiftleri için hâlâ alabileceği herhangi bir Binding isteğine yanıt vermeye DEVAM ETMELİDİR. Bölüm 7.3.1.4’te tanımlandığı üzere, bir çiftin durumu Succeeded olduğunda, ajan bu çift için bir Binding isteği aldığında artık tetiklenen denetimler üretmez.
Kontrol listesi kümesindeki her bir kontrol listesinin durumu Completed olduğunda, ajan ICE oturumunun durumunu Completed olarak ayarlar.
Bir kontrol listesinin durumu Failed ise, ICE, kontrol listesiyle ilişkili veri akışı için süreci başarıyla tamamlayamamıştır. Doğru davranış, kontrol listesi kümesindeki kontrol listelerinin durumuna bağlıdır. Denetleyici ajan, başarısız olan kontrol listesiyle ilişkili veri akışı olmadan oturuma devam etmek istiyorsa ve Running veya Completed modunda hâlâ bir veya daha fazla kontrol listesi varsa, ajan ICE işlemenin devam etmesine izin verebilir. Ajan, başarısız olan veri akışını kaldırmak için uygun işlemleri MUST yapmak zorundadır. Denetleyici ajan oturuma devam etmek istemiyor ve oturumu sonlandırması MUST gerekiyorsa, ICE oturumunun durumu Failed olarak ayarlanır.
Kontrol listesi kümesindeki her kontrol listesinin durumu Failed ise, ICE oturumunun durumu Failed olarak ayarlanır. Denetleyici ajan veri akışları olmadan oturuma devam etmek istemediği sürece, oturumu sonlandırması MUST gerekir.
8.2. Lite Gerçekleştirmeler için Prosedürler
ICE sonuçlandığında, bir lite ICE ajanı, Bölüm 8.3'te açıklandığı üzere, ICE tarafından kullanılmayan ana makine adaylarını serbest bırakabilir.
Eş ajan tam bir ajan ise, lite ajan bir aday çifti için bir aday gösterme isteğini kabul ettiğinde, lite ajan çifti aday gösterilmiş olarak kabul eder. Bir veri akışının her bileşeni için aday gösterilmiş çiftler oluştuğunda, bu çiftler veri akışının bileşenleri için seçilmiş çiftler hâline gelir. Lite ajan, tüm veri akışlarının tüm bileşenleri için seçilmiş çiftler ürettiğinde, ICE oturumunun durumu Completed olarak ayarlanır.
Eş ajan bir lite ajan ise, ajan yerel adayları, aynı veri akışına ait olan ve aynı bileşen, taşıma protokolü ve IP adres ailesine sahip uzak adaylarla eşleştirir. Her veri akışının her bileşeni için yalnızca bir aday çifti varsa, bu çift geçerli listeye eklenir. Birden fazla çift varsa, bir ajanın RFC 6724 [RFC6724] prosedürlerini izleyerek bir çift seçmesi ve bunu geçerli listeye eklemesi RECOMMENDED edilir.
Tüm veri akışlarının tüm bileşenleri için birer çift varsa, ICE işlemenin durumu Completed olur. Aksi takdirde, farklı ajanların farklı aday çiftleri seçmesini uzlaştırmak için denetleyici ajan MUST güncellenmiş bir aday listesi göndermelidir. ICE işleme, ancak ve ancak güncellenmiş aday değişimi tamamlandıktan sonra tamamlanmış sayılır.
8.3. Adayların Serbest Bırakılması
8.3.1. Tam Gerçekleştirme Prosedürleri
Bu bölümdeki kurallar, bir ajanın seçilmiş bir aday hâline gelmeyen (yani seçilmiş bir çiftle ilişkili olmayan) bir aday üzerinde kontrol göndermeyi veya almayı ne zaman güvenle durdurabileceğini ve adayı ne zaman serbest bırakabileceğini açıklar.
Bir kontrol listesi Completed durumuna ulaştığında, ajan SHOULD olarak ek üç saniye beklemeli ve ardından seçilmiş adaylar hâline gelenler dışındaki tüm yerel adaylar üzerinde kontrollere yanıt vermeyi veya tetiklenmiş kontroller üretmeyi durdurabilir. Belirli bir yerel aday, onu kullanan tüm ICE oturumları tarafından kullanılmayı bıraktığında (bir aday birden fazla ICE oturumu tarafından kullanılabilir; örneğin çatallanma senaryolarında), ajan bu adayı serbest bırakabilir. Üç saniyelik gecikme, agresif aday gösterme kullanıldığında ve ICE tamamlandıktan sonra seçilmiş çiftlerin hızla değişebileceği durumları ele alır.
Sunucu-yansıtmalı adayların serbest bırakılması hiçbir zaman açık değildir; bu, bir keepalive'ın olmamasıyla gerçekleşir.
8.3.2. Lite Gerçekleştirme Prosedürleri
Bir lite gerçekleştirme, bu adayları kullanan tüm ICE oturumları için ICE işlemi Completed durumuna ulaşır ulaşmaz, seçilmiş adaylar hâline gelmeyen adayları serbest bırakabilir.
#9. ICE Yeniden Başlatmaları
Bir ICE ajanı, mevcut veri akışları için ICE'yi yeniden başlatmayı MAY yapabilir. Bir ICE yeniden başlatması, ajanların rollerini hariç tutarak, veri akışlarının önceki tüm durumlarının temizlenmesine neden olur. Bir ICE yeniden başlatması ile tamamen yeni bir veri oturumu arasındaki tek fark, yeniden başlatma sırasında mevcut veri oturumları kullanılarak veri gönderiminin devam edebilmesi ve yeni bir veri oturumunun her zaman rollerin belirlenmesini gerektirmesidir.
Aşağıdaki işlemler yalnızca bir ICE yeniden başlatması kullanılarak gerçekleştirilebilir (ajan bunları yapmak için ICE yeniden başlatmalarını MUST kullanmalıdır):
- Veri akışlarının hedeflerini değiştirmek.
- Lite bir gerçekleştirmeden tam bir gerçekleştirmeye geçmek.
- Tam bir gerçekleştirmeden lite bir gerçekleştirmeye geçmek.
ICE'yi yeniden başlatmak için, bir ajan yeniden başlatılan veri akışı(ları) için hem parolayı hem de kullanıcı adı parçasını MUST değiştirmelidir.
ICE yeniden başlatıldığında, yeni ICE oturumu için aday kümesi, mevcut ICE oturumunda kullanılan adayların bazılarını, hiçbirini veya tamamını içerebilir.
Bölüm 6.1.1'de açıklandığı üzere, ajanlar, rollerin yeniden belirlenmesini gerektiren belirli ölçütler sağlanmadıkça, bir ICE yeniden başlatmasının parçası olarak rolleri MUST NOT yeniden belirlememelidir.
#10. ICE Seçeneği
Bu bölüm, ice2 adlı yeni bir ICE seçeneğini tanımlar. Bir ICE ajanı, bir aday değişiminde ice2yi dahil ettiğinde, ICE seçeneği bu belirtime uyumlu olduğunu gösterir. Örneğin, ajan RFC 5245'te tanımlanan agresif aday gösterme prosedürünü kullanmayacaktır. Ayrıca, bu belirtime uyumlu bir eş ajanın, RFC 5245'e uyumlu olmasını sağlamak için, RFC 5245'in Bölüm 14'ünde gerektirdiği üzere, agresif aday gösterme kullanmamasını da temin edecektir.
Bu belirtime uyumlu bir ajan, uyumluluğu ice2 seçeneğini kullanarak eş ajana bildirmeyi MUST yapmalıdır.
NOT: `ice2` seçeneğinin kodlanması ve bunu eş ajana taşıyan mesaj(lar) protokole özgüdür. SDP [RFC4566] için kodlama [ICE-SIP-SDP] içinde tanımlanmıştır.
#11. Keepalive'lar
Tüm uç noktalar, her veri oturumu için keepalive göndermeyi MUST yapmalıdır. Bu keepalive'lar, veri oturumu için NAT bağlamalarını canlı tutma amacına hizmet eder. Keepalive'lar, eş ajan tarafından desteklenen bir format kullanılarak gönderilmelidir (SHOULD). ICE uç noktaları, UDP akışları için STUN tabanlı keepalive'lara izin verir ve bu nedenle, bir ICE ajanı tam bir ICE gerçekleştirmesi olduğunda ve ICE (lite veya tam) destekleyen bir eş ile iletişim kurduğunda, STUN keepalive'ları MUST kullanılmalıdır.
Bir ajan, son Tr saniye içinde o çift üzerinde hiçbir paket gönderilmediyse, veri göndermek için kullanılan her aday çifti üzerinde bir keepalive MUST göndermelidir. Ajanlar, Tr değeri olarak 15 saniyeyi SHOULD kullanmalıdır. Ajanlar daha büyük bir değer MAY kullanabilir ancak 15 saniyeden daha küçük bir değer MUST NOT kullanmamalıdır.
Bir veri akışı için seçilmiş çiftler üretildikten sonra, keepalive'lar yalnızca bu çiftler üzerinde gönderilir.
Bir veri akışı kaldırılırsa, bir ajan bu veri akışı üzerindeki keepalive göndermeyi MUST durdurmalıdır. ICE oturumu sonlandırılırsa, bir ajan tüm veri akışları üzerindeki keepalive göndermeyi MUST durdurmalıdır.
Bir ajan, yapılandırmaya veya ağ/NAT özelliklerine dayalı olarak, örneğin Tr için başka bir değer MAY kullanabilir. Örneğin, bir ajan, aradaki NAT'lerin bağlama ömürlerini dinamik bir şekilde keşfetme yoluna sahipse, Tr değerini belirlemek için bu değeri kullanabilir. ICE'yi daha kontrollü ağ ortamlarında devreye alan yöneticiler, Tr değerini kendi ortamlarındaki mümkün olan en uzun süreye ayarlamalıdır (SHOULD).
Keepalive'lar için STUN kullanıldığında, bir STUN Binding Indication kullanılır [RFC5389]. Bu Indication herhangi bir kimlik doğrulama mekanizmasını MUST NOT kullanmamalıdır. Demultiplekslemeye yardımcı olmak için FINGERPRINT özniteliğini içermelidir (SHOULD), ancak başka hiçbir öznitelik SHOULD NOT içermemelidir. Yalnızca NAT bağlamalarını canlı tutmak için kullanılır. Binding Indication, veri için kullanılan aynı yerel ve uzak adaylar kullanılarak gönderilir. Binding Indication'lar keepalive için kullanılsa da, bir ajan bir bağlantı denetimi almayı da MUST beklemeye hazır olmalıdır. Bir bağlantı denetimi alınırsa, [RFC5389]'da tartışıldığı üzere bir yanıt üretilir, ancak bunun ICE işlemesi üzerinde başka bir etkisi olmaz.
Ajanlar, varsayılan olarak STUN keepalive'larını MUST kullanmalıdır. Bireysel ICE kullanımları ve ICE uzantıları, kullanıma veya uzantıya özgü keepalive'ları MAY belirtebilir.
#12. Veri İşleme
12.1. Veri Gönderme
Bir ICE ajanı, bir veri akışı için seçilmiş çiftler üretilmeden önce, herhangi bir geçerli çift üzerinde veri göndermeyi MAY yapabilir.
Bir veri akışı için seçilmiş çiftler üretildikten sonra, bir ajan yalnızca bu çiftler üzerinde veri göndermeyi MUST yapmalıdır.
Bir ajan, veriyi yerel adayın tabanından uzak adaya gönderir. Yerel adayın yönlendirilmiş bir aday olması durumunda, veri [RFC5766]'da tanımlanan prosedürler kullanılarak, taban (TURN sunucusunda bulunan) üzerinden iletilir.
Yerel aday yönlendirilmiş bir aday ise, bir ajanın uzak adaya doğru TURN sunucusu üzerinde bir kanal oluşturması RECOMMENDED edilir. Bu, [RFC5766]'nın Bölüm 11'inde tanımlanan kanal oluşturma prosedürleri kullanılarak yapılır.
Bir veri akışının bir bileşeni için seçilmiş çift:
- Bu veri akışı için kontrol listesinin durumu Running ise ve bir ICE yeniden başlatması nedeniyle bu bileşen için önceki bir seçilmiş çift yoksa boştur
- Bu veri akışı için kontrol listesinin durumu Running ise ve bir ICE yeniden başlatması nedeniyle bu bileşen için önceki bir seçilmiş çift varsa, önceki seçilmiş çifte eşittir
Bir ajan, bir veri akışıyla ilişkili her bileşen için bir seçilmiş çift üretemediği sürece, bu veri akışıyla ilişkili herhangi bir bileşen için veri göndermeye devam etmeyi MUST NOT yapmalıdır.
12.1.1. Lite Gerçekleştirmeler için Prosedürler
Bir lite gerçekleştirme, bu veri akışının her bileşeni için bir aday çifti içeren bir geçerli listeye sahip olana kadar veri göndermeyi MUST NOT yapmalıdır. Bu gerçekleştiğinde, ICE ajanı veri paketleri göndermeye MAY başlayabilir. Bunu yapmak için, veriyi çiftteki uzak adaya gönderir (paketin hedef adresini ve bağlantı noktasını bu uzak adaya eşitleyerek) ve veriyi, veri göndermek için kullanılan aday çiftiyle ilişkili tabandan gönderir. Yönlendirilmiş bir aday durumunda, veri ajandan gönderilir ve [RFC5766]'da tanımlanan prosedürler kullanılarak taban (TURN sunucusunda bulunan) üzerinden iletilir.
12.2. Veri Alma
ICE ajanlarının yalnızca geçerli aday çiftlerini kullanarak (ve seçilmiş çiftler üretildikten sonra yalnızca seçilmiş çiftler üzerinde) veri göndermesine izin verilmesine rağmen, ICE gerçekleştirmeleri varsayılan olarak, eş ile yapılan en son aday değişiminde sağlanan adayların herhangi biri üzerinde veri almaya hazır olmalıdır (SHOULD). ICE kullanımları, bundan farklı kurallar tanımlayabilir; örneğin, bir veri akışı için seçilmiş çiftler üretilene kadar veri gönderilmeyeceğini tanımlayabilir.
Bir ajan, belirli bir RTP/RTCP veri akışı için yeni bir kaynak veya hedef IP adresine sahip bir RTP paketi aldığında, ajanın jitter arabelleklerini yeniden ayarlaması RECOMMENDED edilir.
RFC 3550'nin Bölüm 8.2'si [RFC3550], eşzamanlama kaynağı (SSRC) çakışmalarını ve döngülerini tespit etmek için bir algoritma açıklar. Bu algoritmalar, kısmen, aynı SSRC ile farklı kaynak taşıma adreslerinin görülmesine dayanır. Ancak ICE kullanıldığında, veri akışları adaylar arasında geçiş yaptıkça bu tür değişiklikler bazen meydana gelir. Bir ajan, medya verisi iletiminden önce gerçekleşen STUN değişimi sonucunda, bir veri akışının aynı eşten geldiğini belirleyebilecektir. Dolayısıyla, kaynak taşıma adresinde bir değişiklik olsa bile, medya veri paketleri aynı eş ajandan geliyorsa, bu durum bir SSRC çakışması olarak MUST NOT ele alınmalıdır.
#13. Genişletilebilirlik Hususları
Bu belirtim, bir oturumdaki her iki ICE ajanının da veri için seçilen aday çiftleri kümesine ulaşmak üzere nasıl koordinasyon sağladığı konusunda çok özel seçimler yapar. Gelecekteki belirtimlerin, zamanlayıcı ayarlamaları gibi basit değişiklikler veya öncelik algoritmasının elden geçirilmesi gibi daha büyük değişiklikler olsun, bu algoritmaları değiştirmek isteyeceği öngörülmektedir. Böyle bir değişiklik yapıldığında, bir oturumdaki iki ajan arasında birlikte çalışabilirlik sağlamak kritik önemdedir.
Öncelikle, ICE, ICE seçeneği kavramını sağlar. ICE'ye yapılan her uzantı veya değişiklik bir ICE seçeneği ile ilişkilendirilir. Bir ajan böyle bir uzantıyı veya değişikliği desteklediğinde, aday değişiminin bir parçası olarak ICE seçeneğini eş ajana sunar.
Birlikte çalışabilirliğe ulaşmadaki zorluklardan biri, ICE'nin her iki ajan üzerinde de çalışan ve üzerinde uzlaşılmış bir aday çiftleri kümesine yakınsayan dağıtık bir algoritmaya dayanmasıdır. İki ajan farklı algoritmalar çalıştırıyorsa, aynı aday çiftleri üzerinde yakınsama sağlamak zor olabilir. Bölüm 8'de açıklanan aday gösterme prosedürü, seçim algoritmasını tamamen denetleyici ajana devrederek sıkı koordinasyon ihtiyacının bir kısmını ortadan kaldırır ve her iki ajan da farklı çift önceliklendirme algoritmaları kullansa bile ICE mükemmel şekilde yakınsar. Bu tür bir yakınsamanın anahtarlarından biri, aday gösterilen çiftin her iki ajan tarafından da doğrulanmasını sağlayan tetiklenmiş kontrollerdir.
ICE, ayrıca RTP'nin ötesindeki diğer veri akışları ve UDP'nin ötesindeki taşıma protokolleri için de genişletilebilir. RTP dışı veri akışları için ICE uzantılarının, kaç bileşen kullandıklarını belirtmeleri ve en önemli bileşen kimliği için 1'den başlayarak bileşen kimlikleri atamaları gerekir. Yeni taşıma protokolleri için belirtimler, ICE işlemesindeki çeşitli adımların UDP'den nasıl ve ne ölçüde farklılaştığını MUST tanımlamalıdır.
#14. Ta ve RTO'nun Ayarlanması
14.1. Genel
ICE toplama aşaması (Bölüm 5.1.1) sırasında ve ICE bağlantı denetimleri gerçekleştirirken (Bölüm 7), bir ICE ajanı STUN ve TURN işlemlerini tetikler. Bu işlemler, Ta ile belirtilen bir hızda ilerletilir ve her bir işlem için yeniden iletim aralığı, STUN işlemleri için yeniden iletim zamanlayıcısına (RTO) [RFC5389] dayalı olarak hesaplanır.
Bu bölüm, ICE toplama aşaması sırasında ve ICE bağlantı denetimleri gerçekleştirirken Ta ve RTO değerlerinin nasıl hesaplandığını açıklar.
NOT: Daha önce, RFC 5245'te, ICE'nin gerçek zamanlı bir veri akışı (örneğin RTP) için kullanılıp kullanılmadığına bağlı olarak, Ta ve RTO'nun hesaplanması için farklı formüller tanımlanmıştı.
Aşağıdaki formüller, bir ajanın her bir bağlantı denetimi için ilk paketini yeniden iletim yapmadan önce göndereceği bir davranışla sonuçlanır. Bu durum, yeniden iletim aralığını temsil eden RTO formüllerinde görülebilir. Bu formüller, gerçekleştirilecek denetim sayısı olan N ile ölçeklenir. Bunun sonucu olarak, ICE oldukça sabit bir hız sürdürür, ancak paket kaybına karşı daha hassas hâle gelir. Herhangi bir bağlantı denetimi için ilk tek paketin kaybı, o çiftin doğrulanmasının uzun sürmesine yol açma olasılığı taşır ve bunun yerine, daha düşük öncelikli bir denetimin (ancak paket kaybı olmayan bir denetimin) önce tamamlanması çok daha olasıdır. Bu da ICE'nin en uygun olmayan şekilde çalışmasına ve daha yüksek öncelikli çiftler yerine daha düşük öncelikli çiftleri seçmesine neden olur.
14.2. Ta
ICE ajanları, varsayılan Ta değeri olarak 50 ms kullanmalıdır (SHOULD), ancak ilişkili verinin özelliklerine bağlı olarak başka bir değer MAY kullanabilir.
Bir ajan, varsayılan değerden farklı bir Ta değeri kullanmak istiyorsa, ICE oturumunun kurulumu sırasında önerilen değeri eş ajana MUST bildirmelidir. Her iki ajan da önerilen değerlerin daha yüksek olanını MUST kullanmalıdır. Bir ajan bir değer önermezse, hangi değerin daha yüksek olduğunu karşılaştırırken o ajan için varsayılan değer kullanılır.
Her bir ajan için seçilen Ta değerinden bağımsız olarak, tüm ajanlardan gelen tüm işlemlerin birleşimi (belirli bir uygulama birden fazla eşzamanlı ajan çalıştırıyorsa) 5 ms’de birden daha sık gönderilmemelidir (tüm ajanların hızını ayarlayan tek bir genel Ta değeri varmış gibi). ICE ile 5 ms değerinin kullanılmasının arka planı için Ek B.1’e bakınız.
NOT: Ek C, farklı Ta değerleri kullanılarak gerekli bant genişliğine ilişkin örnekler göstermektedir.
14.3. RTO
ICE toplama aşaması sırasında, ICE ajanları RTO değerini aşağıdaki formülü kullanarak HESAPLAMALIDIR:
RTO = MAX(500 ms, Ta (Num-Of-Cands)) Num-Of-Cands*: sunucu-yansıtmalı ve röle adaylarının sayısı
Bağlanırlık kontrolleri için, ajanlar RTO değerini aşağıdaki formülü kullanarak HESAPLAMALIDIR:
RTO = MAX(500 ms, Ta N (Num-Waiting + Num-In-Progress)) N: gerçekleştirilecek toplam bağlanırlık kontrolü sayısı. Num-Waiting: kontrol listesi kümesinde Beklemede (Waiting) durumundaki kontrollerin sayısı. Num-In-Progress: kontrol listesi kümesinde Devam Ediyor (In-Progress) durumundaki kontrollerin sayısı. RTO’nun, Beklemede ve Devam Ediyor durumlarındaki kontrol sayısı değiştikçe her işlem için farklı olacağına dikkat ediniz.
Ajanlar, yukarıda açıklananların dışında mekanizmalar kullanarak da RTO değerini hesaplayabilir. Ajanlar 500 ms’den küçük bir RTO değeri KULLANMAMALIDIR.
#15. Örnekler
Bu bölüm iki ICE örneği göstermektedir: biri IPv4 adreslerini, diğeri IPv6 adreslerini kullanmaktadır.
Anlaşılmayı kolaylaştırmak için, taşıma adresleri anımsatıcı adlara sahip değişkenler kullanılarak listelenmiştir. Ad biçimi varlık-tür-sıra no şeklindedir: “varlık”, taşıma adresinin üzerinde bulunduğu varlığı ifade eder ve "L", "R", "STUN" veya "NAT" değerlerinden biridir. Tür, genel olan taşıma adresleri için "PUB" ya da özel olan taşıma adresleri için "PRIV" [RFC1918] değerlerinden biridir. Son olarak, sıra no, belirli bir varlık üzerindeki aynı türdeki her taşıma adresi için farklı olan bir sıra numarasıdır. Her değişkenin bir IP adresi ve bir portu vardır; bunlar sırasıyla varname.IP ve varname.PORT ile gösterilir; burada varname değişkenin adıdır.
Çağrı akışının kendisinde, STUN iletileri çeşitli özniteliklerle açıklanmıştır. "S=" özniteliği iletinin kaynak taşıma adresini belirtir. "D=" özniteliği iletinin hedef taşıma adresini belirtir. "MA=" özniteliği STUN Binding yanıt iletilerinde kullanılır ve eşlenmiş adresi ifade eder. "USE-CAND", USE-CANDIDATE özniteliğinin varlığını ima eder.
Çağrı akışı örnekleri STUN kimlik doğrulama işlemlerini dışarıda bırakır ve iki tam uygulama arasındaki tek bir veri akışına odaklanır.
15.1. IPv4 Adresleri ile Örnek
Aşağıdaki örnek, Şekil 7’de gösterilen topolojiyi kullanmaktadır.
+-------+
| STUN |
|Server |
+-------+
|
+---------------------+
| |
| Internet |
| |
+---------------------+
| |
| |
+---------+ |
| NAT | |
+---------+ |
| |
| |
+-----+ +-----+
| L | | R |
+-----+ +-----+
Figure 7: Example TopologyBu örnekte, ICE ajanları L ve R tam ICE uygulamalarıdır. Her iki ajanın da tek bir IPv4 adresi vardır ve her ikisi de aynı STUN sunucusu ile yapılandırılmıştır. NAT, uç noktadan bağımsız eşleme özelliğine ve adrese bağımlı filtreleme özelliğine sahiptir. ICE ajanlarının, STUN sunucusunun ve NAT’ın IP adresleri aşağıda gösterilmiştir:
| VARLIK | IP Adresi | Anımsatıcı ad | |---------------|------------|---------------| | ICE Ajanı L | 10.0.1.1 | L-PRIV-1 | | ICE Ajanı R | 192.0.2.1 | R-PUB-1 | | STUN Sunucusu | 192.0.2.2 | STUN-PUB-1 | | NAT (Genel) | 192.0.2.3 | NAT-PUB-1 |
L NAT STUN R
| STUN alloc. | | |
| (1) STUN Req | | |
| S=$L-PRIV-1 | | |
| D=$STUN-PUB-1 | | |
|-------------->| | |
| | (2) STUN Req | |
| | S=$NAT-PUB-1 | |
| | D=$STUN-PUB-1 | |
| |-------------->| |
| | (3) STUN Res | |
| | S=$STUN-PUB-1 | |
| | D=$NAT-PUB-1 | |
| | MA=$NAT-PUB-1 | |
| |<--------------| |
| (4) STUN Res | | |
| S=$STUN-PUB-1 | | |
| D=$L-PRIV-1 | | |
| MA=$NAT-PUB-1 | | |
|<--------------| | |
| (5) L'nin Aday Bilgileri | |
|--------------------------------------------->|
| | | | STUN alloc.
| | | (6) STUN Req |
| | | S=$R-PUB-1 |
| | | D=$STUN-PUB-1|
| | |<-------------|
| | | (7) STUN Res |
| | | S=$STUN-PUB-1|
| | | D=$R-PUB-1 |
| | | MA=$R-PUB-1 |
| | |------------->||(8) R'nin Aday Bilgileri| |
|<-------------------------------------------|
| | (9) Bind Req | Başlangıç
| | S=$R-PUB-1 | Bağlanırlık
| | D=$L-PRIV-1 | Kontrolleri
| | <-------------------|
| | Dropped |
|(10) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|------------->| | |
| |(11) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |---------------------------->|
| |(12) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(13) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
|Data | | |
|===========================================>|
| | | |
| |(14) Bind Req | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |<----------------------------|
|(15) Bind Req | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|<-------------| | |
|(16) Bind Res | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|MA=$R-PUB-1 | | |
|------------->| | |
| |(17) Bind Res | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |MA=$R-PUB-1 | |
| |---------------------------->|
|Data | | |
|<===========================================| | | | |
.......
| | | |
|(18) Bind Req | | |
|S=$L-PRIV-1 | | |
|D=$R-PUB-1 | | |
|USE-CAND | | |
|------------->| | |
| |(19) Bind Req | |
| |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | |
| |USE-CAND | |
| |---------------------------->|
| |(20) Bind Res | |
| |S=$R-PUB-1 | |
| |D=$NAT-PUB-1 | |
| |MA=$NAT-PUB-1 | |
| |<----------------------------|
|(21) Bind Res | | |
|S=$R-PUB-1 | | |
|D=$L-PRIV-1 | | |
|MA=$NAT-PUB-1 | | |
|<-------------| | |
| | | |Şekil 8: Örnek Akış
İletiler 1–4: Ajan L, yerel IP adresinden bir ana makine adayı toplar ve bundan STUN sunucusuna bir STUN Binding isteği gönderir. İstek bir NAT bağlaması oluşturur. Bağlamanın NAT genel IP adresi, ajan L’nin sunucu-yansıtmalı adayı haline gelir.
İleti 5: Ajan L, ICE kullanımına ilişkin sinyalleşme protokolünü kullanarak yerel aday bilgilerini ajan R’ye gönderir.
İletiler 6–7: Ajan R, yerel IP adresinden bir ana makine adayı toplar ve bundan STUN sunucusuna bir STUN Binding isteği gönderir. Ajan R bir NAT arkasında olmadığından, R’nin sunucu-yansıtmalı adayı ana makine adayı ile özdeş olacaktır.
İleti 8: Ajan R, ICE kullanımına ilişkin sinyalleşme protokolünü kullanarak yerel aday bilgilerini ajan L’ye gönderir.
Her iki ajan da tam ICE uygulamaları olduğundan, başlatıcı ajan (ajan L) denetleyici ajan olur.
Ajanlar L ve R her ikisi de adayları eşleştirir. Her iki ajan da başlangıçta iki çifte sahiptir. Ancak, ajan L sunucu-yansıtmalı adayını içeren çifti budar ve geriye yalnızca bir tane (L1) kalır.
Ajan L’de bu çiftin yerel adayı $L_PRIV_1 ve uzak adayı $R_PUB_1’dir. Ajan R’de iki çift vardır. En yüksek öncelikli çift (R1) yerel aday olarak $R_PUB_1 ve uzak aday olarak $L_PRIV_1’e sahiptir; ikinci çift (R2) ise yerel aday olarak $R_PUB_1 ve uzak aday olarak $NAT_PUB_1’e sahiptir. Çiftler aşağıda gösterilmiştir (çift numaraları yalnızca referans amaçlıdır):
Çiftler
| VARLIK | Yerel | Uzak | Çift # | Geçerli | |---------------|-------------|-------------|--------|---------| | ICE Ajanı L | L_PRIV_1 | R_PUB_1 | L1 | | | ICE Ajanı R | R_PUB_1 | L_PRIV_1 | R1 | | | | R_PUB_1 | NAT_PUB_1 | R2 | |
İleti 9: Ajan R, çift #2 için bir bağlanırlık kontrolü başlatır. Çiftin uzak adayı ajan L’nin özel adresi olduğundan, istek R’den L’ye yönlendirilemeyeceği ve ağ tarafından düşürüleceği için kontrol başarılı olmayacaktır.
İletiler 10–13: Ajan L, L1 çifti için bir bağlanırlık kontrolü başlatır. Kontrol başarılı olur ve L yeni bir çift (L2) oluşturur. Yeni çiftin yerel adayı $NAT_PUB_1, uzak adayı ise $R_PUB_1’dir. (L2) çifti, ajan L’nin geçerli listesine eklenir. Ajan L artık isterse (L2) çifti üzerinden veri gönderip alabilir.
Çiftler
| VARLIK | Yerel | Uzak | Çift # | Geçerli | |---------------|-------------|-----------|--------|---------| | ICE Ajanı L | L_PRIV_1 | R_PUB_1 | L1 | | | | NAT_PUB_1 | R_PUB_1 | L2 | X | | ICE Ajanı R | R_PUB_1 | L_PRIV_1 | R1 | | | | R_PUB_1 | NAT_PUB_1 | R2 | |
İletiler 14–17: Ajan R, ajan L’den gelen Binding isteğini (ileti 11) aldığında tetiklenmiş bir bağlanırlık kontrolü başlatır. Çift, ajan R’nin mevcut çiftlerinden biriyle (R2) eşleşir. Kontrol başarılı olur ve (R2) çifti, ajan R’nin geçerli listesine eklenir. Ajan R artık isterse (R2) çifti üzerinden veri gönderip alabilir.
Çiftler
| VARLIK | Yerel | Uzak | Çift # | Geçerli | |---------------|-----------|-----------|--------|---------| | ICE Ajanı L | L_PRIV_1 | R_PUB_1 | L1 | | | | NAT_PUB_1 | R_PUB_1 | L2 | X | | ICE Ajanı R | R_PUB_1 | L_PRIV_1 | R1 | | | | R_PUB_1 | NAT_PUB_1 | R2 | X |
İletiler 18–21: Bir noktada, denetleyici ajan (ajan L) geçerli listedeki bir çifti (L2) aday göstermeye karar verir. (L2) çifti üzerinde bir bağlanırlık kontrolü gerçekleştirir ve Binding isteğine USE-CANDIDATE özniteliğini ekler. Kontrol başarılı olduğundan, ajan L (L2) çiftinin aday gösterilmiş bayrak değerini true olarak ayarlar ve ajan R eşleşen çiftin (R2) aday gösterilmiş bayrak değerini true olarak ayarlar. Akışla ilişkili başka bileşen kalmadığından, aday gösterilmiş çiftler seçilmiş çiftler haline gelir. Sonuç olarak, bu akış için işleme Tamamlandı (Completed) durumuna geçer. ICE süreci de Tamamlandı (Completed) durumuna geçer.
15.2. IPv6 Adresleri ile Örnek
Aşağıdaki örnek, Şekil 9’da gösterilen topolojiyi kullanmaktadır.
+-------+
| STUN |
| Server|
+-------+
|
+---------------------+
| |
| Internet |
| |
+---------------------+
| |
+-----+ +-----+
| L | | R |
+-----+ +-----+Şekil 9: Örnek Topoloji
Örnekte, ICE ajanları L ve R tam ICE uygulamalarıdır. Her iki ajan da tek bir IPv6 adresine sahiptir ve her ikisi de aynı STUN sunucusu ile yapılandırılmıştır. ICE ajanlarının ve STUN sunucusunun IP adresleri aşağıda gösterilmiştir:
| VARLIK | IP Adresi | anımsatıcı ad | |---------------|----------------|---------------| | ICE Ajanı L | 2001:db8::3 | L-PUB-1 | | ICE Ajanı R | 2001:db8::5 | R-PUB-1 | | STUN Sunucusu | 2001:db8::9 | STUN-PUB-1 |
L STUN R
| STUN ayırma | |
|(1) STUN İsteği | |
|S=$L-PUB-1 | |
|D=$STUN-PUB-1 | |
|---------------------------->| |
|(2) STUN Yanıtı | |
|S=$STUN-PUB-1 | |
|D=$L-PUB-1 | |
|MA=$L-PUB-1 | |
|<----------------------------| |
|(3) L'nin Aday Bilgileri | |
|------------------------------------------->|
| | | STUN ayırma
| |(4) STUN İsteği|
| |S=$R-PUB-1 |
| |D=$STUN-PUB-1 |
| |<-------------|
| |(5) STUN Yanıtı|
| |S=$STUN-PUB-1 |
| |D=$R-PUB-1 |
| |MA=$R-PUB-1 |
| |------------->|
|(6) R'nin Aday Bilgileri | |
|<-------------------------------------------|
|(7) Bağlama İsteği | |
|S=$L-PUB-1 | |
|D=$R-PUB-1 | |
|------------------------------------------->|
|(8) Bağlama Yanıtı | |
|S=$R-PUB-1 | |
|D=$L-PUB-1 | |
|MA=$L-PUB-1 | |
|<-------------------------------------------| |Veri | |
|===========================================>|
| | |
|(9) Bağlama İsteği | |
|S=$R-PUB-1 | |
|D=$L-PUB-1 | |
|<-------------------------------------------|
|(10) Bağlama Yanıtı | |
|S=$L-PUB-1 | |
|D=$R-PUB-1 | |
|MA=$R-PUB-1 | |
|------------------------------------------->|
|Veri | |
|<===========================================|
| | |
.......
| | |
|(11) Bağlama İsteği | |
|S=$L-PUB-1 | |
|D=$R-PUB-1 | |
|USE-CAND | |
|------------------------------------------->|
|(12) Bağlama Yanıtı | |
|S=$R-PUB-1 | |
|D=$L-PUB-1 | |
|MA=$L-PUB-1 | |
|<-------------------------------------------|
| | | |Şekil 10: Örnek Akış
Mesajlar 1–2: Ajan L, yerel IP adresinden bir ana bilgisayar adayı toplar ve bundan STUN sunucusuna bir STUN Binding isteği gönderir. Ajan L bir NAT arkasında olmadığı için, L'nin sunucu-yansıtmalı adayı ana bilgisayar adayı ile özdeş olacaktır.
Mesaj 3: Ajan L, ICE kullanımına bağlı sinyalleşme protokolünü kullanarak yerel aday bilgilerini ajan R'ye gönderir.
Mesajlar 4–5: Ajan R, yerel IP adresinden bir ana bilgisayar adayı toplar ve bundan STUN sunucusuna bir STUN Binding isteği gönderir. Ajan R bir NAT arkasında olmadığı için, R'nin sunucu-yansıtmalı adayı ana bilgisayar adayı ile özdeş olacaktır.
Mesaj 6: Ajan R, ICE kullanımına bağlı sinyalleşme protokolünü kullanarak yerel aday bilgilerini ajan L'ye gönderir.
Her iki ajan da tam ICE uygulamaları olduğundan, başlatıcı ajan (ajan L) denetleyici ajan olur.
Ajanlar L ve R adayları eşleştirir. Her iki ajan da başlangıçta birer eşe sahiptir. Ajan L'de, (L1) çifti yerel aday olarak $L_PUB_1 ve uzak aday olarak $R_PUB_1 içerir. Ajan R'de, (R1) çifti yerel aday olarak $R_PUB_1 ve uzak aday olarak $L_PUB_1 içerir. Eşler aşağıda gösterilmiştir (eş numaraları yalnızca referans amaçlıdır):
Eşler
| VARLIK | Yerel | Uzak | Eş # | Geçerli | |--------------|-----------|------------|------|---------| | ICE Ajanı L | L_PUB_1 | R_PUB_1 | L1 | | | ICE Ajanı R | R_PUB_1 | L_PUB_1 | R1 | |
Mesajlar 7–8: Ajan L, L1 çifti için bir bağlantı denetimi başlatır. Denetim başarılı olur ve (L1) çifti ajan L'nin geçerli listesine eklenir. Ajan L artık isterse (L1) çifti üzerinden veri gönderip alabilir.
Eşler
| VARLIK | Yerel | Uzak | Eş # | Geçerli | |--------------|-----------|------------|------|---------| | ICE Ajanı L | L_PUB_1 | R_PUB_1 | L1 | X | | ICE Ajanı R | R_PUB_1 | L_PUB_1 | R1 | |
Mesajlar 9–10: Ajan R, ajan L'den gelen Binding isteğini (mesaj 7) aldığında, tetiklenmiş bir bağlantı denetimi başlatır. Bu eş, ajan R'nin mevcut (R1) çifti ile eşleşir. Denetim başarılı olur ve (R1) çifti ajan R'nin geçerli listesine eklenir. Ajan R artık isterse (R1) çifti üzerinden veri gönderip alabilir.
Eşler
| VARLIK | Yerel | Uzak | Eş # | Geçerli | |--------------|-----------|------------|------|---------| | ICE Ajanı L | L_PUB_1 | R_PUB_1 | L1 | X | | ICE Ajanı R | R_PUB_1 | L_PUB_1 | R1 | X |
Mesajlar 11–12: Bir noktada, denetleyici ajan (ajan L) geçerli listedeki bir çifti (L1) aday göstermeye karar verir. (L1) çifti üzerinde bir bağlantı denetimi gerçekleştirir ve Binding isteğine USE-CANDIDATE özniteliğini ekler. Denetim başarılı olduğundan, ajan L (L1) çiftinin aday gösterildi bayrak değerini true olarak ayarlar ve ajan R, eşleşen (R1) çiftinin aday gösterildi bayrak değerini true olarak ayarlar.
Akışla ilişkili başka bileşen kalmadığından, aday gösterilen çiftler seçilen çiftler haline gelir. Sonuç olarak, bu akış için işleme Completed durumuna geçer. ICE süreci de Completed durumuna geçer.
#16. STUN Uzantıları
16.1. Öznitelikler
Bu belirtim dört STUN özniteliği tanımlar: PRIORITY, USE-CANDIDATE, ICE-CONTROLLED ve ICE-CONTROLLING.
PRIORITY özniteliği, bu denetimle keşfedilecekse bir eş-yansıtmalı adaya iliştirilecek önceliği belirtir. 32 bitlik işaretsiz bir tam sayıdır ve öznitelik değeri 0x0024'tür.
USE-CANDIDATE özniteliği, bu denetim sonucunda oluşan aday çiftinin veri iletimi için kullanılacağını belirtir. Özniteliğin içeriği yoktur (özniteliğin Length alanı sıfırdır); bir bayrak görevi görür. Öznitelik değeri 0x0025'tir.
ICE-CONTROLLED özniteliği bir Binding isteğinde bulunur. Bu öznitelik, istemcinin şu anda denetlenen rolde olduğuna inandığını belirtir. Özniteliğin içeriği, ağ bayt sırasına göre 64 bitlik işaretsiz bir tam sayıdır ve rastgele bir sayı içerir. Bu sayı, rol çakışmalarını çözmek için kullanılır ve bu bağlamda "bağlantı kesici değeri" olarak adlandırılır. Bir ICE ajanı, bir ICE oturumu içinde, tüm akışlar ve tüm Binding istekleri için aynı sayıyı KULLANMAK ZORUNDADIR; ancak 487 yanıtı almışsa, bu durumda sayıyı DEĞİŞTİRMEK ZORUNDADIR (Bölüm 7.2.5.1). ICE yeniden başlatması gerçekleştiğinde ajan sayıyı DEĞİŞTİREBİLİR.
ICE-CONTROLLING özniteliği bir Binding isteğinde bulunur. Bu öznitelik, istemcinin şu anda denetleyici rolde olduğuna inandığını belirtir. Özniteliğin içeriği, ağ bayt sırasına göre 64 bitlik işaretsiz bir tam sayıdır ve rastgele bir sayı içerir. ICE-CONTROLLED özniteliğinde olduğu gibi, bu sayı rol çakışmalarını çözmek için kullanılır. Bir ajan, bir ICE oturumu içinde, tüm akışlar ve tüm Binding istekleri için aynı sayıyı KULLANMAK ZORUNDADIR; ancak 487 yanıtı almışsa, bu durumda sayıyı DEĞİŞTİRMEK ZORUNDADIR (Bölüm 7.2.5.1). ICE yeniden başlatması gerçekleştiğinde ajan sayıyı DEĞİŞTİREBİLİR.
16.2. Yeni Hata-Yanıt Kodları
Bu belirtim tek bir hata-yanıt kodu tanımlar:
487 (Rol Çakışması): Binding isteği, sunucu ile çakışan bir ICE rolünü belirten ICE-CONTROLLING veya ICE-CONTROLLED özniteliğini içermektedir. Uzak sunucu, istemci ve sunucunun bağlantı kesici değerlerini karşılaştırmış ve istemcinin rol değiştirmesi gerektiğini belirlemiştir.
#17. Operasyonel Hususlar
Bu bölüm, ICE'nin uç noktalar tarafından kullanılacağı ağları işleten operatörler için ilgili konuları ele alır.
17.1. NAT ve Güvenlik Duvarı Türleri
ICE, mevcut NAT ve güvenlik duvarı ekipmanlarıyla çalışacak şekilde tasarlanmıştır. Sonuç olarak, ICE'nin dağıtımını kolaylaştırmak için mevcut güvenlik duvarı ve NAT ekipmanlarını değiştirmek veya yeniden yapılandırmak gerekli değildir. Nitekim ICE, VoIP operatörünün güvenlik duvarları ve NAT'lar dahil IP ağ altyapısı üzerinde hiçbir denetime sahip olmadığı ortamlarda dağıtılmak üzere geliştirilmiştir.
Bununla birlikte, ICE, RFC 4787 ve RFC 5382'de tanımlanan önerileri karşılayan, davranışa uygun NAT aygıtlarının bulunduğu ortamlarda en iyi şekilde çalışır. Davranışa uygun NAT'lara sahip ağlarda, ICE bir TURN sunucusuna ihtiyaç duymadan çalışır; bu da ses kalitesini artırır, çağrı kurulum sürelerini kısaltır ve ağ operatörü üzerindeki bant genişliği taleplerini azaltır.
17.2. Bant Genişliği Gereksinimleri
ICE'nin dağıtımı, operatörlerin dikkate alması gereken mevcut ağ kapasitesiyle çeşitli etkileşimlere sahip olabilir.
17.2.1. STUN ve TURN Sunucu-Kapasite Planlaması
Her şeyden önce, ICE genellikle veri merkezlerinde konumlandırılan TURN ve STUN sunucularını kullanır. STUN sunucuları nispeten az bant genişliği gerektirir. Her veri akışının her bileşeni için, her istemciden STUN sunucusuna bir veya daha fazla STUN işlemi olacaktır. Temel bir yalnızca sesli IPv4 VoIP dağıtımında, çağrı başına dört işlem olacaktır (RTP için bir, RTCP için bir; hem arayan hem de aranan için). Her işlem tek bir istek ve tek bir yanıttan oluşur; ilki 20 bayt, ikincisi 28 bayttır.
Sonuç olarak, bir sistemde N kullanıcı varsa ve her biri yoğun bir saatte dört çağrı yapıyorsa, bu N × 1,7 bps gerektirir. Bir milyon kullanıcı için bu 1,7 Mbps'tir; bu da (nispeten) çok küçük bir sayıdır.
TURN trafiği daha büyüktür. TURN sunucusu, STUN hacmine eşit bir trafik hacmi görecektir (hatta TURN sunucuları dağıtılmışsa, ayrı bir STUN sunucusuna gerek yoktur); buna ek olarak gerçek veriye ait trafiği de taşır. Veri aktarımı için TURN gerektiren çağrıların miktarı ağ topolojilerine son derece bağlıdır ve zaman içinde değişebilir. %100 davranışa uygun NAT'lara sahip bir ağda bu değer tam olarak sıfırdır.
Yukarıdaki planlama hususları, multimedya senaryolarında (ör. ses ve video konferansları) ve bir oturumdaki katılımcı sayıları arttığında daha da önemli hale gelir.
17.2.2. Toplama ve Bağlantı Denetimleri
Adayların toplanması ve bağlantı denetimlerinin gerçekleştirilmesi süreci bant genişliği açısından yoğun olabilir. ICE, bu süreçlerin her ikisini de hız sınırlamalı olarak yürütmek üzere tasarlanmıştır. Toplama ve bağlantı denetimi aşamalarının, ICE süreci tamamlandıktan sonra veri trafiğinin tüketeceği bant genişliğine yaklaşık olarak eşdeğer trafik üretmesi amaçlanmıştır. Bu, bir ağ belirli bir tür iletişim trafiğini (ses, video veya yalnızca metin) destekleyecek şekilde tasarlanmışsa, bu veriler için ICE denetimlerini de destekleyecek yeterli kapasiteye sahip olmasını sağlamak için yapılmıştır. ICE tamamlandıktan sonra, müteakip ICE canlı tutma iletileri toplam bant genişliği kullanımında marjinal bir artışa neden olacaktır; ancak bu genellikle son derece küçük bir artıştır.
Toplama ve denetim aşamalarından kaynaklanan tıkanıklık, hız sınırlaması kullanılmayan dağıtımlarda bir sorun olarak ortaya çıkmıştır. Tipik olarak, uç noktalar denetimleri gönderebildikleri kadar hızlı bir şekilde göndererek ağı doldurduğunda erişim bağlantıları tıkanmıştır. Bu nedenle, ağ operatörlerinin ICE uygulamalarının hız sınırlama özelliğini desteklediğinden emin olmaları gerekir. Bu hız sınırlaması çağrı kurulum sürelerini artırsa da, ICE'yi ağ dostu hale getirir ve dağıtımını kolaylaştırır.
17.2.3. Canlı Tutma İletileri
STUN canlı tutma iletileri (STUN Binding Indication biçiminde) bir veri oturumunun ortasında gönderilir. Ancak bunlar yalnızca gerçek veri trafiğinin olmadığı durumlarda gönderilir. Sürekli medyanın olduğu ve Ses Etkinliği Algılama (VAD) kullanılmayan dağıtımlarda veya VAD'nin kısa aralıklı (en fazla 1 saniye) konfor gürültüsü ile birlikte kullanıldığı dağıtımlarda, canlı tutmalar hiç kullanılmaz ve bant genişliği kullanımında artış olmaz. VAD'nin konfor gürültüsü olmadan kullanıldığı durumlarda, sessizlik dönemlerinde canlı tutmalar gönderilir. Bu, 15–20 saniyede bir tek paket içerir; bu da ses olduğunda gönderilen her 20–30 ms'de bir paketle karşılaştırıldığında çok daha azdır. Dolayısıyla, canlı tutmalar kapasite planlaması üzerinde gerçek bir etkiye sahip değildir.
17.3. ICE ve ICE-Lite
ICE ve ICE-lite karışımını kullanan dağıtımlar birbiriyle birlikte çalışabilir. Bu amaçla açıkça tasarlanmışlardır.
Bununla birlikte, ICE-lite yalnızca sınırlı kullanım durumlarında dağıtılabilir. Bu durumlar ve bunlarla ilgili uyarılar Ek A'da belgelenmiştir.
17.4. Sorun Giderme ve Performans Yönetimi
ICE, uçtan uca bağlantı denetimlerini kullanır ve işlemenin büyük bir kısmını uç noktalara yerleştirir. Bu durum ağ operatörü için bir zorluk ortaya çıkarır—ICE dağıtımlarında nasıl sorun giderilir? ICE'nin nasıl performans gösterdiği nasıl anlaşılır?
ICE, bu sorunlarla başa çıkmaya yardımcı olan yerleşik özelliklere sahiptir. Genellikle ağ operatörünün veri merkezlerinde konuşlandırılan sinyalleşme sunucuları, ICE parametrelerini ileten aday değişimlerinin içeriklerini görecektir. Bu parametreler, her bir adayın türünü (host, server reflexive veya relayed) ve bunlara ilişkin adresleri içerir. ICE işleme tamamlandığında, seçilen adresi (ve onun türünü) bildiren güncellenmiş bir aday değişimi gerçekleşir. Bu güncellenmiş sinyalleşme, ICE işlemenin sonuçları hakkında ağ ekipmanlarını (örneğin, bir sinyalleşmeye bağlı tanılama aracı) bilgilendirmek amacıyla tam olarak gerçekleştirilir.
Bunun bir sonucu olarak, bir sinyalleşme sunucusu tarafından üretilen günlükler aracılığıyla bir ağ operatörü, her çağrı için hangi tür adayların kullanıldığını ve ICE tarafından hangi adreslerin seçildiğini gözlemleyebilir. Bu, ICE’in nasıl performans gösterdiğini değerlendirmeye yardımcı olan temel bilgidir.
17.5. Uç Nokta Yapılandırması
ICE, uç noktalara yapılandırılmış birkaç veri parçasına dayanır. Bu yapılandırma verileri; zamanlayıcıları, TURN sunucuları için kimlik bilgilerini ve STUN ile TURN sunucuları için ana bilgisayar adlarını içerir. ICE’in kendisi bu yapılandırma için bir mekanizma sağlamaz. Bunun yerine, bu bilgilerin uç noktadaki diğer tüm parametreleri yapılandırmak için kullanılan mekanizmaya ekli olduğu varsayılır. SIP telefonları için, RFC 6080 yapılandırma çerçevesi gibi standart çözümler tanımlanmıştır.
#18. IAB Değerlendirmeleri
IAB, "Tek Taraflı Kendi Kendine Adres Düzeltme" (Unilateral Self-Address Fixing - UNSAF) sorununu incelemiştir. Bu, bir ICE aracısının, işbirliğine dayalı bir protokol yansıtma mekanizması (RFC 3424) aracılığıyla bir NAT’ın diğer tarafındaki başka bir alanda kendi adresini belirlemeye çalıştığı genel süreçtir. ICE, bu tür bir işlevi yerine getiren bir protokol örneğidir. İlginç bir şekilde, ICE için süreç tek taraflı değil, iki taraflıdır ve bu fark, IAB tarafından gündeme getirilen sorunlar üzerinde önemli bir etkiye sahiptir. Nitekim ICE, bir UNSAF protokolü yerine İki Taraflı Kendi Kendine Adres Düzeltme (Bilateral Self-Address Fixing - B-SAF) protokolü olarak değerlendirilebilir. Bununla birlikte, IAB bu amaçla geliştirilen tüm protokollerin belirli bir değerlendirmeler kümesini belgelemesini zorunlu kılmıştır. Bu bölüm, bu gereksinimleri karşılamaktadır.
18.1. Sorun Tanımı
RFC 3424’e göre, herhangi bir UNSAF önerisinin aşağıdakileri sağlaması gerekir:
UNSAF önerisiyle çözülecek belirli ve sınırlı kapsamlı bir sorunun kesin tanımı. Kısa vadeli bir çözüm, başka sorunları çözmek üzere genelleştirilmemelidir. Bu tür genellemeler, sözde kısa vadeli çözümün uzun süreli bağımlılığına ve kullanımına yol açar — bu da artık onu "kısa vadeli" olarak adlandırmayı doğru olmaktan çıkarır.
ICE tarafından çözülen belirli sorunlar şunlardır:
- İki eşin iletişim için kullanılabilecek aktarım adresleri kümesini belirlemesini sağlayan bir yöntem sunmak.
Başka bir eşle iletişim kurmak isteyen bir aracının, o eş tarafından erişilebilir olan bir adresi belirlemesini sağlayan bir yöntem sunmak.
18.2. Çıkış Stratejisi
RFC 3424’e göre, herhangi bir UNSAF önerisinin aşağıdakileri sağlaması gerekir:
Bir çıkış stratejisinin/geçiş planının açıklaması. Daha iyi kısa vadeli çözümler, uygun teknoloji devreye alındıkça doğal olarak giderek daha az kullanılacak olanlardır.
ICE’in kendisi kolayca devre dışı bırakılarak aşamalı olarak kaldırılmaz. Bununla birlikte, küresel olarak bağlı bir İnternet’te bile, örneğin bir yönlendirici arızasının bağlantıyı geçici olarak bozup bozmadığını tespit etmek için yararlı bir araç olarak hizmet eder. ICE ayrıca NAT ile ilgisi olmayan belirli güvenlik saldırılarını önlemeye de yardımcı olur. Ancak ICE’in yaptığı şey, diğer UNSAF mekanizmalarının aşamalı olarak ortadan kaldırılmasına yardımcı olmaktır. ICE, bu mekanizmalar arasında etkin bir seçim yapar; daha iyi olanları önceliklendirir ve daha kötü olanların önceliğini düşürür.
IPv6’nın kullanıma girmesiyle NAT’ler dağılmaya başladıkça, server-reflexive ve relayed adaylar (UNSAF adreslerinin her iki biçimi) hiç kullanılmaz hale gelir; çünkü yerel host adaylarına yönelik daha yüksek öncelikli bağlantı mevcuttur. Bu nedenle sunucular giderek daha az kullanılır ve kullanım sıfıra düştüğünde sonunda kaldırılabilir.
Gerçekten de ICE, IPv4’ten IPv6’ya geçişe yardımcı olabilir. İki çift yığınlı ana bilgisayar SIP ile iletişim kurduğunda IPv6 mı yoksa IPv4 mü kullanılacağını belirlemek için kullanılabilir (IPv6 kullanılır). Ayrıca hem 6to4 hem de yerel v6 bağlantısına sahip bir ağın, bir eşle iletişim kurarken hangi adresin kullanılacağını belirlemesine olanak tanır.
18.3. ICE Tarafından Getirilen Kırılganlık
RFC 3424’e göre, herhangi bir UNSAF önerisinin aşağıdakileri sağlaması gerekir:
Sistemleri daha "kırılgan" hale getirebilecek belirli sorunların tartışılması. Örneğin, birden fazla ağ katmanındaki verilerin kullanılmasını içeren yaklaşımlar daha fazla bağımlılık oluşturur, hata ayıklama zorluklarını artırır ve geçişi zorlaştırır.
ICE, mevcut UNSAF mekanizmalarındaki kırılganlığı aslında ortadan kaldırır. Özellikle, klasik STUN’un (RFC 3489 [RFC3489]’da tanımlandığı şekilde) birkaç kırılgan noktası vardır. Bunlardan biri, bir ICE aracısının arkasında bulunduğu NAT türünü sınıflandırmaya çalışmasını gerektiren keşif sürecidir. Bu süreç hataya açıktır. ICE ile bu keşif süreci basitçe kullanılmaz. Adresin geçerliliği tek taraflı olarak değerlendirilmek yerine, bir eşe olan bağlantının ölçülmesiyle dinamik olarak belirlenir. Bağlantının belirlenmesi süreci oldukça sağlamdır.
Klasik STUN’daki ve diğer tüm tek taraflı mekanizmalardaki bir diğer kırılganlık noktası, ek bir sunucuya mutlak bağımlılıktır. ICE, tek taraflı adreslerin tahsisi için bir sunucudan yararlanır, ancak mümkünse ajanların doğrudan bağlanmasına izin verir. Bu nedenle, bazı durumlarda bir STUN sunucusunun arızalanması, ICE kullanıldığında bir çağrının ilerlemesine yine de izin verebilir.
Klasik STUN’daki bir başka kırılganlık noktası, STUN sunucusunun genel İnternet üzerinde olduğunu varsaymasıdır. İlginç bir şekilde, ICE ile bu gerekli değildir. Çeşitli adres alanlarında çok sayıda STUN sunucusu bulunabilir. ICE, kullanılabilir bir adres sağlayanı keşfedecektir.
Klasik STUN’daki en sorunlu kırılganlık noktası, tüm ağ topolojilerinde çalışmamasıdır. Her bir ajan ile STUN sunucusu arasında paylaşılan bir NAT bulunan durumlarda, geleneksel STUN çalışmayabilir. ICE ile bu kısıtlama ortadan kaldırılır.
Klasik STUN ayrıca bazı güvenlik değerlendirmelerini de gündeme getirir. Neyse ki, bu güvenlik değerlendirmeleri de ICE tarafından hafifletilir.
Sonuç olarak, ICE klasik STUN’da ortaya çıkan kırılganlığı onarmaya hizmet eder ve sisteme herhangi bir ek kırılganlık getirmez.
Bu iyileştirmelerin bedeli, ICE’in oturum kurma sürelerini artırmasıdır.
18.4. Uzun Vadeli Bir Çözüm için Gereksinimler
RFC 3424’e göre, herhangi bir UNSAF önerisinin aşağıdakileri sağlaması gerekir:
Daha uzun vadeli, sağlam teknik çözümler için gereksinimlerin belirlenmesi; doğru uzun vadeli çözümü bulma sürecine katkıda bulunulması.
RFC 3489’dan elde ettiğimiz sonuçlar değişmeden kalmaktadır. Ancak, ICE’in uzun vadeli çözümün bir parçası olabileceğine inandığımız için gerçekten yardımcı olduğunu düşünüyoruz.
18.5. Mevcut NAPT Kutularıyla İlgili Sorunlar
RFC 3424’e göre, herhangi bir UNSAF önerisinin aşağıdakileri sağlaması gerekir:
Mevcut, dağıtılmış NAPT’lerle ilgili belirtilen pratik sorunların etkisinin ve deneyim raporlarının tartışılması.
Piyasaya, "genel" ALG işlevselliği sağlamaya çalışan çok sayıda NAT kutusu dağıtılmaktadır. Bu genel ALG’ler, bir paket içinde metin veya ikili biçimde IP adreslerini arar ve bir eşleme ile uyuşurlarsa bunları yeniden yazar. Bu, klasik STUN ile çakışır. Ancak STUN’daki güncelleme [RFC5389], bu ikili adresleri genel ALG’lerden gizleyen bir kodlama kullanır.
Mevcut NAPT kutuları, UDP tabanlı eşlemeler için deterministik olmayan ve genellikle kısa sona erme sürelerine sahiptir. Bu, uygulamaların bu eşlemeleri sürdürmek için periyodik keepalive paketleri göndermesini gerektirir. ICE, 15 s’lik bir varsayılan değer kullanır; bu oldukça muhafazakâr bir tahmindir. Zamanla, NAT kutuları [RFC4787]’ye uygun şekilde davranır hale geldikçe, bu asgari keepalive süresi deterministik ve iyi bilinir hale gelecek ve ICE zamanlayıcıları ayarlanabilecektir. Asgari keepalive aralığını keşfetmenin ve kontrol etmenin bir yoluna sahip olmak çok daha iyi olacaktır.
#19. Güvenlik Değerlendirmeleri
19.1. IP Adresi Gizliliği
Adayları yoklama süreci, istemcinin ve eşinin kaynak adreslerini ağ üzerindeki dinleyen herhangi bir saldırgana açığa çıkarır; adayların değişimi süreci ise müzakereyi görebilen herhangi bir saldırgana adresleri ifşa eder. VPN kullanıcılarının yerel arayüzü üzerinden toplanan server-reflexive adresler gibi bazı adresler hassas bilgiler olabilir. Bu potansiyel saldırılar hafifletilemiyorsa, ICE kullanımları müzakere ve/veya yoklama sürecine hangi adreslerin açığa çıkarılacağını kontrol etmeye yönelik mekanizmalar tanımlayabilir. Bireysel uygulamalar, hangi adreslerin açığa çıkarılacağını kontrol etmek için uygulamaya özgü kurallara da sahip olabilir. Örneğin, [WebRTC-IP-HANDLING], WebRTC uygulamaları için ICE aracılığıyla IP adreslerinin açığa çıkarılmasının gizlilik yönleri hakkında ek bilgiler sağlar. Bu tür sorunların ortaya çıkabileceği ICE uygulamalarının, aday üretmek için hangi ağ arayüzlerinin kullanıldığını kontrol etmeye olanak tanıyan programatik veya kullanıcı arayüzü sağlaması ÖNERİLİR.
Eş tarafından sağlanan aday türlerine ve bu adaylara karşı gerçekleştirilen bağlantı testlerinin sonuçlarına dayanarak, eş yerel ağın özelliklerini belirleyebilir; örneğin, eşe farklı zamanlamalar belirgin görünebilir. Bu sınırlar dahilinde, eş yerel ağı yoklayabilir.
Bir ICE sisteminde mümkün olan çeşitli saldırı türleri vardır. Alt bölümler bu saldırıları ve karşı önlemlerini ele alır.
19.2. Bağlantı Kontrollerine Yönelik Saldırılar
Bir saldırgan, STUN bağlantı kontrollerini bozmayı deneyebilir. Nihayetinde, bu saldırıların tümü bir ICE aracısını bağlantı kontrollerinin sonuçları hakkında yanlış bir şey düşündürür. Saldırının türüne bağlı olarak, saldırganın farklı yeteneklere sahip olması gerekir. Bazı durumlarda saldırganın bağlantı kontrollerinin yol üzerinde olması gerekir. Diğer durumlarda ise, STUN bağlantı kontrolleri üretebildiği sürece yol üzerinde olması gerekmez. Bağlantı kontrollerine yönelik saldırılar genellikle ağ varlıkları tarafından gerçekleştirilse de, bir saldırgan bir uç noktayı kontrol edebiliyorsa, bağlantı kontrolü saldırılarını tetikleyebilir. Bir saldırganın neden olmaya çalışabileceği olası yanlış sonuçlar şunlardır:
- Yanlış Geçersiz: Bir saldırgan, bir aday çiftinin geçersiz olduğunu, gerçekte geçerli olduğu halde, bir çift ajanı buna inandırabilir. Bu, bir ajanın farklı bir adayı (örneğin saldırgan tarafından enjekte edilen bir adayı) tercih etmesine yol açmak veya tüm adayları başarısız olmaya zorlayarak bir çağrıyı bozmak için kullanılabilir.
- Yanlış Geçerli: Bir saldırgan, bir aday çiftinin geçerli olduğunu, gerçekte geçerli olmadığı halde, bir çift ajanı buna inandırabilir. Bu, bir ajanın bir oturuma devam etmesine ancak daha sonra herhangi bir veri alamamasına neden olabilir.
- Yanlış Eş-Reflexive Aday: Bir saldırgan, bir ajanın beklenmediği halde yeni bir eş-reflexive aday keşfetmesine neden olabilir. Bu, veri akışlarını bir DoS hedefine veya dinleme ya da diğer amaçlar için saldırgana yönlendirmek üzere kullanılabilir.
Yanlış Aday Üzerinde Yanlış Geçerli: Bir saldırgan, gerçekte o ajana yönlenmeyen bir adresle bir aday bulunduğuna (örneğin yanlış bir eş-reflexive aday veya yanlış bir server-reflexive aday enjekte ederek) bir ajanı zaten ikna etmiştir. Ardından saldırgan, ajanların bu adayın geçerli olduğuna inanmasını zorlayan bir saldırı başlatır.
Bir saldırgan yanlış bir eş-reflexive aday veya yanlış aday üzerinde yanlış geçerli durumu oluşturabiliyorsa, [RFC5389]’da tanımlanan saldırıların herhangi birini başlatabilir.
Yanlış geçersiz sonucunu zorlamak için saldırganın, ajanlardan birinden gelen bağlantı kontrolünün gönderilmesini beklemesi gerekir. Gönderildiğinde, saldırganın kurtarılamaz bir hata yanıtı (örneğin 400) içeren sahte bir yanıt enjekte etmesi veya yanıtı düşürerek ajana hiç ulaşmamasını sağlaması gerekir. Ancak aday gerçekte geçerli olduğundan, özgün istek eş ajana ulaşabilir ve bir başarı yanıtıyla sonuçlanabilir. Saldırganın bu paketi veya onun yanıtını bir DoS saldırısı, Katman 2 ağ kesintisi ya da başka bir teknik yoluyla düşürmesi gerekir. Bunu yapmazsa, başarı yanıtı da gönderene ulaşarak olası bir saldırıya dikkat çekecektir. Saldırganın sahte bir yanıt oluşturma yeteneği, STUN kısa süreli kimlik bilgisi mekanizmasıyla hafifletilir. Bu yanıtın işlenebilmesi için saldırganın parolaya ihtiyacı vardır. Aday değişim sinyalleşmesi güvenliyse, saldırgan parolaya sahip olmayacak ve yanıtı atılacaktır.
Sahte ICMP Sert Hataları (Tip 3, kodlar 2–4) da yanlış geçersiz sonuçlar oluşturmak için kullanılabilir. Bir ICE aracısı bu ICMP hatalarına yanıt uyguluyorsa, saldırgan bağlantı kontrolünü gönderen ajana iletilen bir ICMP mesajı üretebilir. ICMP hata mesajının ajan tarafından doğrulanması, tek savunmasıdır. Tip 3 kod 4 için, bağlantı kontrolü DF=0 ile gönderilmedikçe, dış IP başlığı herhangi bir doğrulama sağlamaz. Ana bilgisayar tarafından üretilen kod 2 veya 3 için ise adresin, uzak ajanın host, reflexive veya relay aday IP adreslerinden herhangi biri olması beklenir. ICMP mesajı, hatayı tetikleyen iletinin IP başlığını ve UDP başlığını içerir. Bu alanların da doğrulanması gerekir. IP hedefi ve UDP hedef portu, ya hedeflenen aday adresi ve portuyla ya da adayın temel adresiyle eşleşmelidir. Kaynak IP adresi ve portu, bağlantı kontrolünü gönderen ajanın aynı temel adresi için herhangi bir aday olabilir. Dolayısıyla, aday değişimine erişimi olan herhangi bir saldırgan gerekli bilgilere sahip olacaktır. Bu nedenle doğrulama zayıf bir savunmadır ve kaynak adresi doğrulaması olmayan bir ağdaki bir düğümden yol dışı saldırganlar için sahte ICMP saldırılarının gönderilmesi de mümkündür.
Yanlış geçerli sonucunu zorlamak benzer şekilde çalışır. Saldırganın her bir ajandan gelen Binding isteğini beklemesi ve sahte bir başarı yanıtı enjekte etmesi gerekir. Yine, STUN kısa süreli kimlik bilgisi mekanizması nedeniyle, saldırganın geçerli bir başarı yanıtı enjekte edebilmesi için parolaya ihtiyacı vardır. Alternatif olarak, saldırgan normalde ağ tarafından düşürülecek veya reddedilecek geçerli bir başarı yanıtını (örneğin bir tünelleme mekanizması kullanarak) ajana yönlendirebilir.
Yanlış eş-reflexive aday sonucunu zorlamak, sahte istekler veya yanıtlar ya da tekrarlar yoluyla yapılabilir. Önce sahte istekler ve yanıtlar durumunu ele alıyoruz. Bu, saldırganın bir ajana, yanlış aday için bir kaynak IP adresi ve portu ile bir Binding isteği göndermesini gerektirir. Buna ek olarak, saldırganın diğer ajandan bir Binding isteği gelmesini beklemesi ve yanlış adayı içeren bir XOR-MAPPED-ADDRESS özniteliğiyle sahte bir yanıt üretmesi gerekir. Burada açıklanan diğer saldırılar gibi, bu saldırı da STUN ileti bütünlüğü mekanizmaları ve güvenli aday değişimleri tarafından hafifletilir.
Paket tekrarlarıyla yanlış eş-geri-yansıtmalı aday sonucunu zorlamak farklıdır. Saldırgan, ajanlardan birinin bir kontrol göndermesini bekler. Bu isteği yakalar ve sahte bir kaynak IP adresiyle diğer ajana doğru tekrar oynatır. Ayrıca, özgün isteğin uzak ajana ulaşmasını engellemesi gerekir; bunu ya paketin düşmesine neden olacak bir DoS saldırısı başlatarak ya da Katman 2 mekanizmalarını kullanarak düşürülmesini zorlayarak yapar. Tekrar oynatılan paket diğer ajanda alınır ve bütünlük denetimi geçtiği için kabul edilir (bütünlük denetimi kaynak IP adresi ve portu kapsayamaz ve kapsamaz). Ardından yanıtlanır. Bu yanıt, yanlış adayla birlikte bir XOR-MAPPED-ADDRESS içerecek ve bu yanlış adaya gönderilecektir. Saldırganın daha sonra bunu alması ve köken ajana doğru iletmesi gerekir.
Diğer ajan daha sonra bu yanlış adaya doğru bir bağlantı denetimi başlatacaktır. Bu doğrulamanın başarılı olması gerekir. Bu da yanlış bir aday üzerinde yanlış bir geçerli sonucunu zorlamayı gerektirir. Bu hedefe ulaşmak için sahte isteklerin veya yanıtların enjekte edilmesi, STUN’un bütünlük mekanizmaları ve aday değişimi kullanılarak engellenir. Dolayısıyla, bu saldırı yalnızca tekrarlar yoluyla başlatılabilir. Bunu yapmak için saldırganın bu yanlış adaya doğru yapılan denetimi yakalaması ve diğer ajana doğru tekrar oynatması gerekir. Ardından yanıtı da yakalayıp geri doğru tekrar oynatması gerekir.
Bu saldırı, saldırgan sahte aday tarafından tanımlanmadıkça başlatılması çok zordur. Bunun nedeni, saldırganın iki farklı ana bilgisayar tarafından gönderilen paketleri yakalayıp tekrar oynatmasını gerektirmesidir. Her iki ajan da farklı ağlardaysa (örneğin, genel İnternet üzerinden), bu saldırının koordine edilmesi zor olabilir; çünkü ağın farklı bölümlerindeki iki farklı uç noktaya karşı aynı anda gerçekleşmesi gerekir.
Saldırganın kendisi sahte aday tarafından tanımlanıyorsa, saldırının koordinasyonu daha kolaydır. Ancak veri yolu güvenli ise (örneğin, Secure Real-time Transport Protocol (SRTP) [RFC3711] kullanılarak), saldırgan veri paketlerini işleyemez; yalnızca onları atabilir ve bu da veri akışını fiilen devre dışı bırakır. Bununla birlikte, bu saldırı ajanın, bağlantı denetiminin hedefe ulaşmasını engellemek için paketleri bozmasını gerektirir. Bu durumda, amaç veri akışını bozmaksa, ICE’e saldırmak yerine aynı mekanizma ile doğrudan veri akışını bozmak çok daha kolaydır.
19.3. Sunucu-Geri-Yansıtmalı Adres Toplamaya Yönelik Saldırılar
ICE uç noktaları, bir STUN sunucusundan sunucu-geri-yansıtmalı adayları toplamak için STUN Binding isteklerinden yararlanır. Bu istekler hiçbir şekilde kimlik doğrulamasına tabi değildir. Sonuç olarak, bir saldırganın istemciye yanlış bir sunucu-geri-yansıtmalı aday sağlamak için kullanabileceği çok sayıda teknik vardır:
- Bir saldırgan DNS’i ele geçirerek DNS sorgularının sahte bir STUN sunucusu adresi döndürmesine neden olabilir. Bu sunucu istemciye sahte sunucu-geri-yansıtmalı adaylar sağlayabilir. Bu saldırı DNS güvenliği ile hafifletilir; ancak bunu ele almak için DNSSEC zorunlu değildir.
- STUN iletilerini gözlemleyebilen bir saldırgan (örneğin, Wi‑Fi gibi paylaşımlı bir ağ segmentindeki bir saldırgan), geçerli olan ve istemci tarafından kabul edilecek sahte bir yanıt enjekte edebilir.
- Bir saldırgan bir STUN sunucusunu ele geçirerek yanlış eşlenmiş adresler içeren yanıtlar göndermesine neden olabilir.
Bu saldırılarla öğrenilen yanlış bir eşlenmiş adres, ICE oturumunun kurulmasında bir sunucu-geri-yansıtmalı aday olarak kullanılacaktır. Bu adayın gerçekten veri için kullanılabilmesi için saldırganın ayrıca bağlantı denetimlerine saldırması ve özellikle yanlış bir aday üzerinde yanlış bir geçerli sonucunu zorlaması gerekir. Bu saldırı, yanlış adres dördüncü bir tarafı (başlatıcı, yanıtlayıcı veya saldırgan olmayan) tanımlıyorsa başlatılması çok zordur; çünkü oturumdaki her ICE ajanı tarafından üretilen denetimlere saldırmayı gerektirir ve adres saldırganın kendisini tanımlıyorsa SRTP tarafından engellenir.
Saldırgan bağlantı denetimlerine saldırmamayı seçerse, yapabileceği en kötü şey sunucu-geri-yansıtmalı adayın kullanılmasını engellemektir. Ancak eş ajan, saldırı altındaki ajan tarafından erişilebilir en az bir adaya sahipse, STUN bağlantı denetimlerinin kendisi veri alışverişi için kullanılabilecek bir eş-geri-yansıtmalı aday sağlayacaktır. Eş-geri-yansıtmalı adaylar genellikle sunucu-geri-yansıtmalı adaylara tercih edilir. Bu nedenle, yalnızca STUN adres toplamaya yönelik bir saldırı normalde bir oturum üzerinde hiçbir etkiye sahip olmayacaktır.
19.4. Aktarımlı Aday Toplamaya Yönelik Saldırılar
Bir saldırgan, istemciyi yanlış bir aktarımlı adaya sahip olduğuna inandırarak aktarımlı adayların toplanmasını bozmayı deneyebilir. TURN sunucusu ile yapılan alışverişler uzun süreli bir kimlik bilgisi kullanılarak kimlik doğrulamasına tabidir. Sonuç olarak, sahte yanıtların veya isteklerin enjekte edilmesi işe yaramaz. Ayrıca, Binding isteklerinin aksine, Allocate istekleri değiştirilmiş kaynak IP adresleri ve portlarla yapılan tekrar saldırılarına açık değildir; çünkü kaynak IP adresi ve port, istemciye aktarımlı adayını sağlamak için kullanılmaz.
Bir saldırgan istemciyi yanlış bir aktarımlı adaya inandırmış olsa bile, bağlantı denetimleri böyle bir adayın yalnızca başarılı olmaları durumunda kullanılmasına neden olur. Dolayısıyla, saldırganın yukarıda belirtildiği gibi yanlış bir aday üzerinde yanlış bir geçerli sonucunu zorlaması gerekir ki bu da koordine edilmesi çok zor bir saldırıdır.
19.5. İçeriden Saldırılar
Saldırganın sahte aday bilgileri veya STUN iletileri eklemeye çalışan bir üçüncü taraf olduğu saldırılara ek olarak, saldırganın ICE alışverişinde kimliği doğrulanmış ve geçerli bir katılımcı olduğu durumlarda da ICE ile mümkün olan saldırılar vardır.
19.5.1. STUN Çoğaltma Saldırısı
STUN çoğaltma saldırısı, saldırganın diğer ajanların ses paketlerini saldırı hedefine yönlendirmesine neden olduğu bir “voice hammer” saldırısına benzer. Ancak, hedefe yönlendirilen paketler ses paketleri yerine STUN bağlantı denetimleridir. Saldırgan, örneğin 50 adet olmak üzere çok sayıda aday gönderir. Yanıtlayan ajan aday bilgilerini alır ve hedefe yönlendirilen, dolayısıyla hiçbir zaman yanıt üretmeyen denetimlerini başlatır. WebRTC durumunda, kullanıcı bu saldırının devam ettiğinin farkında bile olmayabilir; çünkü kullanıcı tarafından alınmış olan kötü niyetli JavaScript kodu tarafından arka planda tetiklenmiş olabilir.
Yanıtlayıcı, her Ta ms’de (örneğin, Ta = 50 ms) yeni bir bağlantı denetimi başlatacaktır. Ancak, aday sayısının fazla olması nedeniyle yeniden iletim zamanlayıcıları büyük bir değere ayarlanır. Sonuç olarak, paketler her Ta milisaniyede bir gönderilir ve ardından giderek artan aralıklarla gönderilmeye devam eder. Böylece STUN, verinin gönderileceğinden daha hızlı bir hızda paket göndermez ve STUN paketleri yalnızca kısa bir süre boyunca varlığını sürdürür; ICE oturum için başarısız olana kadar. Yine de bu bir çoğaltma mekanizmasıdır.
Çoğaltmayı tamamen ortadan kaldırmak imkansızdır; ancak hacim çeşitli sezgisel yöntemlerle azaltılabilir. ICE ajanları, gerçekleştirdikleri toplam bağlantı denetimi sayısını 100 ile sınırlamalıdır (SHOULD). Ayrıca, ajanlar kabul edecekleri aday sayısını sınırlayabilir (MAY).
Bu tür saldırılardan kaçınmak isteyen protokoller sıklıkla başlatıcıyı, bir sonraki iletiyi göndermeden önce bir yanıt beklemeye zorlar. Ancak ICE durumunda bu mümkün değildir. Aşağıdaki iki durumu ayırt etmek mümkün değildir:
- Yanıt alınmamasının nedeni, başlatıcının yanıt vermeyecek masum bir hedefe karşı bir DoS saldırısı başlatmak için kullanılmasıdır.
- Yanıt alınmamasının nedeni, IP adresi ve portun başlatıcı tarafından erişilebilir olmamasıdır.
İkinci durumda, bir sonraki fırsatta başka bir denetim gönderilirken, ilk durumda başka denetimler gönderilmeyecektir.
#20. IANA Hususları
Özgün ICE belirtimi dört STUN özniteliği ve bir yeni STUN hata yanıtı kaydetmiştir. STUN öznitelikleri ve hata yanıtı burada yeniden verilmiştir. Buna ek olarak, bu belirtim yeni bir ICE seçeneği kaydetmektedir.
20.1. STUN Öznitelikleri
IANA dört STUN özniteliğini kaydetmiştir:
0x0024PRIORITY0x0025USE-CANDIDATE0x8029ICE-CONTROLLED0x802AICE-CONTROLLING
20.2. STUN Hata Yanıtları
IANA aşağıdaki STUN hata-yanıt kodunu kaydetmiştir:
- 487 Rol Çakışması: İstemci, sunucunun rolüyle çakışan bir ICE rolü (controlling veya controlled) ileri sürmüştür.
20.3. ICE Seçenekleri
IANA, [RFC6336]’da tanımlanan prosedürleri izleyerek, “Interactive Connectivity Establishment (ICE)” kaydının “ICE Options” alt kaydında aşağıdaki ICE seçeneğini kaydetmiştir.
ICE Seçeneği adı:
ice2
İrtibat:
- İsim: IESG
- E-posta: iesg@ietf.org
Değişiklik Denetleyicisi:
- IESG
Açıklama:
- ICE seçeneği, ICE seçeneğini kullanan ICE ajanının RFC 8445’e göre uygulanmış olduğunu belirtir.
Referans:
- RFC 8445
#21. RFC 5245’ten Yapılan Değişiklikler
Bu güncellenmiş ICE belirtiminin amacı şunlardır:
- RFC 5245’teki prosedürleri netleştirmek.
- RFC 5245’te keşfedilen kusurlar ve RFC 5245’e dayalı ICE uygulamalarını geliştirmiş ve dağıtmış olan topluluktan gelen geri bildirimler nedeniyle teknik değişiklikler yapmak.
- SIP ve SDP prosedürlerini kaldırarak, prosedürleri sinyalleşme protokolünden bağımsız hale getirmek. Belirli bir sinyalleşme protokolüne özgü prosedürler ayrı kullanım belgelerinde tanımlanacaktır. [ICE-SIP-SDP], SIP ve SDP ile ICE kullanımını tanımlar.
Aşağıdaki teknik değişiklikler yapılmıştır:
- Agresif aday seçimi kaldırıldı.
- Aday çifti durumlarının hesaplanması ve bağlantı denetimlerinin zamanlanmasına ilişkin prosedürler değiştirildi.
- Ta ve RTO’nun hesaplanmasına ilişkin prosedürler değiştirildi.
- Aktif kontrol listesi ve Donmuş kontrol listesi tanımları kaldırıldı.
ice2ICE seçeneği eklendi.- IPv6 hususları değiştirildi.
- Keepalive’lar için no-op kullanımı ve ICE olmayan eşlerle keepalive kullanımı kaldırıldı.
#22. Kaynaklar
22.1. Normatif Kaynaklar
- [RFC2119] Bradner, S., "RFC’lerde Gereksinim Düzeylerini Belirtmek için Kullanılan Anahtar Sözcükler", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Mart 1997, https://www.rfc-editor.org/info/rfc2119.
- [RFC4941] Narten, T., Draves, R. ve S. Krishnan, "IPv6’da Durumsuz Adres Otomatik Yapılandırması için Gizlilik Uzantıları", RFC 4941, DOI 10.17487/RFC4941, Eylül 2007, https://www.rfc-editor.org/info/rfc4941.
- [RFC5389] Rosenberg, J., Mahy, R., Matthews, P. ve D. Wing, "NAT için Oturum Geçişi Yardımcı Programları (STUN)", RFC 5389, DOI 10.17487/RFC5389, Ekim 2008, https://www.rfc-editor.org/info/rfc5389.
- [RFC5766] Mahy, R., Matthews, P. ve J. Rosenberg, "NAT Çevresinde Aktarıcılar Kullanarak Geçiş (TURN): NAT için Oturum Geçişi Yardımcı Programlarına (STUN) Aktarıcı Uzantıları", RFC 5766, DOI 10.17487/RFC5766, Nisan 2010, https://www.rfc-editor.org/info/rfc5766.
- [RFC6336] Westerlund, M. ve C. Perkins, "Interactive Connectivity Establishment (ICE) Seçenekleri için IANA Kaydı", RFC 6336, DOI 10.17487/RFC6336, Temmuz 2011, https://www.rfc-editor.org/info/rfc6336.
- [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A. ve T. Chown, "Internet Protocol Sürüm 6 (IPv6) için Varsayılan Adres Seçimi", RFC 6724, DOI 10.17487/RFC6724, Eylül 2012, https://www.rfc-editor.org/info/rfc6724.
- [RFC8174] Leiba, B., "RFC 2119 Anahtar Sözcüklerinde Büyük Harf ve Küçük Harf Belirsizliği", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Mayıs 2017, https://www.rfc-editor.org/info/rfc8174.
22.2. Bilgilendirici Kaynaklar
- [ICE-SIP-SDP] Petit-Huguenin, M., Nandakumar, S. ve A. Keranen, "Interactive Connectivity Establishment (ICE) için Session Description Protocol (SDP) Teklif/Yanıt Prosedürleri", Çalışma Taslağı, draft-ietf-mmusic-ice-sip-sdp-21, Haziran 2018.
- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. ve E. Lear, "Özel İnternetler için Adres Tahsisi", BCP 5, RFC 1918, DOI 10.17487/RFC1918, Şubat 1996, https://www.rfc-editor.org/info/rfc1918.
- [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. ve W. Weiss, "Farklılaştırılmış Hizmetler için Bir Mimari", RFC 2475, DOI 10.17487/RFC2475, Aralık 1998, https://www.rfc-editor.org/info/rfc2475.
- [RFC3102] Borella, M., Lo, J., Grabelsky, D. ve G. Montenegro, "Alana Özgü IP: Çerçeve", RFC 3102, DOI 10.17487/RFC3102, Ekim 2001, https://www.rfc-editor.org/info/rfc3102.
- [RFC3103] Borella, M., Grabelsky, D., Lo, J. ve K. Taniguchi, "Alana Özgü IP: Protokol Belirtimi", RFC 3103, DOI 10.17487/RFC3103, Ekim 2001, https://www.rfc-editor.org/info/rfc3103.
- [RFC3235] Senie, D., "Ağ Adresi Çeviricisi (NAT) Dostu Uygulama Tasarım Yönergeleri", RFC 3235, DOI 10.17487/RFC3235, Ocak 2002, https://www.rfc-editor.org/info/rfc3235.
- [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. ve E. Schooler, "SIP: Oturum Başlatma Protokolü", RFC 3261, DOI 10.17487/RFC3261, Haziran 2002, https://www.rfc-editor.org/info/rfc3261.
- [RFC3264] Rosenberg, J. ve H. Schulzrinne, "Session Description Protocol (SDP) ile Bir Teklif/Yanıt Modeli", RFC 3264, DOI 10.17487/RFC3264, Haziran 2002, https://www.rfc-editor.org/info/rfc3264.
- [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. ve A. Rayhan, "Orta Kutu İletişim Mimarisi ve Çerçevesi", RFC 3303, DOI 10.17487/RFC3303, Ağustos 2002, https://www.rfc-editor.org/info/rfc3303.
- [RFC3424] Daigle, L., Ed. ve IAB, "Ağ Adresi Çevirisi Üzerinden Tek Taraflı Kendi Kendine Adres Düzeltme (UNSAF) için IAB Hususları", RFC 3424, DOI 10.17487/RFC3424, Kasım 2002, https://www.rfc-editor.org/info/rfc3424.
- [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. ve R. Mahy, "STUN - Kullanıcı Datagram Protokolünün (UDP) Ağ Adresi Çeviriciler (NAT’ler) Üzerinden Basit Geçişi", RFC 3489, DOI 10.17487/RFC3489, Mart 2003, https://www.rfc-editor.org/info/rfc3489.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. ve V. Jacobson, "RTP: Gerçek Zamanlı Uygulamalar için Bir Taşıma Protokolü", STD 64, RFC 3550, DOI 10.17487/RFC3550, Temmuz 2003, https://www.rfc-editor.org/info/rfc3550.
- [RFC3605] Huitema, C., "Session Description Protocol (SDP) İçinde Gerçek Zamanlı Denetim Protokolü (RTCP) Özniteliği", RFC 3605, DOI 10.17487/RFC3605, Ekim 2003, https://www.rfc-editor.org/info/rfc3605.
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. ve K. Norrman, "Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, Mart 2004, https://www.rfc-editor.org/info/rfc3711.
- [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H. ve G. Camarillo, "Session Initiation Protocol (SIP) İçinde Üçüncü Taraf Çağrı Denetimi (3pcc) için En İyi Güncel Uygulamalar", BCP 85, RFC 3725, DOI 10.17487/RFC3725, Nisan 2004, https://www.rfc-editor.org/info/rfc3725.
- [RFC3879] Huitema, C. ve B. Carpenter, "Site Yerel Adreslerinin Kullanımdan Kaldırılması", RFC 3879, DOI 10.17487/RFC3879, Eylül 2004, https://www.rfc-editor.org/info/rfc3879.
- [RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P. ve E. Castro, "IPv6 Geçişinin Uygulama Yönleri", RFC 4038, DOI 10.17487/RFC4038, Mart 2005, https://www.rfc-editor.org/info/rfc4038.
- [RFC4091] Camarillo, G. ve J. Rosenberg, "Oturum Tanımlama Protokolü (SDP) Gruplama Çerçevesi için Alternatif Ağ Adresi Türleri (ANAT) Anlambilimi", RFC 4091, DOI 10.17487/RFC4091, Haziran 2005, https://www.rfc-editor.org/info/rfc4091.
- [RFC4092] Camarillo, G. ve J. Rosenberg, "Oturum Başlatma Protokolü (SIP) içinde Oturum Tanımlama Protokolü (SDP) Alternatif Ağ Adresi Türleri (ANAT) Anlambiliminin Kullanımı", RFC 4092, DOI 10.17487/RFC4092, Haziran 2005, https://www.rfc-editor.org/info/rfc4092.
- [RFC4103] Hellstrom, G. ve P. Jones, "Metin Konuşması için RTP Yükü", RFC 4103, DOI 10.17487/RFC4103, Haziran 2005, https://www.rfc-editor.org/info/rfc4103.
- [RFC4291] Hinden, R. ve S. Deering, "IP Sürüm 6 Adresleme Mimarisi", RFC 4291, DOI 10.17487/RFC4291, Şubat 2006, https://www.rfc-editor.org/info/rfc4291.
- [RFC4566] Handley, M., Jacobson, V. ve C. Perkins, "SDP: Oturum Tanımlama Protokolü", RFC 4566, DOI 10.17487/RFC4566, Temmuz 2006, https://www.rfc-editor.org/info/rfc4566.
- [RFC4787] Audet, F., Ed. ve C. Jennings, "Tekil Yayın UDP için Ağ Adresi Çevirisi (NAT) Davranış Gereksinimleri", BCP 127, RFC 4787, DOI 10.17487/RFC4787, Ocak 2007, https://www.rfc-editor.org/info/rfc4787.
- [RFC5245] Rosenberg, J., "Etkileşimli Bağlantı Kurulumu (ICE): Teklif/Cevap Protokolleri için Ağ Adresi Çeviricisi (NAT) Geçişine Yönelik Bir Protokol", RFC 5245, DOI 10.17487/RFC5245, Nisan 2010, https://www.rfc-editor.org/info/rfc5245.
- [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S. ve P. Srisuresh, "TCP için NAT Davranış Gereksinimleri", BCP 142, RFC 5382, DOI 10.17487/RFC5382, Ekim 2008, https://www.rfc-editor.org/info/rfc5382.
- [RFC5761] Perkins, C. ve M. Westerlund, "RTP Veri ve Kontrol Paketlerinin Tek Bir Port Üzerinde Çoklanması", RFC 5761, DOI 10.17487/RFC5761, Nisan 2010, https://www.rfc-editor.org/info/rfc5761.
- [RFC6080] Petrie, D. ve S. Channabasappa, Ed., "Oturum Başlatma Protokolü Kullanıcı Aracısı Profil Dağıtımı için Bir Çerçeve", RFC 6080, DOI 10.17487/RFC6080, Mart 2011, https://www.rfc-editor.org/info/rfc6080.
- [RFC6146] Bagnulo, M., Matthews, P. ve I. van Beijnum, "Durum Tutan NAT64: IPv6 İstemcilerden IPv4 Sunuculara Ağ Adresi ve Protokol Çevirisi", RFC 6146, DOI 10.17487/RFC6146, Nisan 2011, https://www.rfc-editor.org/info/rfc6146.
- [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P. ve I. van Beijnum, "DNS64: IPv6 İstemcilerden IPv4 Sunuculara Ağ Adresi Çevirisi için DNS Uzantıları", RFC 6147, DOI 10.17487/RFC6147, Nisan 2011, https://www.rfc-editor.org/info/rfc6147.
- [RFC6298] Paxson, V., Allman, M., Chu, J. ve M. Sargent, "TCP'nin Yeniden İletim Zamanlayıcısının Hesaplanması", RFC 6298, DOI 10.17487/RFC6298, Haziran 2011, https://www.rfc-editor.org/info/rfc6298.
- [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B. ve A. Roach, "Etkileşimli Bağlantı Kurulumu (ICE) ile TCP Adayları", RFC 6544, DOI 10.17487/RFC6544, Mart 2012, https://www.rfc-editor.org/info/rfc6544.
- [RFC6928] Chu, J., Dukkipati, N., Cheng, Y. ve M. Mathis, "TCP'nin Başlangıç Penceresinin Artırılması", RFC 6928, DOI 10.17487/RFC6928, Nisan 2013, https://www.rfc-editor.org/info/rfc6928.
- [RFC7050] Savolainen, T., Korhonen, J. ve D. Wing, "IPv6 Adres Sentezi için Kullanılan IPv6 Önekinin Keşfi", RFC 7050, DOI 10.17487/RFC7050, Kasım 2013, https://www.rfc-editor.org/info/rfc7050.
- [RFC7721] Cooper, A., Gont, F. ve D. Thaler, "IPv6 Adres Üretim Mekanizmaları için Güvenlik ve Gizlilik Hususları", RFC 7721, DOI 10.17487/RFC7721, Mart 2016, https://www.rfc-editor.org/info/rfc7721.
- [RFC7825] Goldberg, J., Westerlund, M. ve T. Zeng, "Gerçek Zamanlı Akış Protokolü (RTSP) Tarafından Kontrol Edilen Medya için Bir Ağ Adresi Çeviricisi (NAT) Geçiş Mekanizması", RFC 7825, DOI 10.17487/RFC7825, Aralık 2016, https://www.rfc-editor.org/info/rfc7825.
- [RFC8421] Martinsen, P., Reddy, T. ve P. Patil, "Etkileşimli Bağlantı Kurulumu (ICE) Çoklu Ev Sahipli ve IPv4/IPv6 Çift Yığın Kılavuzları", RFC 8421, DOI 10.17487/RFC8421, Temmuz 2018, https://www.rfc-editor.org/info/rfc8421.
- [WebRTC-IP-HANDLING] Uberti, J. ve G. Shieh, "WebRTC IP Adresi İşleme Gereksinimleri", Çalışma Aşamasında, draft-ietf-rtcweb-ip-handling-09, Haziran 2018.
#Ek A. Lite ve Tam Uygulamalar
ICE iki tür uygulamaya izin verir. Tam bir uygulama, bir oturumda denetleyen ve denetlenen rollerini destekler ve ayrıca adres toplama işlemini gerçekleştirebilir. Buna karşılık, lite bir uygulama, STUN denetimlerine yanıt vermek dışında çok az şey yapan ve bir oturumda yalnızca denetlenen rolünü destekleyen minimalist bir uygulamadır.
ICE, her iki uç noktanın da fayda sağlayabilmesi için her ikisinin de ICE desteklemesini gerektirdiğinden, bir ağda ICE'in kademeli olarak devreye alınması daha karmaşıktır. Birçok oturum, tek başına bir NAT arkasında olmayan ve NAT geçişi konusunda endişe duymayacak bir uç nokta içerir. Çok yaygın bir durum, NAT geçişi gerektiren bir uç noktanın (örneğin bir VoIP donanım telefonu veya yazılım telefonu) bu tür cihazlardan birine çağrı yapmasıdır. Telefon tam bir ICE uygulamasını desteklese bile, diğer cihaz bunu desteklemiyorsa ICE hiç kullanılmayacaktır. Lite uygulama, bu cihazlar için düşük maliyetli bir giriş noktası sağlar. Lite uygulamayı desteklediklerinde, tam uygulamalar onlara bağlanabilir ve ICE'in tüm avantajlarını elde edebilir.
Dolayısıyla, lite bir uygulama yalnızca her zaman genel İnternet'e bağlı olacak ve herhangi bir muhabirden paket alabileceği genel bir IP adresine sahip cihazlar için uygundur. Lite bir uygulama NAT arkasına yerleştirildiğinde ICE çalışmaz.
ICE, lite bir uygulamanın tek bir IPv4 ana makine adayına ve birkaç IPv6 adresine sahip olmasına izin verir. Bu durumda, aday çiftleri denetleyen aracı tarafından, bu belirtim tarafından önerilen RFC 6724'teki gibi statik bir algoritma kullanılarak seçilir. Ancak adres seçimi için statik mekanizmalar her zaman hataya açıktır; çünkü gerçek topolojiyi asla yansıtamazlar veya bağlantı için gerçek garantiler sağlayamazlar. Bunlar her zaman sezgiseldir. Sonuç olarak, bir ICE aracısı ICE'i yalnızca IPv4 ve IPv6 adresleri arasında seçim yapmak için uyguluyorsa ve IP adreslerinin hiçbiri NAT arkasında değilse, mümkün olan en sağlam adres seçimi biçimini sağlamak için yine de tam ICE kullanımının ÖNERİLDİĞİ belirtilir.
Lite uygulamanın bu belirtime, tam uygulamaya geçiş için bir basamak sağlamak amacıyla eklendiğini belirtmek önemlidir. Yalnızca tek bir IPv4 adresiyle her zaman genel İnternet'e bağlı olan cihazlar için bile, mümkünse tam bir uygulama tercih edilir. Tam uygulamalar ayrıca NAT geçişiyle ilişkili olmayan ICE güvenlik avantajlarını da elde eder. Son olarak, bugün genel bir adrese sahip olduğunu gören bir cihazın yarın NAT arkasında olacağı bir ağa yerleştirilmesi sık rastlanan bir durumdur. Bir cihazın veya ürünün ömrü boyunca her zaman genel İnternet'te kullanılıp kullanılmayacağını kesin olarak bilmek zordur. Tam uygulama, iletişimin her zaman çalışacağına dair güvence sağlar.
#Ek B. Tasarım Motivasyonları
ICE, kendileri basit olabilen ancak daha ayrıntılı tartışmayı hak eden karmaşık veya açık olmayan düşünce ya da kullanım senaryolarından türeyen bir dizi bağlayıcı davranış içerir. Bu tasarım motivasyonları, uygulama amaçları için anlaşılması gerekli olmadığından burada ele alınmaktadır. Bu ek bağlayıcı değildir.
B.1. STUN İşlemlerinin Aralıklı Gönderimi
Adayları toplamak ve bağlantıyı doğrulamak için kullanılan STUN işlemleri, yaklaşık olarak her Ta milisaniyede bir yeni işlem olacak şekilde aralıklı olarak gönderilir. Her işlem, sırayla, Ta'nın bir fonksiyonu olan bir yeniden iletim zamanlayıcısı RTO'ya sahiptir. Bu işlemler neden aralıklı gönderilir ve neden bu formüller kullanılır?
Bu STUN isteklerinin gönderilmesi, çoğu zaman istemci ile STUN sunucuları arasında NAT cihazlarında bağlamaların oluşmasına yol açar. Deneyimler, birçok NAT cihazının yeni bağlamalar oluşturma hızına ilişkin üst sınırları olduğunu göstermiştir. Bu belirtim üzerinde yapılan çalışmalar sırasında IETF ICE WG içindeki tartışmalar, her 5 ms'de bir gönderimin iyi desteklendiği sonucuna varmıştır. Bu nedenle Ta için alt sınır 5 ms'dir. Ayrıca, bu paketlerin ağ üzerinden iletilmesi bant genişliği kullanır ve ICE aracısı tarafından hız sınırlamasına tabi tutulması gerekir. [RFC5245]'in önceki taslak sürümlerine dayanan kurulumlar, hız kısıtlı erişim bağlantılarını aşırı yükleme ve genel olarak kötü performans gösterme eğilimindeydi; buna ek olarak ağı olumsuz etkiliyordu. Sonuç olarak, bu aralıklı gönderim NAT cihazının aşırı yüklenmemesini ve trafiğin makul bir hızda tutulmasını sağlar.
"Makul" bir hızın tanımı, veri akışı başladığında STUN'un RTP'nin kendisinin kullanacağından daha fazla bant genişliği KULLANMAMASI GEREKTİĞİdir. Ta için kullanılan formül, her Ta saniyede bir STUN paketi gönderilmesi durumunda, tüm veri akışları üzerinden toplandığında RTP paketleriyle aynı miktarda bant genişliği tüketecek şekilde tasarlanmıştır. Elbette STUN yeniden iletimlere sahiptir ve amaç bunları da aralıklı göndermektir. Bu nedenle, RTO, ilk işlemdeki ilk yeniden iletimin, son işlemdeki ilk STUN isteğinin gerçekleştiği anda meydana gelmesi için ayarlanır. Görsel olarak:
First Packets Retransmits
| |
| |
-------+------ -------+------
/ \ / \
/ \ / \
+--+ +--+ +--+ +--+ +--+ +--+
|A1| |B1| |C1| |A2| |B2| |C2|
+--+ +--+ +--+ +--+ +--+ +--+
---+-------+-------+-------+-------+-------+------------ Time
0 Ta 2Ta 3Ta 4Ta 5TaBu şekilde, gönderilecek üç işlem vardır (örneğin aday toplama durumunda, üç ana makine adayı/STUN sunucusu çifti vardır). Bunlar A, B ve C işlemleridir. Yeniden iletim zamanlayıcısı, ilk işlemdeki ilk yeniden iletimin (A2 paketi) 3Ta zamanında gönderilecek şekilde ayarlanmıştır.
İlk yeniden iletimden sonraki yeniden iletimler, STUN yeniden iletimlerinde üstel geri çekilme kullandığından, Ta milisaniyeden daha seyrek aralıklarla gerçekleşir.
5 ms'lik küresel bir asgari aralıklı gönderim aralığı mekanizması genellikle taşıma protokolleri için uygulanabilir değildir; ancak aşağıdaki gerekçelere dayanarak ICE için uygulanabilirdir.
- Taşıma protokolleri için genel olarak uygulanabilir olacak aşağıdaki kurallarla başlayın:
- MaxBytes, başlangıçta ağda beklemede olmasına izin verilen azami bayt sayısı olsun; [RFC6928]'in Bölüm 2'sinde tanımlandığı üzere 14600 OLMALIDIR.
- HTO, işlem zaman aşımı olsun; RTT biliniyorsa 2*RTT, aksi takdirde 500 ms OLMALIDIR. Bu, [RFC5389]'daki STUN iletileri için RTO'ya ve [RFC6298]'de 1 saniye olan TCP başlangıç RTO'suna dayanmaktadır.
- MinPacing, işlemler arasındaki asgari aralıklı gönderim aralığı olsun; bu 5 ms'dir (yukarıya bakınız).
- Aracıların, ICE işlemleri (özellikle bağlantı denetimleri) için RTT'yi tipik olarak bilmediklerini ve bunun HTO'nun neredeyse her zaman 500 ms olacağı anlamına geldiğini gözlemleyin.
- 5 ms'lik bir MinPacing ve 500 ms'lik bir HTO'nun, HTO başına en fazla 100 paket verdiğini; tipik olarak 120 bayttan küçük bir ICE denetimi için bunun ağda en fazla 12000 bayt beklemede olması anlamına geldiğini ve bunun 1. kuralda ifade edilen azami değerden düşük olduğunu gözlemleyin.
- Dolayısıyla, ICE için kural kümesi yalnızca MinPacing kuralına indirgenir; bu da küresel bir Ta değerine sahip olmaya eşdeğerdir.
#B.2. Birden Fazla Temele Sahip Adaylar
Bölüm 5.1.3, aynı taşıma adresine ve temele sahip adayların elenmesinden bahseder. Ancak, aynı taşıma adreslerine sahip olup farklı temellere sahip adaylar gereksiz değildir. Bir ICE aracısı ne zaman aynı IP adresi ve porta sahip, ancak farklı temellere sahip iki aday bulundurabilir? Şekil 11'in topolojisini düşünün:
+----------+
| STUN Srvr|
+----------+
|
|
-----
// \\
| |
| B:net10 |
| |
\\ //
-----
|
|
+----------+
| NAT |
+----------+
|
|
-----
// \\
| A |
|192.168/16 |
| |
\\ //
-----
|
|
|192.168.1.100 -----
+----------+ // \\
| | | | +----------+
| Initiator|---------| C:net10 |-----------| Responder|
| |10.0.1.100| | 10.0.1.101 | |
+----------+ \\ // +----------+
-----Şekil 11: Farklı Temellere Sahip Özdeş Adaylar
Bu durumda, başlatan aracı çoklu ağ bağlantısına sahiptir. C ağı üzerinde, net 10 özel ağı olan bu ağda, 10.0.1.100 IP adresine sahiptir. Yanıtlayan aracı da aynı ağdadır. Başlatan aracı ayrıca 192.168/16 olan A ağına bağlıdır ve 192.168.1.100 IP adresine sahiptir. Bu ağda, başka bir net 10 özel ağı olan ancak C ağına bağlı olmayan B ağına doğru adres çevirisi yapan bir NAT vardır. B ağında bir STUN sunucusu bulunmaktadır.
Başlatan aracı, C ağındaki IP adresi üzerinde bir ana makine adayı (10.0.1.100:2498) ve A ağındaki IP adresi üzerinde bir ana makine adayı (192.168.1.100:3344) elde eder. 192.168.1.100:3344 adresinden yapılandırılmış STUN sunucusuna bir STUN sorgusu gerçekleştirir. Bu sorgu NAT üzerinden geçer ve NAT tesadüfen 10.0.1.100:2498 bağlamasını atar. STUN sunucusu bunu STUN Binding yanıtında yansıtır. Artık başlatan aracı, bir ana makine adayıyla özdeş bir taşıma adresine (10.0.1.100:2498) sahip sunucu-yansıtmalı bir aday elde etmiştir. Ancak sunucu-yansıtmalı adayın temeli 192.168.1.100:3344 iken, ana makine adayının temeli 10.0.1.100:2498'dir.
#B.3. İlişkili Adres ve İlişkili Port Özniteliklerinin Amacı
Aday özniteliği, ICE'in kendisi tarafından hiç kullanılmayan iki değer içerir — ilişkili adres ve ilişkili port. Bunlar neden mevcuttur?
Bunların dahil edilmesi için iki motivasyon vardır. İlki tanısaldır. Farklı aday türleri arasındaki ilişkiyi bilmek çok faydalıdır. Bu öznitelikler dahil edilerek, bir ICE aracısı hangi aktarımlı adayın hangi yansıtmalı adayla ilişkili olduğunu ve bunun da belirli bir ana makine adayıyla bağlantılı olduğunu bilebilir. Bir aday için denetimler başarılı olurken diğerleri için olmazsa, bu durum ağda neler olduğuna dair faydalı tanısal bilgiler sağlar.
İkinci neden, yol-dışı Hizmet Kalitesi (Quality-of-Service, QoS) mekanizmalarıyla ilgilidir. ICE, PacketCable 2.0 gibi ortamlarda kullanıldığında, proxy’ler normal SIP işlemlerini yerine getirmenin yanı sıra SIP mesajlarındaki SDP’yi inceler ve veri trafiği için IP adresi ile portu çıkarır. Daha sonra, politika sunucuları aracılığıyla ağdaki erişim yönlendiricileriyle etkileşime girerek veri akışları için garantili QoS tesis edebilirler. Bu QoS, RTP trafiğinin 5-tuple temelinde sınıflandırılması ve ardından garantili bir hız sağlanması ya da DSCP’nin uygun şekilde işaretlenmesiyle sunulur. Bir ev tipi NAT mevcut olduğunda ve veri için yönlendirilmiş (relayed) bir aday seçildiğinde, bu yönlendirilmiş aday gerçek bir TURN sunucusu üzerindeki bir taşıma adresi olacaktır. Bu adres, QoS işlemi için paketleri sınıflandırmakta kullanılacak erişim yönlendiricisindeki gerçek taşıma adresi hakkında hiçbir bilgi vermez. Bunun yerine, TURN sunucusuna doğru olan sunucu-yansıtmalı (server-reflexive) aday gereklidir. Çeviri bilgisi SDP içinde taşındığında, proxy bu taşıma adresini kullanarak erişim yönlendiricisinden QoS talep edebilir.
#B.4. STUN Kullanıcı Adının Önemi
ICE, STUN ile mesaj bütünlüğünün kısa süreli kimlik bilgisi (short-term credential) işlevi kullanılarak uygulanmasını gerektirir. Gerçek kısa süreli kimlik bilgisi, aday değişimi sırasında kullanıcı adı parçalarının (username fragments) karşılıklı paylaşılmasıyla oluşturulur. Bu mekanizmaya duyulan ihtiyaç yalnızca güvenlikle sınırlı değildir; aslında ICE’in doğru şekilde çalışabilmesi için baştan gereklidir.
ICE ajanları L, R ve Z’yi ele alalım. L ve R, 10.0.0.0/8 kullanan özel kuruluş 1 içindedir. Z ise yine 10.0.0.0/8 kullanan özel kuruluş 2 içindedir. Görüldüğü üzere, R ve Z’nin her ikisi de 10.0.1.1 IP adresine sahiptir. L, adaylarını Z’ye gönderir. Z, L’ye kendi ana makine (host) adaylarıyla yanıt verir. Bu durumda bu adaylar 10.0.1.1:8866 ve 10.0.1.1:8877’dir. Aynı anda R de bir oturum içindedir ve ana makine adayları olarak 10.0.1.1:8866 ve 10.0.1.1:8877 kullanmaktadır. Bu, R’nin de tıpkı Z gibi bu portlar üzerinde STUN mesajlarını kabul etmeye hazır olduğu anlamına gelir. L, 10.0.1.1:8866 adresine bir STUN isteği ve 10.0.1.1:8877 adresine bir tane daha gönderir. Ancak bunlar beklendiği gibi Z’ye gitmez. Bunun yerine R’ye giderler. Eğer R bunlara basitçe yanıt verseydi, L Z’ye bağlantısı olduğunu düşünecek, oysa gerçekte tamamen farklı bir kullanıcı olan R’ye bağlantısı olacaktı.
Bunu düzeltmek için STUN kısa süreli kimlik bilgisi mekanizmaları kullanılır. Kullanıcı adı parçaları yeterince rastgele seçilir; dolayısıyla R’nin Z ile aynı değerleri kullanıyor olması son derece düşük bir olasılıktır. Sonuç olarak R, kimlik bilgileri geçersiz olduğundan STUN isteğini reddedecektir. Özünde, STUN kullanıcı adı parçaları, aday değişiminin bir parçası olarak kurulan belirli bir oturuma bağlı, geçici ana makine tanımlayıcıları biçiminde işlev görür.
IP adreslerinin benzersiz olmamasının talihsiz bir sonucu olarak, yukarıdaki örnekte R bir ICE ajanı bile olmayabilir. Herhangi bir ana makine olabilir ve STUN paketinin yönlendirildiği port, o ana makinedeki herhangi bir geçici (ephemeral) port olabilir. Eğer bu soket üzerinde paketler için dinleme yapan bir uygulama varsa ve kullanılan protokol için bozuk paketleri ele almaya hazır değilse, bu uygulamanın çalışması etkilenebilir. Neyse ki, değiş tokuş edilen portlar geçicidir ve genellikle dinamik veya kayıtlı aralıktan seçilir; bu nedenle bu portun R ana makinesinde bir sunucu çalıştırmak için kullanılıyor olmaması, daha ziyade bir protokolün ajan tarafı olması ihtimali yüksektir. Bu durum, bu aralıktaki port kullanımının geçici doğası nedeniyle tahsis edilmiş bir porta isabet etme olasılığını azaltır. Ancak yine de bir sorun olasılığı mevcuttur ve ağ dağıtımcılarının buna hazırlıklı olması gerekir.
Bunun ICE’e özgü bir sorun olmadığını unutmayın; başıboş paketler, özellikle genel İnternet üzerindekiler olmak üzere, herhangi bir protokol türü için herhangi bir zamanda bir porta ulaşabilir. Dolayısıyla bu gereksinim, İnternet uygulamaları için genel bir tasarım kılavuzunu yeniden ifade etmektedir — herhangi bir portta bilinmeyen paketlere hazırlıklı olun.
#B.5. Aday Çifti Öncelik Formülü
Bir aday çifti için öncelik alışılmadık bir biçime sahiptir. Şöyledir:
çift önceliği = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)Peki neden böyledir? Aday çiftleri bu değere göre sıralandığında, ortaya çıkan sıralama MAX/MIN özelliğine sahiptir. Bu, çiftlerin önce iki önceliğin minimum değerinin azalan sırasına göre sıralandığı anlamına gelir. Minimum öncelik değeri aynı olan çiftler için, maksimum öncelik sıralamada kullanılır. Maksimum ve minimum öncelikler de aynıysa, ifadenin son kısmında bağlayıcı unsur olarak denetleyici ajanın önceliği kullanılır.
2^32 katsayısı, tek bir adayın önceliği her zaman 2^32’den küçük olduğundan kullanılır; bu da çift önceliğinin iki bileşen önceliğin bir “birleştirilmesi” olmasını sağlar. Bu, MAX/MIN sıralamasını meydana getirir. MAX/MIN, belirli bir ICE ajanı için, daha düşük öncelikli bir adayın, tüm daha yüksek öncelikli adaylar denenmeden asla kullanılmamasını garanti eder.
#B.6. Neden Keepalive’lara İhtiyaç Vardır?
Bir aday çifti üzerinde veri akışı başladıktan sonra bile, oturum süresince aradaki NAT’lerdeki bağlamaların (binding) canlı tutulması gerekir. Normalde veri akışı paketlerinin kendisi (örneğin RTP) bu amacı karşılar. Ancak bazı durumlar daha ayrıntılı tartışmayı gerektirir.
Birincisi, SIP gibi bazı RTP kullanımlarında veri akışları “beklemeye alınabilir”. Bu, RFC 3264 [RFC3264]’te tanımlandığı üzere SDP’deki "sendonly" veya "inactive" özniteliklerinin kullanılmasıyla gerçekleştirilir. RFC 3264, bu durumlarda uygulamaların veri iletimini durdurmasını belirtir. Ancak bu, NAT bağlamalarının zaman aşımına uğramasına neden olabilir ve veri beklemeden çıkarılamaz.
İkincisi, metin konuşması için yük biçimi gibi bazı RTP yük biçimleri [RFC4103], paketleri o kadar seyrek gönderebilir ki, aralık NAT bağlama zaman aşımını aşar.
Üçüncüsü, sessizlik bastırma kullanılıyorsa, uzun sessizlik dönemleri veri iletiminin NAT bağlamalarının zaman aşımına uğrayacak kadar uzun süre durmasına yol açabilir.
Bu nedenlerle, veri paketlerinin kendilerine güvenilemez. ICE, STUN Binding Indication’larını kullanan basit, periyodik bir keepalive tanımlar. Bu, bant genişliği gereksinimlerini son derece öngörülebilir kılar ve böylece QoS rezervasyonlarına elverişli hale getirir.
#B.7. Neden Eş-Yansıtmalı (Peer-Reflexive) Adaylar Tercih Edilir?
Bölüm 5.1.2, bir adayın önceliğinin türüne ve yerel tercihlerine göre hesaplanmasına yönelik prosedürleri açıklar. Bu bölüm, eş-yansıtmalı adaylar için tür tercihinin her zaman sunucu-yansıtmalı adaylardan daha yüksek olmasını gerektirir. Bunun nedeni nedir?
Nedeni, Bölüm 19’daki güvenlik değerlendirmeleriyle ilgilidir. Bir saldırganın bir ICE ajanını sahte bir sunucu-yansıtmalı adayı kullanmaya yönlendirmesi, sahte bir eş-yansıtmalı adayı kullandırmasına kıyasla çok daha kolaydır. Sonuç olarak, Binding istekleriyle adres toplama işlemlerine yönelik saldırılar, eş-yansıtmalı adayların tercih edilmesi sayesinde ICE tarafından engellenir.
#B.8. Neden Keepalive’lar İçin Binding Indication Kullanılır?
Veri keepalive’ları Bölüm 11’de açıklanmaktadır. Bu keepalive’lar, her iki uç nokta da ICE destekliyse STUN kullanır. Ancak bir Binding isteği işlemi (yanıt üreten) kullanmak yerine, keepalive’lar bir Indication kullanır. Bunun nedeni nedir?
Birincil neden, ağ QoS mekanizmalarıyla ilgilidir. Veri akışı başladıktan sonra, ağ elemanları veri akışının, sabit aralıklarda periyodik paketler kullanan ve jitter olasılığı bulunan oldukça düzenli bir yapıya sahip olduğunu varsayar. Bir ICE ajanı veri paketleri gönderirken bir Binding isteği alırsa, veri paketlerine ek olarak bir yanıt paketi üretmesi gerekir. Bu, veri paketlerini taşıyan 5-tuple için gerçek bant genişliği gereksinimlerini artırır ve bu paketlerin iletimine jitter ekler. Analizler, bunun veriler için oldukça sıkı paket zamanlayıcıları kullanan bazı Katman 2 erişim ağlarında bir endişe kaynağı olduğunu göstermiştir.
Buna ek olarak, Binding Indication kullanılması bütünlüğün devre dışı bırakılmasına olanak tanır; bu da daha iyi performansla sonuçlanabilir. Bu durum, Genel Anahtarlamalı Telefon Ağı (Public Switched Telephone Network, PSTN) ağ geçitleri ve Oturum Sınır Denetleyicileri (Session Border Controllers, SBCs) gibi büyük ölçekli uç noktalar için faydalıdır.
#B.9. Aday Türü Tercihinin Seçilmesi
Tür ve yerel tercih değerlerinin seçilmesine yönelik bir ölçüt, TURN sunucusu gibi bir veri aracısı, VPN sunucusu gibi bir tünel hizmeti veya NAT kullanımıdır. Bir veri aracısı ile, veri bu adaya gönderildiğinde, alınmadan önce önce veri aracısından geçer.
Veri aracısı içeren bir aday türü yönlendirilmiş (relayed) adaydır. Bir diğer tür ise VPN arayüzünden elde edilen ana makine adayıdır. Veri bir veri aracısı üzerinden geçirildiğinde, iletim ile alım arasındaki gecikme üzerinde olumlu ya da olumsuz bir etkiye sahip olabilir. Alınan ek yönlendirici atlamaları nedeniyle paket kayıplarını artırabilir veya artırmayabilir. Hizmet sağlama maliyetini artırabilir; çünkü veri, bir sağlayıcı tarafından işletilen bir veri aracısına yönlendirilir ve oradan tekrar dışarı çıkar. Bu endişeler önemliyse, yönlendirilmiş adaylar için tür tercihi dikkatle seçilmelidir.
Tercihlerin seçilmesine yönelik bir başka ölçüt IP adresi ailesidir.
ICE hem IPv4 hem de IPv6 ile çalışır. Çift yığınlı ana makinelerin IPv6 üzerinden bağlantıyı tercih etmesine, ancak v6 ağları kopuksa IPv4’e geri dönmesine olanak tanıyan bir geçiş mekanizması sağlar. Uygulamalar, bozuk yollar mevcutsa bağlantı denetimi aşamasında aşırı gecikmelerden kaçınmak için [RFC8421]’deki yönergeleri izlemelidir.
Tercihlerin seçilmesine yönelik bir diğer ölçüt topolojik farkındalıktır. Bu, aracılar kullanan adaylar için faydalıdır. Bu durumlarda, bir ICE ajanı aracılarının kendisine olan topolojik yakınlığına dair önceden yapılandırılmış veya dinamik olarak keşfedilmiş bilgiye sahipse, bunu daha yakın aracılardan elde edilen adaylara daha yüksek yerel tercihler atamak için kullanabilir.
Tercihlerin seçilmesine yönelik bir başka ölçüt güvenlik veya gizlilik olabilir. Bir kullanıcı uzaktan çalışan biriyse ve dolayısıyla hem kurumsal bir ağa hem de yerel bir ev ağına bağlıysa, kullanıcı, kurum içi iletişimde ses trafiğinin kurumsal ağ üzerinde kalmasını sağlamak için VPN veya benzeri bir tünel üzerinden yönlendirilmesini tercih edebilir; ancak kurum dışındaki kullanıcılarla iletişim kurarken yerel ağı kullanabilir. Böyle bir durumda, bir VPN adresi diğer tüm adreslerden daha yüksek bir yerel tercihe sahip olacaktır.
#Ek C. Bağlantı Denetimi Bant Genişliği
Aşağıdaki tablolar, IPv4 ve IPv6 için, farklı Ta değerleri (ms cinsinden verilmiştir) ve farklı ufrag boyutları (bayt cinsinden verilmiştir) kullanılarak bağlantı denetimleri gerçekleştirmek için gereken bant genişliğini göstermektedir.
Sonuçlar, 11 Nisan 2016 tarihinde Justin Uberti (Google) tarafından sağlanmıştır.
IP sürümü: IPv4
Paket uzunluğu (bayt): 108 + ufrag
| ms | 4 | 8 | 12 | 16 | |-----|-------|-------|-------|-------| | 500 | 1.86k | 1.98k | 2.11k | 2.24k | | 200 | 4.64k | 4.96k | 5.28k | 5.6k | | 100 | 9.28k | 9.92k | 10.6k | 11.2k | | 50 | 18.6k | 19.8k | 21.1k | 22.4k | | 20 | 46.4k | 49.6k | 52.8k | 56.0k | | 10 | 92.8k | 99.2k | 105k | 112k | | 5 | 185k | 198k | 211k | 224k | | 2 | 464k | 496k | 528k | 560k | | 1 | 928k | 992k | 1.06M | 1.12M |
IP sürümü: IPv6
Paket uzunluğu (bayt): 128 + ufrag
| ms | 4 | 8 | 12 | 16 | |-----|-------|-------|-------|-------| | 500 | 2.18k | 2.3k | 2.43k | 2.56k | | 200 | 5.44k | 5.76k | 6.08k | 6.4k | | 100 | 10.9k | 11.5k | 12.2k | 12.8k | | 50 | 21.8k | 23.0k | 24.3k | 25.6k | | 20 | 54.4k | 57.6k | 60.8k | 64.0k | | 10 | 108k | 115k | 121k | 128k | | 5 | 217k | 230k | 243k | 256k | | 2 | 544k | 576k | 608k | 640k | | 1 | 1.09M | 1.15M | 1.22M | 1.28M |
Şekil 12: Bağlantı Denetimi Bant Genişliği