DIAMETER

Innen informasjonsteknologi og telekommunikasjon er Diameter en AAA ( Authentication , Authorization and Accounting )-protokoll som følger RADIUS , selv om den ikke er direkte bakoverkompatibel . RADIUS er en klient-server AAA-protokoll mellom en Network Access Server ( NAS ) og en sentralisert RADIUS - server , basert på TCP - transportlagprotokollen ; Diameter er en peer-to-peer AAA-protokoll og består av en kjerneprotokoll (spesifisert i RFC 3588 ) og et sett med utvidelser kalt Diameter-applikasjoner . Den grunnleggende protokollen kan ikke brukes alene, men alltid assosiert med en spesifikk Diameter-applikasjon av tjenesten som skal tilbys ( Mobil IP , NASREQ , Strong Security, etc.). Den er basert på TCP- eller SCTP- transportprotokollene , og krever obligatorisk bruk av IPsec .

Fødsel

Hovedårsakene til å definere en ny protokoll var RADIUS -problemene som er oppført nedenfor.

• Begrenset attributtstørrelse: Et RADIUS-attributt bæres i en RADIUS-melding som en tuppel med lengde 3 { Attribute Type, Attribute Length, Attribute Value }. Attributtlengde-feltet er én oktett, og den maksimale verdien på 255 setter et tak på antall dataoktetter for et gitt attributt. Et Diameter-attributt bæres i en Diameter-melding som en tuppel med lengde 5 { Attribute Type, Flags, Attribute Length, Vendor-ID, Attribute Value }. Attributtlengde-feltet er tre oktetter, så maksimumsverdien tillater over 16 millioner oktetter med data for et gitt attributt.
• Begrenset antall samtidige ventende meldinger: Identifikatorfeltet i overskriften til en RADIUS- pakke brukes til å gjenkjenne retransmisjoner. Identifikatorfeltet er en oktett, som pålegger en maksimal grense på 255 meldinger som venter mellom en RADIUS -klient og en RADIUS - server . End-to-End Identifier-feltet i overskriften til en Diameter-melding brukes også til å gjenkjenne retransmisjoner; har en lengde på 4 oktetter, noe som gir mulighet for over 4 milliarder meldinger som venter fra en Diameter-klient.
• Manglende evne til å kontrollere flyten på serveren: RADIUS fungerer på UDP , en enkel ikke-tilkoblet transportprotokoll som mangler noen mekanisme for mottaksnoden for å regulere dataflyten fra avsendernoden. Diameter opererer på TCP eller SCTP ( Stream Control Transmission Protocol ), tilkoblingsorienterte transportprotokoller med strømningskontrollmekanismer og for å unngå overbelastning.
• Begrenset gjenkjenning av et serverheng: Det kan være mange grunner til at en NAS kan henge og ikke motta et svar på en gitt RADIUS-forespørsel, inkludert nettverksoverbelastning eller et midlertidig fall i signalet i banen mellom NAS-en og serveren. eller en blokkering av selve serveren osv. Med RADIUS, og derfor UDP, kan ikke NAS-en skille årsaken som forårsaket blokkeringen, så den antar at problemet er ved neste hopp og sender på nytt til et alternativt hopp; denne typen gjenoppretting er svært ofte upassende. Med et tilkoblingsorientert transportlag og med Diameter Keepalive-meldinger, kan en Diameter-node oppdage et lokalt peer-fall.
• Stille pakkeavvisning: RADIUS-protokollen spesifiserer at meldinger stille kan avvises for en rekke feiltilstander. I disse tilfellene vil NAS anta at serveren ikke har mottatt meldingen, og vil gjøre flere forsøk på å sende på nytt før forespørselen forlates permanent. Diameter-protokollen returnerer et svar for alle, eller nesten alle, feiltilstandene.
• Ineffektiv server-fail-over: Mange NAS-implementeringer konfigurerer flere RADIUS-servere, en primær server og et sett med alternative servere. Når den må gå til en alternativ server, vet ikke NAS-en om sistnevnte er tilgjengelig; dette kan føre til en betydelig forsinkelse for brukere inntil et nyttig alternativ er funnet. Med et tilkoblingsorientert transportlag og takket være Diameter Keepalive-meldingene, har en Diameter-node muligheten til å legge merke til konfigurasjonen av nettverket, og også gå tilbake til primærserveren når den blir tilgjengelig igjen, uten forsinkelse eller tidsavbrudd.
• Ineffektiv bruk av RADIUS-servere i proxy-miljøer: Under RADIUS gjøres alle reoverføringer av NAS-en. Proxy - servere videresender ikke RADIUS-forespørsler; NAS-en, uten å vite om slippet er lokalt eller eksternt, kan upassende sende tilbake til en alternativ neste hopp-peer. Under Diameter vil hver node en melding krysser på vei fra kilden til serveren oppdage en blokk av sin neste hop-peer og sende på nytt. Dessuten administreres en blokk lokalt.
• Fravær av uønskede servermeldinger: RADIUS-protokollen tillater ikke en server å sende uønskede meldinger til NAS-en. For nødvendige initialiseringsaktiviteter har produsentene vendt seg til løsninger utenfor RADIUS-protokollen (for eksempel SNMP ) eller til proprietære løsninger som involverer RADIUS-utvidelser, men som ofte kompromitterer interoperabilitet. Diameter, som er en peer-to-peer- protokoll i stedet for en klient-server- protokoll , tillater serverinitialiseringsmeldinger. Den grunnleggende protokollen definerer to typer meldinger, en for å be om at Diameter-klienten avslutter en spesifikk brukersesjon, og en annen for å be om at klienten reautentiserer eller reautoriserer en spesifikk bruker.
• Replay-angrep: RADIUS-protokollen gir ikke replay-angrep. En gammel pakke kan sendes på nytt fra en falsk NAS uten å bli oppdaget. Dette kan gi en tjenestenekt hvis serveren har en grense for samtidig økt for en bruker.
• Bare hopp-for-hopp og ikke ende-til-ende- sikkerhet: RADIUS-protokollen tilbyr kun hopp-for-hopp-sikkerhet og inneholder ingen fasiliteter for å sikre mellomliggende peers mellom NAS-en og serveren. Dette lar proxy-servere samle inn konfidensiell informasjon eller endre meldinger (som regnskapsinformasjon) uten at endepunktene merker det. Diameter-protokollen tilbyr ende-til-ende-sikkerhet i tillegg til hopp-for-hopp. Digitale signaturer sikrer integriteten til de involverte jevnaldrende, og deres konfidensialitet sikres ved kryptering .
• Ingen støtte for leverandørspesifikke kommandoer: RADIUS-protokollen støtter leverandørspesifikke attributter, men ikke kommandoer. Dette betydde at de private kommandokodene laget av produsentene skapte interoperabilitetsproblemer. Diameter-protokollen støtter både attributter og leverandørspesifikke kommandoer.
• Ingen justeringskrav: RADIUS-protokollen pålegger ingen justeringskrav, noe som kan overbelaste mange prosessorer unødvendig . Alle felt i overskriften og attributtene må håndteres byte for byte. Diameter-protokollen krever at alle attributter er justert med 32-bits ord, samt felt i meldingshodet.
• Delt hemmelighet kreves: RADIUS-protokollen krever at det eksisterer en delt hemmelighet mellom jevnaldrende, selv om IPSec brukes på lokal kommunikasjon. Diameter-protokollen kan sikre kommunikasjon mellom peers med både IPSec og TLS .

