Vad är ett Nätverkstrafikflöde?

nätverkstrafikflöden (flöden) är användbara för att bygga en grovkornig förståelse av trafik i ett datanätverk, vilket ger en bekväm enhet för mätning och/eller behandling av trafik.

flöden kan mätas för att förstå vad värdar pratar i nätverket, med detaljer om adresser, volymer och typer av trafik. Denna syn på nätverket kan vara användbar för felsökning, detektering av säkerhetsincidenter, planering och fakturering

men vad exakt är ett flöde och hur definieras det?

denna fråga låter trivial att svara på, men när vi gräver djupare hittar vi nyanser och hörnfall som gör flöden intressanta och i slutändan svåra att definiera.

Bakgrund

för att verkligen förstå flöden måste vi börja med lite bakgrund.

nätverk började som kretskopplade. När en värd ville kommunicera med en annan värd frågade det nätverket att skapa en krets. Efter att informationsflödet hade avslutats revs kretsen.

Figur 1-exempel Kretskopplat nätverk

kretskopplade nätverk har sitt arv i telefonnät. De har ett antal nackdelar, inklusive dålig skalbarhet och lågt kapacitetsutnyttjande.

ett alternativ behövdes för att bygga det som i slutändan blev Internet-paketkopplade nätverk. Meddelanden hakas upp i bitar med varierande storlek som adresseras individuellt och skickas som paket över nätverket.

Figur 2-Exempel Paketkopplat nätverk

den mottagande värden återmonterar nyttolasten från paketen tillbaka till meddelandet. Paket kan också innehålla kontrollinformation, till exempel flödeskontroll och banor behöver inte vara symmetriska.

att definiera flöden i ett kretskopplat nätverk är enkelt eftersom kretsen är ett flöde och följer ett protokoll för att upprätta och avveckla (krets = flöde); men i ett paketkopplat nätverk är saker mindre uppenbara.

Föreställ dig för en sekund att du befinner dig vid observationspunkt A i det kretskopplade nätverket i Figur 1, skulle du se:

Figur 3-zooma in på Kretskopplat nätverk

två flöden skulle observeras-kretsar mellan värdar 3 & 4 och värdar 5 & 6. Att observera flöden i ett kretskopplat nätverk är relativt enkelt eftersom nätverket är involverat i att ställa in kretsarna, så vet deras tillstånd och slutpunkterna.

Föreställ dig nu att du befinner dig vid observationspunkt A i det paketkopplade nätverket i Figur 2 istället skulle du se:

Figur 4-zooma in på Paketkopplat nätverk

plötsligt är saker mindre tydliga. Det finns ett paket som kommer in från värd 5 avsedd för värd 6. Förutsatt att vi observerar under en tid ser vi fler paket anländer och avgår. Att observera flöden på ett paketkopplat nätverk tar tid och kräver inspelning och analys av paketinformation.

första (naiva) försöket att definiera ett flöde

med hjälp av vår kunskap om paketkopplade nätverk kan ett första försök att svara ‘Vad är ett flöde’ vara:

ett flöde är en sekvens av paket som bär information mellan två värdar

denna definition ser ut som:

Figur 5 – första försöket att definiera ett flöde

det finns dock ett problem. Vad händer om det händer mer än en typ av kommunikation mellan värdarna, till exempel har A en SSH-och HTTPS-anslutning till B? Är SSH-och HTTPS-paketen en del av samma flöde? Intuitivt säger Vi nej, de är olika sessioner och till och med helt olika protokoll. Vi kan göra bättre…

andra försök att definiera

vad sägs om att vi använder protokollinformation från pakethuvuden som vanliga egenskaper för att identifiera paket i flöden? Detta kommer att separera olika typer av anslutningar i olika flöden.

en stor del av paket i ett nätverk kommer sannolikt att vara IP layer – 3-protokoll, med TCP eller UDP som layer-4-transportprotokoll. Det är därför rimligt att överväga att använda TCP-och UDP-parametrar som flödestangenter från pakethuvudena.

vi använder 5 parametrar från pakethuvudena; källa IP, destination IP, protokoll, TCP eller UDP källport och TCP eller UDP destinationsport som en ordnad lista, allmänt känd som 5-tuple, som de gemensamma egenskaperna för att kartlägga paketen till flöden.

