JungleLabs Insights

Vad är RIPE-databasen och varför är den viktig?

Artikel

Vad är RIPE-databasen?

RIPE-databasen är en offentlig registerdatabas som lagrar information om internetnummerresurser och relaterade tekniska objekt. Den drivs av RIPE NCC, det regionala internetregistret som betjänar Europa, Mellanöstern och delar av Centralasien. Dess syfte är att bidra till att upprätthålla transparens, ansvarsskyldighet och teknisk samordning över det offentliga internet.Databasen innehåller poster för IPv4- och IPv6-adressutrymme, ASN:er, organisationer, nätverkskontakter, routningspolicyer, ruttutannonseringar, omvända DNS-delegeringar, säkerhetskontakter och annan teknisk information. Dessa poster är ordnade som strukturerade objekt. Varje objekt har en typ, en unik nyckel eller identifierare, en uppsättning attribut och en eller flera underhållsansvariga som styr vem som får uppdatera det.

Till exempel kan en IPv4-adresstilldelning representeras av en inetnum object. An IPv6 allocation may be represented by an inet6num objekt. Ett ASN representeras vanligtvis av ett aut-num objekt. En BGP-routningspolicy kan representeras av en ruttning object for IPv4 or a route6 object for IPv6. A company itself may be represented by an organisation objekt, medan en teknisk kontakt kan representeras genom en person eller roll objekt.Dessa objekt är kopplade till varandra. Ett IP-adressblock kan hänvisa till ett organisationsobjekt. Organisationsobjektet kan vara kopplat till administrativa och tekniska kontakter. Ett route-objekt kan länka ett IP-prefix till ett ASN. Ett maintainer-objekt kan definiera vem som har behörighet att ändra posten. Denna länkade struktur är det som gör RIPE Database användbar för både teknisk drift och resursadministration.

Det är viktigt att förstå att RIPE Database är ett register- och samordningssystem, inte ett enkelt ägarintyg. En offentlig registrering kan visa vilken organisation som ansvarar för en resurs eller vilken enhet som är registrerad som slutanvändare, men den juridiska, avtalsmässiga och policyrelaterade kontexten kan vara mer komplex. Företag bör inte enbart förlita sig på en databassökning vid genomförandet av en IPv4-överföring av högt värde, ett förvärv, en tvistgranskning eller en omfattande due diligence-process. I sådana situationer är databasen en viktig beviskälla, men den bör granskas tillsammans med aktuella registerförfaranden, avtalsdokumentation och professionell rådgivning när så är lämpligt.

RIPE NCC, RIPE-gemenskapen och RIPE-databasen

Termerna ”RIPE”, ”RIPE NCC” och ”RIPE Database” används ofta tillsammans, men de betyder inte exakt samma sak. RIPE hänvisar till den bredare gemenskapen av nätoperatörer, internetleverantörer, tekniska specialister och andra intressenter som deltar i utvecklingen och samordningen av internetverksamhet i regionen. RIPE NCC, eller Réseaux IP Européens Network Coordination Centre, är den organisation som tillhandahåller register- och samordningstjänster, inklusive drift av RIPE Database.

RIPE NCC är ett av världens fem regionala internetregister. De fyra andra är ARIN för USA, Kanada och delar av Karibien och Nordatlanten; APNIC för Asien och Stillahavsområdet; LACNIC för Latinamerika och stora delar av Karibien; samt AFRINIC för Afrika och regionen kring Indiska oceanen. Varje RIR hanterar internetnummerresurser inom sin tjänsteregion enligt policyer som utvecklas genom gemenskapsprocesser.RIPE-databasen är därför ett centralt operativt verktyg för RIPE NCC-regionen. Ett företag som till exempel får ett ASN genom en RIPE NCC-sponsrande LIR kan få information införd i eller uppdaterad i RIPE-databasen som en del av registreringsprocessen. Företaget kan senare behöva underhålla organisationsposter, tekniska kontaktpersoner, ruttobjekt, RPKI-auktoriseringar, information om missbrukskontakter och BGP-relaterade data.

För nätoperatörer stöder databasen dagliga operativa beslut. En transitoperatör kan använda data om ruttobjekt när prefixfilter byggs. En säkerhetsanalytiker kan använda databasen för att identifiera en relevant abuse-kontakt. Ett företag kan söka efter ett ASN innan det inleder en peering- eller tjänsterelation. Ett datacenter kan kontrollera adressregistreringsposter under en granskning av en IP-överföring. En ingenjör som felsöker ett ruttannonserande kan jämföra IP-prefixet, ursprungs-ASN:et, ruttobjektet, RPKI-statusen och kraven från uppströmsleverantören.

Varför RIPE-databasen är viktig för företag

