Uppe.nu

TL;DR: BGP-peering är när två internetoperatörer utbyter trafik direkt med varandra istället för via en transit-leverantör. Eget AS-nummer är förutsättningen för att kunna delta. För svenska företag med egen infrastruktur — colocation, multi-leverantör-redundans, eget IP-utrymme — innebär peering lägre latens, billigare trafik och oberoende från en enskild ISP. Här är hur det fungerar och vad ni faktiskt behöver för att etablera det i Stockholm.

Tre sätt att skicka trafik på Internet

När er server i Stockholm pratar med en användare i Göteborg så finns det tre möjliga vägar:

Transit — den standardiserade vägen

Ni betalar en operatör (Telia, GTT, Hurricane Electric, Cogent) som åtar sig att skicka er trafik vart som helst på Internet. Pris typiskt $0,5–1,5/Mbps/månad i Stockholm. Enkelt men dyrast.

Peering — direkt utbyte

Ni och en annan operatör (eller flera) kommer överens om att skicka trafik mellan varandra direkt, oftast utan kostnad. Funkar bara mellan operatörer som faktiskt har trafik att utbyta — t.ex. Adminor och Bahnhof, eller Adminor och Comhem.

IX (Internet Exchange) — peering i skala

Ett gemensamt nätverk där flera operatörer kopplar in sig och peering:ar med många på en gång. STHIX, SONIX, Netnod i Stockholm — alla är exempel. Ni betalar en månadsavgift för IX-anslutningen men kan peering:a med dussintals operatörer över den enda anslutningen.

Vad ger BGP-peering för svenska företag?

Lägre latens till svenska användare

Trafik mellan Comhem-användare och en server hos Adminor (Västberga eller Solna) går via STHIX direkt — ingen omväg via Frankfurt eller London. Sub-millisekund RTT istället för 8–15 ms.

Mer förutsägbar prestanda

Vid trafiktoppar är peering oberoende av transit-leverantörens kapacitet. En operatör som bara har transit är beroende av att deras transit-leverantör har överskott. Multipla peering-relationer + transit ger redundans.

Lägre trafik-kostnad

Peering är typiskt avgiftsfri (”settlement-free”). Vid stora volymer (>1 Tbps/månad) är det signifikant billigare än transit. För colocation-kunder med 100 Mbps+ kontinuerlig trafik är skillnaden märkbar.

Operationell oberoende

Multihoming — peering med flera operatörer — innebär att om en transit-länk går ner så omdirigeras trafik automatiskt via en annan. Det är BGP:s själva poäng.

Vad krävs för att peering:a?

Det är inte en plug-and-play-tjänst. Tre saker måste vara på plats:

1. Eget AS-nummer

AS = Autonomt System, ett unikt identifierat nätverk. AS51701 är Adminors. AS3301 är Telias. AS8473 är Bahnhofs. Ni måste ha eget AS-nummer för att delta i BGP-spelet.

Hur får man ett? Via en RIPE LIR (Local Internet Registry). RIPE NCC tar ~50 EUR engångsavgift för AS-tilldelning, plus löpande LIR-medlemskap (~1 700 EUR/år). Många svenska företag väljer att använda en Sponsoring LIR som hanterar AS-tilldelningen åt dem — Adminor är en sådan för cirka 30 svenska kunder.

2. Eget IP-utrymme (PI-prefix)

Ni måste ha IP-adresser att annonsera. Två varianter:

• PA-utrymme (Provider Aggregatable) — utdelat av en operatör, bara giltigt så länge ni är deras kund
• PI-utrymme (Provider Independent) — ert eget, följer med vid leverantörsbyte

För peering vill ni nästan alltid ha PI-utrymme. Det köps från RIPE NCC via en Sponsoring LIR. För IPv4 är det idag dyrt (~$50/IP eller ~$13 000 för /24) eftersom utrymmet är slut. För IPv6 är det fortfarande tillgängligt och relativt billigt.

3. Anslutning till en IX eller direkt fiber till peer

