Host Identification Protocol (HIP) er en værtsidentifikationsteknologi designet til brug på Internet Protocol ( IP ) netværk, såsom "wide web ". Der er to hovednavneområder på internettet: IP-adresser og domænenavnesystemet. HIP er opdelt i roller til slutpunkt-id og IP-adresselokalisering. Det introducerer Host Identity (HI) navneområdet baseret på en offentlig nøglesikkerhedsinfrastruktur. Host Identity Protocol giver sikre metoder til IP-adressering og mobilkommunikation.
På netværk, der implementerer Host Identification Protocol, elimineres alle forekomster af IP-adresser i applikationer og erstattes med kryptografiske værtsidentifikatorer. Kryptografiske nøgler er normalt selvgenererede.
Resultatet af eliminering af IP-adresser på applikations- og transportlagene er adskillelsen af transportlaget fra internetarbejdeslaget (netværkslaget) i TCP/IP . HIP er blevet beskrevet af IETF HIP-arbejdsgruppen. Internet Technology Research Group ( IRTF ) ser nærmere på HIP.
En gruppe forskere har til opgave at udarbejde et arbejdsforslag ( RFC ) på det "eksperimentelle" spor, men det skal forstås, at de foreslåede kvalitets- og sikkerhedsegenskaber skal opfylde standardsporets krav. Hovedformålet med at skabe eksperimentelle dokumenter i stedet for standarddokumenter er de ukendte effekter, som mekanismer kan have på applikationer og på internettet generelt.
Et navn i Host Identity (HI) navneområdet er et statistisk globalt unikt navn til at navngive ethvert system med en IP-stak. Denne identitet er normalt forbundet med, men ikke begrænset til, IP-stakken. Et system kan have flere identifikatorer, nogle "velkendte", nogle upublicerede eller "anonyme". Systemet er i stand til selv at hævde sin egen identitet eller kan bruge en tredjepartsgodkendelse, såsom DNS Security ( DNSSEC ), Pretty Good Privacy ( PGP ) eller X.509 til at "notarisere" identitetspåstanden. Værts-id'er forventes oprindeligt at blive godkendt ved hjælp af DNSSEC .
I teorien kan ethvert navn, der kan hævde at være "statistisk globalt unikt", tjene som værts-id. Men ifølge forfatterne genererer nøglen fra det "offentlige nøglepar" et bedre værts-id. Offentlig nøgle-baseret HI kan autentificere HIP-pakker og beskytte dem mod man-in-the-middle-angreb. Fordi der kræves autentificerede datagrammer for at give det meste af DoS-beskyttelsen i HIP, skal Diffie-Hellman- kommunikation i HIP være autentificeret. I praksis er det således kun HI public key og autentificerede HIP-meddelelser, der understøttes.
Tidligere havde netværkslagsprotokollen (dvs. IP) følgende fire "klassiske" egenskaber (invarianter):
I dagens verden forsøger vi bevidst at slippe af med den anden invariant (både til mobilitet og multifunktionssøgning), og vi er blevet tvunget til at opgive den første og fjerde. Domænespecifik IP er et forsøg på at gendanne den fjerde invariant uden den første invariant. IPv6 er et forsøg på at gendanne den første invariant.
Få systemer på internettet har DNS- navne, der giver mening. Det vil sige, at hvis de har et fuldt kvalificeret domænenavn ( FQDN ), hører dette navn normalt til NAT -enheden eller fjernadgangsserveren og identificerer ikke rigtig selve systemet, men dets nuværende forbindelse. FQDN'er (og deres udvidelser som e-mail-navne) er navne på applikationsniveau, oftere navngivningstjenester end et bestemt system. Det er grunden til, at mange systemer på internettet ikke er registreret med DNS ; de har ikke tjenester af interesse for andre internetværter.
DNS -navne er links til IP-adresser. Dette viser kun forholdet mellem netværket og applikationslagene. DNS , som den eneste distribuerede database på internettet, er også et opbevaringssted for andre navneområder, delvist på grund af DNSSEC- specifikke nøgleregistreringer og applikationer. Selvom hvert navneområde kan udvides (IP med v6, DNS med KEY-poster), kan ingen af dem korrekt give værtsgodkendelse eller fungere som en afgrænsning mellem netværket og transportlagene.
Host Identity (HI) -navneområdet udfylder et vigtigt hul mellem IP- og DNS - navneområderne . Det interessante ved HI er, at det faktisk giver dig mulighed for at droppe alt undtagen det 3. netværkslags invariante. Det vil sige, at hvis kilde- og destinationsadresserne i netværkslagsprotokollen er reversible, fungerer alt fint, fordi HIP sørger for at identificere værten, og reversibilitet tillader, at pakken returneres tilbage til peer-værten . Du er ligeglad med, om netværkslagets adresse ændres under overførsel, og du er ligeglad med, hvilken netværkslagsadresse peeren bruger.