RIPE-databasen är viktig eftersom internetinfrastruktur behöver offentlig ansvarsskyldighet. När ett företag hanterar ett IP-prefix eller ett ASN behöver andra nätverk ett tillförlitligt sätt att fastställa vem som ansvarar för den resursen. Detta är särskilt viktigt vid en routingincident, DDoS-attack, spamklagomål, missbruksrapport, misstänkt trafikmönster, BGP-kapning, anslutningsfel eller säkerhetsutredning.

En välunderhållen post i RIPE Database kan göra det enklare att identifiera och kontakta ett företag. Den kan också minska friktionen i samarbetet med uppströmsleverantörer av transit, Internet Exchange Points, partner för molnanslutning, leverantörer av DDoS-begränsning och andra nätoperatörer. Om en organisations poster är ofullständiga, felaktiga eller inaktuella kan den drabbas av förseningar när den försöker annonsera prefix, validera BGP-routing, bevisa kontroll över resurser, uppdatera kontaktuppgifter eller hantera en incident.

Databasen är också viktig för rykteshantering. Offentliga IP-adresser kan bygga upp ett rykte baserat på sin historiska användning. En hostingleverantör, VPN-operatör, e-postplattform, molnföretag eller proxytjänst kan behöva visa att den har en legitim organisationsstruktur, en fungerande abusekontakt, tydliga tekniska kontaktpersoner och korrekt underhållna routingposter. Även om en post i RIPE Database inte garanterar ett gott rykte kan den bidra till en mer transparent och professionell nätverksnärvaro.För organisationer som använder BGP är korrekta route-objekt och RPKI-poster särskilt värdefulla. Många upstream-leverantörer använder information från routingregister för att skapa prefixfilter. Om ett nätverk annonserar ett prefix men inte har ett lämpligt route-objekt eller en ruttauktorisering kan leverantören avvisa rutten. Detta kan leda till avbrott, försenad onboarding eller ofullständig global nåbarhet.

RIPE-databasen stöder också intern styrning. Ett företag kan ha flera personer involverade i nätverksdrift, efterlevnad, juridisk hantering, fakturering, hantering av missbruk och underhåll av infrastrukturen. Tydliga objektrelationer och underhållarkontroller kan hjälpa företaget att definiera vem som får uppdatera vilka poster. Detta minskar risken för att tidigare anställda, tredjepartskonsulter eller obehöriga parter behåller kontrollen över kritiska poster för internetresurser.

Viktiga objekttyper i RIPE-databasen

RIPE-databasen innehåller många olika objekttyper. Vissa används främst av registeradministratörer, medan andra används regelbundet av nätverkstekniker och IP-resurshanterare. De viktigaste objekten för ett typiskt företag som använder offentligt IP-utrymme och ett ASN är organisationsobjektet, IP-adressobjektet, ASN-objektet, kontaktobjektet, underhållarobjektet och ruttobjektet.

An organisation objekt representerar en juridisk person, en resursinnehavare, en slutanvändare eller en annan erkänd organisation som är involverad i registreringen av internetnummerresurser. Det kan innehålla organisationens namn, typ, adressreferenser, kontaktreferenser och information om underhållare. Detta objekt hjälper till att koppla IP-adressintervall och ASN:er till en ansvarig organisation.

An inetnum objekt representerar ett IPv4-adressintervall. Det kan innehålla själva intervallet, ett beskrivande namn, en organisationsreferens, administrativa och tekniska kontakter, statusinformation, referenser till missbrukskontakter och underhållskontroller. Ett inet6num object performs a similar function for IPv6 address space. These records are critical because they identify the network operator or organization associated with an address block.

An aut-num objektet representerar ett autonomt systemnummer. Det kan innehålla ASN-numret, den organisation som ansvarar för det, information om routingpolicy, referenser till import- och exportpolicyer, tekniska kontaktpersoner och information om underhållsansvarig. Ett företag som använder BGP bör säkerställa att dess ASN-relaterade data är korrekta eftersom denna post är en del av det offentliga sammanhanget kring nätverkets routingidentitet.

A person objekt identifierar en enskild kontakt, medan en roll objekt identifierar en funktionell kontakt såsom ”Network Operations Center”, ”Abuse Department”, ”Technical Support” eller ”IP Resource Administration”. I många fall är rollobjekt mer praktiska än personliga kontakter eftersom de förblir giltiga även när anställda byts ut. Ett välskött företag använder ofta funktionella rolladresser för nätverksdrift och hantering av missbruk i stället för att helt förlita sig på en enskild anställds personuppgifter.