För att utbyta trafik behöver ni en fysisk länk. Två alternativ:

• IX-anslutning — fysisk fiber-port till STHIX, SONIX eller Netnod IX:en i Stockholm. Månadsavgift ~3 000–8 000 SEK beroende på portkapacitet och IX. Sedan kan ni peering:a med alla andra deltagare via den enda porten.
• PNI (Private Network Interconnect) — dedikerad fiber direkt mellan er och en specifik peer. Vanligt för stor-skaliga relationer (t.ex. CDN-noder), mindre relevant för SMB.

För colocation-kunder hos Adminor: vår 100 Gbps backbone är redan ansluten till STHIX, SONIX och KN7/Stokab. Ni ”ärver” peering-täckningen via vår AS51701 — eller etablerar egen BGP-session ovanpå er colocation-anslutning om ni har eget AS.

BGP-sessions: så här ser konfigurationen ut

När de tre förutsättningarna finns på plats är själva BGP-sessionen relativt enkel. Cisco/Juniper/Mikrotik/FRR — alla kör samma protokoll.

Exempel-konfiguration (FRR, förenklad):

router bgp 65501
  bgp router-id 192.0.2.1
  neighbor 198.51.100.1 remote-as 51701
  neighbor 198.51.100.1 description "Adminor STHIX"
  !
  address-family ipv4 unicast
   network 192.0.2.0/24
   neighbor 198.51.100.1 prefix-list MY-PREFIXES out
   neighbor 198.51.100.1 prefix-list PEER-PREFIXES in
  exit-address-family
!
ip prefix-list MY-PREFIXES seq 5 permit 192.0.2.0/24
ip prefix-list PEER-PREFIXES seq 5 permit 0.0.0.0/0 le 24

Tre viktiga säkerhetsdetaljer:

1. prefix-list out — annonsera bara prefix ni faktiskt äger, aldrig default-route. Skyddar mot att ni av misstag annonserar hela Internet (klassisk BGP leak).
2. prefix-list in — acceptera bara förväntade prefix från peer. Skyddar mot fel-annonseringar.
3. RPKI-validering — droppa invalid routes på inkommande sida. Se vår tidigare artikel om RPKI för svenska företag.

När är peering rätt val? När är det overkill?

Peering ger mest värde när:

• Ni har egen serverhårdvara i ett svenskt datacenter (colocation)
• Trafikvolymen är >100 Mbps kontinuerlig eller har spikar mot specifika svenska destinationer
• Latens-kritisk applikation: realtidsspel, finansiell handel, video-streaming, telemedicin
• Multi-leverantör-redundans är ett affärskrav
• Ni driver egen ISP, hostingverksamhet eller CDN

Peering är overkill när:

• Ni hostar primärt på publik cloud (AWS/Azure/GCP) — leverantörens egen peering räcker
• Trafikvolym <10 Mbps — kostnaden för LIR + IX överstiger besparingen
• Ni inte har nätverksingenjör som kan hantera BGP-konfiguration och felsöka
• Tjänsten kan tolerera 5–10 ms extra latens (de flesta webbapplikationer)

Vad kostar det totalt?

Grov kostnadskalkyl för en typisk svensk colocation-kund som vill peering:a själv:

Komponent	Engångs	Löpande/år
AS-nummer (via Sponsoring LIR)	~5 000 kr	~3 000 kr
IPv4 /24 PI (om behov, valfritt)	~140 000 kr	~3 000 kr
IPv6 /48 PI	~3 000 kr	~1 000 kr
STHIX-anslutning 1G	~5 000 kr	~36 000 kr
Cross-connect colocation → STHIX	~3 000 kr	~12 000 kr
Totalt år 1	~210 000 kr
Totalt löpande/år	~55 000 kr

För Quarter Rack och uppåt hos Adminor ingår BGP-session via vårt AS51701 — ni behöver inget eget AS-nummer för att få peering-effekten. Det är ”BGP-as-a-service” och passar 90 % av användarna.

Vanliga frågor