Figur 6-exempel 5-tupel

här går försök 2:

ett flöde är en sekvens av paket som bär information mellan två värdar, där paket har gemensamma egenskaper:

• alla paket i flödet delar samma 5-tupel

vårt scenario ser nu ut så här:

Figur 7-sekunders försök att definiera ett flöde

perfekt du säger. Livet är bra. Vi har en definition för ett flöde, inget mer att se här … men hänga på, hur är det med paketets riktning?

tredje försöket-dubbelriktad

en 5-tupel är enkelriktad (enkelriktad). Som standard matchar det bara paket som reser i en riktning, eftersom paket i omvänd riktning har transponerat IP-adresser och portnummer, och därmed en annan 5-tuple-hash.

det finns goda skäl att betrakta flöden som Dubbelriktade i motsats till enkelriktade, inklusive förmåga att bestämma klient/serverbeteende och beräkna tur-och returtider samt förbättra detektering av säkerhetsincidenter som skanning.

Tänk på en enkel TCP-anslutning i Figur 8 där paket studsar fram och tillbaka mellan värd a & B:

figur 8-Stegdiagram över ett enkelt TCP-flöde

vi ser ett klassiskt TCP 3-vägs handslag (SYN, SYN+ACK, ACK) följt av utbyte av data. Enkelriktad flödesanalys vid en observationspunkt i nätverket skulle se två separata flöden, en per riktning, enligt Figur 9:

Figur 9-enkelriktade stegar för enkelt TCP-flöde

problemet med enkelriktad flödesmätning är att vi missar möjligheten att fånga några viktiga metadata om flödet. Visst, varje enkelriktat flöde kan lagra riktningsmetadata för byte och paket i den riktningen. Detta kan inkludera inter-packet timing (se märkta punkter i Figur 9). Men vi missar möjligheten att samla metadata som kräver mätning av trafikparametrar i båda riktningarna.

överväga dubbelriktad observation i Figur 10:

Figur 10-stege av Dubbelriktade observationer för enkelt TCP-flöde

vi kan nu observera och mäta TCP 3-vägs handskakning (punkterna F1, B1, F2) och titta på andra mätvärden som svarstider.

för Dubbelriktade flöden behöver vi två 5-tuplar, varav den andra vänder tupelordningen för både IP-adresserna och portnumren. Nedan är ett exempel på SSH flöde framåt och bakåt 5-tuples:

Figur 11-att vända en 5-tupel

rätt, det var inte för svårt. Men vänta, en liten detalj lurar som kräver ytterligare uppmärksamhet. Hur vet vi vad som är flödesriktningen framåt? Vi bestämmer riktningen baserat på det första observerade paketet, vilket antas resa i klienten till serverns riktning, men det kommer inte att vara 100% pålitligt eftersom paket kan vara i ordning och/eller observationen kan börja delvis genom ett flöde. Vi kommer att använda med den här metoden, men måste komma ihåg när vi tittar på resultat att det inte är perfekt.

en alternativ metod är att inspektera transportprotokollfält. I TCP till exempel är närvaron av bara SYN-flaggan en rimlig indikator på att paketet är det första i flödet.

vår definition för ett flöde är nu:

ett flöde är en sekvens av paket som bär information mellan två värdar där paket har gemensamma egenskaper:

• alla paket i flödet delar samma 5-tupel eller transponerade 5-tupel

fjärde försöket-inklusive icke-TCP IP-trafik

fram till denna punkt har vi antagit att transportprotokollet är TCP. Vad sägs om andra IP – transportprotokoll?

UDP är det självklara valet för näst vanligaste transportprotokoll, särskilt med ökningen av realtidstrafik över UDP samt nya protokoll som QUIC. UDP passar lätt in i samma modell som den har käll-och destinationsportnummer, enligt QUIC-exemplet nedan:

Figur 12-reversering av en UDP 5-tupel (samma som TCP)

Stream Control Transmission Protocol (SCTP) är ett annat transportprotokoll som använder portnummer och därmed fungerar med en 5-tupel.

men hur är det med andra protokoll, till exempel IPsec?

IPsec ESP (Encapsulating Security Payload) är ett protokoll som inte innehåller käll-/destinationsportnummer, så vi måste falla tillbaka till en 3-tupel eftersom det är osannolikt att det är praktiskt att förstå nyttolasten för protokollet.

