Port Control Protocol

Port Control Protocol ( PCP ) är ett datornätverksprotokoll som tillåter värdar på IPv4- eller IPv6 -nätverk att kontrollera hur de inkommande IPv4- eller IPv6 - paketen översätts och vidarebefordras av en uppströms router som utför nätverksadressöversättning (NAT) eller paketfiltrering . Genom att tillåta värdar att skapa explicita vidarebefordran av portar kan hanteringen av nätverkstrafiken enkelt konfigureras för att göra värdar placerade bakom NAT:er eller brandväggar tillgängliga från resten av Internet (så att de också kan fungera som nätverksservrar ), vilket är ett krav för många applikationer.

Dessutom tillåter explicita portvidarebefordransregler tillgängliga via PCP värdar att minska mängden genererad trafik genom att eliminera lösningar i form av utgående NAT Keepalive -meddelanden, som krävs för att upprätthålla anslutningar till servrar och för olika NAT-traversaltekniker som TCP-håltagning . Samtidigt minskar mindre genererad trafik strömförbrukningen , vilket direkt förbättrar batteritiden för mobila enheter .

PCP standardiserades 2013 som en efterföljare till NAT Port Mapping Protocol (NAT-PMP), som den delar liknande protokollkoncept och paketformat med.

I miljöer där en Universal Plug and Play Internet Gateway Device (UPnP IGD) används i det lokala nätverket, krävs en samverkansfunktion mellan UPnP IGD och PCP för att vara inbäddad i IGD. UPnP IGD-PCP Interworking Function specificeras i RFC6970.

DHCP (IPv4 och IPv6) alternativ för att konfigurera värdar med Port Control Protocol (PCP) server IP-adresser anges i RFC7291. Proceduren att följa för att välja en server bland en lista med PCP-servrar diskuteras i RFC7488.

I miljöer där NAT64 används, tillåter PCP att lära sig IPv6-prefixet som används av en PCP-kontrollerad NAT64-enhet för att bygga IPv4-konverterade IPv6-adresser av NAT64 (RFC7225).

Översikt

Många applikationer och distributioner av nätverksutrustning kräver att deras nätverksplatser kan nås utanför deras lokala nätverk , enligt den ursprungligen tänkta modellen för IP -änd-till-änd-anslutning över Internet, så att de kan fungera som nätverksservrar och acceptera anslutningar från fjärrklienter . Ett exempel på sådan utrustning är en IP-kamera , som inkluderar en nätverksserver som tillhandahåller fjärrövervakning över IP-nätverk.

Vanligtvis placerar nätverksutrustningsinstallationer enheterna bakom routrar eller brandväggar som utför NAT (för att möjliggöra delning av en IPv4-adress , till exempel) eller paketfiltrering (för förbättrad nätverkssäkerhet och skydd), vilket slutar med att bryta end-to-end-anslutningen och göra utrustningen och applikationerna otillgängliga från resten av Internet.

Problemet

Att göra den distribuerade utrustningen tillgänglig, genom att utöka dess serverroll utanför det lokala nätverket, kräver antingen manuell konfiguration av portvidarebefordran vid nätverksgatewayen ( som vanligtvis är en CPE ), eller lösningar på applikationsnivå som initierar anslutningar från den distribuerade utrustningen till ytterligare mellanliggande utrustning. servrar som används för att "sammanfoga" dessa "brandväggsstämplande"-anslutningar och anslutningar från de faktiska klienterna. Båda tillvägagångssätten har sina nackdelar – manuell CPE-konfiguration är vanligtvis antingen obekväm eller inte möjlig, medan användning av ytterligare mellanliggande servrar ökar komplexiteten och kostnaden.

Till exempel kräver ett datorspel online (som fungerar som en klient) kommunikation med en spelserver för utbyte av speldata . För att göra det möjligt för en spelserver att tillhandahålla data till sina klienter måste dessa klienter göras tillgängliga för servern. Vanligtvis initierar klienter anslutningar till spelservern för att öppna kommunikationskanaler. Sådana öppna anslutningar kan emellertid bli inaktiva och kan därefter stängas av nätverksgateways, vilket leder till nödvändigheten av att underhålla dem genom att använda en form av keepalive-meddelanden. Keepalive-meddelanden är små meddelanden som skickas mellan klient och server som skapar trafik över en kommunikationskanal och därför förhindrar gatewayservrar från att stänga den. Att hålla en anslutning vid liv kräver således ett konstant utbyte av tomma meddelanden mellan klient och server. Detta ökar nätverkets chatter, slösar bort nätverksbandbredd och CPU-cykler och minskar autonomin för batteridrivna enheter.

Dessutom kräver vissa nätverksapplikationer (till exempel FTP ) dynamisk öppning av flera anslutningar, vilket involverar gateways på applikationsnivå (ALG) och dessutom ökar komplexiteten.

PCP som lösning

