[IPsec] tunnel met encryptie of zonder?

[vso]

inleiding
IPsec is een open standaard voor het leggen van tunnels en VPN's (wat het verschil is tussen een VPN en Tunnel ?? i dunno)
Ipsec kan je op 3 verschillende manieren gebruiken
1) transport (soort NAT achtige functie om te communiceren met een ander LAN)
2) tunnel (vaste verbinding met ander LAN)
3) Tunnel + encryptie (zie 2 alleen + encryprytie)

nu gebruik ik zelf met 2 vrienden een hele tijd een IPsec Transport verbinding via FreeBSD gateway's) geen encryprie, en alles draait eigenlijk vlekkenloos. onze Win2K domain's zitten via een Trust aan elkaar en alles verloopt vrijwel vlekken loos.

Het probleem:
Smoothwall is een kant en klaar produkt en gebruikt IPsec + Encryptie (3DES) (dus een tunnel) de andere partij(en) willen dit inzetten om een ster/ring topologie aan te leggen met ons. ze gebruiken 486's en hoger om smoothwall te draaien.
Wat ons een probleem lijkt is dat we de volgende problemen denken te verwachten.
- een tunnel is een constante factor die bandbreedte gaat eten (up+down) en meerdere tunnels geeft dus een verstopping van je bandbreedte
- encryptie kost meer CPU dan zonder (DOH) en beperkt dus zeer het aantal tunnels wat je aankan.

een voorbeeld (gelezen van het net)voor HTTP:
een HTTP server kan 1000 normal connecties aan maar 5 concurent encrypted connecties

de vraag is dus heb ik gelijk of zie ik dingen over het hoofd ? er staat zeer veel informatie op het web over IPsec maar weinig echt relevante zaken/praktijk voorbeelden waarmee ik mijn vraag kan beantwoorden.

[qless]

IPsec valt wel mee kwa zwaarte. Een 486 kan met gemak 100 Mbps via een VPN tunnel doen, dus met normale internetlinks is dat geen enkel probleem

(HTTPS is wat anders dan een VPN)

[Verwijderd]

qless schreef op 10 februari 2003 @ 11:49:
IPsec valt wel mee kwa zwaarte. Een 486 kan met gemak 100 Mbps via een VPN tunnel doen, dus met normale internetlinks is dat geen enkel probleem

(HTTPS is wat anders dan een VPN)

Ik weet niet over welke implementatie jij het hebt en of dat met of zonder encryptie is.

Uit de freeswan faq:

Is there a limit on number of tunnels?
There is no hard limit, but see next question.

Is a ... fast enough to handle FreeS/WAN with my loads?
A quick summary:

Even a limited machine can be useful
A 486 can handle a T1, ADSL or cable link, though the machine may be breathing hard.
A mid-range PC (say 800 MHz with good network cards) can do a lot of IPsec
With up to roughly 50 tunnels and aggregate bandwidth of 20 Megabits per second, it willl have cycles left over for other tasks.
There are limits
Even a high end CPU will not come close to handling a fully loaded 100 Mbit/second Ethernet link.
Beyond about 50 tunnels it needs careful management.

Freebsd implementatie kan beter zijn dan die van freeswan, maar je trekt met encryptie nooit 100mbit op een 486

[ Voor 6% gewijzigd door Verwijderd op 10-02-2003 12:20 ]

[vso]

Het gaat hier om een 486 met een DSL verbindig (1mbit) en ik denk dat eerder de verbinding dicht slipt dan dat de proccessor het niet trekt

maar zeker weten doe ik het niet

het kan ook zo zijn dat de proc eerder getaxed word dan de verbinding en dit is een beetje waar ik mee zit

wat wordt het eerst getaxed ? de verbinding of de proc en wat is de limit voor zo'n 486 ?
dit omdat we van plan zijn om met minimaal 5 tot 10 man op een verbinding te gaan zitten hangen en tja is het bv nog wel rendabel om te surfen ofzo ? ik ga uit van een 486@33mhz +16 mbram omdat dat nu de laagste spec is die ik gehoord heb.

--------------------------------------------------------------------------
wat ik draai is btw als gateway is een FreeBSD-Bak k6-2@450mhz met 128 mbram

[Verwijderd]

overhead van ipsec verkeer is max 10%

[LeNNy]

Ik heb IPsec in transport mode met een 3des encryptie getest tussen p3-600 w2k server en een p3-1ghz ws. Je trekt dan 2Mbyte/Sec met een 100% cpu load op de w2k server. Dat is dus zo'n 20Mbit op een p3-600.

Over IPsec in tunnel mode kan ik niets zeggen maar ik denk dat het niet veel verschilt met de transport mode.

IPsec Transport mode = encrypted ip verkeer in een lan /wan.
IPsec Tunnel mode = encrypted tunnel over een publiek netwerk. Verkeer is dan alleen versleuteld in de tunnel. Daarbuiten iet. Je netwerk is dan eigenlijk gewoon gesegmenteerd.