A mntner objekt, en förkortning för maintainer-objekt, är en av de viktigaste säkerhetskontrollerna i RIPE-databasen. Det anger autentiserings- och auktoriseringskrav för ändring av relaterade objekt. Om en maintainer inte är korrekt konfigurerad kan företaget förlora möjligheten att uppdatera sina databasposter eller utsätta sig för obehöriga ändringsförsök. Maintainer-autentiseringsuppgifter, lösenord, API-uppgifter och auktoriseringsprocedurer bör hanteras noggrant och aldrig exponeras i offentlig källkod, skript på klientsidan eller osäkrad dokumentation.

A ruttning object documents the relationship between an IPv4 prefix and an origin ASN. A route6 objekt tillhandahåller motsvarande post för ett IPv6-prefix. Till exempel kan ett ruttobjekt ange att 203.0.113.0/24 är avsett att tillkännages av AS64500. Dessa objekt används vanligtvis av leverantörer och peeringpartners när de bygger ruttfilter. Ett ruttobjekt är inte samma sak som en aktiv BGP-annonsering, men det är en viktig deklaration av routningsavsikt.

Så här söker du i RIPE-databasen

RIPE-databasen kan sökas via dess webbgränssnitt, WHOIS-liknande frågeverktyg och REST API. Vilken metod som väljs beror på användarens syfte. En affärsansvarig kan föredra webbgränssnittet eftersom det är lätt att läsa. En nätverksingenjör kan använda kommandoradsfrågor eller REST API för automatisering. Ett säkerhetsteam kan använda en kombination av databassökningar, RPKI-valideringsverktyg, BGP-övervakningsplattformar och interna system för incidenthantering.

En grundläggande IP-sökning kan visa registreringsinformationen som är kopplad till ett offentligt IPv4- eller IPv6-adressintervall. Om en användare söker efter en IP-adress kan databasen returnera ett objekt för adressintervallet som innehåller det allokerade eller tilldelade intervallet, nätverksnamn, landskod, organisationsreferens, tekniska kontaktpersoner, referenser till missbrukskontakter och information om underhållsansvarig. Beroende på objektet och tillämpliga integritetsregler kan vissa kontaktuppgifter vara maskerade eller begränsade.

En ASN-sökning kan visa aut-num objekt som är associerat med ett nätverk. Detta kan omfatta själva ASN:et, en beskrivning, relevanta organisationsreferenser, tekniska kontaktuppgifter, information om routningspolicy och uppgifter om underhållsansvarig. En ASN-post kan vara användbar när man undersöker ett nätverks routningsidentitet eller förbereder en BGP-relation.

En ruttuppslagning kan hjälpa till att fastställa om ett prefix är dokumenterat som annonserat av ett visst ASN. Detta är användbart när en uppströmsleverantör begär ett ruttobjekt innan den accepterar en BGP-annonsering. Det kan också hjälpa ingenjörer att diagnostisera varför ett prefix filtreras bort, avvisas eller behandlas som oväntat.

Användare bör dock förstå datans begränsningar. Ett ruttobjekt bevisar inte att rutten för närvarande är synlig på det globala internet. Det bevisar inte att alla leverantörer accepterar rutten. Det ersätter inte heller RPKI-validering. För att förstå den aktuella routningssynligheten kan användaren behöva konsultera BGP-övervakningssystem, ruttinsamlare, leverantörers looking glass-tjänster, RPKI-validerare eller plattformar för routningsinformation.

På samma sätt kan en IP-adresspost visa en registrerad organisation, men den avslöjar inte nödvändigtvis alla företag som använder tjänster bakom den adressen. Webbhotellsleverantörer, molnplattformar, VPN-tjänster och återförsäljare kan driva infrastruktur för många kunder med hjälp av ett delat eller delegerat block.

TEKNISK HANDLEDNING

Så här använder du RIPE-databasens REST API

Lär dig REST-URI-formatet, objektnycklar, säkra skrivskyddade uppslagningar, autentiserade uppdateringar, validering i torrkörningsläge, svarsformat och operativa skyddsåtgärder.

RIPE Database REST API ger programmatisk åtkomst till RIPE Database-objekt via HTTPS. Den är användbar för tillgångsinventeringar, nätverkshanteringsverktyg, interna portaler, övervakningsarbetsflöden och kontrollerad resurshantering. Varje RIPE Database-objekt har en unik lokaliserings-URI, så en applikation kan hämta eller hantera ett specifikt objekt när den känner till databasens källa, objekttypen och primärnyckeln.

1 Förstå REST-URI-formatet

Standardformatet för objekt-URI är https://rest.db.ripe.net/source/objecttype/key. Den källa identifierar databaskällan, såsom RIPE för produktionsdata eller TEST när testmiljön används. Den objekttyp identifierar RIPE Database-objektet, såsom inetnum, inet6num, aut-num, person, roll, mntner, ruttning, eller route6. Den nyckel är objektets primära identifierare.

