site-to-site ipv6 koppelingen met encryptie?

[axis]

Ik wil het graag hebben over hoe men in de enterprise koppelingen maakt (of straks zal gaan maken) tussen bedrijven (of vestigingen) met ipv6 op een veilige manier.

IPv6

Ik werk al jaren met ipv6, en in verschillende datacentra (waar we wat racks huren) hebben we ipv6 uitgerold. Als contentprovider zijn de meeste van de webapplicaties die we maken en hosten native beschikbaar over ipv6, al dan niet achter ipv6-enabled proxies. Dat werkt allemaal prima, ik heb de afgelopen jaren veel geleerd en ervaring opgedaan met ipv6, en dat zal hopelijk de komende tijd doorgaan. (Beter nu op mijn gemak dan straks hals over kop moeten.) Onze klanten en leveranciers hebben meestal nog nooit ipv6 aangeraakt, maar dat zal in de toekomst vast veranderen

Site-to-site koppelingen met IPv4

De defacto standaard voor het koppelen van netwerken is de ipsec site-to-site vpn (of meer recentlijk de SSL vpn). Hierbij spreken 2 bedrijven met elkaar af welke subnets ze met elkaar willen delen (al dan niet genat e.d.), ze spreken parameters met elkaar af zoals welke encryptie te gebruiken, de endpoints, en een gedeeld geheim zoals een preshared key of certificates. Ik heb een stuk of 30 site-to-site vpn's draaien met klanten en leveranciers, waar allerlei interne rfc1918 netwerken gerouteerd worden. Dit draait (aan onze kant) allemaal op Cisco ASA5505's en ASA5510's, onze klanten en leveranciers draaien alles wat je maar kunt bedenken (cisco, juniper, 3com, etc).

Site-to-site koppelingen met IPv6?

De bovenstaande 2 concepten zijn me helder. Als ik echter in de toekomst koppelingen tot stand wil brengen, zal dat wellicht op een andere manier gaan gebeuren. Als ik nu een koppeling met een klant tot stand wil brengen, gaan we om tafel zitten en overleggen we welke netwerken we aan elkaar willen knopen (bij ons bijvoorbeeld 10.2.3.0/24 en aan zijn kant bijvoorbeeld 172.16.45.64/26), en maken we een site-to-site vpn. Maar als we in de toekomst aan beide kanten publicly routeable ipv6 adressen hebben (en misschien niet eens ipv4 meer), hoe doen we dat dan?

Voorbeeldje: Stel dat ik mijn 2001:xxx:123::/64 zou willen koppelen aan 2001:xxx:456::/64 bij de klant.

