Wat is een Netwerkverkeersstroom?

Netwerkverkeersstromen (flows) zijn nuttig voor het opbouwen van een grofkorrelig inzicht in het verkeer op een computernetwerk en bieden een handige eenheid voor het meten en/of behandelen van het verkeer.

stromen kunnen worden gemeten om te begrijpen wat hosts over het netwerk spreken, met details van adressen, volumes en soorten verkeer. Deze weergave van het netwerk kan nuttig zijn voor het oplossen van problemen, het detecteren van beveiligingsincidenten, planning en facturering

maar wat is een stroom precies en hoe wordt deze gedefinieerd?

deze vraag klinkt triviaal om te beantwoorden, maar als we dieper graven vinden we nuances en hoekgevallen die stromen interessant maken, en uiteindelijk moeilijk te definiëren.

Achtergrond

om stromen echt te begrijpen, moeten we beginnen met wat achtergrond.

netwerken begonnen als circuitgeschakeld. Wanneer een host wilde communiceren met een andere host vroeg het netwerk een circuit op te zetten. Nadat de informatiestroom was afgelopen, werd het circuit afgebroken.

figuur 1-Voorbeeld circuitgeschakelde netwerken

circuitgeschakelde netwerken hebben hun erfgoed in telefoonnetwerken. Ze hebben een aantal nadelen, waaronder een slechte schaalbaarheid en een lage bezettingsgraad.

een alternatief was nodig om te bouwen wat uiteindelijk de internet – packet-switched networks werd. Berichten worden opgedeeld in stukken van variabele grootte die individueel worden geadresseerd en als pakketten over het netwerk worden verzonden.

Figuur 2 – voorbeeld Packet-Switched Network

de ontvangende host herstelt de lading van de pakketten terug in het bericht. Opmerking: pakketten kunnen ook besturingsinformatie bevatten, zoals stroomregeling en paden hoeven niet symmetrisch te zijn.

het definiëren van stromen in een circuitgeschakeld netwerk is eenvoudig omdat het circuit een stroom is en een protocol volgt om te vestigen en te ontmantelen (circuit = stroom); in een pakketgeschakeld netwerk zijn de zaken echter minder voor de hand liggend.

stel je even voor dat je op observatiepunt A bent in het circuit-geschakelde netwerk van Figuur 1, zou je zien:

Figuur 3-inzoomen op circuitgeschakeld netwerk

twee stromen worden waargenomen-circuits tussen hosts 3 & 4 en hosts 5 & 6. Het observeren van stromen in een circuit-geschakeld netwerk is relatief eenvoudig omdat het netwerk betrokken is bij het opzetten van de circuits, dus Weet hun toestand, en de eindpunten.

stel je nu voor dat je op observatiepunt A in het packet-switched netwerk van Figuur 2 in plaats daarvan, zou je zien:

Figuur 4-inzoomen op Packet-Switched Network

plotseling zijn dingen minder duidelijk. Er komt een pakket binnen van Host 5 bestemd voor Host 6. Ervan uitgaande dat we een periode van tijd observeren zien we meer pakketten aankomen en vertrekken. Het observeren van stromen op een pakketgeschakeld netwerk kost tijd en vereist het opnemen en analyseren van pakketinformatie.

eerste (naïeve) poging om een stroom

te definiëren met behulp van onze kennis van pakketgeschakelde netwerken, kan een eerste poging om te antwoorden op ‘wat is een stroom’ zijn:

een stroom is een reeks pakketten die informatie bevatten tussen twee hosts

deze definitie lijkt:

Figuur 5 – eerste poging om een stroom

te definiëren er is echter een probleem. Wat gebeurt er als er meer dan één type communicatie plaatsvindt tussen de hosts, bijvoorbeeld A heeft een SSH en HTTPS verbinding met B? Maken de SSH-en HTTPS-pakketten deel uit van dezelfde stroom? Intuïtief zeggen we nee, het zijn verschillende sessies, en zelfs totaal verschillende protocollen. We kunnen het beter doen…

tweede poging om

te definiëren hoe zit het met protocolinformatie van pakketheaders als gemeenschappelijke eigenschappen om pakketten in stromen te identificeren? Dit zal verschillende soorten verbindingen scheiden in verschillende stromen.

een groot deel van de pakketten op een netwerk is waarschijnlijk IP layer-3 protocol, met TCP of UDP als layer-4 transport protocol. Het is daarom redelijk om te overwegen om TCP-en UDP-parameters te gebruiken als flow-sleutels van de pakketheaders.

we gebruiken 5 parameters van de pakketheaders; bron-IP, doel-IP, protocol, TCP-of UDP-bronpoort en tcp-of UDP-bestemmingspoort als een geordende lijst, algemeen bekend als de 5-tuple, als de gemeenschappelijke eigenschappen om de pakketten aan stromen toe te wijzen.