IPsec is er in twee varianten, AH en ESP. AH = Athentication Header. ESP = encapsulate Security Payload. IPsec / AH kan NIET over een NAT verbinding gebruikt worden. ESP daarintegen wel. Dit komt omdat IPsec in AH mode ook de source en destination adressen encrypt. Nat wil dit aanpassen en daarom werkt AH niet met nat. ESP zorgt alleen voor dat de host die de data stuurt daadwerkelijk de host is die de ontvangen verwacht.

vergelijk ah / esp met encrypting en signing van mail.

[LeNNy]

Zonder encryptie zou een tunnel allen zin hebben als je je netwerk koppeld maar dat er geen belangrijke data overheen gaat. Routing issue. Met VPN wordt normaal IPsec in tunnel mode met encryptie bedoelt.

[vso]

LeNNy schreef op 14 februari 2003 @ 00:52:
Zonder encryptie zou een tunnel allen zin hebben als je je netwerk koppeld maar dat er geen belangrijke data overheen gaat. Routing issue. Met VPN wordt normaal IPsec in tunnel mode met encryptie bedoelt.

en hier gaat het nu net om wat is het verschil ? als ik 100 mb verstuur over een 1mbit lijn dan telt dus de encrypted versie meer CPU load.

maar hoeveel tunnels (dus zonder/nauwlijks data tussen de beide kanten) kan ik leggen op een gateway met een 1mbit lijn 486proc@66mhz en wat houd ik effectief over als te versturen data ..

[LeNNy]

vso schreef op 14 February 2003 @ 16:30:
[...]


en hier gaat het nu net om wat is het verschil ? als ik 100 mb verstuur over een 1mbit lijn dan telt dus de encrypted versie meer CPU load.

maar hoeveel tunnels (dus zonder/nauwlijks data tussen de beide kanten) kan ik leggen op een gateway met een 1mbit lijn 486proc@66mhz en wat houd ik effectief over als te versturen data ..

Uiteraard is met meer cpu load met een encrypted tunnel. Ik vraag me ook af of je 486 wel een 3des 1Mbit verbinding aankan... ik denk het zelf niet.

Je zult het gewoon moeten proberen. Ik heb er geen cijfers van.

[vso]

Waarom denk je van niet ? Niet om cru te wezen maar met gedachten heb weinig. het gaat trouwens om meerdere encrypted IPSec verbindingen, denk aan 4 of 8 ofzo zoals je misschien begrijpt heb ik wat data nodig waarop jij je "gedachtes"/beredennatie op basseerd.

[Verwijderd]

Ik heb je al een indicatie gegeven uit de freeswan faq, dus zoals al is gezegd probeer het. Meten is weten in dit geval, dus maak een testopstelling. Bedoel er is voor niet al teveel geld wel iets snellers 2e hands te vinden dan een 486.

[Verwijderd]

/leermode/
wie zou mij kunnen vertellen wat je met ipsec kan en waarvoor je het zou gebruiken?
/leermode off/

[Rukapul]

Ik ben voor m'n afstudeeropdracht met IPsec op FreeBSD machines in de weer geweest op Pentium Pro 200 MHz machines en die trokken echt maar een paar mbit/s met 3DES. Het aantal verbindingen dat zo'n oude doos met beperkte CPU en geheugen aankan onder FreeBSD is trouwens nog best aanzienlijk (tientallen).
Eerste optimalisatie die je kan doen is AES of ander cipher gebruiken wat minder CPU kracht vergt (3DES is erg slecht in software te implementeren).

Let op dat je niet te vaak IKE (re)negotiations doet op basis van PKI / certificaten, want die RSA operaties zijn nog een graadje erger dan 3DES. (Hoewel IKE met certificaten een mooiere oplossing is dan een shared secret.)

Als je perse aan een bepaalde transport mode gebonden bent (transport / tunnel) dan kun je nog overwegen om het zgn NULL encryptie algoritme te gebruiken, wat inhoudt dat je geen encryptie doet.

Over bandbreedte hoef je je geen zorgen te maken. Per pakket komen er maar een paar bytes bij, wat uitkomt op zo'n 5% overhead. (Packetfragmentatie komt wel veel voor door deze manier.)

[vso]

geen encryptie lijkt me inderdaad efficenter, wat ik gelukkig ook heb ondervonden in de praktijk op transport modus.

5% is idd niet zoveel maar als je bv 4 a 8 tunnels opzet dan kan het aardig oplopen IHMO ook kwa CPU power denk ik. daarnaast de inderdaad genoemd packetfragementatie die je krigjt met encryptie is ook geen voordeel. (we zitten helaas aan 3DES gebonden met smoothwall)

maar goed wat ik dus dacht en hier wederom bevestigd word, is dat gebruiken van encryptie over een tunnel maakt de verbinding traag maakt en redelijk veel overhead kost (zeker als voor een packet 1, 2 a 3 packets extra verstuurd moeten worden)