URI-mönster https://rest.db.ripe.net/source/objecttype/key

De flesta objekttyper använder ett primärnyckelvärde. Person- och rollobjekt använder det nic-hdl värdet som deras nyckel. Route- och route6-objekt använder en kombinerad nyckel: route-prefixet följt omedelbart av ursprungs-ASN:et. Till exempel, ett route-objekt för prefix 193.0.22.0/23 har sitt ursprung i AS3333 använder den kombinerade nyckeln 193.0.22.0/23AS3333. Använd URL-kodning där det krävs när en nyckel innehåller tecken som snedstreck, mellanslag eller andra reserverade URL-tecken.

Produktionsmiljö https://rest.db.ripe.net

Använd denna slutpunkt för RIPE Database-objekt i realtid och auktoriserade produktionsuppdateringar.

Testmiljö https://rest-test.db.ripe.net

Använd denna slutpunkt för att öva på förfrågningar och validera integrationslogik utan att ändra produktionsdata.

2 Börja med en skrivskyddad objektsökning

Skrivskyddad hämtning är den säkraste startpunkten för en integration. Följande kommando begär den offentliga aut-num objekt för exempel-ASN AS3333 och ber API:t att returnera JSON. Ersätt endast exempel-ASN:et med ett riktigt offentligt ASN som du har tillåtelse att fråga. Detta kommando skapar, ändrar eller tar inte bort något databasobjekt.

curl -H "Accept: application/json" \
  "https://rest.db.ripe.net/ripe/aut-num/AS3333.json"

Du kan begära XML genom att använda Acceptera: application/xml eller genom att använda en .xml tillägg. JSON kan begäras med Acceptera: application/json eller en .json tillägg. Om svarsformatet inte anges använder API:t XML som standard. Applikationer bör uttryckligen begära sitt föredragna format så att parsningens beteende förblir förutsägbart.

3 Sök efter data när du inte känner till den exakta objektnyckeln

En sökförfrågan är användbar när du har ett ASN, en IP-adress, ett prefix, en organisationsidentifierare eller ett annat sökvärde, men ännu inte känner till den exakta objekt-URI:n. Exemplet nedan söker i RIPE-källan efter poster relaterade till AS3333. Den flags=ej-refererad Parametern efterfrågar ett strömlinjeformat svar som inte inkluderar refererade objekt.

curl --get "https://rest.db.ripe.net/search.json" \
  --data-urlencode "query-string=AS3333" \
  --data-urlencode "source=ripe" \
  --data-urlencode "flags=no-referenced"

För en routinguppslagning, begränsa svaret efter objekttyp. Följande exempel söker efter IPv4 ruttning objekt associerade med dokumentationsprefixet 203.0.113.0/24. Ett route-objekt dokumenterar avsedd routinginformation; det bör bedömas tillsammans med aktuell BGP-synlighet och RPKI-status innan ett routingbeslut fattas.

curl --get "https://rest.db.ripe.net/search.json" \
  --data-urlencode "query-string=203.0.113.0/24" \
  --data-urlencode "type-filter=route" \
  --data-urlencode "source=ripe"۔

4 Använd endast POST, PUT och DELETE med korrekt auktorisering

REST API:et har stöd för INLÄGG för att skapa ett objekt, PUT för att uppdatera ett befintligt objekt, och RADERA för att ta bort ett objekt. Dessa operationer kräver HTTPS, korrekt auktorisering och en giltig begärandekropp eller ett giltigt målobjekt. Begärandekroppen för skapande eller uppdatering av objekt är en WhoisResource-representation av objektet. För POST-, PUT- och DELETE-begäranden anger du lämpliga Innehållstyp och Acceptera rubriker. Objektrepresentationer som stöds omfattar application/json och application/xml.

INLÄGG

Skapa ett objekt

Använd POST /{source}/{objecttype} för att skapa ett nytt objekt. En lyckad begäran returnerar det nyskapade, ofiltrerade objektet.

PUT

Uppdatera ett objekt

Använd PUT /{source}/{objecttype}/{key} att lämna in en ny version av ett befintligt objekt.

RADERA

Ta bort ett objekt

Använd RADERA /{source}/{objecttype}/{key} endast när objektet inte längre behövs och radering har godkänts.

Placera inte en API-nyckel, ett värde för Basic Authentication, ett certifikat, ett lösenord eller en autentiseringsuppgift för en underhållare i WordPress-HTML, JavaScript på klientsidan, ett offentligt Git-repositorium, en skärmbild eller ett e-postmeddelande. Autentiserade förfrågningar hör hemma i en säkrad tjänst på serversidan, en kontrollerad automatiseringskörning eller en professionell miljö för hantering av hemligheter.

