En Route Origin Authorization är en digitalt signerad RPKI en post som identifierar vilken ASN som får attoritera en IP-prefix i BGP. Den skapas av, eller på vägnar av, den organisation som innehar de relevanta internetnummerresurserna. En ROA innehåller normalt tre grundläggande element: IP-prefixet, den auktoriserade origin-ASN:n och det maximala prefixlängden som ASN:n får annonsera. Till exempel kan en organisation kontrollera IPv4-prefixet 203.0.113.0/24 och använda AS64500 för att annonsera det. En motsvarande ROA kan auktorisera AS64500 att attoritera detta /24. Med enkla ord kommunicerar posten följande instruktion till routingekosystemet: ”Denna ASN är tillåten att annonsera detta prefix.” Nätverk som utför RPKI-validering kan sedan jämföra posten med vad de observerar i BGP. En ROA överför inte äganderätten till ett IP-adressblock. Den ersätter inte ett kontrakt, en registerpost, en allokeringsspost eller ett överenskommelse om överföring av IPv4. Den publicerar endast en auktorisation relaterad till ursprunget på en route. Juridisk kontroll och routingauktorisation är kopplade, men de är inte samma sak. ROAs kan skapas för både IPv4- och IPv6-resurser. Formatet är liknande, även om prefixlängderna och den operativa designen kan skilja sig åt. IPv4-nätverk arbetar ofta med prefix som /24, medan IPv6-nätverk vanligtvis annonserar aggregat som /32, /36, /48 eller annan lämplig längd beroende på deras allokering och routningsplan.
Varför behövs en ROA?
Utan ett ROA har andra nätverk ingen RPKI-baserad auktorisation för att bekräfta att en BGP-origin-ASN får annonsera ett prefix. Routen kan fortfarande vara legitim, men den kommer generellt att ge ett resultat av "Not Found" under RPKI-validering eftersom det inte finns någon matchande auktorisation. Ett resultat av "Not Found" är inte automatiskt ett routingproblem. Många giltiga rutter på Internet saknar ROA:er. När en organisation dock publicerar en korrekt ROA ger den andra nätverk en starkare signal som kan användas för att skilja förväntad origin från en obehörig eller felkonfigurerad origin. Ett ROA blir särskilt användbart när ett prefix är värdefullt, affärskritiskt eller brett annonserat. En företagsorganisation kan använda sitt eget adressutrymme för offentliga tjänster, ett molnplattform kan annonsera kundinfrastruktur, eller en hostingleverantör kan annonsera stora adressintervall från flera platser. I dessa situationer kan en felaktig origin påverka många användare och tjänster. ROA:er hjälper också vid incidenthantering. Om ett prefix plötsligt dyker upp från en oväntad ASN kan en nätverksoperatör kontrollera RPKI-statusen och snabbt avgöra om annonsen strider mot resursinnehavarens publicerade avsikt. Detta förklarar inte alla detaljer i incidenten, men det ger en viktig utgångspunkt för undersökningen. För organisationer som använder flera upstream-leverantörer kan ett ROA ge en konsekvent auktorisation oavsett vilken leverantör som transporterar rutten. Leverantören kan bytas ut, men origin-ASN:n kan förbli densamma. I så fall behöver ROA:et vanligtvis inte ändras endast för att transitvägen har ändrats.
Hur fungerar en ROA med BGP?
BGP distribuerar route-annonseringar mellan autonoma system. En route-annonsering innehåller vanligtvis ett IP-prefix och en ursprungs-ASN, tillsammans med annan sökvägs- och policyinformation. Ursprungs-ASN är det autonoma system som hävdar att vara källan till routen. RPKI-validering fungerar parallellt med BGP. En validerare hämtar signerade auktoriseringsdata från RPKI-systemet och kontrollerar att posterna är autentiska och aktuella. Den skapar därefter en validerad datamängd som kan användas av routrar, route-servrar eller system för routingpolicy. När ett nätverk mottar en BGP-annonsering jämförs det annonserade prefixet och ursprungs-ASN med den validerade ROA-informationen. Det finns tre huvudsakliga utfall. Annonseringen kan vara Valid, Invalid eller Not Found. Ett Valid resultat innebär att annonseringen täcks av en ROA och att ursprungs-ASN är auktoriserad. Ett Invalid resultat innebär att en relevant ROA finns men att annonseringen strider mot den. Ett Not Found-resultat innebär att ingen tillämplig ROA hittades. Det mottagande nätverket bestämmer vad som ska göras med dessa resultat. Vissa operatörer avvisar Invalid-rutter. Andra tilldelar dem lägre preferens, genererar en varning eller tillämpar olika policyer beroende på källa. Det finns ingen universell policy för alla nätverk, men många leverantörer behandlar Invalid-annonseringar som ett allvarligt säkerhetsproblem inom routningen. Viktigt är att ROA inte direkt styr globala Internet. Den publicerar auktoriseringsinformation. Den praktiska effekten beror på om andra nätverk hämtar, validerar och använder denna information i sina routingbeslut.
De tre huvuddelarna i en ROA
Den första delen av en ROA är IP-prefixet som auktoriseras, vilket identifierar det adressområde som origin-ASN:en får annonsera. För IPv4 kan ett prefix vara 198.51.100.0/24; för IPv6 kan det vara 2001:db8:1234::/48. Prefixet måste motsvara en resurs som organisationen har behörighet att hantera genom den relevanta registret eller sponsringsrelationen. Prefixet ska anges korrekt, eftersom ett stavfel, felaktig nätverksgräns eller felaktig prefixlängd kan göra ROA:en ineffektiv eller auktorisera ett annat område än det avsedda.
Den andra delen är det ursprungliga ASN som har behörighet att annonsera prefixet, vilket matchar det ASN som visas som ursprunget för BGP-annonsen. Om ett företag äger en adressblock men annonserar det via en transitleverantörs ASN beror det korrekta ursprunget på den faktiska routningsdesignen. ASN:et i ROA bör normalt vara det ASN som originerar rutten, inte bara det upstream-leverantörens ASN. Denna distinktion är viktig eftersom en transitleverantör kan transportera en ruta utan att vara dess ursprung; om kundens ASN originerar prefixet och leverantören endast transporterar det, är kundens ASN vanligtvis det värde som behöver auktoriseras.
Den tredje delen är den maximala prefixlängden, ofta kallad maxLength, som definierar hur specifik en annons kan vara samtidigt som den täcks av ROA. Antag att en ROA godkänner 198.51.100.0/24 med en maximal längd på /24: den auktoriserade ASN får annonsera exakt /24, men det är inte tillåtet att annonsera mindre subprefix såsom /25 eller /26. Om samma prefix godkänns med en maximal längd på /26 kan annonseringar för /24, /25 och /26 betraktas som täckta beroende på exakt rutt och valideringsregler. Detta ger flexibilitet, men det möjliggör också mer specifika annonseringar. Den maximala längden bör därför spegla den faktiska routningsplanen, eftersom att sätta den för kort kan göra att legitima mer specifika rutter blir ogiltiga, medan att sätta den för lång kan auktorisera annonseringar som organisationen aldrig har avsett att tillåta.
Varför är maxLength viktigt?
Den maximala prefixlängden är en av de viktigaste och mest missförstådda ROA-inställningarna, eftersom den styr hur specifika den auktoriserade ASN:en får vara när den annonserar resursen. Många nätverksoperatörer annonserar ett aggregerat prefix för att minska tillväxten i routningstabellen; exempelvis kan en organisation inneha ett /20 men annonsera det som ett enda aggregat. I vissa fall kan organisationen också behöva annonsera mindre specifika prefix för trafikstyrning, regional anslutning eller tjänsteseparation. Om RO:n endast täcker aggregatet medan nätverket annonserar mer specifika rutter, kan dessa rutter klassificeras som ogiltiga. BGP-annonseringen kan vara tekniskt korrekt ur organisationens perspektiv, men den stämmer inte överens med den auktorisation som publicerats i RPKI. Å andra sidan kan det att auktorisera varje möjlig mer specifik rutt försvaga precisionen i policyn, eftersom ett /20 som auktoriseras med en mycket bred maximal längd gör att ett betydligt mindre subprefix kan framstå som auktoriserat även om det ligger utanför den avsedda designen. En praktisk metod är att endast auktorisera de prefixlängder som nätverket verkligen förväntas annonsera baserat på dess adressplan, leverantörs krav, failover-design och trafikstyrningsstrategi. Ändringar av den maximala längden bör testas noggrant, genom att bekräfta att alla produktionsannonser returnerar det förväntade valideringsresultatet innan strikt filtrering tillämpas.
ROAs for IPv4 and IPv6
ROA:er kan skapas för både IPv4- och IPv6-nätverk, och den underliggande säkerhetsprincipen är densamma: att koppla ihop ett prefix med en auktoriserad ursprungs-ASN. Den främsta operativa skillnaden ligger i adressstrukturen. IPv4-resurser är knappa och annonseras ofta i relativt små prefix, där /24 är en vanlig minimistorlek för annonsering på det offentliga internet. IPv6-nätverk får generellt större tilldelningar och kan dela upp dem i segment för platser, tjänster eller geografiska områden, varvid de annonserar ett aggregat medan flera interna prefix används internt. ROA:en måste stämma överens med de prefix som annonseras offentligt. IPv6-operatörer bör inte anta att ett stort adressutrymme eliminerar riskerna för routning, eftersom en obehörig IPv6-annonsering fortfarande kan leda till problem med nåbarhet, omdirigering av trafik eller inkonsekvent global routning. RPKI ger IPv6-operatörer samma möjlighet att publicera ursprungsauktorisation som IPv4-operatörer. Innan IPv6-ROA:er skapas bör nätverksteamet dokumentera vilka aggregatprefix som kommer att annonseras, om mer-specifika annonseringar förväntas, och vilken ASN som ska ursprungligen annonsera dem, för att undvika poster som är antingen för restriktiva eller onödigt breda.
När ska du skapa en ROA?
En ROA bör skapas innan en prefix annonseras i produktion när resursinnehavaren har en tydlig routningsplan, vilket ger validerande nätverk tid att hämta informationen innan routen blir allmänt synlig. Organisationer bör också granska ROAr när de får en ny allokering, förvärvar ett IPv4-block, slutför en adressöverföring, ändrar ursprungs-ASN eller börjar använda en ny IPv6-allokering, eftersom dessa händelser ändrar relationen mellan prefixet och det ursprungliga nätverket. En leverantörsomflyttning är ytterligare en vanlig utlösande faktor: om organisationen behåller samma ursprungs-ASN och endast ändrar upstream-operatören kan ROA:n förbli giltig; om omflyttningen ändrar ursprungs-ASN måste posten uppdateras före eller samtidigt med routningsändringen. ROAr bör granskas vid fusioner, uppköp, flytt av datacenter, ändringar av ASN-sponsorship och större nätverksomkonstruktioner för att säkerställa att offentlig auktorisering stämmer överens med den operativa verkligheten. En periodisk granskning är användbar även när inga kända förändringar har ägt rum, då nätverksdokumentation blir föråldrad, personalansvar ändras och gamla auktorisationer kan vara aktiva länge efter att den ursprungliga routningsdesignen har ersatts.
Vanliga konfigureringsfel för ROA
Ett av de vanligaste misstagen är att ange felaktigt ursprungligt ASN, vilket sker när ingenjörer förväxlar kundens ASN med transitleverantörens ASN eller när ett gammalt ASN finns kvar i konfigurationen efter en migration. Ett annat vanligt misstag är att glömma uppdatera ROA:n efter en IPv4-överföring, där den nya innehavaren annonserar prefixet från sitt eget ASN medan den gamla auktorisationen fortfarande pekar på det tidigare ursprunget, vilket gör att routen blir ogiltig. En felaktig maximal längd skapar liknande problem när en organisation endast auktoriserar ett /24 men senare annonserar ett /25 för trafikoptimering. Vissa organisationer skapar flera överlappande ROA:er utan att dokumentera deras syfte; även om de är giltiga inom vissa designmönster kan de ge oväntade resultat och komplicera felsökning. Att inte ta bort inaktuella poster tillåter ett ASN att härleda ett prefix långt efter att nätverksdesignen har ändrats. Slutligen aktiverar organisationer ibland strikt avvisning av ogiltiga rutter utan att först testa egna annonseringar; produktionsprefix, maximala längder och ursprungliga ASN måste alltid verifieras innan man förlitar sig på automatisk filtrering.
ROA and IPv4 Transfer Planning
IPv4-överföringar kräver särskild uppmärksamhet eftersom administrativ innehavare, sponsringsarrangemang och routingursprung kan ändras vid olika stadier i processen. Innan en överföring bör den nuvarande innehavaren dokumentera befintliga ROA:er och bekräfta vilket ASN som för närvarande originerar prefixet, medan köparen förbereder avsedd ursprungsinformation och samordnar med transitleverantörer. Under övergångsfasen behöver båda parter en tydlig plan för att uppdatera eller ersätta auktorisationsregister: att låta den tidigare ROA:n vara aktiv för länge efter överföringen auktoriserar det gamla ursprunget, medan att ta bort den för tidigt gör att den befintliga routningen blir ogiltig innan den nya routningen är redo. Den exakta processen beror på registret, resurstypen, överenskommelsen om överföring och den operativa designen, vilket gör RPKI till ett väsentligt kontrollpunktsobjekt tillsammans med registerverifiering, avtalsgranskning, BGP-meddelanden, route-objekt, omvänd DNS och reputationskontroll. En offentlig beredskapskontroll hjälper till att identifiera det aktuella ursprungs-ASN, RPKI-tillstånd, registerinformation och BGP-synlighet för ett prefix för tekniska förhandskontroller, även om den inte bekräftar juridiskt ägande eller garanterar överföringsbehörighet.
Ändringar av ROA och ASN
En ASN-ändring påverkar RPKI-validering direkt. Om en prefix som tidigare annonserades av AS64500 nu kommer att annonseras av AS64510 måste ROA:a godkänna den nya ursprungsadressen innan BGP-meddelandet kan accepteras som giltigt. Detta är särskilt viktigt när en organisation flyttar från en leverantörsadministrerad ASN till sin egen ASN eller ändrar sitt LIR-sponsringsavtal, vilket kräver att registerrrelationen och routningsauktoriseringen granskas tillsammans. En noggrant planerad övergång kan innefatta att både gamla och nya ursprung tillfälligt auktoriseras för att skapa ett kontrollerat migrationsfönster, förutsatt att detta dokumenteras och att den inaktuella auktoriseringen tas bort när övergången är slutförd. Nätverksteamet bör testa ordningen på åtgärderna innan produktionsändringar genomförs, och säkerställa att den nya auktoriseringen publiceras och valideras innan den nya BGP-rutten annonseras.
Hur kontrollerar du om en ROA fungerar?
Den första kontrollen består i att bekräfta att ROA:n innehåller den avsedda prefixlängden, ursprungs-ASN och maximal prefixlängd via den relevanta RIR-portalen, granskande LIR-gränssnittet eller RPKI-hanteringssystem. Jämför därefter auktorisationen med den faktiska BGP-meddelandet och verifiera att det annonserade prefixet omfattas samt att ursprungs-ASN matchar ROA:n. En extern RPKI-validerare kan sedan bekräfta det offentliga statusläget, där ett korrekt konfigurerat meddelande returnerar Valid. Om resultatet är Invalid, undersök först ursprungs-ASN och prefixlängd; om resultatet är Not Found, kontrollera att ROA:n har publicerats och att validerarna haft tid att hämta den. Resultaten uppdateras inte omedelbart eftersom register, validerare och routningssystem förlitar sig på uppdateringsintervall, vilket gör korta fördröjningar normala under spridningen. Genom att jämföra flera offentliga källor – inklusive registerndata, valideringsresultat och aktuella BGP-observationer – undviks beroende av cachad information och en komplett bild erhålls.
Vad händer när en ROA är ogiltig?
När en BGP-annons strider mot en befintlig ROA klassificerar RPKI-validerare den som ogiltig. Routen tas inte bort automatiskt från det globala internet, men nätverk som tillämpar RPKI-baserade policyer kan avslå den eller tilldela den lägre prioritet. Den operativa påverkan beror på omfattningen av genomförandet: vissa nätverk filtrerar strikt medan andra använder statusen för övervakning, vilket innebär att en ogiltig route kan vara synlig i delar av internet samtidigt som den blir oåtkomlig via andra. Om en legitim route blir ogiltig bör organisationen hantera detta som ett akut konfigurationsproblem och prioritera granskningar av ursprungs-ASN, annonsad prefixlängd och ROA:s maximala längd. Routen ska inte antas vara skadlig, eftersom de flesta resultat som är ogiltiga beror på vanliga misstag såsom ofullständiga migrationer, inaktuella poster, felaktiga leverantörsuppgifter eller oavsiktliga mer-specifika annonseringar. När felet har korrigerats behöver systemen tid att uppdateras, och nätverksteamet bör övervaka routen tills den stabiliseras över alla observationspunkter.
Hur bör organisationer hantera ROA:er?
Hantering av ROA kräver en tydlig ägare, oavsett om det är nätverksteknikteamet, säkerhetsteamet, den sponsrande LIR:n, en leverantör av hanterade tjänster eller en annan grupp som ansvarar för Internet-nummerresurser. Organisationen bör upprätthålla ett register som innehåller detaljerad information om varje prefix, ursprungligt ASN, maximal längd, tillkännagivandepositioner och ansvariga kontakter för att förenkla granskning av ändringar och incidenthantering. Ändringar av ROA måste integreras i standardiserade procedurer för nätverksändringar, där RPKI behandlas som ett explicit krav vid migrationer av ASN, byten av leverantörer, överföringar av IPv4-adresser eller utveckling av IPv6. Övervakning och varningar ska konfigureras för ogiltiga resultat, oväntade ursprung, borttagna auktorisationer eller förändringar i BGP-synlighet. Avgörande är att organisationer undviker alltför breda auktorisationer: precisa ROA:er är lättare att förstå, enklare att auditera och betydligt mindre benägna att tillåta oförutsedda tillkännagivanden.
Vanliga frågor
Är en ROA samma sak som ett IP-ägandebrev?
Nej. En ROA är en routingauktorisation som anger vilken ASN som får originera ett prefix i BGP. Den ersätter inte registerposter, avtal, överlåtelsehandlingar eller bevis på juridiskt ägande.
Kan ett prefix ha mer än en ROA?
Ja. Flera ROA:er kan vara lämpliga när en prefix avsiktligt origineras av mer än en ASN eller när en kontrollerad migration kräver tillfällig auktorisation för flera ursprung, även om överlappande poster bör dokumenteras noggrant.
Meddelar en ROA mitt prefix i BGP?
Nej. Att skapa en ROA skapar inte en BGP-annons; nätverket måste fortfarande konfigurera BGP via sina routrar och upphovsleverantörer.
Behöver en transitleverantör listas i ROA?
Vanligtvis bör ROA identifiera det ASN som ursprungligen publicerar routen. En leverantör som endast transporterar routen är inte nödvändigtvis det ursprungliga ASN, och det korrekta värdet beror på den faktiska routingarkitekturen.
Hur lång tid tar det innan en ROA blir synlig?
Tidpunkten beror på RIR-systemet, publiceringsarkivet, validerarens uppdateringsintervall och cachning. Uppdateringar är ofta synliga relativt snabbt, men produktionsändringar bör ge tillräckligt med tid för validering.
Bör varje IPv4- och IPv6-prefix ha en ROA?
Det rekommenderas starkt att publicera korrekta ROAs för prefix som annonseras i BGP. Organisationen bör först bekräfta sin routningsdesign så att auktoriseringen inte av misstag gör legitima annonser ogiltiga.
Kan en ROA skydda mot alla BGP-attacker?
Nej. En ROA stöder främst ursprungsgodkännande. Den validerar inte varje del av BGP-vägen, förhindrar inte alla route leaks, krypterar inte trafik eller garanterar att trafiken följer en säker fysisk väg.
En Route Origin Authorization (ROA) är en central komponent i RPKI, som etablerar ett kryptografiskt signerat samband mellan ett IP-prefix och det ASN som har behörighet att originera detta prefix i BGP. Posten innehåller normalt sett prefixet, origo-ASN:t samt ett maximalt prefixlängd – var och en av dessa spelar en avgörande roll för att identifiera resursen, tillåta origot och definiera hur specifikt annonsen får vara. Korrekt utformade ROAs hjälper nätverk att identifiera obehöriga eller felkonfigurerade annonsningar, vilket visar sig vara livsviktigt vid IPv4-transferingar, ASN-ändringar, leverantörsbyten, IPv6-implementeringar och drift av flervägsanslutna nätverk. Samtidigt är en ROA inte bevis på juridisk äganderätt och fungerar inte som en fristående lösning för ruttningssäkerhet; den ger bäst resultat när den används tillsammans med korrekta registerposter, disciplinerade BGP-konfigurationer, IRR-data, ruttkontroll och dokumenterade ändringsprocesser. För alla organisationer som annonserar offentligt IPv4- eller IPv6-adressutrymme gäller den enkla praktiska regeln: publicera endast de origon du avser att använda, auktorisera endast de prefixlängder du faktiskt planerar att annonsera, och granska posterna varje gång nätverket ändras. Detta håller RPKI-datan i linje med den verkliga routningsmiljön och minskar risken för att en legitim rutt klassificeras som ogiltig (Invalid).