LDP ( El-di-pi , Eng. Label Distribution Protocol - Label Distribution Protocol ) är ett protokoll genom vilket två LERs ( Eng. Label Edge Router - Border Label Router ) i ett MPLS -nätverk utbyter information om etikettmappning [1] . De två LER kallas LDP-kamrater. Informationsutbytet mellan LERs är dubbelriktat.
Label Distribution Protocol (LDP) ger LSR:er ( Label Switching Router ) möjlighet att begära, distribuera och släppa bindningsinformation för etikettprefix till peer-routrar i ett nätverk. LDP tillåter LSR:er att upptäcka potentiella peers och upprätta LDP-sessioner med dessa peers för att utbyta etikettbindande information.
Med andra ord används LDP för att upprätta MPLS-transport -LSP ( Label Switch Path ) när trafikkontroll inte krävs . Den etablerar LSP:er som följer den befintliga IP-routningstabellen och är särskilt väl lämpad för att skapa ett komplett nätverk av LSP:er mellan alla routrar i nätverket.
LDP kan fungera i många lägen för att passa olika krav; den vanligaste användningen är dock oönskat läge, som upprättar ett komplett nätverk av tunnlar mellan routrar.
I begärt läge skickar ingångsroutern en LDP-etikettbegäran till nästa hop-router, som fastställs från dess IP-routningstabell. Denna begäran skickas över nätverket av varje router. Så snart förfrågan når utgångsroutern genereras ett svarsmeddelande. Det här meddelandet bekräftar LSP:n och talar om för varje router vilken etikettmappning som ska användas på varje länk för den LSP:n.
I oönskat läge sänder utgående routrar etikettmappningar för varje extern länk till alla sina grannar. Dessa sändningar sprids genom varje länk i nätverket tills de når ingångsroutrarna. Vid varje steg informerar de uppströmsroutern om etikettmappningen som används för varje extern länk, och genom att översvämma nätverket upprättar de en LSP mellan alla externa länkar.
Den största fördelen med LDP framför RSVP är att det är lätt att sätta upp ett fullständigt tunnelnätverk med oönskat läge, varför det oftast används i detta läge för att ställa in det grundläggande tunnelnätverk som behövs för Layer 2 och Layer 3 VPN .
Etableringen av grannrelationer mellan routrar utförs i två faser:
Fas N2 exekveras endast om fas N1 är framgångsrikt genomförd.
Hej-meddelanden skickas av routern på alla LDP-aktiverade gränssnitt var 15:e sekund till adressen 224.0.0.2 (all-routrar), port 646, UDP-transportprotokoll . Hej-meddelanden kan också utbytas mellan LSR:er som inte är direkt anslutna. I det här fallet skickas meddelandet till en unicast-adress.
Hej meddelanden innehåller följande information:
Nedhållningstimer - den tid under vilken grannarna måste skicka minst ett Hej-meddelande. Om grannarna erbjuder ett annat värde måste de acceptera minimivärdet. Eftersom UDP-protokollet inte ger leveransgarantier, rekommenderas det att skicka Hello-meddelanden med en period som är tre gånger kortare än Holddown-timern. Om nedtryckningstimern är 0, accepteras följande standardvärden:
Värdet på Holddown-timern lika med 0xFFFF betyder oändlighet, men varför det är det - RFC är tyst.
T bit - (Targeted Hello) om denna bit är 1 betyder det att meddelandet skickas till en specifik (unicast) adress, annars skickas meddelandet till 224.0.0.2.
R bit - (Request Send Targeted Hellos) om denna bit är 1 betyder det att mottagaren ska svara på detta meddelande (Hej), annars borde den inte. Denna bit kan bara sättas till 1 om T-bit=1.
Obs: Targeted Hello används vid implementering av ytterligare funktionalitet baserad på MPLS.
Transportadress - detta fält är valfritt i Hello-paketet. Om den finns, används den adress som anges i den senare för att upprätta en LDP-session mellan enheter. Om detta fält saknas, måste källadressen för Hello-paketet användas för att upprätta sessionen. Adressen som används för att upprätta en LDP-session kommer att kallas "transportadressen".
Konfigurationssekvensnummer - Fältet innehåller konfigurationsnumret. När du ändrar inställningarna på LSR ändras detta nummer i enlighet med detta. Att ändra numret kan göra att LDP-sessionen återupprättas (eller så kanske det inte - RFC är inte tydligt här).
Hej-meddelanden kan kasseras, och följaktligen kan grannrelationsfasen N1 inte utföras på grund av följande skäl:
LDP-sessionen körs över TCP/IP (port 646).
LSR1 och LSR2 lär sig varandras transportadresser när de utbyter hej-meddelanden. Om transportadressen för LSR1 är större än transportadressen för LSR2, så blir LSR1 den "aktiva" grannen och LSR2 den "passiva", annars vice versa. Vidare upprättas LDP-sessionen enligt följande scenario.
Om något oväntat inträffar i något skede (fel typ av paket kommer, det förväntade meddelandet kommer inte alls eller LDP-sessionsparametrarna i Init-meddelandet stämmer inte överens, etc.), så anses sessionen inte etablerad. En LSR som stöter på ett fel skickar ett Shutdown- eller Reject-meddelande till sin granne.
Init meddelandeInit-meddelandet innehåller följande information:
Protokollversion - protokollversion.
KeepAlive Time - maximal tid mellan KeepAlive-tjänstmeddelanden. Båda parter kan erbjuda olika värden - minimum ska användas.
A-bit, Label Advertisement Discipline - läge för utbyte av etikettinformation. Det är möjligt att använda två sätt för informationsutbyte om taggar:
D-but, Loop Detection - LSP-loopförebyggande mekanism. 0 - inaktiverad, 1 - aktiverad.
PVLim, Path Vector Limit - Variabeln används för mekanismen för att undvika loop.
Max PDU Length - LDP-meddelanden grupperas i PDU:er (Protocol Data Units) och skickas i ett TCP/IP-paket. Max PDU Length - betyder den maximala möjliga längden av sammanlänkade LDP-meddelanden i byte. Grannar kan erbjuda olika värden, men båda måste välja minimum. Observera att även ett enda meddelande är packat i en PDU.
Mottagarens LDP-identifierare - Label Space Identifier (eller Label Space Identifier). Fältformatet är som följer: LSR_ID:Label_Space_ID. LSR_ID är identifieraren för LSR. Denna identifierare måste vara unik inom MPLS-domänen och unik för varje LSR. Label_Space_ID är etikettuppsättningens identifierare. Etikettutrymmesidentifieraren indikeras i huvudet på PDU:n, och identifierar därigenom grannen och gränssnittet på vilket grannen är etablerad. Till exempel kan två LSR:er anslutas av två kanaler, och för varje kanal måste en annan Label Space Identifier tilldelas, som endast skiljer sig i värdet av Label_Space_ID.
Obs: Init-meddelandet innehåller också flera extra, valfria fält, vars beskrivning har utelämnats. Det finns fortfarande ingen mening från dessa fält i IP-nätverk.
En LDP-session upprättas när följande villkor är uppfyllda:
En PVLim-felmatchning, enligt RFC, bör inte resultera i en sessionsstängning, men kan orsaka en varning på LSR.
LSR MÅSTE tilldela en timer till varje LDP-session. Vid mottagande av något LDP-meddelande ställer LSR timern till 00:00 och startar om den. Innan timern når värdet "KeepAlive Time" MÅSTE grannen LSR skicka något LDP-meddelande. Om grannen inte har några informativa meddelanden att vidarebefordra, bör den skicka ett KeepAlive-meddelande.
Obs: Med en specifik implementering kan timern fungera både från 00:00 till "KeepAlive Time" och vice versa.
Om meddelanden inte kommer fram vid utsatt tid, anses grannen vara frånkopplad och sessionen med honom måste återupprättas.
Det finns flera parametrar för LDP-drift:
Mellan grannar är det möjligt att använda två sätt för informationsutbyte om etiketter:
I Downstream On Demand-läge måste en LSR begära en etikett för att skapa en LSP (för en FEC) från en granne LSR som är nästa hopp för den FEC. I nedströms oönskat läge tilldelar en LSR en etikett till varje FEC i dess IP-routningstabell och sänder den till alla dess grannar. Om för en granne LSR är källans LSR nästa hopp, så sätts etiketten i växlingstabellen.
Det finns också flera mekanismer för att kontrollera distributionen av etiketter (Label Distribution Control Mode):
När man använder oberoende kontroll över etikettutbredning kan en LSR tilldela etiketter för FEC till sina grannar även om LSR inte har en utetikett för sig själv från nästa LSR. Om beordrad etikettutbredningskontroll används, kommer LSR inte att allokera etiketter till sina grannar förrän LSR själv tar emot en utdataetikett för en given FEC från NH-LSR. I detta läge skickar den LSR som FEC är direkt kopplad till etiketten först.
Etikettretentionsläge
När du använder det diskreta etikettbeständighetsläget tas etiketten bort när rutten förstörs på FEC. Återställning av LSP kräver att etiketten omfördelas av den angränsande NH-LSR. Om det fria etikettsparläget används, raderas inte etiketten när rutten förstörs på FEC, utan bara markeras som inaktiv. Och om rutten på FEC återställs genom samma NH-LSR, efterfrågas inte etiketten, utan den gamla används, vars status ändras till aktiv.
Obs: Etikettkvarhållningsläget, etikettutbredningskontrollmekanismen och etikettkvarhållningsläget får inte förhandlas mellan LDP-grannar.
LDP-protokollet måste svara på följande händelser:
Möjliga kombinationer av driftlägen för LDP-protokollet, såväl som exempel på drift, ges i tabell. ett.
| Läge för utbyte av etikettinformation | Nedströms oönskad | Nedströms oönskad | Nedströms oönskad | Nedströms On Demand | Nedströms On Demand |
| Mekanismen för att kontrollera distributionen
märkning |
oberoende kontroll | Beställd kontroll | Beställd kontroll | Beställd kontroll | oberoende kontroll |
| Cue hold-läge | liberal | liberal | konservativ | konservativ | konservativ |
| uppkomsten av en ny FEC-post | 1) Vi skickar etiketter till alla kända FEC:er till alla grannar.
2) Vi förväntar oss en etikett från NH-LSR. 3) Vi använder den mottagna etiketten för att byta. |
1) Vi väntar på att etiketten från NH-LSR ska komma fram.
2) Vi skickar en etikett till FEC till alla grannar. 3) Vi använder den mottagna etiketten för att byta. PS. Den första skickar etiketten till routern som är ansluten till FEC. |
1) Vi skickar en förfrågan till NH-LSR för etiketttilldelning.
2) Vi väntar på svar. 3) Vi använder den mottagna etiketten för att byta. | ||
| nästa hopp-ändring för FEC-inspelning | 1) Vi letar efter en etikett i listan över "uppskjutna".
2) Om den inte hittas skickar vi en NH-LSR-förfrågan för att välja en etikett, annars punkt 4. 3) Vi väntar på svar. 4) Vi använder den mottagna etiketten för att byta. |
1) Vi skickar en förfrågan till NH-LSR för etiketttilldelning.
2) Vi väntar på svar. 3) Vi använder den mottagna etiketten för att byta. | |||
| Får en begäran om att välja en etikett | Vi väljer etiketten utan att vänta på svar från vår NH-LSR. | Vi väljer etiketten först efter ett svar från vår NH-LSR. | Vi väljer etiketten utan att vänta på svar från vår NH-LSR. | ||
När en FEC-post försvinner från routingtabellerna MÅSTE alla LSR:er återkalla tilldelade FEC-växlingsetiketter från sina grannar. Detta görs genom att skicka ett meddelande om Label Draw.
LDP-protokollet innehåller en mekanism för att undvika slinga. Syftet med denna mekanism är att förhindra att förfrågningar och rutter går i loop. Denna effekt uppnås genom att i alla meddelanden om etikettmappning och etikettmappningsförfrågan inkluderas information om den LSR som dessa förfrågningar har passerat. Om LSR:er fungerar i beställt kontrollläge, uppnås denna effekt lätt. Om LSR:er använder oberoende kontroll, måste LSR:er skicka förfrågningar och svar på dem igen, eftersom information om LSR:er som förfrågningar har passerat kommer att uppdateras.
Mekanismen för att undvika loopar får inte användas, eftersom frånvaron av loopar i teorin bör garanteras av IP-routingprotokollet, information från vilken LDP använder.
Slingor kan endast inträffa under en kort period om IP-routningsprotokollet är långsamt att konvergera och LDP är snabbare än IP-routningsprotokollet.
Tabellen visar typerna av LDP-meddelanden:
| Meddelande | Beskrivning |
|---|---|
| underrättelse | LSR skickar ett viktigt händelsemeddelande till grannen. Meddelandet signalerar ett allvarligt fel eller ger rådgivande information såsom resultatet av bearbetningen av ett LDP-meddelande eller tillståndet för en LDP-session. |
| Hallå | Meddelandet används för att identifiera grannar, vilket etablerar N1-fasen av grannförhållandet. |
| initiering | Meddelandet används för att upprätta grannrelationer (fas N2), utbyta och förhandla LDP-sessionsparametrar. |
| Håll vid liv | Meddelandet används för att hålla LDP-sessionen aktiv. |
| Adress | Meddelandet används för att meddela grannar om nya IP-nätverk direkt kopplade till LSR. |
| Adress Återkalla | Meddelandet används för att meddela grannar om försvinnandet direkt kopplat till LSR, IP-nätverk. |
| etikettmappning | Meddelandet innehåller FEC-beskrivningen och etiketten som tilldelats av den sändande LSR. |
| Etikettbegäran | Med detta meddelande ber LSR:n grannarna att byta etikett för en viss FEC. Beskrivningen av FEC ingår i begäran. |
| Etikett avbryt begäran | Avbryter en begäran om etiketttilldelning som tidigare skickats i ett meddelande om etikettbegäran. |
| Etikett dra tillbaka | Återkallelse av den tilldelade taggen från en granne. Grannen måste sluta använda den återkallade etiketten för byte. |
| Etikettsläpp | Bekräftelse på mottagande av etiketten i meddelandet Label Mapping. Skickas om etiketten begärdes av en etikettförfrågan. |
Det här avsnittet identifierar de hot som LDP kan vara sårbara för och diskuterar hur dessa hot kan mildras.
Det finns två typer av LDP-kommunikation som kan vara målet för en spoofingattack.
1. Öppnande av utbyten genomförs via UDP.LSR:er som är direkt anslutna till länklagret utbyter Basic Hello-meddelanden över länken. Hotet att förfalska Basic Hello-meddelanden kan minskas genom att:
LSR:er som inte är direkt anslutna till länklagret KAN använda Extended Hello-meddelanden för att indikera att de är redo att upprätta en LDP-session. En LSR kan minska hotet om förfalskade utökade hälsningar genom att filtrera dem och bara acceptera de som kommer från källor som tillåts av åtkomstlistan.
2. Sessionskommunikation via TCP.LDP definierar användningen av TCP MD5- signeringsalternativet för att säkerställa äktheten och integriteten hos sessionsmeddelanden.
[RFC2385] säger att MD5-autentisering nu av vissa anses vara för svag för denna applikation. Han påpekar också att en liknande variant av TCP med en starkare hashalgoritm (han nämner SHA-1 som ett exempel ) skulle kunna användas. Så vitt vi vet har inget sådant TCP-alternativ definierats och distribuerats. Vi noterar dock att LDP kan använda alla tillgängliga TCP-meddelandesammandragsmetoder, och när en som är starkare än MD5 har definierats och implementerats kommer det att vara relativt enkelt att uppgradera LDP för att använda den.
LDP tillhandahåller ingen mekanism för att skydda etikettspridningssekretessen. Säkerhetskraven för etikettutbredningsprotokoll är väsentligen identiska med de för routingprotokoll.
För att undvika etikettspoofing-attacker är det nödvändigt att se till att märkta datapaket är märkta av betrodda LSR och att etiketter som placeras på paket lärs in ordentligt genom att märka LSR.
LDP tillhandahåller två potentiella mål för Denial of Service (DoS)-attacker:
1. Välkänd UDP-port för LDP-upptäckt.En LSR-administratör kan mildra hotet om DoS-attacker med Basic Hello genom att se till att LSR endast är direkt ansluten till kamrater som man kan lita på att inte initierar en sådan attack.
Gränssnitt med peers inom administratörens domän bör inte utgöra ett hot, eftersom interna noder står under administratörens kontroll. Gränssnitt med peers utanför domänen är ett potentiellt hot, men externa peers är det inte. En administratör kan mildra detta hot genom att endast ansluta LSR till externa kamrater som man kan lita på att inte initierar en Basic Hello-attack. DoS-attacker via Extended Hello-meddelanden är potentiellt ett allvarligare hot. Detta hot kan mildras genom att filtrera utökade hälsningar med hjälp av åtkomstlistor som definierar adresser med vilka utökad upptäckt är tillåten. LSR-resursen krävs dock för att utföra filtreringen. I en miljö där ett pålitligt MPLS-moln kan identifieras, kan en LSR i kanten av molnet användas för att skydda interna LSR:er från DoS-attacker med utökade hej genom att filtrera bort utökade hej som kommer utanför det betrodda MPLS-molnet, endast acceptera de som kommer från adresser tillåtna av åtkomstlistor. Denna filtrering skyddar LSR:er inom molnet, men förbrukar resurser vid kanterna.
2. Välkänd TCP-port för att upprätta en LDP-session.Liksom andra kontrollplansprotokoll som använder TCP, kan LDP vara målet för DoS-attacker som SYN-attacker . LDP är varken mer eller mindre sårbart för sådana attacker än andra kontrollplansprotokoll som använder TCP.
Hotet om sådana attacker kan minskas något genom följande:
LDP-specifikation RFC3036
Flerprotokoll Label Switching Architecture RFC3031