5 Validera ändringar först med torrkörning

Använd de dry-run=true frågeparameter för att validera en föreslagen POST-, PUT- eller DELETE-begäran utan att genomföra uppdateringen. Detta är det rekommenderade sättet att testa begärans struktur, objektinnehåll och auktoriseringsbeteende innan någon ändring i produktionen görs. Exemplet nedan är avsiktligt riktat mot testslutpunkten och använder platshållarvärden. Det får endast anpassas av en auktoriserad administratör som arbetar med ett giltigt testobjekt och säkra autentiseringsuppgifter.

curl -X PUT \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  --data @object.json \
  "https://rest-test.db.ripe.net/test/person/EXAMPLE-TEST?dry-run=true"

Det valfria oformaterad parametern kan användas när en applikation behöver bevara den formatering som anges i begäran, inklusive blanksteg och radbrytningar. För borttagningsbegäranden, den valfria anledning parametern kan anges för att dokumentera varför objektet tas bort. En torrkörning validerar begäran men skapar, uppdaterar eller tar inte bort målobjektet.

6 Tolka HTTP-statuskoder och API-svar

Klientapplikationer bör använda HTTP-statuskoder för att fastställa resultatet av en åtgärd och bör läsa svarstexten när ett fel inträffar. Svarstexten returneras i det begärda JSON- eller XML-formatet. Ett lyckat uppdateringssvar innehåller objektet så som det ser ut i databasen efter åtgärden, vilket är användbart när en applikation behöver en omedelbar bekräftelse av det lagrade resultatet.

200Lyckad begäran eller uppdatering.
400Felaktig begäran, till exempel en ogiltig objekttyp eller nyckel.
401Autentisering misslyckades eller nödvändiga inloggningsuppgifter angavs inte.
403 / 429Begäran avvisades eller så överskreds en frågegräns.
404Det begärda objektet eller sökresultatet hittades inte.
409En integritetsbegränsning överträddes, till exempel genom att skapa ett befintligt objekt.
415Medietypen för Accept eller Content-Type saknas eller stöds inte.
500Tjänsten stötte på ett oväntat internt tillstånd.

7 Plan för kodning och uppdateringsfördröjning

REST API-svar returneras i UTF-8. RIPE-databasobjekt lagras med teckenuppsättningen Latin-1, så begärans innehåll bör använda UTF-8 samtidigt som det förblir inom giltiga Latin-1-tecken. Om ett tecken som inte stöds behöver konverteras kan tjänsten ersätta det med ett frågetecken och returnera en varning. Efter en skrivåtgärd utför du en uppföljande fråga eller förlitar dig på det lyckade ändringssvar för att bekräfta vad som lagrades.

Databasuppdateringar kanske inte syns omedelbart i uppslags- och sökoperationer. Den dokumenterade maximala fördröjningen kan vara upp till tio sekunder. Icke-hierarkiska objekt, såsom person-, roll- och organisationsobjekt, blir ofta synliga snabbare. Hierarkiska objekttyper, inklusive inetnum-, inet6num-, route-, route6- och domänobjekt, kan ta flera sekunder innan de visas i efterföljande sökningar. Automatisering i produktion bör därför inkludera återförsökslogik och bör inte behandla ett omedelbart misslyckat uppslag som bevis på att en lyckad uppdatering misslyckades.

Hur route-objekt i RIPE-databasen stöder BGP-filtrering

BGP är det routningsprotokoll som gör det möjligt för autonoma system att utbyta information om nåbarhet över internet. När ett företag annonserar ett IPv4- eller IPv6-prefix måste dess uppströmsleverantör besluta om den ska acceptera den rutten. För att minska risken för routeläckor, prefixkapning, oavsiktliga annonseringar och policyöverträdelser använder många leverantörer routningsfilter.

Ett ruttobjekt är en av de indata som kan stödja denna filtreringsprocess. Objektet anger att ett visst prefix är avsett att ha sitt ursprung i ett visst ASN. Om ett företag driver AS64500 och meddelar 203.0.113.0/24, ett route-objekt kan dokumentera den relationen. En leverantör kan använda route-objektet när den bygger ett prefixfilter som tillåter ASN:et att endast annonsera det förväntade prefixet.Detta innebär inte att alla leverantörer använder samma filtreringspolicy. Vissa leverantörer använder IRR-routeobjekt i stor utsträckning. Andra förlitar sig mer på RPKI. Många använder en kombination av RPKI, IRR-data, interna policyregler, kundavtal, prefixgränser och manuell granskning. Därför bör ett företag inte anta att skapandet av ett route-objekt automatiskt garanterar att routen accepteras överallt.Det bästa operativa tillvägagångssättet är att samordna med upstream-leverantören före annonseringen. Företaget bör bekräfta vilka prefix som kommer att annonseras, vilket ASN som kommer att origina dem, huruvida leverantören kräver IRR-routeobjekt, huruvida RPKI ROA:er krävs, vilken maximal prefixlängd som är tillåten och huruvida leverantören har någon process för routeregistrering eller ärendehantering.