Struktur

Diameter er definert i form av en grunnleggende protokoll og et sett med applikasjoner. Denne utformingen gjør at protokollen kan utvides til nye tilgangsteknologier. Grunnprotokollen gir grunnleggende mekanismer for pålitelig transport, meldingslevering og feilhåndtering, og må brukes sammen med en Diameter-applikasjon. Hver applikasjon er avhengig av grunnleggende protokolltjenester for å støtte en bestemt type nettverkstilgang. De to hovedapplikasjonene er Mobile IPv4 og NASREQ (Network Access Server Requirements). NASREQ-applikasjonen støtter PPP / IP-oppringing og er ment som en erstatning for RADIUS.

Basisprotokollen definerer formatet til en basisdiametermelding. Dataene føres i Diameter-meldingen som en samling av AVP (Attribute Value Pair); en AVP tilsvarer et RADIUS-attributt og består av flere felt: AVP-kode, Lengde, Flagg og Data. Noen AVP-er brukes av den grunnleggende Diameter-protokollen; andre AVP-er er for Diameter-applikasjoner; atter andre kan brukes av høynivåapplikasjonen av sluttsystemet ved bruk av Diameter.

Diameter, i motsetning til RADIUS, opererer på et pålitelig transportlag ( TCP eller SCTP ) som gir flytkontroll, bekreftelser på transportnivå og retransmisjoner. Mens TCP er universelt kjent, er Stream Control Transmission Protocol (SCTP) noe sånt som en ny IP-transportprotokoll, som eksisterer på samme nivå som UDP eller TCP. I 2000 ble SCTP foreslått som en standard og er spesifisert i RFC 2960 .

Definisjoner

I tillegg til klient og server , definerer Diameter-protokollen andre typer noder :

• en klientdiameter er en enhet som får tilgang til nettverket på en kontrollert måte. En NAS er også en Diameter-klient;
• en serverdiameter er enheten som administrerer forespørsler om autentisering, autorisasjon og regnskap for et domene;
• en reléagent tar seg av rutingen av Diameter-meldinger basert på informasjonen i meldingen. Rutingbeslutninger tas ved hjelp av en liste over støttede domener og kjente peers . Reléagenter er gjennomsiktige; de kan endre meldinger bare ved å legge inn eller slette ruteinformasjon, men de kan ikke endre andre deler av meldingen;
• en proxy-agent tar seg også av rutingen; den kan modifisere meldinger for å implementere politiske beslutninger , for eksempel å kontrollere bruken av ressurser;
• en omdirigeringsagent gjør fortsatt rutingen, og fungerer vanligvis som en sentralisert kilde til domeneadressekart for medlemmene. I motsetning til andre typer agenter, returnerer en omdirigeringsagent en spesiell type svarmelding til peeren som sendte forespørselen. Denne svarmeldingen inneholder ruteinformasjon som gjør at peeren kan sende forespørselen på nytt, direkte til riktig destinasjon. En omdirigeringsagent forsinker ikke forespørsler;
• en Translation Agent utfører "oversettelser" mellom forskjellige protokoller, for eksempel fra RADIUS til Diameter. I dette tilfellet støtter oversettelsesagenten migrering fra RADIUS til Diameter, for eksempel muliggjør serverkonverteringer til Diameter.

Spesifikasjoner

En Diameter-melding består av en overskrift med fast lengde på 20 byte , etterfulgt av et variabelt antall AVP-er. Overskriftsformatet er som følger:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Versjon | | | 0 0 0 0 0 0 0 1 | Meldingslengde | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Flagg | | | RPET xxxx | Kommando-kode | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Applikasjons-ID | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Hopp-for-hopp-identifikator | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | End-to-end identifikator | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | AVP-er... + - + - + - + - + - + - + - + - + - + - + - + - + -