Je zou exact dezelfde ipsec site-to-site vpn kunnen opzetten, en dan die bovenstaande subnetten eroverheen routeren. Op mijn Cisco ASA kan ik in de ASDM niet eens ipv6 traffic toevoegen aan crypto maps. Zo te zien is dit wel een feature van de ASA 8.3.x software (waarvoor je ook geheugen in je ASA's moet upgraden), maar dit werkt alleen tussen ASA's, niet met andere partijen. Geen oplossing voor ons dus.

Je zou ook kunnen kiezen om slechts een rule in de firewalls te maken, aangezien end-to-end communicatie op routing-niveau al mogelijk is. Maar dan heb je nog geen encryptie. Dat kan dan weer met ipsec, maar hoe configureer je dat? Ik lees hier over virtual tunnel interfaces in IOS, maar wij gebruiken weer enkel ASA's..

Ik vraag me vooral af wat industry best practices zijn (ik kan ze niet vinden), en hoe jullie hiermee omgaan.

[Bigs]

Daarvoor zit ESP in de IPv6 standaard. Ik weet nog niet hoe IPv6 nu eigenlijk overal geïmplementeerd gaat worden, maar ik verwacht dat elke site gewoon een publieke /64 krijgt (en dus geen ULA's gebruikt) en dat je dus in je router ESP tussen twee van die netwerken inschakelt.

Ik vraag me af of iemand dit in de praktijk al in gebruik heeft. De implementatie van ESP is volgens de IPv6 spec wel verplicht, met minimaal DES (ja single DES) als cipher.

[ Voor 6% gewijzigd door Bigs op 12-05-2010 17:10 ]

[Verwijderd]

Volgens mij zie je het verkeerd.

Of ip's nu wel of niet genat zijn, er zit vast en zeker een firewall tussen. Je kan straks een publieke /64 gebruiken door een tunnel heen routeren, wel of niet encrypted maakt niet uit. Het enige verschil is dat je meer met firewalls moet werken, en niet van de zogenaamde "veiligheid" van NAT uit kan gaan.

[axis]

Verwijderd schreef op zondag 16 mei 2010 @ 17:40:
Volgens mij zie je het verkeerd.

Of ip's nu wel of niet genat zijn, er zit vast en zeker een firewall tussen. Je kan straks een publieke /64 gebruiken door een tunnel heen routeren, wel of niet encrypted maakt niet uit. Het enige verschil is dat je meer met firewalls moet werken, en niet van de zogenaamde "veiligheid" van NAT uit kan gaan.

En hoe implementeer je die encryption precies? Wat voor keys gebruik je? Welke commando's tik je in op welke routers?

Het verhaal in mijn startpost is geen hypothetisch gewauwel, maar realiteit. Ik heb al bijna elke server en client op ipv6 draaien (tussen interne locaties en datacenters), en ik heb ook overal publicly routeable adressen. Het probleem is alleen dat ik er niet heel veel mee kan, omdat ik mijn servers niet wil managen over het internet zonder encryptie.

[CyBeR]

Heb je al gekeken naar gewoon een firewall die IPSec in tunnel mode doet als dst == andere site? Dwz, de packets die binnenkomen gewoon encapsuleert in een IPSec-crypted packet. Zie Wikipedia: IPsec.

Ik moet bekennen ook nog niet veel aandacht besteed te hebben aan IPSec in ipv6, maar volgens mij is dat een beetje 't idee…

[ Voor 26% gewijzigd door CyBeR op 17-05-2010 15:41 ]

[Verwijderd]

Had je al nagedacht over het feit dat je tunnel overbodig is geworden aangezien het verkeer al routeerbaar is ?

Transport mode zou daarmee dus moeten kunnen voldoen.

[CyBeR]

Zover ik 't begrijp is transport mode om van end-host naar end-host te crypten, terwijl tunnel mode iets is wat door 't netwerk gedaan wordt.

[Verwijderd]

CyBeR schreef op dinsdag 18 mei 2010 @ 20:53:
Zover ik 't begrijp is transport mode om van end-host naar end-host te crypten, terwijl tunnel mode iets is wat door 't netwerk gedaan wordt.

Niet geheel, tunnel mode encrypt en her encapsuleerd het gehele frame inclusief IP headers. Hiermee stop je dus complete ip fames in een end to end tunnel.

Met transport mode zeg je dat alleen de payload encrypt moet worden. Dit kan inderdaad door de betreffende nodes gedaan worden maar de tussenliggende routers / firewall's kunnen dit ook voor je doen.

http://www.cisco.com/en/U...tion/guide/ip6-ipsec.html zou meer duidelijkheid over de configuratie moeten bieden.

[ Voor 10% gewijzigd door Verwijderd op 18-05-2010 20:59 ]

[CyBeR]

De reden dat ik dat idee had is eigenlijk de volgende letterlijke wikipediabewoording:

Transport mode is used for host-to-host communications.

[axis]

Eigenlijk zou je inderdaad iets ertussenin in willen hebben, dus transport mode ipsec voor gerouteerd verkeer.. 't schijnt toch allemaal maar lastig te zijn.

Wat ik beetje denk te zien is dat cisco wil dat je hiervoor toch tunnels maakt, in de link van Mash_man (is ook dezelfde die ik in de TS noemde) leggen ze uit hoe je een VTI kunt maken, een virtual tunnel interface, waar je het verkeer over kunt laten lopen. Maar volgens mij is dat een proprietair protocol, en geen standaard. Zal nog eens verder lezen.

[Verwijderd]

CyBeR schreef op dinsdag 18 mei 2010 @ 21:04:
De reden dat ik dat idee had is eigenlijk de volgende letterlijke wikipediabewoording:

[...]

Begrijpelijk maar dat hoeft dus niet.