Figuur 6-Voorbeeld 5-tupel

hier gaat poging 2:

een stroom is een reeks pakketten die informatie tussen twee hosts bevatten, waarbij pakketten gemeenschappelijke eigenschappen hebben:

• alle pakketten in de stroom hebben dezelfde 5-tupel

ons scenario ziet er nu zo uit:

Figuur 7 – tweede poging om een stroom

Perfect te definiëren, zeg je. Het leven is goed. We hebben een definitie voor een stroom, niets meer te zien hier… maar wacht even, hoe zit het met de richting van de pakketten?

derde poging-bidirectioneel

een 5-tupel is unidirectioneel (eenrichtingsverkeer). Standaard komt het alleen overeen met pakketten die in één richting reizen, omdat pakketten in de omgekeerde richting IP-adressen en poortnummers hebben getransponeerd, en dus een andere 5-tuple hash.

er zijn goede redenen om stromen als bidirectioneel in plaats van unidirectioneel te beschouwen, met inbegrip van de mogelijkheid om het gedrag van client/server te bepalen en retourtijden te berekenen, alsook het verbeteren van de detectie van beveiligingsincidenten zoals scannen.

beschouw een eenvoudige TCP-verbinding in Figuur 8 waarbij pakketten heen en weer stuiteren tussen Host A & B:

Figuur 8-Ladderdiagram van een eenvoudige TCP Flow

we zien een klassieke TCP 3-weg handshake (SYN, SYN+ACK, ACK) gevolgd door uitwisseling van gegevens. Unidirectionele stroomanalyse op een observatiepunt in het netwerk zou twee afzonderlijke stromen zien, één per richting, volgens figuur 9:

figuur 9-unidirectionele Ladders voor eenvoudige TCP Flow

het probleem met unidirectionele flow meting is dat we de kans missen om een aantal belangrijke metadata over de flow vast te leggen. Zeker, elke unidirectionele stroom kan directionele metadata opslaan voor bytes en pakketten in die richting. Dit kan inter-pakket timing omvatten (zie gelabelde punten in Figuur 9). Maar we missen de kans om metadata te verzamelen die het meten van verkeersparameters in beide richtingen vereist.

beschouw bidirectionele waarneming in Figuur 10:

Figuur 10-Ladder van bidirectionele waarnemingen voor eenvoudige TCP Flow

we kunnen nu de TCP 3-weg handshake (punten F1, B1, F2) observeren en meten, en kijken naar andere metrics zoals responstijden.

voor bidirectionele stromen hebben we twee 5-tupels nodig, waarvan de tweede de tupelvolgorde van zowel de IP-adressen als de poortnummers omkeert. Hieronder is een voorbeeld van SSH flow forward en reverse 5-tupels:

Figuur 11-omkeren van een 5-tupel

rechts, dat was niet zo moeilijk. Maar wacht, een klein detail ligt op de loer dat verdere aandacht vereist. Hoe weten we wat de voorwaartse richting van de stroming is? We bepalen de richting op basis van het eerste waargenomen pakket, dat wordt verondersteld te reizen in de client naar server richting, maar dit is niet van plan om 100% betrouwbaar als pakketten kunnen zijn buiten de orde en/of de observatie kan beginnen halverwege een flow. We zullen gebruiken met deze methode, maar moeten onthouden wanneer we kijken naar de resultaten dat het niet perfect is.

een alternatieve methode is het inspecteren van velden met transportprotocollen. In TCP bijvoorbeeld, de aanwezigheid van alleen de SYN vlag is een redelijke indicator dat het pakket is de eerste in de flow.

onze definitie voor een stroom is nu:

een stroom is een reeks pakketten die informatie tussen twee hosts bevatten, waarbij pakketten gemeenschappelijke eigenschappen hebben:

• alle pakketten in de stroom hebben dezelfde 5-tupel of getransponeerde 5-tupel

vierde poging-Inclusief niet-TCP IP-verkeer

tot op dit punt hebben we aangenomen dat het transportprotocol TCP is. Hoe zit het met andere IP-transportprotocollen?

UDP is de voor de hand liggende keuze voor het op één na meest voorkomende vervoersprotocol, vooral met de opkomst van real-time verkeer over UDP en nieuwe protocollen zoals QUIC. UDP past gemakkelijk in hetzelfde model aangezien het bron-en bestemmingspoortnummers heeft, volgens QUIC voorbeeld hieronder:

Figuur 12-het omkeren van een UDP 5-tupel (hetzelfde als TCP)

Stream Control Transmission Protocol (SCTP) is een ander transportprotocol dat poortnummers gebruikt en dus werkt met een 5-tupel.

maar hoe zit het met andere protocollen, IPsec bijvoorbeeld?