Ett vanligt misstag är att konfigurera BGP först och hantera ruttregistreringar senare. Detta kan leda till förseningar eftersom leverantören kan avvisa annonseringen tills registreringsuppgifterna är fullständiga. En bättre process är att förbereda ruttobjektet, skapa eller validera ROA:n, verifiera ASN- och organisationsposterna, sedan konfigurera BGP-sessionen och genomföra kontrollerade tester.

RIPE-databasen och RPKI: Liknande men olika

RIPE-databasen och RPKI är relaterade till routningssäkerhet, men de har olika funktioner. RIPE-databasen innehåller offentligt underhållen registrerings- och routningspolicyinformation. RPKI, eller Resource Public Key Infrastructure, är ett kryptografiskt ramverk som används för att skapa Route Origin Authorizations.

Ett route-objekt kan ange att ett specifikt IP-prefix är avsett att annonseras från ett specifikt ASN. En ROA ger ett ASN kryptografiskt tillstånd att annonsera ett specifikt prefix och kan även ange den maximala prefixlängd som får annonseras. Nätverk som utför RPKI-validering av routens ursprung kan använda ROA:er för att klassificera mottagna routes som giltiga, ogiltiga eller ej funna.

Till exempel kan en organisation inneha ett IPv6-prefix och använda ett ASN. Den kan skapa ett route6-objekt i RIPE-databasen för att dokumentera det avsedda ursprungs-ASN:et. Den kan också skapa en ROA som ger detta ASN tillstånd att annonsera prefixet. Route6-objektet kan underlätta IRR-baserad filtrering, medan ROA:n stöder kryptografisk validering av ruttursprung.De två bör underhållas konsekvent. Om ruttobjektet pekar på ett ASN men ROA:n auktoriserar ett annat ASN, kan uppströmsleverantörer och nätoperatörer se motstridiga signaler. Om ROA:n har en felaktig maximal prefixlängd kan legitima annonseringar av mer specifika prefix markeras som ogiltiga. Om ett ruttobjekt är inaktuellt kan en leverantör som använder IRR-baserade filter avvisa en annars legitim annonsering.

Organisationer bör granska sina route-objekt och ROA:er när de ändrar sina ASN-upplägg, byter sponsrande LIR, överför IPv4-resurser, omstrukturerar sitt företag, lägger till en ny upstream-leverantör eller ändrar sin policy för prefixannonsering. Routingposter bör behandlas som levande driftdata, inte som engångsuppgifter för konfiguration.

Med hjälp av RIPE Database REST API

RIPE Database REST API gör det möjligt för programvarusystem att hämta och, med rätt behörighet, hantera RIPE Database-objekt genom programmatiska förfrågningar. API:et kan vara användbart för organisationer som driver många nätverk, förvaltar stora portföljer av IP-resurser, kör övervakningssystem, bygger kundportaler eller behöver integrera registerdata i interna arbetsflöden.

Ett enkelt REST API-arbetsflöde kan börja med en sökförfrågan. Systemet skickar en fråga efter ett ASN, en IP-adress, ett prefix, en organisationsidentifierare, ett nätverksnamn eller något annat känt värde. Databasen returnerar strukturerade data, vanligtvis i JSON- eller XML-format. Applikationen kan sedan tolka resultatet och visa relevanta attribut för en operatör eller jämföra resultatet med interna register.

Till exempel kan en molnleverantör använda skrivskyddade API-frågor för att kontrollera om ett ASN som kunden tillhandahållit finns och om de offentliga routningsposterna överensstämmer med informationen från onboardingprocessen. Ett nätverkssäkerhetssystem kan använda API-frågor för att identifiera en registrerad missbrukskontakt för ett adressintervall. En plattform för hantering av IP-resurser kan jämföra sitt interna register med offentliga registreringsuppgifter för att identifiera föråldrade kontaktuppgifter eller saknade route-objekt.

API:t bör användas ansvarsfullt. Automatiserade system bör undvika en överdriven mängd frågor, hantera fel på ett robust sätt och inte betrakta ett enda databasresultat som fullständigt bevis på ägarskap, auktorisation eller aktuell routningsstatus. Ett robust arbetsflöde kan kombinera resultat från RIPE Database API med RPKI-validering, BGP-övervakningsdata, interna avtal, kundverifiering och manuell granskning.