Måste jag ha eget AS-nummer för att hosta hos Adminor?
Nej. De allra flesta kunder kör under vårt AS51701 och får automatisk peering-täckning. Eget AS-nummer är relevant för er som driftar egen ISP-verksamhet eller behöver multihoming över flera oberoende leverantörer.

Kan jag ha eget AS-nummer utan att vara LIR själv?
Ja, via en Sponsoring LIR (Adminor är en). Vi tar AS-tilldelning, hanterar uppdateringar i RIPE Database, utfärdar LOA och signerar ROA. Ni behöver inte vara RIPE-medlem själva.

Vad är skillnaden mellan peering och multihoming?
Multihoming är att ha flera oberoende uppströmsleverantörer för redundans. Peering är att utbyta trafik direkt med en specifik peer. Det är två separata beslut — ni kan vara multihomed via transit utan att peering:a, eller peering:a utan att vara multihomed.

Hur lång tid tar det att etablera eget AS?
Med en Sponsoring LIR: typiskt 2–4 veckor från beställning till färdig BGP-session. RIPE-processen tar 1–2 veckor, IX-anslutning kan ta längre vid kapacitetsbrist på IX:en.

Behöver jag IPv4 eller räcker IPv6?
Tekniskt räcker IPv6, men ~30 % av Internet är fortfarande IPv4-only. Om er tjänst ska nås av en bred publik behöver ni minst lite IPv4 (även om det är via NAT64 eller dual-stack).

Sammanfattning

BGP-peering är infrastrukturen för att verkligen äga sin närvaro på Internet — istället för att hyra access via en operatör. Eget AS-nummer är förutsättningen, peering över IX är vanligaste utförandet, multihoming är logisk följd för redundans. För svenska företag i Stockholm är STHIX/SONIX/KN7-täckning väletablerad och kostnaden överkomlig vid rätt skala.

Adminor är RIPE LIR och Sponsoring LIR för svenska företag som vill etablera eget AS-nummer eller PI-prefix utan att själva bli RIPE-medlemmar. Vår 100 Gbps backbone är ansluten till STHIX, SONIX och KN7/Stokab — colocation-kunder från Quarter Rack och uppåt får BGP-sessioner inkluderade. Mer information på Colocation Stockholm och IP Registry.

---

Frågor om BGP-peering, eget AS-nummer eller IP-utrymme? Kontakta Adminor — vi är RIPE LIR med AS51701 och hanterar BGP-frågor för svenska företag.

TL;DR: Schrems II-domen (CJEU C-311/18, juli 2020) ogiltigförklarade Privacy Shield och slog fast att data i USA inte har likvärdigt skydd som inom EU. Den centrala konsekvensen: en EU-baserad cloud-leverantör med amerikanskt moderbolag — AWS, Microsoft Azure, Google Cloud — kan tvingas lämna ut data till US-myndigheter via CLOUD Act eller FISA 702, även om hårdvaran står i Frankfurt eller Stockholm. SCC (Standard Contractual Clauses) löser inte problemet automatiskt. För svenska företag som hostar känslig data är moderbolagsjurisdiktion en separat faktor från fysisk dataplats.

Vad är Schrems II — kort

Max Schrems, österrikisk jurist och dataskyddsaktivist, drev sedan 2013 mål mot Facebooks dataöverföringar från EU till USA. Schrems I (2015) ogiltigförklarade Safe Harbor-avtalet. Schrems II (juli 2020) ogiltigförklarade dess efterföljare Privacy Shield. EU-domstolen slog fast att amerikansk lag — specifikt FISA Section 702 och Executive Order 12333 — ger US-myndigheter bred åtkomst till data hos amerikanska tjänsteleverantörer utan EU-likvärdig rättssäkerhet.

Konsekvensen: överföring av personuppgifter från EU till USA kräver ytterligare skyddsåtgärder utöver SCC, och i många fall är dessa praktiskt omöjliga att uppfylla.

CLOUD Act — den parallella historien

