Vad borde egentligen ett VPN-utgångsadressregister registrera?
Ett utgångsregister är bara användbart om varje post anger sin betydelse, sin utgivare och sitt utgångsdatum. Klassificering är inte abonnentidentifiering.
Utgångsregister låter som listor, och listan är inte den svåra delen. Den svåra delen är att avgöra vad varje post hävdar, vem som får publicera den och vad som händer när påståendet inte längre är sant. Tre olika adressroller blandas ihop i dessa förslag, och ett register som blandar dem kan inte svara på någon fråga pålitligt. Följ en post från publicering till återkallelse och designkraven dyker upp av sig själva.
Börja med posten, inte med listan
Den första frågan är inte hur många adresser som ska ingå, utan vad en enda rad betyder. Beskriver den var klienter ansluter, vilken källa en destination kan se, eller vem som har en tilldelning i ett register? Det är tre påståenden med tre ägare och tre fellägen. Ett register som inte anger vilken av dem det registrerar kan inte valideras, korrigeras eller löpa ut. Att få betydelsen rätt är designarbetet, och listan är bara utdata.
Skriv raddefinitionen innan du skriver något schema. Om definitionen behöver ordet och är det förmodligen två poster som låtsas vara en.
Tre adressroller som ser likadana ut
Rollerna är lätta att förväxla eftersom en distribution kan använda alla tre samtidigt, och ofta gör det. En tjänst kan avsluta anslutningar på en adress och vidarebefordra trafik från en annan, medan ett register registrerar ett helt tredje faktum.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Ett hostingblock kan innehålla VPN-utgångar och orelaterade arbetsbelastningar sida vid sida, så en registerträff säger ingenting om vad en viss adress gör vid en viss tidpunkt. En post som inte namnger sin roll är inte bevis för något särskilt. Det är namngivningen av rollen som gör posten falsifierbar. Ange också adressfamiljen, för ett register som tyst bara täcker IPv4 kommer att vilseleda alla som antar motsatsen.
Följ en post från publicering till återkallelse
Ta en hypotetisk utgång och följ den. En operatör publicerar prefixet och sin roll vid en angiven ikraftträdandetid, konsumenter hämtar den, och senare slutar adressen att fungera som utgång. Varje steg behöver en regel: vem som får publicera, vad prefixet faktiskt täcker, när posten träder i kraft och hur den återkallas. Ett flöde utan återkallelseväg samlar inaktuella påståenden som ingen kan skilja från aktuella.
Skilj befogenheten att publicera från etikettens noggrannhet. En registerpost som kopplar en organisation till en resurs bevisar tilldelningen och inte den nuvarande användningen, och det är olika påståenden med olika bevis. Konsumenterna måste veta vilken av de två de litar på.
Definiera också rättelse. En adress som tilldelas en kund på nytt, eller en orelaterad tjänst som fångas av en felaktig etikett, behöver en dokumenterad väg till en rättelse i stället för en diskussion i en biljettkö. Återkallelseutlösaren hör hemma i samma dokument som publiceringsregeln.
Vad ett publicerat flöde kan och inte kan stödja
Publicerade prefixattribut är ett etablerat mönster, och de befintliga exemplen beskriver geografi eller ägarskap snarare än beteende. Ett VPN-flöde skulle behöva sin egen semantik, sina egna bevisregler och sin egen granskningsprocess, och att byta namn på en landslista ger inget av det. ARIN-registerhandledningen visar vad tilldelningsposter hävdar och inte hävdar, och ett nytt flöde måste vinna samma klarhet om sina egna påståenden. Det är en specifikationsuppgift, inte en ometiketteringsuppgift.
Det ett sådant flöde kan stödja är ett klassificeringsbeslut om en nätverkskälla. Det det inte kan är att identifiera en person bakom en delad adress, bevisa att all trafik från den adressen är tunnlad, eller avgöra om en viss begäran är missbruk. Det är tre separata frågor med tre separata beviskrav.
Håll den juridiska frågan utanför specifikationen
En teknisk specifikation kan inte avgöra om ett föreslaget registreringskrav är lagligt, proportionellt eller klokt. Den bedömningen behöver den faktiska lagtexten, de berörda rättigheterna, jurisdiktionen och en juridisk analys som ett dataformat inte kan leverera. Ett format kan vara väl utformat och ändå stödja en dålig politik.
Det specifikationen kan göra är att göra debatten konkret. Definiera först de föreslagna uppgifterna, deras gränser och fellägen, så att det politiska argumentet handlar om en verklig mekanism i stället för en odefinierad lista som varje deltagare föreställer sig olika. Det är det mesta ett tekniskt dokument kan bidra med till en juridisk fråga.