För skrivskyddade förfrågningar kan ett kommandoradsverktyg som cURL vara tillräckligt. En utvecklare kan skicka en GET-förfrågan till sökändpunkten, ange ett sökvärde, tillämpa ett källfilter och begära ett JSON-svar. Svaret kan sedan tolkas i Python, PHP, JavaScript, Go, Java eller något annat programmeringsspråk som kan läsa JSON.När man arbetar med uppdateringar av objekt är risken större. Ändringar av routningsobjekt, kontakter, organisationsposter eller underhållsansvariga kan påverka produktionsroutning, incidenthantering och verksamhetskontinuitet. Skrivåtgärder kräver lämplig auktorisering genom den relevanta underhållsansvariga eller registerprocessen. Autentiseringsuppgifter måste lagras säkert på serversidan eller i ett godkänt system för hantering av hemligheter. De får aldrig bäddas in i webbplatsens HTML, JavaScript på klientsidan, offentliga kodarkiv, webbläsarens lokala lagring, skärmbilder, e-postmallar eller okrypterade konfigurationsfiler.

Ett företag bör också fastställa rutiner för förändringshantering. Innan ett ruttobjekt eller en ASN-relaterad post uppdateras bör den ansvariga ingenjören verifiera det avsedda prefixet, ursprungs-ASN:et, RPKI-statusen, kraven från uppströmsleverantören, auktoriseringsvägen och förändringens potentiella påverkan. För större organisationer kan en granskning av en annan person bidra till att förhindra oavsiktliga fel i ruttpolicyer.

RIPE-databasens datakvalitet och vanliga misstag

Datakvalitet är en av de viktigaste frågorna i RIPE Database. Ett företag kan ha legitima IP-resurser och ett aktivt ASN, men om de tillhörande objekten är föråldrade, inkonsekventa eller dåligt underhållna kan verksamheten fortfarande drabbas av tekniska och operativa problem.Ett vanligt misstag är att använda personuppgifter om enskilda anställda som den enda tekniska eller administrativa kontakten. Anställda byter roller, lämnar företag, ändrar e-postadresser eller blir otillgängliga under incidenter. Ett funktionellt rollobjekt, till exempel en kontakt för ett Network Operations Center eller en Abuse Desk, är ofta mer beständigt. Företaget kan uppdatera personerna bakom rollen utan att behöva ändra alla länkade resursobjekt.

Ett annat vanligt misstag är att inte uppdatera organisationsinformationen efter ett byte av juridiskt namn, ett förvärv, en fusion eller en företagsomstrukturering. Om den juridiska enhet som är kopplad till ett ASN eller ett IP-block ändras kan registeruppgifterna behöva granskas. Företaget bör samordna detta med sin sponsrande LIR eller registertjänsteleverantör i stället för att anta att en intern juridisk förändring automatiskt återspeglas i offentliga internetregister. Vissa organisationer skapar också route-objekt men underlåter att underhålla dem. De kan lägga till en ny upstream-leverantör, ändra ett ASN, överföra ett prefix eller ändra sin BGP-design utan att uppdatera routinguppgifterna. Detta kan skapa en diskrepans mellan den avsedda route-policyn och informationen i offentliga databaser.

Ett relaterat problem är att behandla IRR-ruttobjekt och RPKI-ROA:er som utbytbara. Det är de inte. Båda kan vara användbara, och var och en kan krävas av olika leverantörer eller valideringssystem. En modern process för routningssäkerhet bör granska båda.

Slutligen bör organisationer noggrant skydda åtkomsten till underhållsansvariga. De kontroller för underhållsansvariga som är kopplade till ett objekt kan avgöra vem som kan uppdatera det. Att förlora åtkomsten till en underhållsansvarig kan göra framtida uppdateringar svåra. Osäker delning av inloggningsuppgifter för underhållsansvariga kan skapa en oacceptabel säkerhetsrisk. Företag bör dokumentera ägarskap, lagra inloggningsuppgifter säkert och upprätthålla en tydlig intern process för återställning av åtkomst och auktoriserade ändringar.

RIPE Database, IPv4-överföringar och resursdue diligence

RIPE-databasen är särskilt relevant vid en IPv4-överföring. Innan en köpare förvärvar IPv4-adressutrymme bör denne granska de offentliga uppgifter som är kopplade till prefixet. Detta kan omfatta det aktuella adressobjektet, organisationsreferens, nätverksnamn, resursstatus, tekniska kontakter, abusekontakt, route-objekt och information om underhållaren.

Syftet är inte bara att bekräfta att prefixet finns. Köparen bör fastställa om registreringsinformationen verkar vara konsekvent, om adressblocket har befintliga ruttobjekt, om dess historiska användning kan ge upphov till anseenderelaterade farhågor och om överföringsprocessen kan hanteras korrekt genom den relevanta registerprocessen.