Clarifying Lawful Overseas Use of Data Act (USA, 2018) klarlägger att amerikanska brottsutredande myndigheter kan kräva data från amerikanska tjänsteleverantörer oavsett var data fysiskt lagras. AWS i Frankfurt, Microsoft Azure i Stockholm, Google Cloud i Belgien — alla omfattas av CLOUD Act eftersom moderbolagen är amerikanska.

Det här är skilt från Schrems II men förstärker problemet. Schrems II handlar om överföringar; CLOUD Act handlar om åtkomst till data som aldrig ”lämnar” EU.

Vad händer i praktiken vid en CLOUD Act-begäran?

Tre scenarier som faktiskt har inträffat eller är dokumenterade:

Scenario 1: Konkreta brottsutredningar

FBI eller DOJ kräver data från ett US-bolag som driver EU-datacenter. Bolaget kan välja att:

• Lämna ut data direkt — i strid med GDPR men i enlighet med amerikansk lag
• Bestrida via egen jurist (sällan framgångsrikt, dyrt)
• Försöka få MLAT-process (mutual legal assistance treaty) — saktar ner men löser sällan principfrågan

Microsoft tappade sitt eget ”Microsoft Ireland”-fall (2018) som föranledde CLOUD Act från början. Sedan dess har juridiska invändningar mot CLOUD Act-begäran i praktiken slagits ner.

Scenario 2: Bulk-program enligt FISA 702

NSA:s PRISM-program ber stora US-cloudleverantörer regelbundet om data. Antalet begäran är hemligstämplat men Googles transparency report redovisar ~70 000 FISA-baserade begäran per halvår (2024-data). Begäran specificeras med ”selector” — vanligen e-postadress, telefonnummer eller IP.

Den drabbade individen får inte veta att begäran skett. Anställda hos cloud-leverantören som hanterat begäran får inte heller berätta (gag order).

Scenario 3: ”National Security Letter” (NSL)

FBI kan utfärda NSL utan domstolskontroll, med inbyggt sekretessförbud. Mottagaren — typiskt en ISP eller cloud-leverantör — får varken bekräfta eller förneka att de fått en NSL. Det här är vad många refererar till som ”warrant canary”-mekanismens motpol.

Räcker SCC eller egen kryptering?

EU-kommissionen publicerade uppdaterade SCC (Standard Contractual Clauses) 2021 som inkluderar Schrems II-aspekter. De fungerar — men endast om mottagarlandets lagstiftning faktiskt erbjuder likvärdigt skydd. För USA är det inte fallet enligt EU-domstolen. EDPB (European Data Protection Board) har därför rekommenderat ytterligare tekniska åtgärder:

• Stark kryptering där nyckel hanteras i EU — bara om leverantören aldrig får tillgång till klartext
• Pseudonymisering före överföring — där återidentifiering kräver information som lagras i EU
• Splittrad lagring — där ingen single part har komplett dataset

Problemet: i många SaaS-tjänster (Office 365, Google Workspace, Salesforce) har leverantören tekniskt tillgång till klartext för att leverera funktioner som sök, ML, content-analys. Då fungerar inte E2E-kryptering som skyddsåtgärd.

Datainspektionen och Schrems II i Sverige

IMY (Integritetsskyddsmyndigheten, tidigare Datainspektionen) har varit relativt stillsam jämfört med franska CNIL och österrikiska DSB, men har:

• 2021 — varnat svenska skolor för Google Workspace för Utbildning (efter klagomål från flera kommuner)
• 2023 — granskat Microsoft Office 365-användning hos statliga myndigheter
• 2024 — utfärdat tillsynsbeslut mot flera svenska företag för otillräcklig SCC-implementering

EU-domstolen har i flera nyare mål (Bindl v Commission 2025) bekräftat att ”ytterligare åtgärder” är ett krav, inte en rekommendation, vid överföringar till USA.

Vad innebär det här för svenska företag?

Beroende på datatyp och regulatoriskt sammanhang:

För personuppgifter i offentlig sektor