figur 13-dubbelriktad 3-tupel

vår definition för ett flöde är nu:

ett flöde är en sekvens av paket som bär information mellan två värdar där paket har gemensamma egenskaper:

• för transportprotokoll med portnummer (dvs. TCP / UDP / SCTP):

alla paket i flödet delar samma 5-tupel eller transponerade 5-tupel

annars:

alla paket i flödet delar samma 3-tupel eller transponerade 3-tupel

det finns dock ännu en faktor att tänka på – tid.

femte försöket-Flödesutgång

ett flöde existerar endast under en viss tid. Det är möjligt att samma 5-tupel (eller 3-tupel) kan återanvändas vid en annan tidpunkt, för ett annat flöde, mellan samma värdar.

Tänk på två värdar där en initierar många nya TCP-anslutningar till den andra. Varje ny TCP-anslutning får en ny källport, i allmänhet inkrementerad med 1 från föregående tilldelning. IANA fördelar intervallet 49152 till 65535 för dessa flyktiga portar, vilket ger 16384 portar. Med tiden kommer TCP-Källporten att rulla genom intervallet och den ursprungliga Källporten återanvändas, och detta flöde kommer att ha samma 5-tupel som det ursprungliga flödet. Detta utgör ett problem, eftersom det inte är samma flöde!

för att lösa detta behöver vi flöden som löper ut där inga paket ses under mer än en viss tid. Här går vi igen:

ett flöde är en sekvens av paket som bär information mellan två värdar där paket har gemensamma egenskaper:

• för transportprotokoll med portnummer (dvs TCP/UDP/SCTP):

alla paket i flödet delar samma 5-tupel eller transponerade 5-tupel

annat:

alla paket i flödet delar samma 3-tupel eller transponerade 3-tupel

• alla interpakettider är mindre än godtyckligt flödesutgångstidsvärde

sjätte försöket-godtyckliga parametrar

ibland kanske du vill ha olika parametrar för att identifiera flöden, eller dessa kan tvingas på dig av typen av hårdvara/programvara i nätverket.

i en Cisco-router identifieras flöden av en 7-tupel som lägger till Typ av tjänst (ToS) och inmatningsundergränssnitt till standard 5-tupel. Det kan också finnas situationer där layer-2-fält, till exempel käll-eller destinations-MAC-adress, kan vara meningsfulla som flödestangenter (även om de bara är lokalt signifikanta).

det finns andra parametrar som kan användas som gemensamma egenskaper för flödesidentifiering; det är i slutändan upp till operatören att bestämma och utrustningens kapacitet. Baserat på detta förfinar vi definitionen ytterligare:

ett flöde är en sekvens av paket som bär information mellan två värdar där paket har gemensamma egenskaper:

• för transportprotokoll med portnummer (dvs. TCP / UDP / SCTP):

alla paket i flödet delar samma 5-tupel eller transponerade 5-tupel

annars:

alla paket i flödet delar samma 3-tupel eller transponerade 3-tupel

• alla inter-pakettider är mindre än godtyckligt flöde utgången timeout värde
• kan använda godtyckliga parametrar som flödestangenter, inklusive ToS, gränssnitt etc.

förpackning av allt

vi har visat att det är ett svårt problem att producera en enda allomfattande flödesdefinition. Flödesdefinitionen är implementeringsspecifik, beroende av användarkrav samt kapaciteten hos nätverksutrustning som mäter flödena.

i del 2 i detta blogginlägg kommer vi att gå in på ytterligare överväganden för flöden som IPv6-flödesetiketter, fragmentering (IPv4 och IPv6-problem..), kryptering, icke-IP-paket och hur flöden mäts och används i andra system som SDN.

se: https://www.eecs.yorku.ca/course_archive/2015-16/W/3214/CSE3214_01_PacketCircuitSwitching_2016_posted_part2.pdf

för vissa relaterade artiklar, se: https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdf och https://is.muni.cz/th/hilnn/cse2009.pdf

för relevant RFC, se: https://tools.ietf.org/html/rfc5103

för mer information om standardisering av QUIC, se: https://datatracker.ietf.org/wg/quic/about/

se: https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml