LDP ( El-di-pi , Eng. Label Distribution Protocol - Label Distribution Protocol ) on protokolla , jonka avulla kaksi LER :tä ( Eng. Label Edge Router - Border Label Router ) MPLS -verkossa vaihtavat tietoja tarrakartoituksesta [1] . Näitä kahta LER:ää kutsutaan LDP-vertaisiksi. Tiedonvaihto LER:ien välillä on kaksisuuntaista.
Label Distribution Protocol (LDP) tarjoaa LSR :ille ( Label Switching Router ) keinot pyytää, jakaa ja vapauttaa tarran etuliitesidontatietoja verkon vertaisreitittimille. LDP:n avulla LSR:t voivat löytää potentiaaliset vertaiskumppanit ja muodostaa LDP-istuntoja näiden kumppanien kanssa etiketin sitomistietojen vaihtamiseksi.
Toisin sanoen LDP:tä käytetään MPLS-siirto- LSP :iden ( Label Switch Path ) perustamiseen, kun liikenteenohjausta ei tarvita . Se perustaa LSP:t, jotka seuraavat olemassa olevaa IP-reititystaulukkoa ja soveltuvat erityisen hyvin täydellisen LSP-verkon luomiseen kaikkien verkon reitittimien välille.
LDP voi toimia useissa tiloissa eri vaatimusten mukaisesti; Yleisin käyttö on kuitenkin ei-toivottu tila, joka muodostaa täyden tunneliverkon reitittimien välille.
Pyydetyssä tilassa sisääntuloreititin lähettää LDP-etikettipyynnön seuraavan hypyn reitittimelle sen IP-reititystaulukon perusteella. Jokainen reititin lähettää tämän pyynnön verkon yli. Heti kun pyyntö saavuttaa poistumisreitittimen, generoidaan vastausviesti. Tämä viesti kuittaa LSP:n ja kertoo kullekin reitittimelle tarrakartoituksen, jota käytetään kunkin LSP:n linkissä.
Ei-toivotussa tilassa ulosmenoreitittimet lähettävät jokaisen ulkoisen linkin nimikartoitukset kaikille naapureilleen. Nämä lähetykset leviävät verkon jokaisen linkin kautta, kunnes ne saavuttavat tuloreitittimet. Jokaisessa vaiheessa ne ilmoittavat ylävirran reitittimelle kullekin ulkoiselle linkille käytetystä etikettikartoituksesta, ja täyttämällä verkon ne muodostavat LSP:n kaikkien ulkoisten linkkien välille.
LDP:n tärkein etu RSVP :hen verrattuna on koko tunneliverkon perustamisen helppous ei-toivotulla tilassa, minkä vuoksi sitä käytetään useimmiten tässä tilassa kerroksen 2 ja 3 VPN :ille tarvittavan perustunneliverkon perustamiseen.
Naapurisuhteiden luominen reitittimien välille tapahtuu kahdessa vaiheessa:
Vaihe N2 suoritetaan vain, jos vaihe N1 on suoritettu onnistuneesti.
Reititin lähettää tervehdysviestejä kaikissa LDP-yhteensopivissa liitännöissä 15 sekunnin välein osoitteeseen 224.0.0.2 (kaikki reitittimet), portti 646, UDP-siirtoprotokolla . Hello-viestejä voidaan myös vaihtaa LSR:ien välillä, jotka eivät ole suoraan yhteydessä. Tässä tapauksessa viesti lähetetään unicast-osoitteeseen.
Tervehdysviestit sisältävät seuraavat tiedot:
Holddown-ajastin – aika, jonka aikana naapureiden on lähetettävä vähintään yksi Hello-viesti. Jos naapurit tarjoavat erilaisen arvon, heidän on hyväksyttävä vähimmäisarvo. Koska UDP-protokolla ei anna toimitustakuita, on suositeltavaa lähettää Hello-viestejä kolme kertaa lyhyemmällä ajanjaksolla kuin Holddown-ajastin. Jos Holddown-ajastin on 0, seuraavat oletusarvot hyväksytään:
Holddown-ajastimen arvo, joka on yhtä suuri kuin 0xFFFF, tarkoittaa ääretöntä, mutta miksi se on - RFC on hiljainen.
T bit - (Targeted Hello) jos tämä bitti on 1, se tarkoittaa, että viesti lähetetään tiettyyn (yksilähetys) osoitteeseen, muuten viesti lähetetään osoitteeseen 224.0.0.2.
R-bitti - (Request Send Targeted Hellos) jos tämä bitti on 1, tämä tarkoittaa, että vastaanottajan tulee vastata tähän viestiin (Hei), muuten sen ei pitäisi. Tämä bitti voidaan asettaa arvoon 1 vain, jos T-bit=1.
Huomautus: Targeted Hello -ohjelmaa käytetään, kun toteutetaan MPLS-pohjaisia lisätoimintoja.
Kuljetusosoite - tämä kenttä on valinnainen Hello-paketissa. Jos se on olemassa, siinä määritettyä osoitetta käytetään myöhemmin LDP-istunnon muodostamiseen laitteiden välillä. Jos tämä kenttä puuttuu, Hello-paketin lähdeosoitetta on käytettävä istunnon muodostamiseen. LDP-istunnon muodostamiseen käytettyä osoitetta kutsutaan "kuljetusosoitteeksi".
Configuration Sequence Number - Kenttä sisältää konfigurointinumeron. Kun muutat LSR:n asetuksia, tämä numero muuttuu vastaavasti. Numeron muuttaminen voi aiheuttaa LDP-istunnon uudelleenmuodostamisen (tai ei - RFC ei ole selvä tässä).
Tervehdysviestit saatetaan hylätä, ja vastaavasti naapurisuhteiden vaihetta N1 ei voida suorittaa seuraavista syistä:
LDP-istunto toimii TCP/IP :n kautta (portti 646).
LSR1 ja LSR2 oppivat toistensa siirtoosoitteet vaihtaessaan tervehdysviestejä. Jos LSR1:n siirtoosoite on suurempi kuin LSR2:n siirtoosoite, niin LSR1:stä tulee "aktiivinen" naapuri ja LSR2:sta "passiivinen", muuten päinvastoin. Lisäksi LDP-istunto muodostetaan seuraavan skenaarion mukaisesti.
Jos jossain vaiheessa tapahtuu jotain odottamatonta (väärän tyyppinen paketti saapuu, odotettu viesti ei tule perille tai Init-sanoman LDP-istunnon parametrit eivät täsmää jne.), istuntoa ei pidetä muodostuneena. LSR, joka kohtaa virheen, lähettää naapurilleen sammutus- tai hylkäysviestin.
AloitusviestiInit-sanoma sisältää seuraavat tiedot:
Protokollaversio - protokollaversio.
KeepAlive Time - enimmäisaika KeepAlive-palveluviestien välillä. Molemmat osapuolet voivat tarjota erilaisia arvoja - vähimmäisarvoa tulee käyttää.
A-bit, Label Advertisement Discipline - etikettitietojen vaihtotila. Tunnisteita koskevien tietojen vaihtoon on mahdollista käyttää kahta tapaa:
D-but, Loop Detection - LSP-silmukan estomekanismi. 0 - ei käytössä, 1 - käytössä.
PVLim, Path Vector Limit - Muuttujaa käytetään silmukan välttämismekanismiin.
Max PDU Length - LDP-viestit ryhmitellään PDU:ihin (Protocol Data Units) ja lähetetään yhdessä TCP/IP-paketissa. Max PDU Length - tarkoittaa ketjutettujen LDP-viestien suurinta mahdollista pituutta tavuina. Naapurit voivat tarjota erilaisia arvoja, mutta molempien on valittava minimi. Huomaa, että jopa yksi viesti on pakattu PDU:n sisään.
Vastaanottimen LDP Identifier - Label Space Identifier (tai Label Space Identifier). Kentän muoto on seuraava: LSR_ID:Label_Space_ID. LSR_ID on LSR:n tunniste. Tämän tunnuksen on oltava yksilöllinen MPLS-verkkotunnuksessa ja yksilöllinen jokaiselle LSR:lle. Label_Space_ID on tarrajoukon tunniste. Label Space Identifier osoitetaan PDU:n otsikossa, jolloin se tunnistaa naapurin ja rajapinnan, jolle naapuri on perustettu. Esimerkiksi kaksi LSR:tä voidaan yhdistää kahdella kanavalla, ja jokaiselle kanavalle on varattava eri Label Space Identifier, joka eroaa vain Label_Space_ID arvosta.
Huomautus: Init-sanoma sisältää myös useita valinnaisia lisäkenttiä, joiden kuvaus on jätetty pois. Näiltä aloilta ei ole vieläkään mitään järkeä IP-verkoissa.
LDP-istunto perustetaan, kun seuraavat ehdot täyttyvät:
RFC:n mukaan PVLim-epäsopivuus ei saa johtaa istunnon sulkemiseen, mutta se voi aiheuttaa varoituksen LSR:ssä.
LSR:n TÄYTYY määrittää ajastin jokaiseen LDP-istuntoon. Vastaanotettuaan minkä tahansa LDP-viestin LSR asettaa ajastimen 00:00:aan ja käynnistää sen uudelleen. Ennen kuin ajastin saavuttaa "KeepAlive Time" -arvon, naapuri-LSR:n TÄYTYY lähettää mikä tahansa LDP-viesti. Jos naapurilla ei ole edelleenlähetettävää informatiivista viestiä, sen pitäisi lähettää KeepAlive-viesti.
Huomautus: Tietyllä toteutuksella ajastin voi toimia sekä klo 00:00:sta "KeepAlive Time" -tilaan ja päinvastoin.
Jos viestit eivät tule perille sovittuna aikana, naapurin katsotaan katkenneeksi ja yhteys hänen kanssaan on aloitettava uudelleen.
LDP-toiminnalle on useita parametreja:
Naapureiden välillä on mahdollista käyttää kahta tiedonvaihtotapaa tarroista:
Downstream On Demand -tilassa LSR:n on pyydettävä tunniste luodakseen LSP (FEC:lle) naapuri-LSR:stä, joka on kyseisen FEC:n seuraava hyppy. Alavirran ei-toivotussa tilassa LSR määrittää tunnisteen jokaiselle FEC:lle IP-reititystaulukossaan ja lähettää sen kaikille naapureilleen. Jos naapuri-LSR:lle lähde-LSR on seuraava hyppy, nimike asetetaan kytkentätaulukkoon.
Tarrojen jakelun ohjaamiseen on myös useita mekanismeja (Label Distribution Control Mode):
Käytettäessä riippumatonta ohjausta leiman etenemiseen, LSR voi allokoida FEC-leimat naapureilleen, vaikka LSR:llä ei olisi itseään varten seuraavaa LSR:ää. Jos käytetään tilattua etiketin etenemisen ohjausta, LSR ei allokoi tunnisteita naapureilleen, ennen kuin LSR itse vastaanottaa NH-LSR:ltä lähtötunnisteen tietylle FEC:lle. Tässä tilassa LSR, johon FEC on liitetty suoraan, lähettää etiketin ensin.
Tarran säilytystila
Kun käytetään hienovaraista etiketin pysyvyystilaa, tarra poistetaan, kun reitti tuhoutuu FEC:ssä. LSP:n palauttaminen edellyttää, että viereinen NH-LSR varaa etiketin uudelleen. Jos käytetään ilmaista tarran tallennustilaa, niin kun reitti tuhoutuu FEC:ssä, tarraa ei poisteta, vaan se vain merkitään ei-aktiiviseksi. Ja jos FEC:n reitti palautetaan saman NH-LSR:n kautta, etikettiä ei pyydetä, vaan käytetään vanhaa, jonka tila muuttuu aktiiviseksi.
Huomautus: Tarran säilytystilasta, etiketin etenemisen ohjausmekanismista ja etiketin säilytystilasta ei voida neuvotella LDP-naapureiden välillä.
LDP-protokollan on vastattava seuraaviin tapahtumiin:
Mahdolliset LDP-protokollan toimintatilojen yhdistelmät sekä toimintaesimerkit on esitetty taulukossa. yksi.
| Label Information Exchange Mode | Alavirran pyytämättä | Alavirran pyytämättä | Alavirran pyytämättä | Downstream On Demand | Downstream On Demand |
| Jakelun hallintamekanismi
merkitseminen |
riippumaton valvonta | Tilattu ohjaus | Tilattu ohjaus | Tilattu ohjaus | riippumaton valvonta |
| Viivan pitotila | liberaali | liberaali | konservatiivinen | konservatiivinen | konservatiivinen |
| uuden FEC-merkinnän ilmestyminen | 1) Lähetämme tarrat kaikille tunnetuille FEC:ille kaikille naapureille.
2) Odotamme etiketin NH-LSR:ltä. 3) Käytämme vastaanotettua etikettiä vaihtamiseen. |
1) Odotamme NH-LSR:n etiketin saapumista.
2) Lähetämme tarran FEC:lle kaikille naapureille. 3) Käytämme vastaanotettua etikettiä vaihtamiseen. PS. Ensimmäinen lähettää tarran FEC:hen liitettyyn reitittimeen. |
1) Lähetämme NH-LSR:lle pyynnön etiketin jakamisesta.
2) Odotamme vastausta. 3) Käytämme vastaanotettua etikettiä vaihtamiseen. | ||
| seuraavan hypyn muutos FEC-tallennukseen | 1) Etsimme etikettiä "lykättyjen" luettelosta.
2) Jos sitä ei löydy, lähetämme NH-LSR-pyynnön valita tarra, muuten kohta 4. 3) Odotamme vastausta. 4) Käytämme vastaanotettua etikettiä vaihtamiseen. |
1) Lähetämme NH-LSR:lle pyynnön etiketin jakamisesta.
2) Odotamme vastausta. 3) Käytämme vastaanotettua etikettiä vaihtamiseen. | |||
| Vastaanotetaan nimiön valintapyyntö | Valitsemme etiketin odottamatta vastausta NH-LSR:ltämme. | Valitsemme etiketin vasta NH-LSR:n vastauksen jälkeen. | Valitsemme etiketin odottamatta vastausta NH-LSR:ltämme. | ||
Kun FEC-merkintä katoaa reititystaulukoista, kaikkien LSR:iden TÄYTYY peruuttaa naapureistaan osoitetut FEC-kytkentätunnisteet. Tämä tehdään lähettämällä tarran poistoviesti.
LDP-protokolla sisältää silmukan välttämismekanismin. Tämän mekanismin tarkoituksena on estää pyyntöjen ja reittien silmukoiminen. Tämä vaikutus saavutetaan sisällyttämällä kaikkiin Label Mapping- ja Label Mapping Request -sanomiin tiedot LSR:stä, jonka kautta nämä pyynnöt ovat kulkeneet. Jos LSR:t toimivat tilatussa ohjaustilassa, tämä vaikutus saavutetaan helposti. Jos LSR:t käyttävät itsenäistä ohjausta, LSR:iden on lähetettävä pyynnöt ja vastaukset niille uudelleen, koska tiedot LSR:istä, joiden kautta pyynnöt ovat kulkeneet, päivitetään.
Silmukan välttämismekanismia ei saa käyttää, koska teoriassa silmukoiden puuttumisen pitäisi taata IP-reititysprotokollalla, jota LDP käyttää.
Silmukoita voi esiintyä lyhyen aikaa vain, jos IP-reititysprotokolla on hidas konvergoimassa ja LDP on nopeampi kuin IP-reititysprotokolla.
Taulukko näyttää LDP-viestien tyypit:
| Viesti | Kuvaus |
|---|---|
| ilmoitus | LSR lähettää tärkeästä tapahtumasta ilmoituksen naapurille. Ilmoitus signaloi kohtalokkaasta virheestä tai antaa neuvoja, kuten LDP-sanoman käsittelyn tuloksen tai LDP-istunnon tilan. |
| Hei | Viestiä käytetään naapureiden tunnistamiseen, mikä muodostaa naapurisuhteen N1-vaiheen. |
| alustus | Viestiä käytetään naapurisuhteiden muodostamiseen (vaihe N2), LDP-istunnon parametrien vaihtoon ja neuvottelemiseen. |
| Pitää hengissä | Viestiä käytetään pitämään LDP-istunto aktiivisena. |
| osoite | Viestiä käytetään ilmoittamaan naapureille uusista IP-verkoista, jotka on liitetty suoraan LSR:ään. |
| Osoite Nosto | Viestiä käytetään ilmoittamaan naapureille katoamisesta suoraan LSR-IP-verkkoihin liitettynä. |
| etikettikartoitus | Viesti sisältää FEC-kuvauksen ja lähettävän LSR:n määrittämän tunnisteen. |
| Merkintäpyyntö | Tällä viestillä LSR pyytää naapureita vaihtamaan nimeä tietylle FEC:lle. FEC:n kuvaus sisältyy pyyntöön. |
| Label Abort -pyyntö | Peruuttaa aiemmin etikettipyyntöviestissä lähetetyn tarran allokointipyynnön. |
| Tarran poisto | Määritetyn tunnisteen peruuttaminen naapurilta. Naapurin on lopetettava peruutetun tunnisteen käyttö vaihtamiseen. |
| Etiketin julkaisu | Tarran vastaanottoilmoitus Label Mapping -viestissä. Lähetetään, jos tarraa pyydettiin etikettipyynnössä. |
Tässä osiossa tunnistetaan uhat, joille LDP voi olla haavoittuva, ja käsitellään keinoja, joilla näitä uhkia voidaan lieventää.
On olemassa kahden tyyppistä LDP-viestintää, jotka voivat olla huijaushyökkäyksen kohteena.
1. UDP:n kautta suoritettujen vaihtojen avaaminen.Linkkikerrokseen suoraan yhdistetyt LSR:t vaihtavat perus Hello -viestejä linkin kautta. Perus Hello -viestien huijauksen uhkaa voidaan vähentää seuraavilla tavoilla:
LSR:t, joita ei ole yhdistetty suoraan linkkikerrokseen, VOIVAT käyttää Extended Hello -viestejä osoittamaan, että ne ovat valmiita muodostamaan LDP-istunnon. LSR voi vähentää huijattujen laajennettujen tervehdysten uhkaa suodattamalla ne ja hyväksymällä vain ne, jotka tulevat käyttöoikeusluettelon sallimista lähteistä.
2. Istuntoviestintä TCP:n kautta.LDP määrittelee TCP MD5 -allekirjoitusvaihtoehdon käytön istuntoviestien aitouden ja eheyden varmistamiseksi.
[RFC2385] toteaa, että MD5-todennus on nyt joidenkin mielestä liian heikko tälle sovellukselle. Hän huomauttaa myös, että samanlainen TCP-muunnos vahvemmalla hajautusalgoritmilla (hän mainitsee SHA-1 :n esimerkkinä ) voitaisiin ottaa käyttöön. Tietojemme mukaan tällaista TCP-vaihtoehtoa ei ole määritelty eikä otettu käyttöön. Huomaa kuitenkin, että LDP voi käyttää mitä tahansa saatavilla olevaa TCP-sanoman tiivistysmenetelmiä, ja kun MD5:tä vahvempi on määritelty ja otettu käyttöön, LDP:n päivittäminen sen käyttöön on suhteellisen yksinkertaista.
LDP ei tarjoa mekanismia etiketin leviämisen luottamuksellisuuden suojaamiseksi. Tarran etenemisprotokollien turvallisuusvaatimukset ovat olennaisesti samat kuin reititysprotokollien.
Tarrahuijaushyökkäysten välttämiseksi on varmistettava, että luotetut LSR:t merkitsevät nimetyt datapaketit ja että paketeille asetetut tarrat opitaan oikein merkitsemällä LSR:t.
LDP tarjoaa kaksi mahdollista kohdetta palvelunestohyökkäyksille (DoS):
1. Tunnettu UDP-portti LDP-etsintää varten.LSR-järjestelmänvalvoja voi lieventää DoS-hyökkäysten uhkaa Basic Hello -sovelluksella varmistamalla, että LSR on suoraan yhteydessä vain sellaisiin vertaisiin, joihin voidaan luottaa, että ne eivät käynnistä tällaista hyökkäystä.
Liitännät järjestelmänvalvojan verkkotunnuksen sisällä olevien vertaisverkkojen kanssa eivät saa aiheuttaa uhkaa, koska sisäiset solmut ovat järjestelmänvalvojan hallinnassa. Liitännät verkkotunnuksen ulkopuolisten kumppanien kanssa ovat mahdollinen uhka, mutta ulkoiset kumppanit eivät ole. Järjestelmänvalvoja voi lieventää tätä uhkaa yhdistämällä LSR:n vain ulkoisiin vertaisverkkoihin, joihin voidaan luottaa, että ne eivät käynnistä Basic Hello -hyökkäystä. DoS-hyökkäykset Extended Hello -viestien kautta ovat mahdollisesti vakavampi uhka. Tätä uhkaa voidaan lieventää suodattamalla laajennettuja tervehdyksiä käyttämällä käyttöoikeusluetteloita, jotka määrittelevät osoitteet, joilla laajennettu etsintä on sallittu. LSR-resurssia tarvitaan kuitenkin suodatuksen suorittamiseen. Ympäristössä, jossa luotettava MPLS-pilvi voidaan tunnistaa, pilven reunassa olevaa LSR:ää voidaan käyttää suojaamaan sisäisiä LSR-hyökkäyksiä DoS-hyökkäyksiltä käyttämällä laajennettuja helloja suodattamalla pois MPLS-luotetun pilven ulkopuolelta peräisin olevat laajennetut hellot hyväksymällä vain ne, jotka ovat peräisin käyttöoikeusluetteloiden sallimat osoitteet. Tämä suodatus suojaa LSR:itä pilvessä, mutta kuluttaa resursseja reunoilla.
2. Tunnettu TCP-portti LDP-istunnon perustamiseen.Kuten muutkin TCP:tä käyttävät ohjaustason protokollat, LDP voi olla DoS-hyökkäysten, kuten SYN-hyökkäysten , kohteena . LDP ei ole enemmän tai vähemmän alttiina tällaisille hyökkäyksille kuin muut TCP:tä käyttävät ohjaustason protokollat.
Tällaisten hyökkäysten uhkaa voidaan jonkin verran vähentää seuraavilla tavoilla:
LDP-määritys RFC3036
Multiprotocol Label Switching Architecture RFC3031