Skolor, sjukvård, statliga myndigheter: amerikanska SaaS-tjänster för känslig data är högrisk. Flera svenska kommuner har migrerat bort från Google Workspace och Microsoft Office 365 för specifika dataset. Egna datacenter eller EU-baserade leverantörer utan US-modernbolag (t.ex. tyska Hetzner, svenska Adminor, franska OVH) är säkrare alternativ.

För B2B-företag

Risken är lägre men inte noll. Om er affärsdata innehåller personuppgifter (HR, kunder, leads), så är CLOUD Act-exponering en relevant fråga. Det gäller särskilt om ni har avtal med statliga kunder eller annan reglerad sektor — de kommer fråga.

För känslig affärsdata utan personuppgifter

Källkod, finansiell data, kunddatabaser, drug discovery, R&D, patent-relaterad data: GDPR gäller inte direkt, men FCPA, säkerhetsskydd, och industri-specifik reglering kan göra US-exponering problematisk.

Vad gör man konkret?

Tre nivåer av åtgärder:

Nivå 1: Inventering

Lista alla SaaS/cloud-tjänster ni använder och deras moderbolagsland. AWS, GCP, Azure, Salesforce, Slack, GitHub, Atlassian (Confluence/Jira), Zoom = alla US-baserade. Datadog, MongoDB Atlas, Snowflake = US. Office 365 = US.

Nivå 2: Riskbedömning per system

Inte alla data är lika känslig. För varje system: vilken datatyp, vilken regulatorisk klassning, vilka skyddsåtgärder redan på plats. Det styr om migration är nödvändig eller om SCC + extra åtgärder räcker.

Nivå 3: Migration för kritiska system

För regulatoriskt känsliga system — finansiell journaling, hälsodata, statliga uppdrag — flytta till en EU-leverantör utan US-modernbolag. Helsvensk drift (Adminor, GleSYS, Bahnhof, Glesys, Resilans) eller EU-baserad utan US-exponering (Hetzner, OVH, Scaleway).

Vanliga frågor

Räcker det att hosta i AWS Frankfurt istället för us-east-1?
Nej. Fysisk dataplats inom EU eliminerar dataöverföringsproblematiken (Schrems II) men inte CLOUD Act-exponeringen. AWS-Frankfurt-data omfattas fortfarande av amerikansk jurisdiktion via moderbolaget.

Är ”EU-only” sovereign cloud från Microsoft eller AWS lösningen?
Microsoft ”EU Data Boundary” och AWS European Sovereign Cloud (annonserad 2024) försöker hantera detta genom strikt EU-personal och separata juridiska entiteter. Inget av initiativen har än så länge bedömts som tillräckligt av EDPB, eftersom moderbolagsrelationen kvarstår.

Är svenska AWS-kunder olagliga?
Nej, inte automatiskt. Det handlar om risknivå och tillämpliga skyddsåtgärder per datatyp. Men IMY kan i vissa fall förbjuda specifika överföringar om SCC + extra åtgärder inte räcker.

Vad är skillnaden mellan Schrems II och GDPR i sig?
GDPR är grundförordningen som styr databehandling inom EU. Schrems II är ett rättsfall som tolkat hur GDPR ska tillämpas vid överföringar till tredjeland (specifikt USA). Schrems II tillför inga nya regler — det förtydligar att existerande regler är striktare än många antagit.

Hur är det med UK efter Brexit?
EU-kommissionen har 2021 utfärdat adekvansbeslut för UK (motsvarande tidigare Privacy Shield), men det är skört. Flera dataskydds­organisationer driver mål för att få det ogiltigförklarat på samma sätt som Privacy Shield. Risk-medveten praxis: behandla UK som lågre-risk-tredjeland snarare än EU.

Sammanfattning

Schrems II och CLOUD Act tillsammans innebär att amerikanska cloud-leverantörers EU-datacenter inte ger samma dataskydd som EU-baserade leverantörer utan US-moderbolag. Det är inte en teknisk fråga — det är en juridisk. Stark kryptering hjälper för storage, men SaaS-tjänster med funktionsberoenden mot klartext är problematiska.