PCP tillåter utrustning och applikationer att skapa explicita mappningar mellan en extern IP-adress , protokoll och port , och en intern IP-adress, protokoll och port. Med sådana explicita mappningar på plats kan inkommande kommunikation nå värdarna bakom en NAT eller brandvägg, som antingen utökar deras serverroller bortom gränserna för lokala nätverk, eller använder olika tjänster förenklat och mindre resurskrävande. Skapade mappningar är permanenta till den grad att de har en känd livslängd som kan förlängas, vilket liknar hur Dynamic Host Configuration Protocol (DHCP) implementerar sina leasingavtal . Samtidigt tillåter PCP applikationer att skapa ytterligare mappningar dynamiskt efter behov, vilket minskar eller eliminerar behovet av att ha ALG -aktiverade NAT-enheter och brandväggar.

Skapat explicita mappningar har en känd livslängd, vanligtvis flera timmar, utan behov av keepalive-meddelanden på applikationsnivå som ska utbytas mellan värdar och servrar i syfte att bevara mappningen. Som ett resultat minskar nätverksanvändningen och energiförbrukningen, och keepalive-logik på applikationsnivå behöver inte längre implementeras på klient- och serversidan. PCP-mappningssvaret förser applikationen med tillhörande externt synliga parametrar (IP-adress, protokoll och port) som sedan kan meddelas till andra klienter på applikationsspecifika sätt så att inkommande anslutningar kan upprättas. Dessutom kan PCP informera applikationer när den externa IP-adressen ändras medan en mappning redan är etablerad.

Olika typer av NAT kan hanteras av PCP, vilket ger stöd för NAT64 , NAT66 och NAT44 ; inkludering av PCP i IPv4- och IPv6-brandväggsenheter stöds också. PCP är designat för att användas på både storskaliga aggregeringspunkter (till exempel som en del av NAT:er av bärarkvalitet ) och inuti billigare enheter av konsumentklass . Både långtidsmappningar (till exempel för en IP-kamera eller en temperatursensor som fungerar som server) och kortsiktiga mappningar (till exempel när du spelar ett datorspel online) stöds.

