LDP ( El-di-pi , Eng. Label Distribution Protocol - Label Distribution Protocol ) er en protokol , hvormed to LER'er ( Eng. Label Edge Router - Border Label Router ) i et MPLS -netværk udveksler information om etiketmapping [1] . De to LER'er kaldes LDP-peers. Informationsudveksling mellem LER'er er tovejs.
Label Distribution Protocol (LDP) giver LSR'er ( Label Switching Router ) midlerne til at anmode om, distribuere og frigive etiketpræfiksbindingsoplysninger til peer-routere på et netværk. LDP giver LSR'er mulighed for at opdage potentielle peers og etablere LDP-sessioner med disse peers for at udveksle etiketbindingsoplysninger.
Med andre ord bruges LDP til at etablere MPLS transport LSP'er ( Label Switch Path ), når trafikkontrol ikke er påkrævet . Den etablerer LSP'er, der følger den eksisterende IP-routingtabel og er særligt velegnet til at skabe et komplet netværk af LSP'er mellem alle routere på netværket.
LDP kan fungere i mange tilstande for at passe til forskellige krav; den mest almindelige brug er dog uopfordret tilstand, som etablerer et komplet netværk af tunneler mellem routere.
I anmodet tilstand sender ingress-routeren en LDP-etiketanmodning til den næste hop-router, som bestemt ud fra dens IP-routingtabel. Denne anmodning sendes på tværs af netværket af hver router. Så snart anmodningen når udgangsrouteren, genereres en svarmeddelelse. Denne meddelelse bekræfter LSP'en og fortæller hver router, hvilken etikettilknytning der skal bruges på hvert link for den LSP.
I uopfordret tilstand udsender egress-routere etikettilknytninger for hvert eksternt link til alle deres naboer. Disse udsendelser forplanter sig gennem hvert link i netværket, indtil de når de indgående routere. Ved hvert trin informerer de upstream-routeren om den etiketmapping, der bruges til hvert eksternt link, og ved at oversvømme netværket etablerer de en LSP mellem alle eksterne links.
Den største fordel ved LDP i forhold til RSVP er den nemme opsætning af et komplet tunnelnetværk ved hjælp af uopfordret tilstand, hvorfor det oftest bruges i denne tilstand til at opsætte det grundlæggende tunnelnetværk, der er nødvendigt for Layer 2 og Layer 3 VPN'er .
Etableringen af naborelationer mellem routere udføres i to faser:
Fase N2 udføres kun, hvis fase N1 er gennemført.
Hej-beskeder sendes af routeren på alle LDP-aktiverede grænseflader hvert 15. sekund til adresse 224.0.0.2 (alle-routere), port 646, UDP-transportprotokol . Hej-beskeder kan også udveksles mellem LSR'er, der ikke er direkte forbundet. I dette tilfælde sendes beskeden til en unicast-adresse.
Hej beskeder indeholder følgende oplysninger:
Holddown-timer - det tidsrum, hvor naboerne skal sende mindst én Hej-besked. Hvis naboerne tilbyder en anden værdi, så skal de acceptere minimum. Da UDP-protokollen ikke giver leveringsgarantier, anbefales det at sende Hello-beskeder med en periode, der er tre gange kortere end Holddown-timeren. Hvis Holddown-timeren er 0, accepteres følgende standardværdier:
Værdien af Holddown-timeren lig med 0xFFFF betyder uendelig, men hvorfor er det - RFC er tavs.
T bit - (Targeted Hello) hvis denne bit er 1, betyder det, at beskeden sendes til en specifik (unicast) adresse, ellers sendes beskeden til 224.0.0.2.
R bit - (Request Send Targeted Hellos) hvis denne bit er 1, betyder det, at modtageren skal svare på denne besked (Hej), ellers skal den ikke. Denne bit kan kun indstilles til 1, hvis T-bit=1.
Bemærk: Målrettet Hello bruges ved implementering af yderligere funktionalitet baseret på MPLS.
Transportadresse - dette felt er valgfrit i Hello-pakken. Hvis den er til stede, bruges den adresse, der er angivet i den, senere til at etablere en LDP-session mellem enheder. Hvis dette felt er fraværende, skal kildeadressen til Hello-pakken bruges til at etablere sessionen. Adressen, der bruges til at etablere en LDP-session, vil blive omtalt som "transportadressen".
Konfigurationssekvensnummer - Feltet indeholder konfigurationsnummeret. Når du ændrer indstillingerne på LSR, ændres dette nummer tilsvarende. Ændring af nummeret kan medføre, at LDP-sessionen bliver genetableret (eller måske ikke - RFC er ikke klart her).
Hej-beskeder kan blive kasseret, og i overensstemmelse hermed kan naborelationer fase N1 muligvis ikke udføres af følgende årsager:
LDP-sessionen kører over TCP/IP (port 646).
LSR1 og LSR2 lærer hinandens transportadresser, når de udveksler hej-beskeder. Hvis transportadressen for LSR1 er større end transportadressen for LSR2, bliver LSR1 den "aktive" nabo og LSR2 den "passive", ellers omvendt. Yderligere etableres LDP-sessionen i henhold til følgende scenarie.
Hvis der på et tidspunkt sker noget uventet (den forkerte type pakke ankommer, den forventede meddelelse ankommer slet ikke, eller LDP-sessionsparametrene i Init-meddelelsen stemmer ikke overens osv.), så anses sessionen for at være ikke etableret. En LSR, der støder på en fejl, sender en Shutdown- eller Reject-meddelelse til sin nabo.
Init beskedInit-meddelelsen indeholder følgende information:
Protokolversion - protokolversion.
KeepAlive Time - maksimal tid mellem KeepAlive servicebeskeder. Begge parter kan tilbyde forskellige værdier - minimum skal bruges.
A-bit, Label Advertisement Discipline - etiketinformationsudvekslingstilstand. Det er muligt at bruge to måder til informationsudveksling om tags:
D-but, Loop Detection - LSP-løkkeforebyggelsesmekanisme. 0 - deaktiveret, 1 - aktiveret.
PVLim, Path Vector Limit - Variablen bruges til sløjfeundgåelsesmekanismen.
Maks. PDU-længde - LDP-meddelelser grupperes i PDU'er (Protocol Data Units) og sendes i én TCP/IP-pakke. Max PDU Length - betyder den maksimalt mulige længde af sammenkædede LDP-meddelelser i bytes. Naboer kan tilbyde forskellige værdier, men begge skal vælge minimum. Bemærk, at selv en enkelt besked er pakket inde i en PDU.
Receiver LDP Identifier - Label Space Identifier (eller Label Space Identifier). Feltformatet er som følger: LSR_ID:Label_Space_ID. LSR_ID er identifikatoren for LSR. Denne identifikator skal være unik inden for MPLS-domænet og unik for hver LSR. Label_Space_ID er etiketsættets identifikator. Label Space Identifier er angivet i headeren på PDU'en og identificerer derved naboen og grænsefladen, som naboen er etableret på. For eksempel kan to LSR'er forbindes af to kanaler, og for hver kanal skal der tildeles en anden Label Space Identifier, som kun vil afvige i værdien af Label_Space_ID.
Bemærk: Init-meddelelsen indeholder også flere ekstra, valgfrie felter, hvis beskrivelse er udeladt. Der er stadig ingen mening fra disse felter i IP-netværk.
En LDP-session etableres, når følgende betingelser er opfyldt:
Et PVLim-mismatch bør ifølge RFC ikke resultere i, at en session lukker, men kan forårsage en advarsel på LSR.
LSR SKAL tildele en timer til hver LDP-session. Ved modtagelse af en LDP-meddelelse indstiller LSR timeren til 00:00 og genstarter den. Før timeren når "KeepAlive Time"-værdien, SKAL nabo-LSR sende enhver LDP-meddelelse. Hvis naboen ikke har nogen informative beskeder at videresende, skal den sende en KeepAlive besked.
Bemærk: Med en specifik implementering kan timeren fungere både fra 00:00 til "KeepAlive Time" og omvendt.
Hvis beskeder ikke ankommer til det aftalte tidspunkt, anses naboen for at være afbrudt, og sessionen med ham skal genetableres.
Der er flere parametre for LDP-drift:
Mellem naboer er det muligt at bruge to måder til informationsudveksling om etiketter:
I Downstream On Demand-tilstand skal en LSR anmode om en etiket for at skabe en LSP (for en FEC) fra en nabo-LSR, som er næste hop for den FEC. I Downstream Unsolicited-tilstand tildeler en LSR en etiket til hver FEC i dens IP-routingtabel og udsender den til alle dens naboer. Hvis for en nabo-LSR er kilde-LSR næste-hop, så sættes etiketten i omskiftningstabellen.
Der er også flere mekanismer til at kontrollere distributionen af etiketter (Label Distribution Control Mode):
Når du bruger uafhængig kontrol over etiketudbredelse, kan en LSR tildele etiketter for FEC til sine naboer, selvom LSR ikke har en ud-etiket for sig selv fra den næste LSR. Hvis der anvendes bestilt etiketudbredelseskontrol, vil LSR'en ikke tildele etiketter til sine naboer, før LSR'en selv modtager en output-etiket for en given FEC fra NH-LSR. I denne tilstand sender den LSR, som FEC er direkte knyttet til, etiketten først.
Etiketopbevaringstilstand
Når du bruger den diskrete etiketpersistenstilstand, fjernes etiketten, når ruten ødelægges på FEC. Gendannelse af LSP kræver, at etiketten gentildeles af den tilstødende NH-LSR. Hvis den gratis etiketlagringstilstand bruges, slettes etiketten ikke, når ruten er ødelagt på FEC, men kun markeret som inaktiv. Og hvis ruten på FEC gendannes gennem den samme NH-LSR, anmodes der ikke om etiketten, men den gamle bruges, hvis status ændres til aktiv.
Bemærk: Etikettilbageholdelsestilstanden, etiketudbredelseskontrolmekanismen og etikettilbageholdelsestilstanden kan ikke forhandles mellem LDP-naboer.
LDP-protokollen skal reagere på følgende hændelser:
Mulige kombinationer af driftstilstande for LDP-protokollen, såvel som eksempler på drift, er angivet i tabel. en.
| Etiketinformationsudvekslingstilstand | Downstream uopfordret | Downstream uopfordret | Downstream uopfordret | Downstream On Demand | Downstream On Demand |
| Mekanismen til at kontrollere distributionen
mærkning |
uafhængig kontrol | Bestilt kontrol | Bestilt kontrol | Bestilt kontrol | uafhængig kontrol |
| Cue hold-tilstand | liberal | liberal | konservative | konservative | konservative |
| fremkomsten af en ny FEC-post | 1) Vi sender etiketter til alle kendte FEC'er til alle naboer.
2) Vi forventer et mærke fra NH-LSR. 3) Vi bruger den modtagne etiket til at skifte. |
1) Vi venter på, at etiketten fra NH-LSR kommer.
2) Vi sender en etiket til FEC til alle naboer. 3) Vi bruger den modtagne etiket til at skifte. PS. Den første sender etiketten til routeren, der er knyttet til FEC. |
1) Vi sender en anmodning til NH-LSR om etikettildeling.
2) Vi venter på svar. 3) Vi bruger den modtagne etiket til at skifte. | ||
| næste hop-ændring for FEC-optagelse | 1) Vi leder efter et mærke på listen over "udskudt".
2) Findes den ikke, sender vi en NH-LSR-anmodning om at vælge en etiket, ellers punkt 4. 3) Vi venter på svar. 4) Vi bruger den modtagne etiket til at skifte. |
1) Vi sender en anmodning til NH-LSR om etikettildeling.
2) Vi venter på svar. 3) Vi bruger den modtagne etiket til at skifte. | |||
| Modtager en anmodning om at vælge en etiket | Vi vælger etiketten uden at vente på svar fra vores NH-LSR. | Vi vælger først etiketten efter et svar fra vores NH-LSR. | Vi vælger etiketten uden at vente på svar fra vores NH-LSR. | ||
Når en FEC-indtastning forsvinder fra routingtabellerne, SKAL alle LSR'er tilbagekalde tildelte FEC-switching-etiketter fra deres naboer. Dette gøres ved at sende en Label tilbagetrækning besked.
LDP-protokollen inkorporerer en sløjfeundgåelsesmekanisme. Formålet med denne mekanisme er at forhindre anmodninger og ruter i at sløjfe. Denne effekt opnås ved at inkludere oplysninger i alle Label Mapping- og Label Mapping Request-meddelelser om den LSR, som disse anmodninger er gået igennem. Hvis LSR'er fungerer i Ordered Control-tilstand, opnås denne effekt let. Hvis LSR'er bruger uafhængig kontrol, skal LSR'er sende anmodninger og svar til dem igen, da information om LSR'er, som anmodninger er gået igennem, vil blive opdateret.
Mekanismen for sløjfeundgåelse må ikke bruges, da fraværet af sløjfer i teorien skal garanteres af IP-routingprotokollen, information som LDP bruger.
Loops kan kun forekomme i en kort periode, hvis IP-routingprotokollen er langsom til at konvergere, og LDP er hurtigere end IP-routingprotokollen.
Tabellen viser typerne af LDP-meddelelser:
| Besked | Beskrivelse |
|---|---|
| notifikation | LSR sender en vigtig begivenhedsmeddelelse til naboen. Meddelelsen signalerer en fatal fejl eller giver rådgivende oplysninger såsom resultatet af behandlingen af en LDP-meddelelse eller tilstanden af en LDP-session. |
| Hej | Meddelelsen bruges til at identificere naboer, der etablerer N1-fasen af naboforholdet. |
| initialisering | Meddelelsen bruges til at etablere naborelationer (fase N2), udveksle og forhandle LDP-sessionsparametre. |
| Holde i live | Meddelelsen bruges til at holde LDP-sessionen aktiv. |
| adresse | Meddelelsen bruges til at underrette naboer om nye IP-netværk, der er direkte knyttet til LSR. |
| Adresse trækkes tilbage | Meddelelsen bruges til at underrette naboer om forsvinden direkte knyttet til LSR, IP-netværk. |
| etiketkortlægning | Meddelelsen indeholder FEC-beskrivelsen og etiketten tildelt af den afsendende LSR. |
| Labelanmodning | Med denne meddelelse anmoder LSR naboerne om at skifte etiket for en bestemt FEC. Beskrivelsen af FEC er inkluderet i anmodningen. |
| Label Afbryd anmodning | Annullerer en etikettildelingsanmodning, der tidligere er sendt i en etiketanmodningsmeddelelse. |
| Etiket trækkes tilbage | Tilbagekaldelse af det tildelte mærke fra en nabo. Naboen skal holde op med at bruge det tilbagekaldte mærke til skift. |
| Etiketfrigivelse | Kvittering for modtagelse af etiketten i meddelelsen Label Mapping. Sendes, hvis etiketten blev anmodet om af en etiketanmodning. |
Dette afsnit identificerer de trusler, som LDP kan være sårbare overfor, og diskuterer midlerne, hvormed disse trusler kan afbødes.
Der er to typer LDP-kommunikation, der kan være målet for et spoofingangreb.
1. Åbning af udvekslinger foretaget via UDP.LSR'er, der er direkte forbundet på linklaget, udveksler Basic Hello-meddelelser over linket. Truslen om spoofing af Basic Hello-beskeder kan reduceres ved:
LSR'er, der ikke er direkte forbundet på linklaget, KAN bruge udvidede hej-meddelelser til at indikere, at de er klar til at etablere en LDP-session. En LSR kan reducere truslen om forfalskede udvidede hilsener ved at filtrere dem og kun acceptere dem, der kommer fra kilder, der er tilladt af adgangslisten.
2. Sessionskommunikation via TCP.LDP definerer brugen af TCP MD5 -signeringsmuligheden for at sikre ægtheden og integriteten af sessionsmeddelelser.
[RFC2385] anfører, at MD5-godkendelse nu af nogle anses for at være for svag til denne applikation. Han påpeger også, at en lignende variant af TCP med en stærkere hashing-algoritme (han nævner SHA-1 som et eksempel ) kunne implementeres. Så vidt vi ved, er der ikke defineret og implementeret en sådan TCP-mulighed. Vi bemærker dog, at LDP kan bruge alle tilgængelige TCP-meddelelsessammenfatningsmetoder, og når en, der er stærkere end MD5, er defineret og implementeret, vil det være relativt simpelt at opgradere LDP til at bruge det.
LDP giver ikke en mekanisme til at beskytte etiketudbredelsens fortrolighed. Sikkerhedskravene for etiketudbredelsesprotokoller er i det væsentlige identiske med dem for routingprotokoller.
For at undgå etiket-spoofing-angreb er det nødvendigt at sikre, at mærkede datapakker er mærket af betroede LSR'er, og at etiketter placeret på pakker læres korrekt ved at mærke LSR'er.
LDP giver to potentielle mål for Denial of Service (DoS)-angreb:
1. Velkendt UDP-port til LDP-opdagelse.En LSR-administrator kan afbøde truslen om DoS-angreb med Basic Hello ved at sikre, at LSR kun er direkte forbundet til peers, som man kan stole på, ikke starter et sådant angreb.
Grænseflader med peers inden for administratorens domæne bør ikke udgøre en trussel, da interne noder er under administratorens kontrol. Grænseflader med peers uden for domænet er en potentiel trussel, men eksterne peers er det ikke. En administrator kan afbøde denne trussel ved kun at forbinde LSR til eksterne peers, som man kan stole på, ikke starter et Basic Hello-angreb. DoS-angreb via Extended Hello-beskeder er potentielt en mere alvorlig trussel. Denne trussel kan afbødes ved at filtrere udvidede hilsener ved hjælp af adgangslister, der definerer adresser, med hvilke udvidet opdagelse er tilladt. LSR-ressourcen er dog påkrævet for at udføre filtreringen. I et miljø, hvor en betroet MPLS-sky kan identificeres, kan en LSR i kanten af skyen bruges til at beskytte interne LSR'er mod DoS-angreb ved hjælp af udvidede hej ved at bortfiltrere udvidede hej, der stammer uden for den betroede MPLS-sky, og kun acceptere dem, der stammer fra adresser tilladt af adgangslister. Denne filtrering beskytter LSR'er i skyen, men bruger ressourcer ved kanterne.
2. Velkendt TCP-port til at etablere en LDP-session.Ligesom andre kontrolplanprotokoller, der bruger TCP, kan LDP være målet for DoS-angreb, såsom SYN-angreb . LDP er hverken mere eller mindre sårbar over for sådanne angreb end andre kontrolplanprotokoller, der bruger TCP.
Truslen om sådanne angreb kan reduceres noget ved følgende:
LDP-specifikation RFC3036
Multiprotokol Label Switching Architecture RFC3031