IPSec ESP (Encapsulating Security Payload) is een protocol dat geen bron/bestemming poortnummers bevat, dus we moeten terugvallen op een 3-tupel omdat het waarschijnlijk niet praktisch is om de payload van het protocol te begrijpen.

Figuur 13 – Bidirectionele 3-Tupel

Onze definitie voor een stroom is nu:

een flow is Een reeks van pakketten die informatie tussen twee hosts waar de pakketten hebben een gemeenschappelijke eigenschappen:

• Voor transport protocollen met poort nummers (ik.e.TCP/UDP/SCTP):

Alle pakketten in de flow delen dezelfde 5-tupel, of ook omgezet 5-tupel

anders:

Alle pakketten in de flow delen dezelfde 3-tupel, of omgezet, 3-tupel

Er is echter nog een andere factor om te overwegen – tijd.

vijfde poging – expiratie

een stroom bestaat slechts gedurende een bepaalde tijd. Het is mogelijk dat dezelfde 5-tupel (of 3-tupel) kan worden hergebruikt op een ander punt in de tijd, voor een andere stroom, tussen dezelfde hosts.

beschouw twee hosts waarbij de ene veel nieuwe TCP-verbindingen met de andere initieert. Elke nieuwe TCP verbinding krijgt een nieuwe bron poort, over het algemeen verhoogd met 1 van de vorige allocatie. IANA toewijzen het bereik 49152 tot 65535 voor deze kortstondige poorten, waardoor 16384 poorten. Na verloop van tijd zal de TCP bronpoort door het bereik rollen en de originele bronpoort worden hergebruikt, en deze flow zal dezelfde 5-tupel hebben als de originele flow. Dit is een probleem, want het is niet dezelfde stroom!

om dit op te lossen hebben we flows nodig die verlopen zijn wanneer er geen pakketten meer dan een bepaalde tijd worden gezien. Hier gaan we weer:

een stroom is een reeks pakketten die informatie bevatten tussen twee hosts waarbij pakketten gemeenschappelijke eigenschappen hebben:

• voor transportprotocollen met poortnummers (d.w.z. TCP/UDP / SCTP):

Alle pakketten in de flow delen dezelfde 5-tupel, of ook omgezet 5-tupel

anders:

Alle pakketten in de flow delen dezelfde 3-tupel, of omgezet, 3-tupel

• Alle inter-pakket keer minder dan willekeurige stroom verstrijken waarde voor time-out

Zesde Poging – Willekeurige Parameters

Soms wil je de verschillende parameters te identificeren stroomt, of deze kan worden afgedwongen door het type hardware/software in het netwerk.

in een Cisco-router worden stromen bijvoorbeeld geïdentificeerd door een 7-tupel die Type of Service (ToS) en input subinterface toevoegt aan de standaard 5-tupel. Er kunnen ook situaties zijn waarin layer-2 velden, zoals bron of bestemming MAC-adres, zinvol kunnen zijn als flow keys (hoewel merk op dat ze alleen lokaal significant zijn).

er zijn andere parameters die kunnen worden gebruikt als gemeenschappelijke eigenschappen voor de identificatie van de stroom; het is uiteindelijk aan de exploitant om te beslissen en de mogelijkheden van de apparatuur. Op basis hiervan verfijnen we de definitie verder:

een flow is Een reeks van pakketten die informatie tussen twee hosts waar de pakketten hebben een gemeenschappelijke eigenschappen:

• Voor transport protocollen met poort nummers (ik.e.TCP/UDP/SCTP):

Alle pakketten in de flow delen dezelfde 5-tupel, of ook omgezet 5-tupel

anders:

Alle pakketten in de flow delen dezelfde 3-tupel, of omgezet, 3-tupel

• Alle inter-pakket keer minder dan willekeurige stroom verstrijken time-out-waarde
• Kunt elke willekeurige parameters als flow toetsen, zoals ToS, interface, enz.

het allemaal inpakken

we hebben aangetoond dat het produceren van een enkele allesomvattende flow definitie een moeilijk probleem is. De definitie van de stroom is implementatiespecifiek, afhankelijk van de behoeften van de gebruiker en de mogelijkheden van netwerkapparatuur die de stroom meet.

in deel 2 van deze blogpost zullen we ingaan op verdere overwegingen voor flows zoals IPv6 flow labels, fragmentatie (IPv4 en IPv6 probleem..), encryptie, niet-IP pakketten en hoe stromen worden gemeten en gebruikt in andere systemen zoals SDN.

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

voor sommige gerelateerde papers, zie: 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 en https://is.muni.cz/th/hilnn/cse2009.pdf

voor relevante RFC, zie: https://tools.ietf.org/html/rfc5103

voor meer informatie over standaardisatie van QUIC, zie: https://datatracker.ietf.org/wg/quic/about/

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