PCP stöder transportlagerprotokoll som använder 16-bitars portnummer (till exempel TCP , UDP , Stream Control Transmission Protocol (SCTP) eller Datagram Congestion Control Protocol (DCCP). Protokoll som inte använder portnummer (till exempel Resource Reservation Protocol (RSVP), Encapsulating Security Payload (ESP), ICMP eller ICMPv6 ) stöds för funktionerna IPv4-brandvägg, IPv6-brandvägg och NPTv6 (IPv6-prefixöversättning), men kan inte stödjas av mer än en klient per extern IP-adress när det gäller NAT .

PCP-specifikationen definierar inte en mekanism för att hantera multi-homed- nätverk (som har flera nätverksgateways eller standardrutter) . Det är ändå möjligt att implementera PCP i sådana nätverk med hjälp av en koordinationsmekanism som conntrackd . Men om de olika nätverken har var sin externa IP-adress, kan en given PCP-mappning endast använda den ena eller den andra eftersom protokollet kräver att en specifik extern IP-adress tillhandahålls till klienten. Om det nätverket sedan skulle bli otillgängligt måste PCP-mappningen uppdateras för att använda en extern IP-adress från det andra nätverket.

PCP-specifikationen definierar inte en mekanism för hur man informerar fjärrdatorer om IP-adressen, protokollet och porten för den inkommande anslutningen. RFC6887 säger att PCP inte tillhandahåller någon rendezvous-funktion och detta måste göras på ett applikationsspecifikt sätt, som att använda externa namntjänstservrar.

Historia

PCP standardiserades 2013 som en efterföljare till NAT Port Mapping Protocol ( NAT-PMP ), och delade liknande protokollkoncept och paketformat med det. Som en av designskillnaderna är NAT-PMP ganska mycket begränsad till distributionen på konsumentklassade enheter, medan PCP är utformad för att även stödja bärarkvalitetsutrustning . Sedan 2005 har NAT-PMP implementerats i olika Apple- produkter.

PCP relaterar till Internet Gateway Device Protocol (IGDP), som standardiserades 2001 som en del av UPnP-specifikationen ( Universal Plug and Play) . Medan IGDP är komplex och skräddarsydd för manuell konfiguration, är PCP designad för enkelhet och automatiserad användning inom mjukvaruapplikationer. NAT-PMP-specifikationen innehåller en lista över de problem med IGDP som föranledde skapandet av NAT-PMP, och därefter dess efterföljare PCP.

säkerhet

Om man utesluter angripare som kan ändra nätverkspaket som utbyts medan en explicit PCP-mappning skapas (paket som innehåller förhandling som krävs för att upprätta en explicit mappning, som utbyts mellan värdar och PCP-aktiverade NAT-enheter eller brandväggar), anses PCP vara säker som så länge skapade explicita mappningar inte överskrider domänen för implicita mappningar. Med andra ord skapas implicita mappningar som ett resultat av hur NAT-enheter och brandväggar hanterar vanliga utgående klientanslutningar, vilket innebär att PCP är säkert så länge inga nya mappningsmöjligheter introduceras genom den explicita mappningsmekanismen.

Ur säkerhetssynpunkt är en viktig PCP-funktion alternativet THIRD_PARTY mappningsbegäran . När det används betyder det här alternativet att IP-adressen som anges som en del av mappningsbegäran ska användas som den interna adressen för den skapade explicita mappningen, snarare än att följa standardbeteendet att använda käll-IP-adressen för det faktiska mappningsbegäranpaketet för det syfte. Sådana mappningsförfrågningar kan sluta med en PCP-aktiverad NAT-enhet eller brandvägg som ger explicita mappningsprivilegier högre än vad som tillåts av implicita mappningar på grund av okända regler som införts någon annanstans för den angivna IP-adressen, vilket gör att en angripare på det sättet kan stjäla lite trafik eller utföra en DoS-attack ( denial -of-service) .

Dessutom finns explicita PCP-säkerhetsmekanismer tillgängliga som tillägg till PCP-protokollet, som tillhandahåller autentiserings- och åtkomstkontrollmekanismer genom att använda en autentiserad och integritetsskyddad signalkanal inom bandet, som förlitar sig på Extensible Authentication Protocol (EAP) för att utföra autentiseringen mellan enheter involverad i en PCP-förhandlingssession. Sådana PCP-aktiverade NAT-enheter eller brandväggar kan fortfarande acceptera oautentiserade mappningsförfrågningar; samtidigt gäller fortfarande alla tidigare beskrivna explicita kartläggningsbegränsningar.

Interner

Internt fungerar PCP genom att utbyta kontrollmeddelanden mellan värdar och PCP-aktiverade NAT-enheter eller brandväggar (kallas servrar), med User Datagram Protocol (UDP) som underliggande protokoll. Denna kommunikation består av portmappningsförfrågningar skapade av värdarna som resulterar i svar när de väl skickats till och bearbetats av servrarna. Efter UDP:s karaktär av opålitlighet, vilket innebär att UDP- datagram kan gå förlorade, dupliceras eller ordnas om, finns det ingen garanti för ett svar av något slag efter att ha skickat in en begäran, så värdförfrågningar hänvisas även till som "tips". Förutom direkta svar genererar servrar även gratismeddelanden – till exempel unicast- aviseringar för att informera värdar om ändringar i den externa IP-adressen.

Opkoder för portkontrollprotokoll
Opcode	Beskrivning
KARTA	Skapar eller förnyar en mappning för inkommande vidarebefordran, vilket gör att en värd kan fungera som en server och ta emot inkommande kommunikation.
JÄMLIKAR	Skapar eller förnyar en utgående mappning, vilket gör att en värd kan hålla öppen kommunikation med en enda peer.
MEDDELA	Meddelar olika ändringar av värdarna, inklusive serverstarter och ändringar av den externa IP-adressen.

Utväxlade meddelanden innehåller inga medel för att bestämma vare sig transaktionen de tillhör, eller vilket stadium av en "session" de representerar. En sådan förenklad design bygger på att alla meddelanden är självbeskrivande och kompletta, utan att ytterligare sammanhang krävs för att varje meddelande ska kunna behandlas framgångsrikt. Servrar kan besluta att tyst ignorera värdförfrågningar, om de inte kan behandla dem för tillfället; i sådana fall måste värdarna återsända begäran. Dessutom kan värdar säkert besluta sig för att tyst ignorera alla oönskade mappningssvar.

För att skapa PCP-förfrågningar konfigureras serverns IP-adress antingen manuellt på värden, hittas som en del av värdens DHCP-leasing eller ställs in på värdens konfigurerade standardgateway . Meddelanden om värdbegäran skickas från valfri UDP-källport på en klient till serverns UDP-port 5351 som den lyssnar på; oönskade multicast- serveraviseringar (såsom meddelanden om serverstart) skickas från serverns UDP-port 5351 till UDP-port 5350 på värdar som de lyssnar på.

Maximal UDP- nyttolastlängd för alla PCP-meddelanden är 1100 oktetter . Varje PCP-meddelande består av en begäran eller ett svarshuvud som innehåller en op-kod som bestämmer den associerade operationen, all relevant opcode-specifik information (som vilka portar som ska mappas) och noll eller fler alternativ (som THIRD_PARTY-alternativet som beskrivs ovan ) . Resultatkoder returneras som en del av serversvar; varje resultatkod har en tillhörande livslängd, som talar om för värdarna när vissa operationer kan försökas igen eller bör upprepas. Till exempel kan resultatlivslängder ange hur länge ett feltillstånd förväntas bestå, eller hur länge den skapade mappningen kommer att pågå.

Se även

DMZ (dator) – ett undernätverk som innehåller och exponerar ens externa tjänster för ett större och opålitligt nätverk
Hålslagning (nätverk) – upprättande av direkta anslutningar mellan två nätverksanslutna parter som bor bakom brandväggar eller NAT-aktiverade routrar
Universal Plug and Play
Internet Gateway Device Protocol

externa länkar