Diameter-meldingshodet inneholder to 32 -bits identifikatorer . Hop-for-hop-identifikatoren hjelper deg med å matche forespørsler og svar. I forespørsler erstattes denne identifikatoren for hvert hopp til meldingen videresendes til dens endelige destinasjon. Avsenderen av svarmeldingen returnerer samme verdi som den fant i den tilsvarende forespørselen. End-to-end Identifier , sammen med identiteten til den opprinnelige verten, brukes til å gjenkjenne dupliserte forespørselsmeldinger, og endres aldri før forespørselen ankommer destinasjonen. Avsenderen av svaret returnerer samme verdi som den fant i den tilsvarende forespørselen.

Diameter tillater datatyper som Integer32, Unsigned32, Integer64, Unsigned64, Float32, Float64, Float128, OctetString og Grouped; en AVP Grouped er en AVP hvis data er en sekvens av AVP-er.

Avledede datatyper er også definert: enumerativ (avledet fra integer32), DiameterIdentity (avledet fra oktettstreng), temporal (avledet fra unsigned32), UTF8String (avledet fra oktettstreng), IPFilterRule (avledet fra oktettstreng) og QoSFilterRule (avledet fra oktettstreng).

Hver Diameter-prosess som kjører på en vert genererer en Diameter Identity, som er en streng med syntaksen til en Uniform Resource Identifier (URI) som representerer FQDN (Fully Qualified Domain Name) til verten, en av portene som lytter etter tilkoblinger i oppføring, transportprotokollen (TCP eller SCTP), AAA-protokollen (Diameter) og sikkerhetstransporten (ingen eller TLS).

Fordi identiteten bærer vertens FQDN, og siden flere Diameter - prosesser på en enkelt vert ikke kan lytte på den samme porten til en gitt protokoll, er hver prosess DiameterIdentity garantert unik.

Når det gjelder meldingene, er det to typer: Forespørsel og svar . Hver svarmelding inkluderer en AVP-resultatkode , hvis verdi er et heltall som indikerer om en bestemt forespørsel ble fullført eller om det oppsto en feil. Hver Diameter-melding inneholder Diameter Identity for sendingsprosessen på den opprinnelige verten, samt domenet til den prosessen. Forespørselsmeldinger kan være "proxiable" eller "non-proxiable", avhengig av et av flaggene i overskriften. Ikke-proxiable forespørsler er strengt ment for neste-hopp-peer, og blir aldri videresendt videre. Proxiable forespørsler kan rutes og rutes per domene. Hver proxiable forespørsel inneholder måldomenet i Destination-Realm AVP.

En Diameter-melding som er relevant for en spesifikk brukerøkt, inkluderer en AVP Session-Id , en konstant verdi for øktens levetid. Denne verdien er en globalt og evig unik tekststreng, som er i stand til å identifisere en brukerøkt unikt uten å referere til annen informasjon. Diameter-klienten som starter økten oppretter Session-Id, som begynner med avsenderens Diameter Identity-streng og fortsetter med en sekvens som garanterer både topologisk og tidsmessig unikhet.

Kommandoliste

Hver kommando kjennetegnes av en kode, brukt for både forespørsler og svar:

Kommando	Abbr.	Kode
Avbryt-økt-forespørsel	ASR	274
Avbryt-økt-svar	SOM EN	274
Regnskap-forespørsel	ACR	271
Regnskap-Svar	ACA	271
Evner-Utveksling-Forespørsel	CER	257
Evner-Utveksling-Svar	CEA	257
Device-Watchdog-Request	DWR	280
Enhet-Vakthund-Svar	DWA	280
Koble fra-peer-forespørsel	DPR	282
Koble fra-Peer-Svar	DPA	282
Re-Auth-Request	RAR	258
Re-Auth-Answer	RAA	258
Økt-avslutning-forespørsel	STR	275
Økt-avslutning-svar	ER	275
Kreditt-kontroll-forespørsel	CCR	272
Kreditt-kontroll-svar	CCA	272

Attributt-verdipar (AVP)

Overskriftsformatet til en AVP Diameter er som følger:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | AVP-kode | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Flagg | | | VMP xxxxx | AVP Lengde | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | Leverandør-ID (hvis leverandørspesifikk AVP) | + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + | AVP-data ... (variabel lengde) + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -

AVP-koden, sammen med leverandør-ID-feltet, identifiserer attributtet unikt. De første 256 tallene, sammen med leverandør-ID satt til null, er reservert for bakoverkompatibilitet med RADIUS . AVP-datafeltet består av null eller flere oktetter og inneholder attributtspesifikk informasjon. Feltene AVP Code og AVP Length bestemmer formatet og lengden på datafeltet.

Attributt-navn	Kode	Data-type
Acct-Interim-Interval	85	Usignert 32
Regnskap-sanntid-påkrevd	483	Oppregnet
Acct-Multi-Session-Id	50	UTF8-streng
Regnskapspostnummer	485	Usignert 32
Regnskap-Rekord-Type	480	Oppregnet
Regnskap-Session-Id	44	Oktettstreng
Accounting-Sub-Session-Id	287	Usignert 64
Acct-Application-Id	259	Usignert 32
Auth-Application-Id	258	Usignert 32
Auth-Request-Type	274	Oppregnet
Autorisasjon-levetid	291	Usignert 32
Auth-Grace-Period	276	Usignert 32
Auth-Session-State	277	Oppregnet
Re-Auth-Request-Type	285	Oppregnet
CC-Request-Type	416	Usignert 32
CC-forespørsel-nummer	415	Usignert 32
Klasse	25	Oktettstreng
Destinasjon-vert	293	DiamIdent
Destinasjon-riket	283	DiamIdent
Koble fra - Årsak	273	Oppregnet
E2E-sekvens	300	Gruppert
Feilmelding	281	UTF8-streng
Feil-rapportering-vert	294	DiamIdent
Hendelse-tidsstempel	55	Tid
Eksperimentelt-resultat	297	Gruppert
Eksperimentell-Resultat-kode	298	Usignert 32
Mislyktes-AVP	279	Gruppert
Firmware-revisjon	267	Usignert 32
Verts-IP-adresse	257	Adresse
Inband-Security-Id	299	Usignert 32
Multi-Round-Time-Out	272	Usignert 32
Opprinnelse-vert	264	DiamIdent
Opprinnelse-rike	296	DiamIdent
Opprinnelse-State-ID	278	Usignert 32
Produktnavn	269	UTF8-streng
Proxy-vert	280	DiamIdent
Proxy-info	284	Gruppert
Proxy-stat	33	Oktettstreng
Omdirigering-vert	292	DiamURI
Omdirigere-vert-bruk	261	Oppregnet
Redirect-Max-Cache-Time	262	Usignert 32
Resultat-kode	268	Usignert 32
Rute-rekord	282	DiamIdent
Øktnummer	263	UTF8-streng
Tidsavbrudd for økten	27	Usignert 32
Sesjonsbinding	270	Usignert 32
Session-Server-Failover	271	Oppregnet
Supported-Vendor-Id	265	Usignert 32
Oppsigelse-årsak	295	Oppregnet
Brukernavn	1	UTF8-streng
Leverandør-ID	266	Usignert 32
Leverandør-spesifikk-applikasjons-ID	260	Gruppert

Eksterne lenker

• ( EN ) RFC 3588 Diameter Base Protocol
• ( EN ) http://gull.sourceforge.net/ Open Source / GPL Seagull testverktøy - med Diameter-støtte
• ( EN ) https://web.archive.org/web/20060823010905/http://www.ulticom.com/html/products/signalware-diameter-what-is.asp Diameter i IMS fra Ulticom, Inc.
• ( EN ) https://www.cisco.com/en/US/products/ps6638/products_data_sheet09186a00804fe332.html Cisco-side som skisserer forskjellene mellom RADIUS og DIAMETER
• ( EN ) Nakhjiri, Nakhjiri, "AAA and Network Security for Mobile Access", Wiley