Till exempel kan en köpare upptäcka att ett IPv4-block har aktiva routningsobjekt kopplade till ett ASN som inte längre kommer att användas efter överföringen. Köparen kan behöva samordna borttagningen eller ersättningen av dessa poster, skapa nya routningsobjekt för sitt eget ASN och uppdatera RPKI ROA:er innan prefixet annonseras från dess nätverk.

Köparen bör också beakta e-post- och säkerhetsreputation. Ett offentligt IP-intervall kan ha använts för hosting, e-postleverans, proxytjänster, VPN-tjänster eller andra arbetsbelastningar. Om blocket har förknippats med missbruk, skräppost, skadlig kod eller misstänkt trafik kan den nya operatören behöva lägga tid på att återställa reputationen efter överföringen. RIPE Database tillhandahåller ingen fullständig reputationshistorik, men kan hjälpa till att identifiera tidigare operatörer och relevanta punkter för vidare undersökning.En professionell IPv4-överföringsprocess bör därför omfatta due diligence av registret, juridisk verifiering, teknisk planering, förberedelser för routing-säkerhet, avtalsgranskning och validering efter överföringen. RIPE Database är en värdefull grund för denna process, men bör användas tillsammans med andra informationskällor.

Hur företag bör underhålla sina RIPE-databasposter

Ett företag bör behandla underhåll av RIPE Database som ett löpande operativt ansvar. Det mest effektiva tillvägagångssättet är att tilldela ett tydligt internt ägarskap. Ett team eller en utsedd roll bör ansvara för att övervaka ändringar av företagsuppgifter, IP-resurser, ASN:er, kontakter, route objects och RPKI-poster.Företaget bör regelbundet granska sina offentliga poster. Det bör bekräfta att organisationsnamn är aktuella, att tekniska kontakter kan nås, att abuse-kontakter övervakas, att åtkomst till maintainer-kontroller finns, att route objects överensstämmer med faktiska BGP-annonseringar och att RPKI ROA:er är förenliga med routingpolicyn.

En granskning är särskilt viktig före större nätverksförändringar. Om företaget lägger till en andra transitoperatör, flyttar till ett nytt datacenter, ändrar sin BGP-arkitektur, skaffar ett nytt IPv4-block, tar emot IPv6-resurser, byter sponsrande LIR eller omstrukturerar sin juridiska person, bör registeruppgifterna granskas som en del av projektplanen.Företag som inte har intern expertis om internetresurser kan samarbeta med ett sponsrande LIR, en nätverkskonsult, en leverantör av hanterade tjänster eller en erfaren BGP-tekniker. Målet är inte bara att fylla i ett registerformulär. Målet är att säkerställa att juridiska uppgifter, tekniska uppgifter, routningspolicy, säkerhetskontroller och operativa processer fungerar tillsammans.

RIPE-databasen är en del av din internetinfrastruktur

RIPE-databasen är mycket mer än ett offentligt sökverktyg. Den är ett centralt register för IP-adresser, IPv6-prefix, ASN:er, routingposter, organisationer, kontakter och underhållare i RIPE NCC:s tjänsteregion. För företag som driver offentlig internetinfrastruktur kan dess poster påverka routingacceptans, incidenthantering, efterlevnad, hantering av IP-resurser och nätverksrykte.

En korrekt underhållen närvaro i RIPE Database stöder transparens och tekniskt förtroende. Den hjälper uppströmsleverantörer att förstå vilka prefix ett nätverk förväntas annonsera. Den hjälper säkerhetsteam att identifiera relevanta kontaktpersoner. Den hjälper företag att validera resurser före en IPv4-överföring. Den hjälper nätoperatörer att upprätthålla konsekvent ASN-, route-object- och RPKI-information.Företag bör använda databasen varsamt och ha dess begränsningar i åtanke. Ett databasobjekt är ingen garanti för aktuell BGP-synlighet, juridiskt ägarskap eller kvaliteten på ett rykte. Det är en viktig del av en bredare process för hantering av internetinfrastruktur. Den starkaste operativa modellen kombinerar korrekta RIPE Database-objekt med korrekt BGP-konfiguration, giltiga RPKI ROA:er, säker åtkomst till underhållare, aktuell organisationsdokumentation, tillförlitlig hantering av missbruk och löpande övervakning.

För alla företag som använder ett RIPE NCC-ASN, IPv4-resurser, IPv6-prefix eller BGP-routing bör det betraktas som ett centralt ansvar för nätverkshanteringen att upprätthålla korrekta uppgifter i RIPE-databasen.