För svenska företag som driftar känslig data — personuppgifter i offentlig sektor, finansiell data, säkerhetsklassad data — är moderbolagsjurisdiktion en separat faktor från fysisk lagringsplats. Helsvenska eller EU-baserade leverantörer utan US-exponering minskar riskprofilen utan att kräva ändringar i den underliggande tekniska arkitekturen.

Adminor är ett helägt svenskt aktiebolag utan utländsk moderbolagsjurisdiktion. Era servrar hos oss — VPS, colocation eller dedikerade — lyder enbart under svensk och EU-lag. Inga CLOUD Act-begäran kan riktas mot oss, eftersom vi inte är amerikansk jurisdiktionssubjekt. Mer information på Adminor VPS och colocation.

---

Frågor om Schrems II, GDPR-compliance eller datasuveränitet för er specifika situation? Kontakta Adminor — vi har drivit svensk IT-infrastruktur sedan 1983 och hanterar dataskydds-känsliga kunder från offentlig sektor och regulerade branscher.

TL;DR: RPKI är en signaturmekanism för BGP — själva protokollet som styr hur Internet-trafik hittar vägen mellan operatörer. Utan RPKI kan vem som helst annonsera era IP-adresser som sina egna och stjäla trafik. Med RPKI är det kryptografiskt verifierbart vem som äger vilka prefix. För svenska företag som driftar egen infrastruktur, hostar känslig data eller är beroende av nätverksupptid är RPKI-täckning idag en hygienfråga — inte ett tillval.

Det grundläggande problemet: BGP litar på rykte

BGP (Border Gateway Protocol) är det språk som alla världens internetoperatörer pratar med varandra på. När er trafik till adminor.net ska hitta vägen från Comhem hem-router till en server i Stockholm, så är det BGP-tabeller hos varje operatör som styr nästa hopp.

Problemet: i grundkonfigurationen finns ingen autentisering. Om en operatör i Pakistan eller Ryssland råkar (eller avsiktligt) annonsera ”jag äger 192.51.100.0/24”, och deras grannar accepterar det, så börjar trafik dit gå dit. Det kallas BGP hijack.

Det är inte teoretiskt. Klassiska incidenter:

• 2008 — Pakistan Telecom annonserade YouTubes IP-prefix för att blockera tjänsten inrikes. Annonsen läckte ut globalt → YouTube nere i två timmar världen över.
• 2018 — Amazon Route 53 hijackad i 2 timmar för att stjäla kryptovaluta. ~$150k flöt iväg.
• 2022 — Klayswap (sydkoreansk DEX) — BGP-hijack via KT Telekom, ~$1.9M i förluster.

Hijack-attacker kräver inget intrång hos er. Det räcker att någon på andra sidan jordklotet annonserar ert IP-utrymme — och era kunder hamnar hos dem.

RPKI: kryptografisk svar på frågan ”vem äger denna IP-adress?”

RPKI lägger ett signaturlager ovanpå BGP. Konceptuellt:

1. Resource certificate utfärdas av regionala internet-registry (RIPE NCC för Europa). Bevis att ni äger ett visst IP-prefix.
2. ROA — Route Origin Authorization — ni signerar ett uttalande: ”AS51701 får annonsera 192.51.100.0/24, ingen annan.”
3. Validerande router — operatörers BGP-routers slår upp varje inkommande annons mot ROA-databasen. Om annonsen inte matchar → den droppas eller nedprioriteras.

Resultat: om någon i Pakistan annonserar ert prefix utan att ha er signatur, så ignoreras annonsen av alla operatörer som validerar RPKI. Hijack-försöket stoppas innan det når svenska Internet.

Vem validerar RPKI i Sverige idag?

Det här är den bit många missar. Att publicera ROAs är värdelöst om ingen operatör validerar dem.

Svenska operatörer som hade RPKI-validering aktiv per 2024 (källa: NLnet Labs Routinator + MANRS):

