Az LDP ( El-di-pi , Eng. Label Distribution Protocol - Label Distribution Protocol ) egy olyan protokoll , amellyel MPLS hálózatban két LER ( Eng. Label Edge Router - Border Label Router ) információt cserél a címkeleképezésről [1] . A két LER-t LDP-társnak nevezik. A LER-ek közötti információcsere kétirányú.
A Label Distribution Protocol (LDP) az LSR -eket ( Label Switching Router ) biztosítja a címkeelőtag-kötési információk lekérésére, terjesztésére és kiadására a hálózaton lévő peer routerek számára. Az LDP lehetővé teszi az LSR-ek számára, hogy felfedezzék a potenciális partnereket, és LDP-munkameneteket hozzanak létre ezekkel a partnerekkel a címkekötési információk cseréje érdekében.
Más szavakkal, az LDP az MPLS szállítási LSP -k ( Label Switch Path ) létrehozására szolgál, amikor nincs szükség forgalomirányításra . LSP-ket hoz létre, amelyek követik a meglévő IP-útválasztási táblát, és különösen alkalmas az LSP-k teljes hálózatának létrehozására a hálózat összes útválasztója között.
Az LDP számos üzemmódban működhet, hogy megfeleljen a különböző követelményeknek; a legáltalánosabb használat azonban a kéretlen mód, amely az útválasztók között teljes alagúthálózatot hoz létre.
Kért módban a bemeneti útválasztó LDP-címkekérést küld a következő ugrású útválasztónak, az IP-útválasztási táblázat alapján. Ezt a kérést minden útválasztó elküldi a hálózaton keresztül. Amint a kérés eléri a kilépési útválasztót, válaszüzenet generálódik. Ez az üzenet nyugtázza az LSP-t, és minden útválasztónak megmondja, hogy az adott LSP-hez milyen címkeleképezést kell használnia.
Kéretlen módban a kilépő útválasztók minden külső hivatkozás címkeleképezését sugározzák az összes szomszédjuknak. Ezek az adások a hálózat minden kapcsolatán keresztül terjednek, amíg el nem érik a bemeneti útválasztókat. Minden lépésnél tájékoztatják az upstream útválasztót az egyes külső kapcsolatokhoz használt címkeleképezésről, és a hálózat elárasztásával LSP-t hoznak létre az összes külső kapcsolat között.
Az LDP fő előnye az RSVP -vel szemben a teljes alagúthálózat egyszerű felállítása kéretlen módban, ezért leggyakrabban ebben a módban használják a 2. és 3. rétegbeli VPN -ekhez szükséges alapvető alagúthálózat beállítására.
A routerek közötti szomszédsági kapcsolatok kialakítása két szakaszban történik:
Az N2 fázis csak akkor kerül végrehajtásra, ha az N1 fázis sikeresen befejeződött.
Az útválasztó az összes LDP-kompatibilis interfészen 15 másodpercenként küldi az üdvözlő üzeneteket a 224.0.0.2 (all-router) címre, a 646-os portra, az UDP szállítási protokollra . A Hello üzenetek olyan LSR-ek között is válthatók, amelyek nincsenek közvetlenül csatlakoztatva. Ebben az esetben az üzenet egy unicast címre kerül elküldésre.
A Hello üzenetek a következő információkat tartalmazzák:
Holddown timer – az az időtartam, amely alatt a szomszédoknak legalább egy Hello üzenetet kell küldeniük. Ha a szomszédok más értéket kínálnak, akkor el kell fogadniuk a minimumot. Mivel az UDP protokoll nem nyújt kézbesítési garanciát, ajánlatos a Hello üzeneteket háromszor rövidebb időtartammal küldeni, mint a Holddown időzítő. Ha a Holddown timer 0, akkor a következő alapértelmezett értékeket fogadjuk el:
A Holddown időzítő 0xFFFF értéke a végtelent jelenti, de miért van így - az RFC néma.
T bit - (Célzott Hello), ha ez a bit 1, az azt jelenti, hogy az üzenet egy adott (unicast) címre kerül elküldésre, ellenkező esetben az üzenet a 224.0.0.2-re.
R bit - (Request Send Targeted Hellos) ha ez a bit 1, akkor ez azt jelenti, hogy a címzettnek válaszolnia kell erre az üzenetre (Hello), különben nem. Ez a bit csak akkor állítható 1-re, ha T-bit=1.
Megjegyzés: A Targeted Hello funkciót az MPLS-en alapuló további funkciók implementálásakor használják.
Szállítási cím – ez a mező nem kötelező a Hello csomagban. Ha jelen van, akkor a benne megadott címet a későbbiekben az eszközök közötti LDP-munkamenet létrehozására használjuk fel. Ha ez a mező hiányzik, akkor a Hello csomag forráscímét kell használni a munkamenet létrehozásához. Az LDP-munkamenet létrehozásához használt címre „szállítási címként” hivatkozunk.
Configuration Sequence Number – A mező tartalmazza a konfigurációs számot. Ha módosítja az LSR beállításait, ez a szám ennek megfelelően változik. A szám megváltoztatása az LDP-munkamenet újbóli létrehozását okozhatja (vagy nem – az RFC itt nem egyértelmű).
A Hello üzenetek eldobhatók, és ennek megfelelően előfordulhat, hogy az N1 szomszédsági fázis nem hajtható végre a következő okok miatt:
Az LDP-munkamenet TCP/IP -n (646-os port) fut.
Az LSR1 és az LSR2 megtanulja egymás szállítási címét, amikor üdvözlőüzeneteket váltanak. Ha az LSR1 szállítási címe nagyobb, mint az LSR2 szállítási címe, akkor az LSR1 lesz az "aktív" szomszéd, az LSR2 pedig a "passzív", ellenkező esetben fordítva. Továbbá az LDP munkamenet a következő forgatókönyv szerint jön létre.
Ha egy szakaszban valami váratlan történik (rossz típusú csomag érkezik, egyáltalán nem érkezik meg a várt üzenet, vagy az Init üzenetben szereplő LDP szekció paraméterei nem egyeznek meg stb.), akkor a munkamenet nem létrejöttnek minősül. A hibát észlelő LSR Leállítás vagy Elutasítás üzenetet küld a szomszédjának.
Init üzenetAz Init üzenet a következő információkat tartalmazza:
Protokoll verzió - protokoll verzió.
KeepAlive Time – a KeepAlive szolgáltatási üzenetek közötti maximális idő. Mindkét fél eltérő értékeket kínálhat - a minimumot kell használni.
A-bit, Label Advertisement Discipline - címke információcsere mód. A címkékkel kapcsolatos információcsere két módozata használható:
D-but, Loop Detection – LSP hurokmegelőző mechanizmus. 0 - letiltva, 1 - engedélyezve.
PVLim, Path Vector Limit – A változó a hurokkerülés mechanizmusára szolgál.
Max PDU Length – Az LDP-üzenetek PDU-kba (Protocol Data Units) vannak csoportosítva, és egyetlen TCP/IP-csomagban küldik el. Max PDU Length – az összefűzött LDP üzenetek maximális lehetséges hosszát jelenti bájtokban. A szomszédok különböző értékeket kínálhatnak, de mindkettőnek a minimumot kell választania. Ne feledje, hogy még egyetlen üzenet is be van csomagolva egy PDU-ba.
Vevő LDP azonosítója - Címketerület azonosító (vagy címketerület azonosító). A mező formátuma a következő: LSR_ID:Label_Space_ID. Az LSR_ID az LSR azonosítója. Ennek az azonosítónak egyedinek kell lennie az MPLS tartományon belül, és egyedinek kell lennie minden egyes LSR számára. A Label_Space_ID a címkekészlet azonosítója. A Label Space Identifier a PDU fejlécében van feltüntetve, ezáltal azonosítja a szomszédot és azt az interfészt, amelyen a szomszéd létrejön. Például két LSR összeköthető két csatornán keresztül, és minden csatornához más Label Space Identifier-t kell kijelölni, amely csak a Label_Space_ID értékében tér el.
Megjegyzés: Az Init üzenet több további, nem kötelező mezőt is tartalmaz, amelyek leírását kihagytuk. Ezeknek a területeknek továbbra sincs értelme az IP hálózatokban.
LDP munkamenet jön létre, ha a következő feltételek teljesülnek:
A PVLim eltérése az RFC szerint nem eredményezheti a munkamenet bezárását, de figyelmeztetést okozhat az LSR-en.
Az LSR-nek minden LDP munkamenethez időzítőt KELL hozzárendelnie. Bármely LDP-üzenet vételekor az LSR 00:00-ra állítja az időzítőt, és újraindítja. Mielőtt az időzítő elérné a "KeepAlive Time" értéket, a szomszédos LSR-nek el KELL küldenie bármilyen LDP-üzenetet. Ha a szomszédnak nincs továbbítandó tájékoztató üzenete, akkor KeepAlive üzenetet kell küldenie.
Megjegyzés: Egy adott megvalósítással az időzítő 00:00-tól „KeepAlive Time”-ig és fordítva is működhet.
Ha az üzenetek nem érkeznek meg a megbeszélt időpontban, akkor a szomszéd megszakadtnak minősül, és a vele való kapcsolatfelvételt újra kell indítani.
Az LDP működéséhez számos paraméter tartozik:
A szomszédok között kétféle információcsere mód használható a címkékre vonatkozóan:
Downstream On Demand módban az LSR-nek címkét kell kérnie, hogy létrehozzon egy LSP-t (egy FEC-hez) a szomszédos LSR-ből, amely az adott FEC következő ugrása. A Downstream kéretlen módban az LSR minden egyes FEC-hez rendel egy címkét az IP-útválasztási táblájában, és továbbítja azt minden szomszédjának. Ha egy szomszédos LSR esetében a forrás LSR a következő ugrás, akkor a címke a kapcsolótáblában van beállítva.
Számos mechanizmus is létezik a címkék elosztásának szabályozására (Címkeelosztás vezérlési mód):
Ha független szabályozást használ a címketerjedés felett, az LSR akkor is hozzárendelheti a FEC címkéit a szomszédjaihoz, ha az LSR-nek nincs kimenő címkéje a következő LSR-ből. Ha rendezett címketerjedési vezérlést használunk, akkor az LSR nem oszt ki címkéket a szomszédai számára, amíg maga az LSR nem kap egy kimeneti címkét egy adott FEC-hez az NH-LSR-től. Ebben a módban az LSR, amelyhez a FEC közvetlenül kapcsolódik, küldi el először a címkét.
Címkemegőrzési mód
A diszkrét címkeperzisztencia mód használatakor a címke eltávolításra kerül, ha az útvonal megsemmisül a FEC-en. Az LSP visszaállításához a címkét a szomszédos NH-LSR-nek újra kell rendelnie. Ha az ingyenes címkementési módot használja, akkor az útvonal megsemmisítésekor a FEC-en a címke nem törlődik, hanem csak inaktívként jelöli meg. És ha az FEC-n lévő útvonalat ugyanazon az NH-LSR-en keresztül állítják vissza, akkor nem kérik a címkét, hanem a régit használják, amelynek állapota aktívra változik.
Megjegyzés: A címkemegőrzési mód, a címketerjedés-vezérlő mechanizmus és a címkemegőrzési mód nem egyeztethető össze az LDP-szomszédok között.
Az LDP protokollnak a következő eseményekre kell válaszolnia:
Az LDP-protokoll üzemmódjainak lehetséges kombinációit, valamint a működési példákat a táblázat tartalmazza. egy.
| Címke információcsere mód | Downstream kéretlen | Downstream kéretlen | Downstream kéretlen | Downstream On Demand | Downstream On Demand |
| Az elosztás szabályozásának mechanizmusa
címkézés |
független vezérlés | Rendezett vezérlés | Rendezett vezérlés | Rendezett vezérlés | független vezérlés |
| Cue hold mód | liberális | liberális | konzervatív | konzervatív | konzervatív |
| új FEC bejegyzés megjelenése | 1) Címkéket küldünk az összes ismert FEC-nek az összes szomszédnak.
2) Az NH-LSR-től címkét várunk. 3) A kapott címkét használjuk a váltáshoz. |
1) Várjuk az NH-LSR címke érkezését.
2) Minden szomszédnak címkét küldünk a FEC-nek. 3) A kapott címkét használjuk a váltáshoz. PS. Az első elküldi a címkét a FEC-hez csatlakoztatott útválasztónak. |
1) Kérelmet küldünk az NH-LSR-nek címkekiosztásra.
2) Várjuk a választ. 3) A kapott címkét használjuk a váltáshoz. | ||
| következő ugrású változás a FEC felvételhez | 1) Keresünk egy címkét a "halasztott" listában.
2) Ha nem található, akkor NH-LSR kérést küldünk a címke kiválasztására, ellenkező esetben a 4. tétel. 3) Várjuk a választ. 4) A kapott címkét használjuk a váltáshoz. |
1) Kérelmet küldünk az NH-LSR-nek címkekiosztásra.
2) Várjuk a választ. 3) A kapott címkét használjuk a váltáshoz. | |||
| Címke kiválasztására vonatkozó kérés fogadása | Kiválasztjuk a címkét anélkül, hogy megvárnánk az NH-LSR válaszát. | A címkét csak az NH-LSR válasza után választjuk ki. | Kiválasztjuk a címkét anélkül, hogy megvárnánk az NH-LSR válaszát. | ||
Amikor egy FEC bejegyzés eltűnik az útválasztási táblákból, minden LSR-nek el KELL vonnia a hozzárendelt FEC kapcsolási címkéket a szomszédjaitól. Ez a címke visszavonása üzenet elküldésével történik.
Az LDP protokoll hurokkerülési mechanizmust tartalmaz. Ennek a mechanizmusnak az a célja, hogy megakadályozza a kérések és útvonalak hurkolását. Ezt a hatást úgy érik el, hogy az összes címkeleképezési és címkeleképezési kérés üzenetbe belefoglalják az LSR-re vonatkozó információkat, amelyeken keresztül ezek a kérések áthaladtak. Ha az LSR-ek Rendezett vezérlés módban működnek, ez a hatás könnyen elérhető. Ha az LSR-ek független vezérlést használnak, akkor az LSR-eknek újra el kell küldeniük a kéréseket és a válaszokat nekik, mivel azokról az LSR-ekről szóló információk frissülnek, amelyeken a kérések átmentek.
A hurokkerülő mechanizmus nem használható, mivel elméletileg a hurkok hiányát az IP-útválasztó protokollnak kell garantálnia, amely információt az LDP használ.
A hurkok csak akkor fordulhatnak elő rövid ideig, ha az IP-útválasztó protokoll lassan konvergál, és az LDP gyorsabb, mint az IP-útválasztó protokoll.
A táblázat az LDP-üzenetek típusait mutatja:
| Üzenet | Leírás |
|---|---|
| értesítés | Az LSR fontos eseményértesítést küld a szomszédnak. Az értesítés végzetes hibát jelez, vagy tanácsadó információkat ad, például egy LDP-üzenet feldolgozásának eredményét vagy egy LDP-munkamenet állapotát. |
| Szia | Az üzenet a szomszédok azonosítására szolgál, létrehozva a szomszéd kapcsolat N1 fázisát. |
| inicializálás | Az üzenet szomszédsági kapcsolatok létrehozására (N2 fázis), LDP-munkamenet-paraméterek cseréjére és egyeztetésére szolgál. |
| Életben tartani | Az üzenet az LDP-munkamenet aktív maradására szolgál. |
| Cím | Az üzenet a szomszédok értesítésére szolgál az LSR-hez közvetlenül kapcsolódó új IP-hálózatokról. |
| Cím visszavonása | Az üzenet arra szolgál, hogy értesítse a szomszédokat az eltűnésről, amely közvetlenül kapcsolódik az LSR, IP hálózatokhoz. |
| címkeleképezés | Az üzenet tartalmazza a FEC leírását és a küldő LSR által hozzárendelt címkét. |
| Címkekérés | Ezzel az üzenettel az LSR arra kéri a szomszédokat, hogy váltsanak címkét egy adott FEC-hez. Az FEC leírását a kérelem tartalmazza. |
| Címke megszakítási kérelem | Megszakítja a korábban címkekérő üzenetben küldött címkekiosztási kérelmet. |
| Címke visszavonása | A hozzárendelt címke visszavonása a szomszédtól. A szomszédnak abba kell hagynia a visszavont címke használatát a váltáshoz. |
| Címke kiadása | A címke átvételének visszaigazolása a Címkeleképezés üzenetben. Elküldve, ha a címkét címkekérés kérte. |
Ez a rész azonosítja azokat a fenyegetéseket, amelyekkel szemben az LDP sebezhető lehet, és megvitatja azokat az eszközöket, amelyekkel ezek a fenyegetések mérsékelhetők.
Az LDP-kommunikáció két típusa lehet hamisító támadás célpontja.
1. UDP-n keresztül végrehajtott cserék megnyitása.A linkréteghez közvetlenül kapcsolódó LSR-ek Basic Hello üzeneteket cserélnek a hivatkozáson keresztül. Az alapvető Hello-üzenetek hamisításának veszélye csökkenthető a következőkkel:
Azok az LSR-ek, amelyek nem kapcsolódnak közvetlenül a kapcsolati réteghez, Bővített Hello üzeneteket használhatnak annak jelzésére, hogy készen állnak az LDP-munkamenet létrehozására. Az LSR csökkentheti a hamisított kiterjesztett üdvözlések veszélyét, ha kiszűri őket, és csak azokat fogadja el, amelyek a hozzáférési lista által engedélyezett forrásokból származnak.
2. Munkamenet kommunikáció TCP-n keresztül.Az LDP meghatározza a TCP MD5 aláírási opció használatát a munkamenet üzenetek hitelességének és integritásának biztosítására.
Az [RFC2385] szerint az MD5-hitelesítést egyesek túlságosan gyengének tartják ehhez az alkalmazáshoz. Arra is rámutat, hogy a TCP hasonló változata erősebb kivonatolási algoritmussal (példaként az SHA-1 -et említi ) telepíthető. Legjobb tudomásunk szerint ilyen TCP-beállítás nincs meghatározva és telepítve. Megjegyezzük azonban, hogy az LDP bármilyen elérhető TCP-üzenet-kivonat-módszert használhat, és ha az MD5-nél erősebbet definiálnak és implementálnak, az LDP frissítése annak használatára viszonylag egyszerű lesz.
Az LDP nem biztosít olyan mechanizmust, amely megvédi a címke terjedésének bizalmasságát. A címketerjesztési protokollok biztonsági követelményei lényegében megegyeznek az útválasztási protokollokéval.
A címkehamisítási támadások elkerülése érdekében gondoskodni kell arról, hogy a címkézett adatcsomagokat megbízható LSR-ek címkézzék, és a csomagokon elhelyezett címkéket megfelelően megtanulják az LSR-ek címkézése.
Az LDP két lehetséges célpontot kínál a szolgáltatásmegtagadási (DoS) támadásokhoz :
1. Jól ismert UDP port az LDP felfedezéséhez.Az LSR-adminisztrátor csökkentheti a DoS-támadások fenyegetését a Basic Hello segítségével, ha gondoskodik arról, hogy az LSR csak közvetlenül csatlakozzon olyan társakhoz, amelyekben meg lehet bízni, hogy nem kezdeményeznek ilyen támadást.
Az adminisztrátor tartományán belüli partnerekkel való interfészek nem jelenthetnek veszélyt, mivel a belső csomópontok a rendszergazda felügyelete alatt állnak. A tartományon kívüli partnerekkel való interfészek potenciális veszélyt jelentenek, a külső társak viszont nem. A rendszergazdák úgy mérsékelhetik ezt a fenyegetést, ha az LSR-t csak olyan külső partnerekhez csatlakoztatják, amelyekben meg lehet bízni, hogy nem kezdeményeznek Basic Hello támadást. Az Extended Hello üzeneteken keresztüli DoS támadások potenciálisan komolyabb veszélyt jelentenek. Ez a fenyegetés csökkenthető a kiterjesztett üdvözlések szűrésével olyan hozzáférési listák segítségével, amelyek olyan címeket határoznak meg, amelyekkel a kiterjesztett felderítés engedélyezett. A szűréshez azonban szükség van az LSR erőforrásra. Olyan környezetben, ahol megbízható MPLS-felhő azonosítható, a felhő szélén található LSR használható a belső LSR-ek védelmére a DoS-támadásokkal szemben kiterjesztett hellók használatával azáltal, hogy kiszűri az MPLS megbízható felhőn kívülről származó kiterjesztett hello-kat, és csak azokat fogadja el. hozzáférési listák által engedélyezett címek. Ez a szűrés védi az LSR-eket a felhőn belül, de erőforrásokat fogyaszt a széleken.
2. Jól ismert TCP-port LDP-munkamenet létrehozásához.Más, TCP-t használó vezérlősík-protokollokhoz hasonlóan az LDP is DoS-támadások, például SYN-támadások célpontja lehet . Az LDP nem többé-kevésbé sebezhető az ilyen támadásokkal szemben, mint a többi, TCP-t használó vezérlősík protokoll.
Az ilyen támadások veszélye némileg csökkenthető a következőkkel:
LDP specifikáció RFC3036
Többprotokollos címkeváltási architektúra RFC3031