• Telia (AS3301) — invalid-routes droppas
• Bahnhof (AS8473) — invalid-routes droppas
• GleSYS (AS42708) — validerar och droppar
• Resilans (AS25406) — validerar
• Netnod IX-route-servers — droppar invalid
• STHIX route-server — droppar invalid

Det innebär att om ert prefix har en korrekt ROA, så ignoreras hijack-försök automatiskt av de operatörer som hanterar majoriteten av svensk konsumenttrafik.

Vad behöver ett svenskt företag göra?

Det beror på hur ni hanterar IP-adresser:

Om ni använder leverantörens IP-adresser

Ni har inget eget IP-utrymme — ni hostar hos AWS, Azure, GleSYS, Bahnhof eller liknande. Då är RPKI leverantörens ansvar, inte ert. Men ni bör fråga: ”har ni ROA-täckning på era IP-prefix?” Om svaret är nej eller ”vad är det?” — det är en signal om driftmognad i övrigt.

Kontrollera er leverantör på RIPEstat → sök på prefix → fliken ”Routing” → ”RPKI Validity”.

Om ni har egna PI-prefix (Provider Independent)

Ni har eget IP-utrymme i RIPE-databasen, oftast med ett eget AS-nummer. Då är ROA ert ansvar och måste hanteras genom er Sponsoring LIR — den RIPE-medlem som administrerar ert PI-prefix.

Adminor är RIPE LIR och fungerar som Sponsoring LIR för flera svenska företag — vi hanterar ROA-publicering, LOA-utfärdanden och uppdateringar i RIPE Database när ni byter operatör. Vi signerar typiskt ROA inom 1 arbetsdag efter prefix-allokering.

Om ni har eget AS-nummer

Ni driver eget autonomt system. Då måste ni:

1. Publicera ROA för alla prefix ni annonserar
2. Köra en RPKI-validerande router (Routinator, FORT, rpki-prover)
3. Konfigurera BGP-policyn att droppa invalid

Det här är arbete för en nätverksingenjör, inte en webbutvecklare. Om ni inte har den kompetensen in-house — be er IP-leverantör om hjälp.

Vanliga frågor

Kostar RPKI något?
Nej, inte direkt. RIPE NCC tar inte separat avgift för ROA-publicering — det ingår i LIR-medlemskapet (~1 700 EUR/år). Som slutkund med PI-prefix kan ni ha en mindre årlig sponsorshipavgift.

Hur lång tid tar det innan ROA syns?
Ny ROA propagerar typiskt inom 30 minuter via RPKI-repository. Validering hos operatörer som hämtar var 10:e minut → max ~40 min innan skyddet är aktivt.

Vad händer vid felkonfigurerad ROA?
Det här är största risken. Om ni publicerar ROA som inte matchar er faktiska annonsering, så droppas er trafik av validerande operatörer. Ni ”RPKI-hijackar” er själva. Dubbelkolla MaxLength-värden och AS-nummer innan publicering.

RPKI vs BGPsec — är det samma sak?
Nej. RPKI signerar origin (vem som får annonsera). BGPsec signerar hela path (vilka mellanled trafik gick via). BGPsec finns men har minimal utbredning. RPKI är dagens standard.

Sammanfattning

RPKI är ett gratis, väletablerat skyddslager mot en specifik attack-klass — BGP hijack — som annars är osynlig för era egna säkerhetssystem. Det är inte ett kraftfullt verktyg, utan en hygienåtgärd som svenska operatörer (Telia, Bahnhof, GleSYS, STHIX-deltagarna) redan validerar mot. Om ni har eget IP-utrymme och inte har publicerat ROA, så är ni i 2026 i minoritet — och anledning till oro vid säkerhetsgranskningar.

Adminor publicerar ROA för alla kundprefix vi hanterar och fungerar som Sponsoring LIR för svenska företag som vill driva eget IP-utrymme utan att själva bli RIPE-medlemmar. Mer information på Adminor IP Registry.

---

Frågor om RPKI eller eget IP-utrymme? Kontakta Adminor — vi är RIPE LIR med AS51701 och hanterar IP-registry-frågor för flera svenska företag.