Mobiltat de l'entorn i arquitectura del projecte SECURity at the network EDge

Mobiltat de l’entorn i arquitectura del projecte SECURity at the network EDge Treball de final de grau Autor: Ferran P´ erez Gutierrez Director: Ren´ e Serral Graci` a 17 d’abril de 2017 Grau en Enginyeria Inform`atica Enginyeria de computadors Resum En el marc del projecte SECURED (SECURity at the network EDge),neix la necessitat d’implementar els mecanismes de mobilitat de l’entorn de l’usuari en l’arquitectura de confian¸ca que ofereix SECURED, de forma transparent a l’usuari. La planificaci´o ha estat acurada amb les necessitats del projecte i no s’han desviat gaire de la realitat. Els costos han estan ajustats dins de la partida pressupostaria de l’equip de la UPC. Es un projecte amb un valors de producci´o sostenible pel medi ambient, social i economic, segons la matriu de “la econom´ıa del bien com´un”[16], una proposta generada des de la FIB. Finalment la soluci´o proposada s’ha provat en el centre d’ensenyament S’Arenal, del municipi Platja de Palma. La prova pilot ha sigut un `exit, demostrant aix´ı que la soluci´o ´es exportable a qualsevol indret. i Resumen En el marco del proyecto SECURED (SECURity at the network EDge), nace la necesidad de implementar los mecanismos de mobilidad del entorno del usuari en la aqrquitectura de confianza que ofreze SECURED, de forma transparente al usuario. La planificacion ha estado acurada con las necesidades del proyecto i se ha deviado mucho de la realidad. Los costes han sido ajustados dentro de la partida presupostaria del equipo de la UPC. Es un proyecto con unos valores de producci´on sostenible para el medio ambiente, social i enomico, seg´un la matriz de l.la econom´ıa del bien com´un”[16], una propuesta generada des de la FIB. Finalmente la soluci´on propuesta se ha probado en el centro de ense˜nanza S’Arenal, del municipio Platja de Palma. La prueba ha sido un exito, demostrando de as´ı que la soluci´on es exportable a cualquier sitio. ii Abstract SECURED (security at the network edge) project fullfilled the need of implementing the user’s mobility mechanisms in the trusted architecture that SECURED offers, in a transparent way to the user. The planning has been careful to the needs of the project and has not deviated much from reality. The costs are adjusted within the budget items of equipment at the UPC. It is a project with sustainable production values for the environment, social and economic, as the matrix of l.la econom´ıa del bien com´un”[16] generated as a proposal from the FIB. Finally, the proposed solution has been tested in the training center of El Arenal municipality of Playa de Palma. The pilot was a success, showing that the solution is exportable anywhere. iii Agra¨ıments Agra¨ıments per a Diego Montero pe la seva ajuda incondicional, gracies aix`o he pogut avan¸car en el moment cr´ıtics del projecte. Tamb´e els meus agra¨ıments a Al´ıcia Vila pel temps que ha dedicat, amb un servidor, a posar en com´u les parts de cadac´u ha desenvolupat del projecte. I per ultim el meus agra¨ıments a Ren´e Serral Graci`a per l’oportunitat que m’ha brindat, per poder realitzar el TFG, dins d’un gran projecte com ha sigut SECURED, a m´es a m´es de la paci`encia que ha tingut amb mi. iv ´ Index 1 Introducci´o 1 1.1 Descripci´o del projecte .............................. 1 1.2 Actors implicats ................................. 1 1.2.1 Lider d’equip ............................... 1 1.2.2 Equip UPC ................................ 2 1.2.3 Altres socis ................................ 2 1.2.4 Beneficiari ................................. 4 1.3 Estat de l’art ................................... 4 1.3.1 Open-Flow ................................ 4 1.3.2 Virtualitzaci´o ............................... 4 1.3.3 VPN .................................... 4 1.3.4 Opendaylight ............................... 5 1.4 Estructuraci´o de document ........................... 5 2 Abast 6 2.1 Formulaci´o del problema ............................. 6 2.2 Objectiu ...................................... 7 2.3 Requeriments ................................... 7 2.3.1 Tecnologies ................................ 7 2.4 Abast ....................................... 7 2.5 Riscos i possibles solucions ............................ 8 2.5.1 Augment del temps en de depuraci´o .................. 8 2.5.2 Burocr`acia ................................ 8 2.5.3 Maquines de prova ............................ 8 2.6 Identificaci´o de lleis i regulacions ........................ 8 2.7 M`etode de treball ................................. 9 2.7.1 Desenvolupament semi-presencial .................... 9 2.7.2 Reunions de seguiment, de l’equip UPC ................ 9 2.7.3 Reunions de seguiment del projecte SECURED ............ 9 2.7.4 Proves i integraci´o de l’entorn ...................... 9 3 Planificiaci´o 10 3.1 Planificaci´o temporal ............................... 10 3.1.1 Descripci´o de les tasques ......................... 10 3.1.2 Diagrama de Gantt ............................ 12 v 4 Pressupost 16 4.1 Pressupost ..................................... 16 4.2 Identificaci´o i estimaci´o de costos ........................ 16 4.2.1 Equip de desenvolupament ....................... 16 4.2.2 Maquinari ................................. 17 4.2.3 Costos indirectes ............................. 18 4.2.4 Taula de costos .............................. 18 5 Arquitectura 19 5.1 Personal Security Application (PSA) ..................... 20 5.1.1 Tipus de PSAs .............................. 20 5.2 TEE ........................................ 21 5.3 Personal Secured Control (PSC) ........................ 21 5.3.1 Trusted Virtual Domain (TVD) ..................... 22 5.4 Comunicaci´o entre els elements ......................... 22 5.5 Personal Security Controller Manager (PSCM) ................ 22 5.6 Trusted Virtual Domain Manager(TVDM) ................... 23 5.7 Network Edge Device (NED) .......................... 23 6 Implementaci´o 24 6.1 Instanciaci´o .................................... 24 6.1.1 Abans d’implementar la migraci´o .................... 24 6.1.2 Passos de instanciaci´o del NED .................... 24 6.1.3 Escenari final ............................... 26 6.2 Implementacions realitzades per a la mobilitat ................ 27 6.2.1 T´unel VPN amb StrongSwan ...................... 27 6.2.2 Funcionalitats de mobilitat afegides a les classes existents ...... 27 6.2.3 La nova classe implementada: TVDMigration ............. 29 6.2.4 Noves funcionalitats incloses en les API REST gunicorns ....... 32 6.2.5 Parall.llelitazaci´o i control fluxe d’execuci´o de la mobilitat . . . . . . 33 6.3 Escenari final: Migraci´o ............................. 34 7 Proves de rendiment 37 7.1 Banc de proves .................................. 37 7.2 Funcionalitats afegides per la realitzaci´o del test ............... 38 7.3 Execucions .................................... 39 8 Resultats 40 8.1 Gr`afica de resultats ................................ 40 8.2 Interpretaci´o dels resultats ............................ 40 9 Sostenibilitat 41 9.1 An`alisi de sostenibilitat ............................. 41 9.2 Projecte en producci´o .............................. 42 9.3 Vida ´util i resultats ............................... 44 9.4 Riscs ........................................ 45 9.5 Avaluaci´o de la sostenibilitat .......................... 46 9.6 Conclusions .................................... 47 vi 10 Conclusions 48 10.1 Conclusions .................................... 48 10.1.1 Treball Assolit .............................. 48 10.1.2 Feina pel futur .............................. 48 A Resultats de les proves 50 B Codis del projecte 57 B.1 Codis amb funcionalitats afegides ........................ 57 B.2 Codi amb les noves funcionalitats de la mobilitat ............... 77 B.3 Bibliografia .................................... 88 Bibliografia 89 vii •Conduir el desenvolupament i la implementaci´o de la xarxa fonamental arquitectura de dispositiu de vora. 3. PTEL •Les activitats de desenvolupament i recerca en el disseny i l’avaluaci´o de l’arquitectura de SECURED, contribuint amb els requisits de la xarxa des de la perspectiva d’una operadora. •Recollida d’informaci´o i retroalimentaci´o dels usuaris finals. •Validaci´o t`ecnica de SECURED. •La difusi´o dels resultats del projecte. 4. TID •Contribuci´o a la definici´o de les necessitats i opcions d’arquitectura per a escenaris d’operador de xarxa. •Contribuir al disseny del servei de seguretat, davant escenaris heterogenis barreja equips de xarxa de llegat i nous nodes de vora, que incorporen tamb´e les normes de seguretat de l’operador i normes internes. •Proporcionar entorns de prova el real HW / SW en ´us dins de Telef`onica, i simular diferents tipus de mobilitat de tr`ansit. •Participen activament en l’estandarditzaci´o a trav´es dels `organs de TID. Fan l’an`alisi, avaluaci´o i validaci´o de la viabilitat de propostes en l’entorn m´es ampli d’Internet. 5. UNICRI •Ajudant en els requeriments de pagaments de part dels interessats, amb especial atenci´o a tres `arees principals de risc: en l´ınia de protecci´o de la inf`ancia, la lluita contra la delinq¨u`encia inform`atica, el suport continu dels usuaris d’Internet contra els r`egims autoritaris. •L’execuci´o del proc´es d’avaluaci´o amb les parts interessades. •Contribuint en l’especificaci´o de les pol´ıtiques sobre l’equilibri de la lluita contra la delinq¨u`encia inform`atica i la privacitat, la protecci´o dels nens en l´ınia i donar suport a la xarxa contra la censura i la vigil`ancia. •Avaluaci´o de la capacitat d’´us de la interf´ıcie d’usuari per a l’especificaci´o de la pol´ıtica. 6. VTT •La investigaci´o en les `arees de detecci´o d’intrusos i de forma an`onima. •Que porta tota la feina d’integraci´o. •Organitzar un laboratori de la integraci´o. •Difusi´o i explotaci´o a trav´es de xarxes nacionals i internacionals VTT. 3 1.2.4 Beneficiari Els beneficiaris directes del projectes son les pr`opies empreses de telecomunicacions que son socis del projecte. Indirectament, les universitats implicades podr`an fer us de part del projecte en noves vies de recerca. A m´es a m´es a el projecte un cop acabat es far`a public i es tindr`a acc´es a ell. 1.3 Estat de l’art Aquest projecte pret´en crear un producte que ofereixi una garantia de seguretat i portabilitat a qualsevol entorn. Per tant, gran part de l’arquitectura que es planteja ´es fer us de recursos de virtualitzaci´o i de pol´ıtiques d’enrutament basades en L’est`andard Open-FLow [3] 1.3.1 Open-Flow Open-Flow ´es un est`andard obert que permet als investigadors per executar els protocols experimentals en les xarxes de campus que fem servir cada dia. Open-Flow s’afegeix com una caracter´ıstica de commutadors Ethernet comercials, routers i punts d’acc´es sense fil, i proporciona un est`andard per permetre als investigadors a realitzar experiments, sense necessitat de venedors per exposar el funcionament intern dels seus dispositius de xarxa. Open-Flow actualment est`a sent implementat pels principals prove¨ıdors.‘ 1.3.2 Virtualitzaci´o La majoria de les m`aquines gesti´o d’usuaris i control de l’entorn, son maquines virtuals fent servir kvm, una soluci´o basada en el nucli Virtual Machine o KVM. ´ Es una soluci´o per implementar virtualitzaci´o completa amb Linux, formada per un m`odul del nucli (amb el nom kvm.ko) i eines en l’espai d’usuari, essent ´ıntegrament programari lliure. El Component KVM Per El nucli est`a incl`os en Linux des de la versi´o 2.6.20.[?] KVM permet executar M`aquines virtuals utilitzant imatges de discs durs que contenen Sistemes Operatius per Modificar. Cada m`aquina virtual t´e el seu propi hardware virtualitzat: discs durs, targetes gr`afiques, etc. A m´es a m´es farem us de Qemu, ´es un emulador de terminal de processadors per programari, que permet a un usuari simular un sistema complet dintre d’un altre. ´ Es programari lliure i ´es escrit per Fabrice Bellard. QEMU ´es un hypervisor i ´es similar a altres projectes com Bochs, VMware Worksation i PearPc.[4] 1.3.3 VPN La connectivitat entre l’usuari i l’entorn de SECURED es realitzara per un t´unel (VPN). Per tant es far`a servir StrongSwan. ´ Es una implementaci´o completa d’Internet Protocol Security (IPsec) per a Linux 2.6, 3.xi 4.x superior. L’objectiu del projecte ´es de tenir mecanismes d’autenticaci´o forts mitjan¸cant certificats de clau p´ublica X.509 i emmagatzematge asseguran¸ca opcional de claus en targetes intel·ligents a trav´es d’una interf´ıcie estandarditzada PKCS. [5] 4 S’utilizar`a l’extensi´o MOBIKE[18] IKEv2 (RFC 4555), que permet canviar el final del t´unel generat en la xarxa. I el plugin de mysql per suportar m´ultiples usuaris connectats. En el cap´ıtol 6s’aprofundir`a amb m´es detall de com s’ha implementat. 1.3.4 Opendaylight OpenDaylight [7] , es una plataforma SDN (Software-Defined Networking) de codi obert actual. Ser`a una soluci´o temporal utilitzada inicialment en el projecte per orquestrar una migraci´o d’una maquina virtual i per posar a punt el banc de proves. 1.4 Estructuraci´o de document A continuaci´o tenim un breu resum de com esta estructurat el document. Abast: Cap´ıtol on es formula el problema. Posteriorment s’expliquen els objectius per solucionar-lo, l’abast del projecte, riscos i possibles solucions que poden sorgir en el transcurs del projecte i el m`etode de treball que s’utilitzar`a. Planificaci´o: Cap´ıtol on es defineixen les tasques que s’han realitzat en el desenvolupament del projecte i el per´ıode dedicat. Arquitectura: Cap´ıtol on es far`a un resum de l’arquitectura del projecte SECURED, funcionalitats pr`evies a la implementaci´o i quin era l’escenari abans d’iniciar la implementaci´o de la mobilitat. Implementaci´o: Cap´ıtol on es parlar`a amb profunditat t`ecnica de totes les implementacions realitzades en el projecte. Jocs de proves: Cap´ıtol on s’exposaran tots els jocs de proves que es realitzaran, quines dades es recolliran, en quines condicions i les caracter´ıstiques de l’entorn de proves on es faran. Resultats: Cap´ıtol on mostrar´e les gr`afiques obtingudes dels jocs de proves explicats l’apartat anterior. Pressupost: Identificaci´o i estimaci´o de costos. Sostenibilitat: Cap´ıtol que s’explicar`a amb detall les avantatges mediambientals, socials i econ`omiques que aportaria el projecte, un cop finalitzat, aplicat en un situaci´o real. Conclusions: Cap´ıtol final on es mostrar`a fins a on s’ha arribat del projecte i futurs desenvolupaments. 5 Cap´ıtol 2 Abast Seguidament s’explicaran el requeriments que ha de complir el projecte per justificar la inversi´o de temps, inversi´o econ`omica i esfor¸c per assolir els objectius amb `exit. 2.1 Formulaci´o del problema Protecci´o dels dispositius m`obils d’amenaces d’Internet s’aconsegueix normalment mitjan¸cant la install.llaci´o de les eines apropiades (per exemple, antiv´ırics, tallafocs personal, control parental) en cada dispositiu. Aix`o, per`o, planteja diversos problemes, normalment es requereix un acc´es privilegiat al dispositiu, i molts cops les eines de protecci´o apropiades no estan disponibles per a totes les plataformes. Un altre problema observat es el programari que ofereix un servei de seguretat. Normalment es especific en cada dispositiu. Amb un equip inform`atics de sobretaula, incl`os port`atils, normalment el programari pot cobrir les necessitats, sempre i quan la connectivitat sigui en la mateix xarxa. Per tant nom´es que canviem de xarxa, aquesta aplicaci´o no sempre pot garantir la seguretat. En els dispositius m`obils, observem que el programari normalment es limitat. A m´es a m´es aquestes eines poden consumir molts recursos, sobretot quan estan connectat a les xarxes de telefonia m`obil, actualment el cost en consum de dades es elevat. El dispositius m`obils constantment estan canviant d’una xarxa a una altre, independent que sigui el punt d’acc´es wifi de l’empresa, com la xarxa de l’operadora de telef`onica que es tingui contractada. L’usuari no sap i desconeix que el canvi de xarxa sigui vulnerable pel seu dispositiu. Un problema emergent, es protegir les generacions m´es joves d’amenaces o acc´es a contingut no apropiat per la seva edat. Els tutors legals no tenen cap eina per controlar i protegir aquest sector de la societat vulnerable. Tot aix`o, tradueix en la protecci´o insuficient pels usuaris amb una alta mobilitat, on els seus dispositius no pot garantir una connectivitat segura o controlada si ´es el cas d’un menor. 6 2.2 Objectiu El projecte SECURED proposa una arquitectura innovadora per aconseguir protecci´o contra les amenaces d’Internet mitjan¸cant la desc`arrega i l’execuci´o de les aplicacions de seguretat en un dispositiu programable pr`oxim al dispositiu de l’usuari, com un punt d’acc´es o un router de l’empresa. L’arquitectura SECURED crea un ambient de confian¸ca i virtualitzat que permet l’execuci´o de diferents actors (per exemple, els usuaris individuals, administradors de TIC corporatius, prove¨ıdors de la xarxa) per a instal·lar sota demanda i executar m´ultiples aplicacions de seguretat en el dispositiu que far`a de punt d’acc´es a la xarxa, per protegir el tr`afic d’un usuari espec´ıfic. Aquesta soluci´o redueix la c`arrega i consum en els dispositius m`obils, el que garanteix el compliment de les pol´ıtiques d’usuari espec´ıfics i independents del dispositiu de seguretat, i protecci´o uniforme a trav´es de diferents dispositius i xarxes. Mecanismes de transici´o entre xarxes es defineixen tamb´e per suportar els dispositius de xarxa tradicionals i implementar aquesta nova tecnologia de forma incremental. S’ha de garantir que tota arquitectura de l’entorn que sustenta la sessi´o de l’usuari es pugui replicar en el moment que l’usuari es connecti a un altre punt d’acc´es a la xarxa . Aix`o implica migrar tot l’entorn virtualitzat, en calent. Totes les pol´ıtiques d’encaminament de les dades de l’usuari s’han de regenerar en el dest´ı on es migrar tot l’entorn de l’usuari. El projecte tamb´e ser`a capa¸c de fer complir les pol´ıtiques de seguretat sota demanda, no nom´es quan l’empleat est`a connectat a la xarxa de l’empresa, sin´o tamb´e quan aquest estigui en moviment. 2.3 Requeriments 2.3.1 Tecnologies La connectivitat entre l’usuari i l’entorn que ofereix SECURED ha d’estar encriptat, per aix`o es realitzara una connexi´o segura VPN. Tecnologies de virtualitzaci´o kvm i qemu han de permetre una migraci´o rapida de l’entorn. Les regles d’encaminament siguin f`acils de replicar d’un punt d’acc´es a un altre. Per l’usuari ha de ser transparent i no ha de notar els canvis quan canvia de punt d’acc´es. 2.4 Abast El resultat del projecte es oferir una soluci´o c`omode, transparent i segura de connectar-se a Internet. L’usuari no s’ha de fer c`arrec de la seguretat, ja s’encarregara l’entorn que l’hi oferiria una operadora telef`onica. I tindr`a mobilitat total sense preocupar-se de perdre connectivitat, amb l’afegit de la seguretat que ofereix l’entorn. 7 2.5 Riscos i possibles solucions Durant el projecte es poden donar algunes situacions problem`atiques. Per cada una d’aquestes s’intentar`a donar soluci´o apropiada: 2.5.1 Augment del temps en de depuraci´o Es un projecte de recerca, per tant es fa us de totes les eines m´es noves possibles per desenvolupar el projecte, aix`o comporta un temps bastant elevat en depurar el correcte funcionament de tot l’ecosistema. Soluci´o: Plantejar el pitjor escenari i sempre treballar amb les ultimes versions estables de les tecnologies que farem servir i donar marge enorme en el moment de depurar abans de consumir el temps abans del seg¨uent pas. 2.5.2 Burocr`acia El projecte dep`en del finan¸cament de l’Uni´o Europea, cada soci te un pressupost diferent. Si en l’equip UPC es necessari obtenir nou maquinari que supera el pressupost, llavors estar´ıem parlant d’una limitaci´o alhora de poder realitzar proves. Soluci´o: Ajustar-se al m`axim amb les possibilitats que dona la partida pressupostaria per cada soci. Justificar obtenci´o de nou material fer una previsi´o de si aquest material ser`a ´util fins al final del projecte. Si escau, reciclar els equips, que inicialment tenien una funci´o que ja no calen desenvolupar,per destinar-los a altres funcions que s´ı ´es necessari prioritzar per optimitzar recursos. 2.5.3 Maquines de prova Tot l’entorn s’ha de provar en una serie de maquinari que ha d’estar en perfectes condicions, perqu`e si falla es genera un problema m´es a l’hora de desenvolupar. Soluci´o: Provar primer que el maquinari estigui en perfectes condicions per construir un entorn de proves. Amb un sistema operatiu net, sense cap configuraci´o, excepte la que requereixi per realitzar les proves. 2.6 Identificaci´o de lleis i regulacions Pel que fa a les lleis i regulacions, aquest projecte no n’afegeix respecte el sistema actual, ja que el projecte es basa en construir un sistema que garanteixi la seguretat de les dades de l’usuari. Per tant, les lleis del tipus LOPD [6] es respecte perqu`e les dades sensibles dels usuaris mai son revelades i un cop l’usuari es desconnecta es destrueixen. 8 2.7 M`etode de treball 2.7.1 Desenvolupament semi-presencial La major part del projecte es dur a terme a l’oficina, ja que les m`aquines estan en un entorn de prova que nom´es ´es accessible des de les install.llacions de la UPC, per fer les proves d’integraci´o s’ha de realitzar presencialment. El desenvolupament es pot realitzar a dist`ancia, amb l’inconvenient que la verificaci´o de les noves implementacions s’han de realitzar presencialment sobre les maquines de prova. 2.7.2 Reunions de seguiment, de l’equip UPC Es fan reunions de seguiment peri`odiques, a nivell equip intern de la UPC, amb el lider d’equip amb la finalitat de comprovar l’evoluci´o de la nostre part dins del marc projecte SECURED. En aquestes reunions s’exposaran tant els avan¸cos com les possibles problem`atiques que puguin sorgir i es tracen accions per solucionar-ho per assolir els objectius. 2.7.3 Reunions de seguiment del projecte SECURED Es fan reunions de seguiment mensuals, on es reuniran els l´ıders de projecte de cada equip amb el director del projecte de amb la finalitat d’exposar la feina realitzada de cada part del projecte. EL aven¸cos del que esta encara en desenvolupament. Finalment es detallen els pr`oxims objectius a realitzar amb de la seg¨uent reuni´o. 2.7.4 Proves i integraci´o de l’entorn 1. L’entorn de proves que es muntar`a per integrar la mobilitat de l’arquitectura SECURED, ser`a inicialment un entorn independent. Per tant es realitzar`a en un entorn controlat i limitat. 2. Un cop el sistema sigui consistent es s’integrar`a amb la resta dels components del projecte, com el PSAR[1] o la comunicaci´o amb el client. En el cap´ıtol d’arquitectura de SECURED aprofundirem amb m´es detall. 3. Un cop funcioni amb els altres components etapa de depuraci´o de tota L’arquitectura per optimitzar la migraci´o de les maquines virtuals, l’entorn i la reconnexi´o de l’usuari en l’entorn en un nou punt d’acc´es. 4. I recoll.llectar dades per tra¸car una gr`afica de temps en la migraci´o. 5. Per ´ultim queda fer una demostraci´o final amb tot l’ecosistema, en un entorn real. Pot ser un institut, universitat, etc. 9 Cap´ıtol 3 Planificiaci´o 3.1 Planificaci´o temporal En aquesta secci´o s’explicaran breument les tasques que s’han dut a terme durant el desenvolupament del projecte. Les tasques es descriuen en ordre cronol`ogic i s’aprofundeixen degudament en el cap´ıtol d’implementaci´o. Finalment podem veure gr`aficament les tasques amb el digrama de gantt, on es mostren els dies que s’han destinat a cada tasca. 3.1.1 Descripci´o de les tasques Per´ıode d’adaptaci´o a l’entorn del projecte SECURED Les primeres setmanes b`asicament es fa un estudi de l’arquitectura del projecte SECURED[1], per saber en quin estat est`a el projecte i veure quines seran les pr`oximes tasques, com per exemple l’´us de maquines virtuals per treballar amb l’entorn. Tamb´e quins s´on els llenguatges de programaci´o que es faran servir. En aquest cas principalment ser`a Python per desenvolupar tot el proc´es que involucra la migraci´o de l’entorn de l’usuari i la configuraci´o de les pol´ıtiques d’encaminament de les dades. Preparaci´o de l’entorn de proves Un cop assolit el coneixement de les eines i l’entorn, cal preparar el maquinari i el programari per realitzar el desenvolupament i posteriorment les proves de mobilitat del projecte SECURED. S’utilitzaran dos equips de format NUC [17] i un equip port`atil. Els NUCs es configuren com un punt d’acc´es. Aquests equips estan connectats entre ells, per simular una xarxa local, nom´es visible entre els equips. Aquests equips faran la funci´o de NEDs. Per provar el funcionament del testbed es fa servir una maquina virtual com orquestrador per simular la migraci´o d’una maquina virtual,amb opendaylight.[7]. Per fer la prova d’encaminament de dades es fa servir openvswitch.[8] Configuraci´o Strongswan Aquesta tasca consisteix en instal·lar i configurar Strongswan. S’ha fet servir la versi´o 5.4.0 [5]. S’ha utilitzat el m`odul de mobike, per tant s’ha reconfigurat perqu`e escolti pel 10 port 4500, en comptes del port 500. Aquesta tasca esta explicada en m´es detall en el cap´ıtol de la implementaci´o. Integraci´o de la mobilitat al projecte SECURED La tasca m´es important, per tant la que ha cobert la major part del projecte, ha estat la implementaci´o la nova nova classe del NED per realitzar la mobilitat de l’entorn de l’usuari (TVD), amb les seves PSAs i el PSC. Finalment, en el NED dest´ı es regeneren les pol´ıtiques d’encaminament openflow, gr`acies a informaci´o transmesa des del NED origen. I les maquines virtuals en dest´ı. Gran part d’aquest bloc de tasques del projecte s’expliquen m´es detalladament en el cap´ıtol de la implementaci´o, no obstant a continuaci´o es far`a un breu resum. Primera versi´o del script de migraci´o de les maquines virtuals Abans de res, es far`a una versi´o m´es senzilla per provar el funcionament amb un script o classe simple amb Python. Es provar`a en el entorn de proves. Un cop funcioni es passar`a a la seg¨uent tasca. Proves amb diferents tipus de migracions Es faran proves amb el script anteriorment creat fent c`alculs del temps que tarda, fer copies incrementals del disc dur d’origen a dest´ı, o fer una creaci´o nova de disc dur. Migraci´o temporal o persistent en dest´ı. Convertir les maquines virtuals en ”readonly”, etc. Tot aix`o servir`a per veure quina es l’opci´o m´es optima per dur a terme en la mobilitat del projecte SECURED. Adaptaci´o del codi de migraci´o de les VM Un cop es trobi l’opci´o amb menys cost de temps i recursos es crear`a una classe nova a l’orquestrador del NED, anomenada TVDMigration, que s’encarregar`a de fer la migraci´o quan sigui el moment. Programar la migraci´o de la inst`ancia del TVD Un cop s’ha aconseguit que la migraci´o de les maquines virtuals entre els NEDs, cal migrar i reinstanciar tot el TVD de l’usuari. Per realitzar les proves en el l’entorn de proves, s’improvisa un script en Python per simular l’aplicaci´o d’usuari, per simular la comunicaci´o amb el NED per realitzar la migraci´o. Integraci´o de la mobilitat amb l’aplicaci´o d’usuari L’aplicaci´o d’usuari envia un missatge REST[9] json[12]. Un cop rebut s’executa la nova classe TVDMigration, que s’encarrega de migrar tot l’entorn (PSAs, PSC, variables de la inst`ancia de l’usuari TVD). En primer lloc comen¸ca a migrar-se les PSAs, un cop migrades, es migra el PSC i finalment s’enviar`a un missatge REST json amb el TVD de l’usuari. Un cop acaben tots els events anteriors s’envia la resposta i tot seguit l’aplicaci´o baixa el t´unel strongswan en origen, seguidament es reconnecta al nou punt d’acc´es i finalment genera una nova connexi´o en dest´ı. Aquest punt s’explicar`a en detall en el cap´ıtol 6. 11 Millora i paral·lelitzaci´o del codi de mobilitat Un cop la mobilitat esta integrada amb l’aplicaci´o, es millora la comunicaci´o entre les dues parts, i es paral·lelitza el proc´es de migraci´o de les PSAs i es crea un fluxe estable del proces de mobilitat, que ser`a el seg¨uent. S’inicia un thread de migraci´o, dins d’aquest thread principal s’inicien n threads secundaris, un per cada PSAs, que realitzen paral·lelament la migraci´o de les PSAs. Un cop que aquests threads secundaris assoleixin un 80% de la migraci´o, envien un event al thread principal, aquest alhora s’inicia el thread secundari per realitzar la migraci´o del PSC. En aquest punt el NED d’origen envia al NED dest´ı, mitjan¸cant un missatge REST json el TVD de l’usuari. Un cop acaben i realitzen el join tots els threads amb un event continua l’execuci´o per enviar la resposta al l’aplicaci´o del client. Optimitzaci´o de la comunicaci´o entre l’aplicaci´o i el NED Un cop aconseguit l’objectiu d’optimitzar el temps d’execuci´o de la migraci´o, cal millorar la comunicaci´o de l’aplicaci´o i el NED perqu`e en el cas d’haver m´ultiples usuaris funcioni a la perfecci´o. Aquesta tasca s’explica de forma m´es detallada en el cap´ıtol d’implementaci´o. Depurar el codi per la demostraci´o de Mallorca El setembre del 2016 es fa una prova real a Mallorca, per tant es centra tots els recursos en mantenir estable tot l’entorn de mobilitat. En els annexes hi ha un enlla¸c a la noticia referent a la prova pilot realitzada al S’Arenal, de la web del Diario de Mallorca Recoll.llecci´o de dades per tra¸car un gr`afica de temps en la migraci´o Es modifica el codi per afegir timestamps per obtenir, de la forma m´es prec´ıs, els temps en la migraci´o de l’entorn. Aquest punt s’aprofundeix en el cap´ıtol de joc de proves i en el de resultats. Depurar el codi per la publicaci´o Per ultim es neteja el codi de comentaris, l´ınies de codi innecess`aries, es fa la redacci´o de la documentaci´o t`ecnica que es sol·licita per ser entregat al socis de POLITO per posar-ho de domini p´ublic. 3.1.2 Diagrama de Gantt 12 Cap´ıtol 5 Arquitectura El projecte SECURED t´e com a objectiu proporcionar una arquitectura innovadora per a la protecci´o d’amenaces externes dels dispositius, mitjan¸cant l’execuci´o de les aplicacions de seguretat m´es comunes en un dispositiu programable en els punts d’acc´es a la xarxa. En aquest cap´ıtol descriurem detalladament l’arquitectura global els components que la formen, fent especial `emfasi en el , , PSAs i el de l’usuari i el NED que engloba tots aquest elements En la Figura 5.1 observem la fotografia general del NED amb els components interns que seran descrits a continuaci´o. Figura 5.1: NED 19 5.1 Personal Security Application (PSA) La Personal Security Application ´es l’entitat at`omica de l’arquitectura SECURED. ´ Es responsable de fer complir una o m´ultiples pol´ıtiques de seguretat dels usuaris. Cada PSA esta composada per una s`erie de controls de seguretat. Aquesta realitza una serie d’operacions primitives orientades al processament de la xarxa, com ara el filtratge, segmentaci´o, c`arrega i reensamblatge dels paquets. Una pol´ıtica de seguretat complexa pot ser aplicada per un sol PSA o mitjan¸cant la connexi´o de m´ultiples PSAs. L’encadenament podria estar entre els PSA que s’executen dins de la mateixa TEE o entre PSAs que s’executen en diferents TEEs per`o pertanyents a la mateixa TVD. Una s`erie de PSAs connectats correctament a l’aplicaci´o d’un servei de seguretat implementa el concepte de feix de PSAs. L’arquitectura PSA internament s’ha de dividir en dos plans: Control-gesti´o i dades. 1. Control & Management plane: ´es la part del programari que proporciona les interf´ıcies cap al control i la part de gesti´o de la TEE per a la configuraci´o, monitoritzaci´o i peticions de senyalitzaci´o des de i cap al PSC. 2. Data plane: ´es la part de la PSA que est`a a c`arrec del processament en el tr`ansit d’entrada/sortida de l´ınia, proporcionant interf´ıcie per a la capa de comunicaci´o de l’entorn d’execuci´o i permetent intercanvi de paquets entre els diferents anuncis de servei p´ublic i tamb´e externament. La l`ogica interna del PSA es pot dividir en diferents m`oduls. 5.1.1 Tipus de PSAs Antiphising LA PSA anti-phishing[10], com b´e diu el seu nom, intenta identificar el contingut de suplantaci´o d’identitat continguda en p`agines web i correu electr`onic o bloquejar als usuaris ser enganyat. VPN corporate La PSA VPN corporate, et permet connectar a la xarxa de la teva empresa i sortir a Internet emulant que estas dins a la xarxa d’aquesta. Control Parental La PSA control parental, es el servei m´es potent pels pares per controlar els dispositius dels seus fills i evitar que entrin en llocs de contingut per adults i no desitjat. Altres Hi ha m´es tipus de PSAs, no obstant en el projecte de mobilitat es va treballar amb aquestes tres. Per tant nom´es esmentem que hi han m´es tipus de funcionalitats. 20 5.2 TEE Cada compartiment d’un usuari cont´e un entorn d’execuci´o. Aquest ambient ha de ser prou segur i de confian¸ca per separar les aplicacions concurrents sense interferir entre si. Es necessita un acc´es privilegiat per poder gestionar, configurar i iniciar les aplicacions. Les aplicacions es despleguen com veiem en la figura , en una `area sense privilegis del TEE. Figura 5.2: NED 5.3 Personal Secured Control (PSC) El controlador de seguretat personal (PSC) ´es el component que controla i gestiona el TVD, els agents d’usuari, configuracions i interf´ıcies de xarxa en nom d’un ´unic usuari. Cada usuari t´e la seva pr`opia inst`ancia d’un PSC dins del seu TVD, que captura tot l’estat de l’usuari i el context de la seva sessi´o. Ja que el PSC t´e el privilegi de carregar aplicacions i fer complir les configuracions, per exig`encies del disseny esta a¨ıllat de les aplicacions.Per tant totes les aplicacions relacionades amb l’usuari s’han de comunicar al seu PSC a trav´es d’una interf´ıcie de Control i Administraci´o restringit. No obstant aix`o, els canvis en la TVD global (com la creaci´o d’un nou TEE) requereixen l’enviament d’una sol·licitud a l’orquestrador, que ´es una entitat privilegiada extern fora de la TVD. Funcions principals: 1. Emmagatzema el gr`afic de servei abstracte (PSA) i les interconnexions de l’usuari; 2. determina la topologia de TVD (realitzaci´o del gr`afic de servei) dels requisits de PSA (aix`o pot canviar depenent dels recursos NED); 21 3. envia la topologia TVD a la TVDM (aquest ´ultim cont´e tota la topologia TVDs i com 1 TVD est`a connectat a un altre); 4. supervisa l’estat de la TVD (detectar per exemple si el TEE s’ha estavellat i necessita reiniciar); 5. PSC rep els manifestos de tots els anuncis de servei p´ublic i s’assigna a cada PSA a la perfecci´o. 5.3.1 Trusted Virtual Domain (TVD) El Trusted Virtual Domain ´es una abstracci´o l`ogica que no esta assignat a cap component f´ısic del NED. No obstant, proporciona la manera d’identificar tots els components que estan associats a un usuari. El TVD representa una porci´o a¨ıllada del NED que es dedica a un ´unic usuari i que inclou els diferents entorns d’execuci´o, les inst`ancies de interf´ıcies l`ogiques associades a un usuari, per implementar tot el data plane i l’encadenament dels serveis que aquest tingui configurat. El TVD de l’usuari ´es una partici´o l`ogica dins del host, per tant no es pot assignar a un component en concret des de la perspectiva de la implementaci´o. En canvi, la TVD es pot considerar com un conjunt de components que pertanyen a un usuari espec´ıfic. 5.4 Comunicaci´o entre els elements La comunicaci´o entre els PSC, PSCM, TVDM i el client es realitzan amb una API REST Gunicorn. ’Green Unicorn’ que ´es un servidor HTTP de Python Web Server Gateway Interface () per a UNIX. El servidor gunicorn ´es `ampliament compatible amb diversos frameworks web, simplement implementat, baix consum de recursos del servidor, i bastant r`apida. Entrarem en detall sobre les diferents APIs que s’ha modificat en el cap´ıtol de ?? 5.5 Personal Security Controller Manager (PSCM) El Personal Security Controller Manager ´es el conjunt de components encarregats de comunicar l’usuari amb el nivell de control (per tant el tr`ansit el usuaris que ser`a processat per una PSA no passa a trav´es del PSCM). Internament, est`a connectat principalment a la xarxa de control i de gesti´o que tamb´e connecta el NED a la SPM i als repositoris. El PSCM aprofita dos components principals: l’agent de confirmaci´o remot i el m`odul d’autenticaci´o, que s’utilitzen en les primeres etapes de la connexi´o d’usuari, que s´on l’establiment de connexi´o segura entre la terminal de l’usuari i el NED, i l’autenticaci´o d’usuari. Una vegada aquests passos es realitzen i s’atorga l’acc´es a l’usuari, el PSCM transfereix el testimoni de la sessi´o d’usuari al TVDM, que continuar`a la creaci´o de la inst`ancia TVD de l’usuari. Finalment, el PSCM informa de la resposta inicial de la creaci´o del TVD a l’usuari despr´es de rebre el TVDM. 22 5.6 Trusted Virtual Domain Manager(TVDM) L’orquestrador ´es el component de la presa de decisions que assigna recursos del TVD d’un usuari, crea les connexions d’aquest TVD, els seus connectors i la configuraci´o del seu data plane. No emmagatzema el context de l’usuari, per`o ha de ser capa¸c de recuperar f`acilment la topologia interna d’aquest en el NED (per exemple, configuraci´o de la xarxa i les m`aquines virtuals que tenia instanciades pr`eviament). 5.7 Network Edge Device (NED) Aquest component acull tots els components descrits en aquest cap´ıtol, i aplicacions de seguretat funcionant concurrentment, proporcionant un punt de control uniforme per a tots els dispositius connectats. Aquest administrador independent, segur i de confian¸ca pot actuar en diversos escenaris diferents, com en passarell.lles residencials, routers d’empresa, punts m`obils o d’acc´es p´ublic. L’arquitectura permet a diferents usuaris (per exemple usuaris individuals, administradors de TIC corporatius i xarxa prove¨ıdors) per instal·lar sota demanda i executar Personal Security Applications (PSA) dins del seu propi entorn d’execuci´o de confian¸ca i virtualitzat. El NED allotja i a¨ılla els entorns d’usuari, aix´ı com a¨ıllaments dels fluxos de tr`ansit del diferents usuaris. Els usuaris s´on capa¸cos de configurar el seus serveis a trav´es del seu propi () () del NED. Per tant, la seguretat arquitectura de la NED ha de ser acuradament dissenyada per fer front de forma segura les diferents necessitats. A m´es del NED, cal esmentar que tamb´e que hi ha entitats externes, com ara el gestor de PSAs (PSAM), el repositori de PSAs (PSAR) i el Security Policy Manager (SPM): s´on els serveis centralitzats dels usuaris descarregar o gestionar els seus serveis contractats i les pol´ıtiques de seguretat configurades. Els usuaris podran registrar-se amb i accedir a aquests serveis garantits i ser capa¸c de triar les pol´ıtiques d’alt nivell necessiten per a ser configurades. 23 Cap´ıtol 6 Implementaci´o Aquesta cap´ıtol tractarem totes les modificacions realitzades en el projecte SECURED per dur a terme la implementaci´o de la mobilitat. 6.1 Instanciaci´o Comen¸carem parlant de la instanciaci´o d’un usuari a l’entorn de SECURED. 6.1.1 Abans d’implementar la migraci´o En el moment que s’inicia l’etapa de desenvolupament i implementaci´o de la mobilitat del projecte de SECURED, ens torbem davant del seg¨uent l’escenari. L’usuari mitjan¸cant, via una interf´ıcie web, es pot connectar al NED, es crea un t´unel strongswan, per crear una canal de confian¸ca. No obstant, un cop instanciat no existeix la possibilitat de portabilitat i replicaci´o del TVD i la resta de l’entorn de l’usuari que s’acaba d’instanciar. Pot navegar, de forma controlada i segura, nom´es en el NED que fet l’autenticaci´o del seu usuari. 6.1.2 Passos de instanciaci´o del NED A continuaci´o s’explica de manera detallada, els passos principals d’un usuari per connectarse a Internet mitjan¸cant un NED: 1. Establir un canal de confian¸ca: aquest pas consisteix en dues fases: a la primera, l’usuari estableix una comunicaci´o segura amb el NED, en el segon, l’usuari comprova la identitat del NED i els components independents de l’usuari (PSCM, Administrador de directives, TVDM, NED management, etc.). 2. L’autenticaci´o de l’usuari: el NED aut`enticaa l’usuari utilitzant les seves credencials, si l’autenticaci´o t´e `exit, PSCM rep senyal de sessi´o posterior. 3. Sol·licitud d’inst`ancies TVD: PSCM demana al TVDM una inst`ancia de TVD b`asic per a l’usuari (i l’hi passa el testimoni de la sessi´o). Inicialment, la TVD inclour`a nom´es el PSC i ser`a llavors s’ampliar`a depenent de la gr`afica de servei de l’usuari. 4. Consulta PSC: el TVDM utilitza l’identificador de sessi´o a cercar el perfil d’usuari (PSC per la seva secci´o corresponent). 24 5. Creaci´o del TVD i inici PSC: El TDVM del NED crea el TVD i el PSC de l’usuari s’inicia. 6. Consulta del perfil de l’usuari: El TVDM recupera el perfil d’usuari (´es a dir, el resum gr`afic de servei d’usuari) de la SPM utilitzant el testimoni(token) de sessi´o. 7. Traduir pol´ıtiques, carregar el perfil d’usuari i configuraci´o de les PSAs: Si cal, a continuaci´o, just a temps, es porta a terme la configuraci´o de les politiques per l’Administrador de directives. Posteriorment, amb el gr`afic d’infraestructura, es fa la configuraci´o del perfil de PSAs i de l’usuari s’envien al PSC de l’usuari. 8. Obtenir anuncis de servei p´ublic: Abans de sol·licitar l’expansi´o TVD, q¨uestions PSC demanen a la TVDM per al PSA. El TVDM desc`arrega PSA de l’usuari utilitzant el token de sessi´o proporcionada. Mentre que els manifestos de PSA sempre es retornen al PSC, els PSA poden tamb´e carregar-se a aquest ´ultim si necessiten ser carregats manualment als TEES. 9. Es determina la topologia del TVD: el PSC de l’usuari the in frastructure graph, PSA configurades i manifest per determinar la topologia requerida per a la instanciaci´o del servei de l’usuari. 10. Sol·licitud d’expansi´o TVD: PSC envia una sol·licitud d’expansi´o del TVD al TVDM per crear noves interficies per a les PSAs. Aquesta petici´o s’emet a trav´es de la interf´ıcie de TVD MGMT. 11. Ampliar TVD: TVDM crea els TEEs sol·licitats en TVD de l’usuari, d’acord amb la informaci´o de sol·licitud del TVD d’expansi´o de l’usuari. 12. configuracio del TEE : PSC establir`a els tees adequadament i enviar-los a la xarxa configuraci´o (utilitzant la interf´ıcie Ctrl / Mgmt). Aix`o ´es necessari per connectar adequadament els m´ultiples anuncis de servei p´ublic que s’executen en el mateix ETE. 13. Configuraci´o a baix nivell de les PSAs : PSC carregar`a PSAs i la seva configuraci´o de baix nivell en els respectius TEE. A continuaci´o, s’iniciar`a PSC anuncis de servei p´ublic. 14. Tipus d’informe: PSC informa sobre el seu estat a la gesti´o de la NED i la segona realitza la certificaci´o segona etapa del PSC i anuncis de servei p´ublic. Llavors, la gesti´o NED genera un informe d’estat global i l’envia al PSCM. 15. Avaluaci´o d’usuari: terminal d’usuari rep informe d’estat des del PSCM, verifica informe d’estat est`a b´e, desconnecta la connexi´o PSCM. 25 Figura 6.1: Instanciaci´o 6.1.3 Escenari final Un cop finalitzada la implementaci´o de la mobilitat,de tot el que s’ha explicat en el punt anterior, excepte punt 1 i a m´es s’afageix un nou punt: 1. Establir un canal de confian¸ca: Ara es realitzara amb una aplicaci´o que funciona en l’equip del client (implementaci´o realitzada per la meva companya Al´ıcia).Juntament amb totes les implementacions noves a StrongSwan, l’aplicaci´o realitza la comunicaci´o amb el NED per iniciar el canal de confian¸ca. 2. Tots els punts, menys el nº1, descrits en la secci´o anterior. 3. Comprovaci´o de senyals: L’aplicaci´o va mirant totes les senyals dels NED pr`oxims, i va enviant crides REST al PSC per indicar que si cal o no cal inciar el proces de migraci´o. Despr´es d’explicar en detall totes les implementacions realitzades a nivell de codi i de funcionalitats internes del NED. Detallarem els seg¨uents punts funcionals de la migraci´o. 26 6.2 Implementacions realitzades per a la mobilitat 6.2.1 T´unel VPN amb StrongSwan Primer de tot la connexi´o havia de ser segura, es decideix utilitzar StrongSwan, una soluci´o basada en virtual protocol network. Es va compilar la versi´o 5.5 amb les seg¨uents extensions o plugins: MOBIKE L’extensi´o MOBIKE[19] IKEv2 (RFC 4555) permet un t´unel ja generat pugui canviar el seu punt d’anclatge de la xarxa. StrongSwan implementa MOBIKE observant les interf´ıcies, adreces i rutes. Si els canvis de configuraci´o, consultes de rutes es realitzen per trobar un cam´ı millor que l’actual i, si cal, el cam´ı es canvia mitjan¸cant una actualitzaci´o MOBIKE. strongSwan s’ha de canviar al port UDP 4500 a partir per que l’extenci´o MOBIKE fa us d’aquest port per la comunicaci´o d’aquest port perqu`e a partir de la sol·licitud de IKE AUTH, que inclou una notificaci´o MOBIKE SUPPORTED, encara que no s’ha detectat NAT. Plugin[?] SQL El plugin de SQL per Charon[?] permet emmagatzemar la configuraci´o de l’enlla¸c complet en una base de dades relacional. A m´es, el dimoni llegeix les credencials, com certificats, claus privades o contrasenyes de la base de dades per fer tot tipus d’autenticaci´o. El registre a la base de dades tamb´e ´es possible.Amb aquests dos elements obtenim la manera de preservar el t´unel en un canvi de configuraci´o inicial, en el moment de la migraci´o de l’entorn de l’usuari i amb el plugin mysql podem tenir un registre d’usuaris, per suportar m´ultiples usuaris connectats simult`aniament en un sol NED. Generem els usuaris amb les ips que seran assignades. Cada ususari tindr`a una ip de rang 10.2.1.x/32. 6.2.2 Funcionalitats de mobilitat afegides a les classes existents mainIPSEC.py S’ha afegit una ruta per la funcionalitat de migraci´o de la API gunicron del TVD. Fragment de codi 6.1: Nova ruta de la funcionalitat del TVDM 1app . add_route ('/migration ', orch ) S’ha modificat la ruta de que iniciava la instanciaci´o, amb un par`ametre nou. ´ Es el flag d’activaci´o de la migraci´o. Aquest flag controla si s’ha d’intancia tot l’entorn de l’usuari des de zero o ha de regenerar-lo Fragment de codi 6.2: Afegit nou par`ametre a la ruta de instanciaci´o 1orch = Orchestrator ( instantiator , migration ) I la instanciaci´o de la migraci´o Fragment de codi 6.3: Instanciaci´o de la migraci´o 1migration = TVDMigration ( instantiator , conf , logger ) Orchestrator.py Es l’orquestardor del TVD, es a dir, el ja esmentat TVDM en el cap´ıtol 5, es la API de la gunicorn de TVDM. Han sigut afegides noves funcionalitats. Ara quan captura una crida REST POST s’inicia amb la migraci´o de clients amb una crida REST POST que rep del PSC. 27 Fragment de codi 6.4: Funci´o on post() 1def on_post(self , request , response ): 2''' 3exclusive for migration 4''' 5try: 6self. instantiator . tvdm_receives_migration_request = datetime . utcnow (). strftime ("% Y -%m -% d %H :%M :% S.% f") 7args = request . stream . read () 8self. TVDMigration . instantiator . logger .info ( request . method + " " + request . uri + " " + args ) 9session = json . loads ( args , 'utf -8 ') 10 11 self. eventList [ session [" token "]] = Event () 12 self. handoverEvents [ session [" token "]] = Event () 13 migration = Thread ( name = session [" token "] , target = self. TVDMigration . init_migration , 14 args =( self. eventList [ session [" token "]] , self.handoverEvents[ session [" token "]] ,) , kwargs ={" session": session}) 15 migration . start () 16 response . status = falcon . HTTP_200 17 except: 18 self. TVDMigration . instantiator . logger . exception ( sys. exc_info () [0]) 19 response . status = falcon . HTTP_500 Tamb´e s’ha afegit la funcionalitat que captura crides REST GET per respondre al PSC si ha d’avisar al client si pot canviar de punt d’acc´es. Fragment de codi 6.5: Funci´o on get() 1def on_get(self , request , response ): 2''' 3Exclusive for migration , non - bloking query migration 4''' 5try: 6self. TVDMigration . instantiator . logger .info ( request . method + " " + request . uri ) 7user = request . get_param (" user ") 8action = request . get_param (" action ") 9 10 obj = {} 11 if action == " migration ": 12 if user in self. eventList . keys () : 13 self.TVDMigration.instantiator.logger.info(" user : %s , eventList : %s" % (str ( user ), str (self. eventList [ user ]. isSet () ))) 14 obj = {" status ": self. eventList [ user ]. isSet ()} 15 if self. eventList [ user ]. isSet () is True : 16 self.instantiator. tvdm_sends_migration_finished = datetime . utcnow (). strftime ("% Y -%m -% d % H:%M:%S.%f") 17 self. handoverEvents [ user ]. set () 18 else: 28 Figura 6.3: Migraci´o del PSC 5. TVDM respon al PSC: El PSC un cop s’ha iniciat la migraci´o, envia crides REST on get() per rebre una resposta positiva del TVDM. Quan el TVDM respon, el PSC recull el testimoni. 6. PSC respon al client: EL PSC respon al client que ja pot fer el canvi 7. Enviament del TVD: Instants despr´es d’iniciar la migraci´o del PSC, s’envia amb un missatge REST, un json amb tots el TVD del l’usuari per ser re-instanciat en dest´ı. Figura 6.4: Enviament del TVD 8. Re-instanciaci´o de tot l’entorn: Es re-inst`ancia tot el data-plane de l’usuari, es regeneren totes les interf´ıcies de l’usuari i la seva configuraci´o. 35 Figura 6.5: Re-instanciaci´o del TVD 9. El client canvia de AP i el punt final del t´unel: El client baixa el t´unel StrongSwan del NEd origen, es connecta al nou punt d’acc´es i aixeca el t´unel en el NED de dest´ı. 36 Cap´ıtol 7 Proves de rendiment En aquest cap´ıtol parlarem de l’entorn que s’ha configurat per realitzar les proves de rendiment de la implementaci´o de mobilitat realitzat al projecte SECURED. 7.1 Banc de proves L’entorn configurat consta de dos equips en format [17] i un port`atil, els dos nucs estan connectats entre elles per una xarxa local, amb una ´unica sortida a Internet, tal com v`eiem a la figura 7.1. Figura 7.1: Disseny conceptual del banc de proves Com es un disseny conceptual. Ja que l’element NAT no es mes que un glsgunicorn corrent en en el test ned 1. Aquesta maquina f´ısicament es l’´unic que te sortida a Internet. Per tant cada cop que s’efectua el canvi d NED, rep una ”sol.licitud amb la informaci´o necess`aria per saber per on ha de re-direccionar transit cap a un ned o un altre. Es va prendre aquesta soluci´o per estalviar recursos i afegir una tercera maquina f´ısica , amb la despesa econ`omica i energ`etica comportava, nom´es per realitzar aquesta funci´o. Finalment 37 tenim la taula seg¨uent amb la informaci´o b`asica de maquinari i programari instal·lats en les maquines que es fan servir per les proves. Equips Nom test ned 1 test ned 2 client Sitema/fabricant NUC5i5RYBAF NUC5i5RYBAF ASUS CPU Intel Core i5-5250U Intel Core i5-5250U Intel Core i5-2430M Mem`oria 8GB 8GB 4GB Distribuci´o Debian GNU/Linux 8 3.16.0-4-amd64 3.16.0-4-amd64 4.7.0-1-686-pae Taula 7.1: Caracter´ıstiques dels equips utilitzats 7.2 Funcionalitats afegides per la realitzaci´o del test S’ha afegit la llibreria datetime, fent us de la funci´o: 1datetime . utcnow () . strftime (\"\% Y -\%m -\% d \%H :\% M:\% S.\%f\") On ens retorna aquesta data amb aquest format: 2016-11-11 09:37:50.391198 Amb aquesta funci´o hem recopilat el temps exacte de les accions dels elements que intervenen en la migraci´o, sense notar cap penalitzaci´o de rendiment. Per tant s’ha afegit timestamps en tot el fluxe d’execuci´o, des de que el client reporta que ha de migrar fins que el t´unel StrongSwan s’ha tornar a crear en dest´ı: 1. CLIENT SENT REPORT: Instant de temps en que el client envia un missatge al PSC que ha d’iniciar el proces de migraci´o 2. PSC RECEIVED REPORT: Instant de temps en el que PSC rep el missatge del client. 3. PSC SENT MIGRATION REQUEST: Instant despr´es de la captura el missatge del client envia la sol.licitud d’inici de migraci´o al TVDM. 4. TVDM RECEIVED MIGRATION REQUEST: Instant de temps en el TVDM rep la solicitud de migraci´o 5. TDVM PSA INI/FIN: LEs seg¨uents marques es realitzen en paral·lel, per tantes PSAs tingui instanciades l’usuari (a) TVDM PSA INI: Instant de temps en el que inicia de la migraci´o de n PSA. (b) TVDM PSA FIN: Instant de temps en el que finalitza la migraci´o de n PSA. 6. TVDM PSC INI: Instant de temps que el PSC inici la seva migraci´o cap al NED de dest´ı 7. TVDM SENDS TVD: Instant de temps en el que el TVDM envia el TVD de l’usuari 8. TVDM PSC FIN: Instant de temps que el PSC ha acabat la seva migraci´o cap al NED de dest´ı 38 9. TVDM FINISHED MIGRATION: Instant de temps que ha acabat tot el proces de migraci´o per part del NED origen 10. TVDM SENT MIGRATION FINISHED: Instant de temps en El TVDM envia un missatge de finalitzaci´o 11. TVDM2 RECEIVED TVD: Instant de temps en que el TVDM del NED dest´ı rep el TVD que ha enviat el TVD del NED origen. 12. TVDM2 FINISHED INSTANTIATION PSAs: Instant de temps en el que acaba de re-instanciar totes les PSAs en el NED de dest´ı 13. TVDM2 FINISHED INSTANTIATION PSC: Instant de temps en el que acaba el PSC de re-instanciar-se en el NED de dest´ı. 14. PSC RECEIVED MIGRATION FINISHED: Instant de temps en el que el PSC re-instanciat rep el missatge de finalitzaci´o de la migraci´o, enviat previament pel TVDM del NED origen. 15. PSC SENT HANDOVER ORDER: Instant en el que just despr´es de rebre el missatge de finalitzaci´o de la migraci´o, envia l’ordre al client per faci el ”handover”. 16. CLIENT RECEIVED HANDOVER ORDER: Instant en el que envia l’ordre al client per faci el ”handover”. 17. CLIENT CLOSED TUNNEL: Instant en el que el client treu el t´unel amb el NED origen. 18. CLIENT CHANGED APS: Instant en el que el client esta fent el canvi de punt d’acc´es (es desconnecta del NED origen i es connecta al NED dest´ı) 19. CLIENT CREATED TUNNEL: Instant en el que el client aixeca el t´unel amb el NED dest´ı. I aqu´ı es finalitza tot el proces de migraci´o 7.3 Execucions La prova que s’ha realitzat s’ha fet amb un usuari amb dos PSAs instanciades, una amb el servei de VPN corporativa i una segona amb el servei de tallafocs. S’ha iniciat la recollllecci´o de dades quan ja portava realitzades un total de 5 migracions entre els dos NEDs. Cada marca de temps, fa la crida a la funci´o ja mostrada anteriorment i llavors el client recull aquests marques i genera un fitxer resultant amb totes les dades. S’ha realitzat unes m´ultiples execucions, en el llarg d’un mes i s’han triat grups de 5 all.lleatoriament, per aproximar al m`axim la fidelitat de les dades i no tinguem outlier que poguessin diferir molt. Els fitxers resultants es poden veure en els Annexes. En el seg¨uent cap´ıtol mostrarem els resultats i els analitzarem. 39 Cap´ıtol 8 Resultats 8.1 Gr`afica de resultats Figura 8.1: Resulats de les proves La gr`afica son totes proves realitzades, en el eix de les X tenim el temps i el eix Y s´onels timestamps que s’han coll.llocat en el codi, estan descrites en el cap´ıtol 7 8.2 Interpretaci´o dels resultats Com podem observar en els resultats, podem assegurar que el temps m`axim de migraci´o es d’uns 17 segons. Si s’escala la quantitats de PSAs Afectaria m´ınimament, ja que es realitza parall.llelament. Totes les proves s’han realitzat mentre el client estava visualitzant un v´ıdeo de Youtube. En ning´un moment s’ha tallat el v´ıdeo, la mobilitat ha esta en funcionament tota l’estona i el port`atil s’anava despla¸cant deliberadament per tota la zona on estava el banc de proves per for¸car la migraci´o. 40 Cap´ıtol 9 Sostenibilitat En aquest cap´ıtol es veur`a l’informe de sostenibilitat. El que aquest pret´en mostrar ´es una an`alisi de tots els efectes i despeses que generar`a el projecte SECURED abans, durant i posteriorment del seu desenvolupament. Com afectaran aquest en `ambits tant socials, econ`omics com ambientals per a poder-los valorar i considerar dins del projecte. 9.1 An`alisi de sostenibilitat Sabem que la sostenibilitat ´es un dels principals reptes d’aquest segle. Ens estem conscienciant dels efectes negatius que tenen les nostres accions sobre l’entorn, sabem de l’exist`encia dels l´ımits que t´e el planeta i de les injust´ıcies socials que es cometen cada dia, igual que de la import`ancia de treballar de manera sostenible. Tot i aix´ı el concepte de sostenibilitat segueix sent una mat`eria pendent, dif´ıcil de concretar i acotar. ´ Es per aquest motiu i per a poder realitzar un estudi de sostenibilitat correcte del projecte SECURED s’ha decidit utilitzar una matriu de puntuacions que s’obtenen a partir d’un llistat de preguntes que corresponen a cada part. L’an`alisi que s’efectua amb aquesta matriu ?? consta de tres parts: la part de posada en marxa del projecte, la part de vida ´util i resultats que t´e i per ´ultim els riscos que poden apar`eixer. Alhora, cada una d’elles s’analitzen des de les tres dimensions de la sostenibilitat: l’econ`omica, la social i l’ambiental. Per a la part posada en marxa del projecte, en la part que ens pertoca de l’equip UPC, mirant les tres dimensions, el que es busca ´es saber si s’ha considerat l’impacte de realitzaci´o del projecte, en l’apartat de mobilitat. Tant per aquelles beneficiaris, per aquells que el gestionen, per al planeta i tamb´e per a la nostra limitaci´o pressupostaria. Saber si s’ha estimat correctament i s’ha quantificat el cost que pot implicar i si s’han pres les mesures necess`aries per a reduir aquest impacte. En la part de vida ´util del projecte es pret´en veure com es resol en l’actualitat el problema a resoldre (com b´e s’ha descrit pr`eviament en el cap´ıtol Abast) i de quina manera millorar`a la situaci´o actual la implantaci´o de la nostra soluci´o. Tamb´e es vol saber quin ser`a l’impacte que produir`a durant la seva vida ´util i quin tipus d’impacte pot produir el projecte a l’hora del seu desmantellament. Per ´ultim, en la part de riscs el que es vol ´es aconseguir enumerar aquells escenaris que 41 s´on factors de perill per augmentar els impactes negatius que pot produir la consecuci´o del projecte i poder tenir un pla d’actuaci´o o saber de quina manera es podrien mitigar aquests efectes tant en la dimensi´o ambiental amb la petjada ecol`ogica, en la dimensi´o econ`omica amb la viabilitat del projecte o en la dimensi´o social amb el perjudici d’algun sector particular de la poblaci´o o la creaci´o de depend`encies. I aqu´ı tenim la matriu de sostenibilitat d’un projecte, de la que tant parlem, amb el seu rang de puntuacions possibles incl`os: Ambiental Econ`omic Social Projecte en producci´o An`alisi de recursos Viabilitat econ`omica Impacte personal Valoraci´o: [0:10] [0:10] [0:10] Vida ´util i resultats Petjada ecol`ogica Cost final Impacte social Valoraci´o: [0:20] [0:20] [0:20] Riscs Perjudicis ambientals Riscs econ`omics Perjudicis socials Valoraci´o: [-20:0] [-20:0] [-20:0] Valoraci´o: [-60:90] Taula 9.1: Matriu de sostenibilitat i puntuacions possibles Les puntuacions s’obtenen a partir de les reflexions i respostes generades per la bateria de preguntes que es correspon a cada casella. Aquesta matriu s’ha plantejat per a que es pugui fer servir en qualsevol projecte d’enginyeria. Les seves respostes donen lloc a l’informe de sostenibilitat del projecte. Qualsevol persona responsable d’un projecte ha de con`eixer i analitzar el seu projecte amb profunditat, saber on s’emmarca i els efectes derivats de la seva implantaci´o i desenvolupament. Considerem que aquest an`alisi t´e un pes important en el projecte i que ´es important recalcar la sotenibilitat del projecte dins el marc de la cooperaci´o per al desenvolupament. A partir d’aqu´ı es realitzar`a una discussi´o amb la intenci´o de donar les justificacions adients i poder realitzar una puntuaci´o correcta per a cada casella de la matriu. Es far`a per a cada part definida, la posada en producci´o del projecte, la vida ´util i els riscs possibles i s’acabar`a amb una avaluaci´o final i les conclusions d’aquest an`alisi. Per a titllar un projecte de sostenible s’ha d’aplicar una visi´o global que inclogui les tres dimensions de sostenibilitat (ambiental, social i econ`omica) i on s’hi vegin les relacions existents entre les tres components. Per aix`o s’analitzaran les dimensions i les seves interrelacions de forma com´u en les tres parts. 9.2 Projecte en producci´o Les preguntes a les que es vol respondre per a realitzar el plantejament de la sostenibilitat en la posada en producci´o del projecte s´on les que us presentem a continuaci´o: Dimensi´o ambiental: 42 •S’ha estimat l’impacte ambiental que tindr`a la realitzaci´o del projecte? Es pot minimitzar reutilitzant recursos? •S’ha quantificat l’impacte ambiental? Quines mesures s’han pres per a reduir-lo? •Quina ´es la proced`encia de les mat`eries primeres usades? El seu origen o fabricaci´o ´es `etic? •S’ha tingut en compte el desmantellament una vegada acabi la vida ´util del projecte? Dimensi´o econ`omica: •S’ha estimat el cost de realitzaci´o del projecte? •S’ha quantificat aquest cost? Quines decisions s’han pres per a reduir aquest cost? •S’ha ajustat al cost previst? La inversi´o inicial permetr`a que sigui competitiu. Dimensi´o social: •Quines aportacions t´e realitzar el projecte a nivell personal? •Ha implicat reflexions significatives a nivell personal, professional o `etic en les persones que han intervingut? •Quina ´es la situaci´o social i pol´ıtica del pa´ıs on s’implantar`a? •L’activitat realitzada afavorir`a o empitjorar`a aquesta situaci´o? Tot projecte d’enginyeria neix de la necessitat de resoldre un problema o de materialitzar una soluci´o. L’entorn de SECURED que es vol generar, ha de ser robust, econ`omicament viable, ha de tenir en compte el f`acil acc´es i l’us dels usuaris i ha de tenir un cost ambiental sostenible. Qualsevol projecte que hagi de ser portat a terme doncs, ha de ser subjecte a un estudi de viabilitat. Pel que fa al projecte SECURED, despr´es d’haver fet una avaluaci´o exhaustiva dels recursos materials i humans en el Cap´ıtol del pressupost, disposem d’una xifra estimada. Aquesta, manca de sentit si no relacionam aquests recursos amb l’impacte real que tenen en l’entorn. Per`o primer de tot, hem de tenir en consideraci´o que aquest ´es un projecte de cooperaci´o entre diferents universitats i empreses de telecomunicaci´o i que ha estat finan¸cat per la Uni´o Europea, no obstant cada equip rep un pressupost varitat, l’equip UPC es dels mes modestos. Un dels objectius primordials ha estat el que les despeses econ`omiques fossin les m´ınimes possibles. Donat aquesta situaci´o, s’ha de tenir en compte que el cost estimat que s’ha presentat no ´es un cost econ`omic real ja que gran part d’aquesta despesa s’ha realitzat en forma d’inversi´o, b´e sigui en hores de treball i dedicaci´o, en la disponibilitat per viatjar o en forma de donaci´o de material inform`atic en des´us per part de l’equip que han deixat el seu granet de sorra aportant un port`atil o components variats. ´ Es molt important remarcat que dins l’objectiu de dotaci´o tecnol`ogica la infraestructura aportada per les proves es nova, exceptuant el port`atil que s’ha utilitzat com a client. 43 Per`o un cop finalitzat aixo pot ser replicat en infraestructures ja en funcionament. Aix`o redueix l’impacte negatiu considerablement en les tres dimensions. Socialment, els beneficiaris no els dificultara el canvi de manera de conectar-se a la xarxa. Econ`omicament es produeix una petita inversi´o dels recursos humans a l’hora de la cerca i posada a punt, per`o n’elimina gaireb´e la totalitat d’inversi´o econ`omica. S’ha pagat la majoria del material per utilitzar-lo en aquest projecte, no obstant ser`a utilitzat a molt d’altres, una vegada que aquest conclogui.I finalment el consum el`ectric durant el seu ´us. Pel que fa al tema ambiental, hi podr´ıem dedicar un cap´ıtol sencer a l’impacte positiu de l’entorn, per`o hem volgut resumir-ho esmentant el m´es important. El fet de que l’entorn es vitualitzat en la seva totalitat, amb l’us d’ordinadors actuals, sense haver de comprar m´es aparells. Aix`o en redueix molt´ıssim l’impacte de triar una soluci´o diferent: s’eliminen els grans costs i recursos necessaris per la construcci´o de nova tecnologia. En definitiva, quan decidim que la soluci´o sigui un entorn virtualitzat. fem una contribuci´o a disminuir la nostra petjada ecol`ogica i no per aix`o disminu¨ım la qualitat ni solv`encia de la soluci´o trobada. Socialment tindr`a un gran impacte positiu perqu`e, encara que l’utilitzi algun grup redu¨ıt, la seguretat que aportara l’entorn de SECURED ajudara a protegir les dades sensibles de possibles o que es corrompin per la infecci´o d’un virus o la possible subtracci´o d’aquesta, estarem ajudant a totes aquestes persones a poder-se connectar de forma segura. Totes aquestes solucions i m´es reflexions s’han generat durant el proc´es de desenvolupament del projecte. Aquest ´es l’origen de l’impacte personal que he rebut a partir que hem vaig posar a donar suport en l’arquitectura i la mobilitat del projecte SECURED. Aquest projecte ´es de recerca i cooperaci´o, es situa un entorn molt diferent al d’una empresa amb finalitats lucratives, per tant la corba d’aprenentatge es elevada. Fins que no s’acaba el desenvolupament no veus com els resultats podrien afectar positivament a la societat. Sobretot el que s’ha apres m´es, es la necessitat de saber adaptar-te a diferents circumstancies de fer tot i que no siguin del teu grat i a qualsevol imprevist que hagi esdevingut. L’impacte que m’emporto s´on tots els coneixements que he obtingut i els aprenentatges dins i fora de la carrera, no podrien tenir millor escenari. 9.3 Vida ´util i resultats Les preguntes a les que s’intenta respondre per a la vida ´util del projecte s´on les seg¨uents: Dimensi´o ambiental: •Com es resol actualment el problema? En que millorar`a ambientalment la nostra soluci´o de les existents? •Quins recursos s’usaran durant la vida ´util del projecte? Quin ser`a l’impacte d’aquests? •El projecte permetr`a reduir l’´us de recursos? Globalment, millorar`a o empitjorar`a la petjada ecol`ogica? Dimensi´o econ`omica: •Com es resol actualment el problema? En que millorar`a econ`omicament la teva soluci´o? 44 Figura A.3: Execuci´o nº22 realitzada el 11-11-2016 Figura A.4: Execuci´o nº23 realitzada el 11-11-2016 Figura A.5: Execuci´o nº24 realitzada el 11-11-2016 51 Figura A.6: Execuci´o nº44 realitzada el 16-11-2016 Figura A.7: Execuci´o nº45 realitzada el 16-11-2016 Figura A.8: Execuci´o nº46 realitzada el 16-11-2016 52 Figura A.9: Execuci´o nº47 realitzada el 16-11-2016 Figura A.10: Execuci´o nº48 realitzada el 16-11-2016 Figura A.11: Execuci´o nº35 realitzada el 01-12-2016 53 Figura A.12: Execuci´o nº36 realitzada el 01-12-2016 Figura A.13: Execuci´o nº37 realitzada el 01-12-2016 Figura A.14: Execuci´o nº38 realitzada el 16-11-2016 54 Figura A.15: Execuci´o nº39 realitzada el 01-12-2016 Figura A.16: Execuci´o nº26 realitzada el 14-12-2016 Figura A.17: Execuci´o nº27 realitzada el 14-12-2016 55 Figura A.18: Execuci´o nº28 realitzada el 14-12-2016 Figura A.19: Execuci´o nº29 realitzada el 14-12-2016 Figura A.20: Execuci´o nº48 realitzada el 14-12-2016 56 Ap`endix B Codis del projecte B.1 Codis amb funcionalitats afegides Fragment de codi B.1: mainIPSEC.py 1''' 2Created on 23/ mag /2014 3 4@author : rbonafiglia 5 6Main script to launch from gunicorn to star the orchestrator WSGI server 7''' 8import falcon 9import Config 10 from Orchestrator import Orchestrator 11 from GraphInstatiator import GraphInstantiator 12 from PSAcreation import PSAcreation 13 from GraphInfo import GraphInfo 14 from PSAConf import PSAConf 15 ### migration code ### 16 from TVDMigration import TVDMigration 17 ### 18 from VerifierCache import VerifierCache 19 import logging 20 import datetime as dt 21 import signal 22 import sys 23 24 # TODO : control if there are sessions open , if true close them 25 class MyFormatter ( logging . Formatter ): 26 converter = dt . datetime . fromtimestamp 27 def formatTime (self , record , datefmt = None): 28 ct = self. converter ( record . created ) 29 if datefmt: 30 s = ct . strftime ( datefmt ) 31 else: 32 t = ct . strftime ("%Y -%m -% d %H :% M:% S") 33 s = "%s ,%03 d" % (t, record .msecs ) 34 return s 35 36 57 37 conf = Config . Configuration () 38 # logging . config . fileConfig ( conf . LOG_FILE ) 39 logger = logging . getLogger ( __name__ ) 40 logger . setLevel ( logging . DEBUG ) 41 42 fh = logging . FileHandler ( conf . LOG_FILE ) 43 fh . setLevel ( logging . DEBUG ) 44 45 console = logging . StreamHandler () 46 47 formatter = MyFormatter (fmt = '%( asctime )s %( message )s ',datefmt='%Y -%m -%d ,%H :%M :% S.%f ') 48 fh. setFormatter ( formatter ) 49 console . setFormatter ( formatter ) 50 51 logger . addHandler ( console ) 52 logger . addHandler ( fh ) 53 # logging . basicConfig ( filename = conf . LOG_FILE , level = logging . DEBUG , format='%( asctime )s %( message )s ', datefmt='%m/%d/%Y %I:%M:%S % p') 54 logger . info (" --- --- --") 55 logger . info (" NED / TVDM init .") 56 logger . info (" NED / TVDM VERSION : " + str (conf . TVDM_VERSION )) 57 logger . info (" --- --- --") 58 # Falcon starts 59 60 app = falcon . API () 61 instantiator = GraphInstantiator (conf , logger , True) 62 ### start migration code ### 63 migration = TVDMigration ( instantiator , conf , logger ) 64 ### end migration code ### 65 def signal_term_handler ( signal , frame ): 66 logger . info (" SIG TERM ") 67 if instantiator . signal_term_handler () : 68 logger . info (" FINISH DESTROY ALL TVD ") 69 sys. exit (0) 70 71 signal . signal ( signal . SIGTERM , signal_term_handler ) 72 ### migration code -> added parameter migration ### 73 orch = Orchestrator ( instantiator , migration ) 74 ### 75 76 ### Verifier cache 77 vc = VerifierCache ( conf ) 78 vc . start () 79 app . add_route ('/verify', vc) 80 81 app . add_route ('/instantiateTVD ', orch ) 82 ### migration code -> added new call ### 83 app . add_route ('/migration ', orch ) 84 ### 85 psa = PSAcreation ( instantiator ) 86 app . add_route ('/createPSA ', psa ) 87 88 graph = GraphInfo ( instantiator , conf . USER_GRAPH_LOCATION , conf ) 89 app . add_route ('/getGraph', graph ) 58 90 91 psaConfRes = PSAConf ( conf . PSA_CONF_LOCATION , logger , conf , instantiator) 92 app . add_route ('/ getConf /{ psa_id }/{ conf_id }', psaConfRes ) Fragment de codi B.2: Orchstrator.py 1import falcon 2import json 3from threading import Thread 4from threading import Event 5import thread 6from GraphInstatiator import GraphInstantiator 7import logging 8import sys 9import subprocess 10 import time 11 from datetime import datetime 12 13 14 class Orchestrator(object): 15 ''' 16 Orchestrator class that intercept the REST call through the WSGI server 17 ''' 18 19 def __init__(self , instantiator , TVDMigration ): 20 ''' 21 Constructor 22 ''' 23 self.instantiator = instantiator 24 self.TVDMigration = TVDMigration 25 self.migrate = False 26 self. eventList = {} 27 self.handoverEvents = {} 28 self.obj = {} 29 self. obj2 = {} 30 31 def on_delete ( self , request , response ): 32 try: 33 args = request . stream . read () 34 self. instantiator .logger .info ( request . method + " " + request .uri + " " + args) 35 session = json . loads ( args , 'utf -8 ') 36 token = self. instantiator . IPandUser [ session [" IP "]] 37 newTVD = Thread(target=self. instantiator . deleteUser , kwargs ={" session ": session }) 38 newTVD . start () 39 response . status = falcon . HTTP_200 40 except Exception as e: 41 self. instantiator . logger . exception (sys . exc_info () [0]) 42 response . status = falcon . HTTP_501 43 44 ###### start migration code ############ 45 46 def on_put(self , request , response ): 59 47 ''' 48 shared by the instantiation and migration of TVD 49 ''' 50 try: 51 self. instantiator . timestamps [" tvdm2_recieves_TVD "] = datetime . utcnow (). strftime ("% Y -%m -% d %H :%M :% S.% f") 52 args = request . stream . read () 53 session = json . loads ( args , 'utf -8 ') 54 self. instantiator .logger .info ( request . method + " " + request .uri + " " + json. dumps (session , indent =4, sort_keys = True)) 55 if "action" in session: 56 if session [" action "] == " TVD ": 57 newTVD = Thread(target=self.instantiator. instatiateTVD , kwargs ={" session ": session }) 58 newTVD . start () 59 response . status = falcon . HTTP_200 60 else: 61 self. instantiator . timestamps = session [" timestamps "] 62 response . status = falcon . HTTP_200 63 else: 64 newTVD = Thread(target=self.instantiator. instatiateTVD , kwargs ={" session ": session }) 65 newTVD . start () 66 response . status = falcon . HTTP_200 67 except Exception as e: 68 self. instantiator . logger . exception (sys . exc_info () [0]) 69 response . status = falcon . HTTP_501 70 71 def on_post(self , request , response ): 72 ''' 73 exclusive for migration 74 ''' 75 try: 76 self. instantiator . tvdm_receives_migration_request = datetime . utcnow (). strftime ("% Y -%m -% d %H :%M :% S.% f") 77 args = request . stream . read () 78 self. TVDMigration . instantiator . logger .info ( request . method + " " + request . uri + " " + args ) 79 session = json . loads ( args , 'utf -8 ') 80 81 self. eventList [ session [" token "]] = Event () 82 self. handoverEvents [ session [" token "]] = Event () 83 migration = Thread ( name = session [" token "] , target = self. TVDMigration . init_migration , 84 args =( self. eventList [ session [" token "]] , self.handoverEvents[ session [" token "]] ,) , kwargs ={" session": session}) 85 migration . start () 86 response . status = falcon . HTTP_200 87 except: 88 self. TVDMigration . instantiator . logger . exception ( sys. exc_info () [0]) 60 250 def deleteUser (self , session , migration = False ): 251 ''' 252 This function is used for the user log out . If there are multiple devices connected it will be deleted only the 253 flows for the specifc device that did the log out. 254 If the last device for that specific user is disconnected the graph will be destroyed 255 ''' 256 if session['IP ']not in self. IPandUser . keys () : 257 self. logger . info (" Machine not logged in ") 258 return 259 token = self. IPandUser [ session ['IP ']] 260 261 if self. mobility : 262 self. mobility_iprules ( session , " delete ", token ) 263 264 del self. IPandUser [ session ['IP ']] 265 userTVD = self. userTVDs [ token ] 266 267 268 if userTVD . deleteTVD ( session ['IP '], migration = migration ): 269 del self.TokenIP[userTVD.pscAddr] 270 del self. userTVDs [ token ] 271 272 def instantiatePSA(self , session): 273 ''' 274 Instantiate the PSA of the TVD 275 ''' 276 global err , err 277 PSAList = session['PSAs '] 278 self. logger . info (" ------> PSAList %s \n" %( json . dumps ( PSAList ))) 279 oup = "egress flow : " 280 if 'egress_flow 'in session: 281 for psa in session['egress_flow ']: 282 oup = oup + str ( psa ) + ", " 283 oup = oup + "\n ingress flow: " 284 if 'ingress_flow 'in session: 285 for psa in session['ingress_flow ']: 286 oup = oup + str ( psa ) + ", " 287 self. logger . info ("\ n%s\n" %( str (oup ))) 288 289 userTVD = self. userTVDs [ session ['token ']] 290 userTVD . instantiatePSA ( PSAList ) 291 292 self. logger . info ("\ n\n --> of FLOWS \n %s \n" %( json . dumps ( userTVD.generatedFlows))) 293 self. logger . info ("\ n\n --> ofPorts \n %s \n" %( json . dumps ( userTVD.ofPorts))) 294 295 ####### start migration code ######## 296 if self. mobility : 297 self. mobility_iprules ( session , "add ", None) 298 ####### stop migration code ######### 299 300 67 301 def signal_term_handler(self): 302 ''' 303 Used on SIGTERM signal to destroy all the instantiated TVD 304 ''' 305 if not self.sigTerm: 306 self.sigTerm = True 307 for userTVD in self. userTVDs . values () : 308 userTVD . deleteAllTVD () 309 return True 310 return False 311 312 def get_default_gw(self , netns =" default "): 313 ''' 314 function to return the default gw ip 315 ''' 316 strs = subprocess . check_output ( shlex . split ('ip netns exec '+ str ( netns )+'ip r l ')) 317 gateway = strs . split ('default via ') [ -1]. split () [0] 318 return gateway 319 320 def mobility_iprules(self , session , adddel , token ): 321 322 if ( adddel == " add ") : 323 userTVD = self. userTVDs [ session ['token ']] 324 else: 325 userTVD = self. userTVDs [ token ] 326 327 psaIPaddresses = userTVD.psaIPaddresses.items() 328 ssid = self.config.DEFAULT_SSID 329 info = self. config . migration_ned_info ( ssid ) 330 if type(info) is str : 331 info = ast . literal_eval ( info ) 332 nat = info['nat'] 333 try: 334 if 'default_gw 'in nat : 335 self. gw_ip = str ( nat ['default_gw ']) 336 else: 337 self. gw_ip = str ( nat ['server '][0]) 338 except Exception as err : 339 self. logger .info ("----> error getting the default gw " + str(err)) 340 self. gw_ip = str ( nat ['server '][0]) 341 342 for psa in psaIPaddresses: 343 psaID = psa [0] 344 ip_psa = psa [1] 345 self. logger .info (" psaID " + psaID + " ip " + ip_psa ) 346 if ( adddel == " add ") : 347 self. psa_ip_route_table += 1 348 if session['token ']not in userTVD.iprules or type (userTVD.iprules[session['token ']]) is not dict: 349 userTVD.iprules[session['token ']] = {} 350 if not ip_psa in userTVD.iprules[session['token ']]: 351 userTVD.iprules[session['token ']][ ip_psa ] = [] 68 352 self. logger .info ("[ Mobility ] ip_psa %s tables %s" % (str (ip_psa ) , str ( userTVD . iprules [ session [' token ']][ ip_psa ]))) 353 if not self. psa_ip_route_table in userTVD.iprules[ session['token ']][ ip_psa ]: 354 self. logger . info (" Cleaning ip route table %s ip_psa %s" % (str( self. psa_ip_route_table ) ,str ( ip_psa ))) 355 commands . cleanRouteTable ( table = str ( self. psa_ip_route_table ), netNs =" default ") 356 userTVD.iprules[session['token ']][ip_psa].append( self. psa_ip_route_table ) 357 ## add ip rule from 358 commands . addIPrule ( table = self. psa_ip_route_table , addressFrom =ip_psa , pref =self. psa_ip_route_table , netns =" default ") 359 ## add ip rule to 360 commands . addIPrule ( table = self. psa_ip_route_table , addressTo = ip_psa , pref =self. psa_ip_route_table , netns =" default ") 361 ## add ip routes to the table 362 result = commands . addRoute ( table = self. psa_ip_route_table , addr = str(self. gw_ip ) , default=True, netNs =" default ") 363 if result is not None:self. logger . warning ("\ n\n[ mobility ip route ] error add default route via %s table %s" % (str(self. gw_ip ) , str ( self. psa_ip_route_table ))) 364 result = commands . addRoute ( table = self. psa_ip_route_table , addr = str ( ip_psa ) , via =str ( self. ip_ext ), netNs =" default ") 365 if result is not None:self. logger . warning ("\ n\n[ mobility ip route ] error add route to %s via % s" % (str(self. ip_ext ), str ( ip_psa ))) 366 else: 367 tables = [] 368 if ip_psa in userTVD . iprules [ token ]: 369 tables = userTVD . iprules [ token ][ ip_psa ] 370 self. logger . info (" Cleaning ip route table and rules ip_psa %s tables %s" % ( str ( ip_psa ), str ( tables ))) 371 for table in tables: 372 commands . delIPrule ( table = table , addressFrom = ip_psa , netns =" default ") 373 commands . delIPrule ( table =table , addressTo = ip_psa , netns =" default ") 374 commands . cleanRouteTable ( table = str ( table ) , netNs =" default ") Fragment de codi B.4: userTVD.py 1import commands 2import json 3 4from manifestManager import ManifestManager 5 69 6 7class UserTVD ( object ): 8''' 9User TVD class in case of IPSEC NED configuration 10 ''' 11 12 def __init__(self , userName , vlanID , networkManager , computeManager , config , logger , userInterface , 13 migration = False, mobility = False ): 14 15 self.logger = logger 16 self.networkManager = networkManager 17 ### start migration code ### 18 if migration : 19 self. userInterface = userInterface 20 commands . createNewPort ('brData ',self. userInterface ) 21 self. logger . info (" entra migracio ") 22 else: 23 ### end migration code ### 24 self. userInterface = self. networkManager . generatePort ('brData ') 25 self. logger . info (" entra intanciacio ") 26 27 self. interfaceIP , result = self.networkManager. generateRoutingTable(self. userInterface ) 28 self. logger . debug ("\ n\n->>> [ RoutingTable ] Interface %s, IP %s result : \n %s" % ( str(self. userInterface ), str ( self. interfaceIP ), str( result ))) 29 self.userName = userName 30 self. userIP = [] 31 self.vlanID = vlanID 32 self.pscAddr = None 33 self.psc = None 34 self.generatedFlows = [] 35 self.computeManager = computeManager 36 self.config = config 37 self.psaList = [] 38 self.psaIPaddresses = {} 39 self. manifestManager = ManifestManager ( config ) 40 self. migration = migration 41 self.iprules = {} 42 self.psaID_first = None 43 self. psaID_last = None 44 self.mobility = mobility 45 self.ofPorts = {} 46 47 def addNewIP(self , newIP ): 48 ''' 49 Add a new machine on the TVD with the given IP 50 ''' 51 if newIP not in self.userIP: 52 self. userIP . append ( newIP ) 53 commands . addIPrule ( table = self.userInterface , addressFrom = newIP + "/32" , pref =2 , netns =" default ") 54 commands . addIPrule ( table = self. userInterface , addressTo 70 = newIP + "/32" , pref =2, netns =" default ") 55 56 def delUserIP ( self , newIP ): 57 ''' 58 Remove the flow for the given IP 59 ''' 60 self. userIP . remove ( newIP ) 61 commands . delIPrule ( table = self. userInterface , addressFrom = newIP + "/32" , pref =2, netns =" default ") 62 commands . delIPrule ( table = self. userInterface , addressTo = newIP + "/32" , pref =2, netns =" default ") 63 64 def setPSC(self , newPSC , pscAddr ): 65 ''' 66 Configure the PSC of the TVD 67 ''' 68 self.psc = newPSC 69 self.pscAddr = pscAddr 70 self. logger .info (" User " + self. userName + " PSC addr : " + pscAddr) 71 72 def generatePSCflows(self): 73 ''' 74 Generete the flow for the PSC 75 ''' 76 flow = {} 77 bridgeName = 'brData' 78 flow['priority '] = "10" 79 match = {} 80 match ['in_port '] = self. userInterface 81 self.ofPorts[self. userInterface ] = commands . findPort ( bridgeName , self. userInterface ) 82 match ['dl_type '] = "0 x0806 " 83 match ['nw_dst '] = self.config.PSC_DP_IF_IP 84 flow['match '] = match 85 action = {} 86 action['output '] = self. psc['interfaces '][2]['name '] 87 self.ofPorts[self.psc['interfaces '][2]['name ']] = commands . findPort ( bridgeName , self.psc['interfaces '][2]['name ']) 88 flow['action '] = action 89 self. networkManager . generateFlow ('brData ', flow ) 90 self. generatedFlows . append ( flow ) 91 92 flow = {} 93 flow['priority '] = "10" 94 match = {} 95 match ['in_port '] = self. userInterface 96 match ['dl_type '] = "0 x0800 " 97 match ['nw_dst '] = self.config.PSC_DP_IF_IP 98 flow['match '] = match 99 action = {} 100 action['output '] = self. psc['interfaces '][2]['name '] 101 flow['action '] = action 102 self. networkManager . generateFlow ('brData ', flow ) 103 self. generatedFlows . append ( flow ) 71 104 105 flow = {} 106 match = {} 107 match ['in_port '] = self. psc['interfaces '][2]['name '] 108 flow['match '] = match 109 action = {} 110 action['output '] = self. userInterface 111 flow['action '] = action 112 self. networkManager . generateFlow ('brData ', flow ) 113 self. generatedFlows . append ( flow ) 114 115 def deleteAllTVD(self): 116 ''' 117 Delete the TVD 118 ''' 119 self. logger . info (" Deleting " + self. userName + " TVD ") 120 for ip in self.userIP: 121 self. deleteTVD (ip ) 122 123 def deleteTVD ( self , IPaddr , migration = False ): 124 ''' 125 Remove an IP from the TVD in case of the last IP the TVD will be deleted 126 ''' 127 self. logger . info (" Removing IP " + IPaddr ) 128 self. delUserIP ( IPaddr ) 129 if len( self. userIP ) > 0: 130 return False 131 self. logger . info (" Deleting flows : %s" % (str(self. generatedFlows))) 132 for flow in self.generatedFlows: 133 if migration is False : 134 self. networkManager . deleteFlow ('brData', flow) 135 else: 136 self.networkManager.deleteFlow_migration('brData', flow , ofPorts = self.ofPorts) 137 138 139 self. logger . info (" Deleting the user Interface ") 140 self. networkManager . deletePort ('brData',self. userInterface ) 141 142 ## self. logger . info (" Deleting PSC %s\n" % ( json . dumps ( self. psc , indent =4, sort_keys = True))) 143 if self. psc is not None : 144 self.computeManager.deleteNF(self. psc ['name ']) 145 146 self. logger . info (" Deleting PSA ") 147 for psa in self.psaList: 148 self. computeManager . deleteNF ( psa['name ']) 149 150 logLine = "PSA :" 151 for ipAddr in self.psaIPaddresses.values(): 152 logLine = logLine + " " + ipAddr 153 logLine = logLine + ", PSC: " + self.pscAddr + " removed" 154 self. logger . info ( logLine ) 72 155 return True 156 157 def deleteFlows(self , IPaddr ): 158 159 for flow in self.generatedFlows: 160 self.networkManager.deleteFlow_migration('brData', flow) 161 self. generatedFlows . remove ( flow ) 162 163 def associateIPPSA(self , psaID , ip= None): 164 ''' 165 Associate an IP on a PSA 166 ''' 167 168 ### start migration code #### 169 if self. migration : 170 ipAddr = ip 171 self.psaIPaddresses[psaID] = ip 172 else: 173 ### end migration code ### 174 ipAddr = self. networkManager . getPSAnewAddress () 175 self. psaIPaddresses [ psaID ] = ipAddr 176 self. logger .info (" User " + self. userName + " PSA " + psaID + " addr : " + ipAddr) 177 178 179 def definePSA ( self , psaID ): 180 ''' 181 Define a new PSA for the TVD 182 ''' 183 manifest = self. manifestManager . getManifest ( psaID ) 184 properties = {} 185 properties ['memory '] = manifest ['memory '] 186 properties ['vcpu '] = manifest ['vcpu '] 187 properties ['interfaces '] = [] 188 189 interface = {} 190 interface ['bridge '] = " brData " 191 interface ['name '] = self.networkManager.generateVMPort() 192 properties ['interfaces ']. append ( interface ) 193 194 interface = {} 195 interface ['bridge '] = " brData " 196 interface ['name '] = self.networkManager.generateVMPort() 197 properties ['interfaces ']. append ( interface ) 198 199 interface = {} 200 interface ['vlan '] = self.vlanID 201 interface ['bridge '] = " brCtl " 202 interface ['name '] = self.networkManager.generateVMPort() 203 properties ['interfaces ']. append ( interface ) 204 205 return properties 206 207 def instantiatePSA(self , PSAList): 208 ''' 73 209 Instantiate the PSAs for the TVD 210 ''' 211 for psa in PSAList: 212 ### start migration code #### 213 if self. migration : 214 psaProperties = psa 215 else: 216 ### end migration code ### 217 psaProperties = self. definePSA ( psa ['id ']) 218 ### start migration code ### 219 if self. migration : 220 psaName = psa ['name '] 221 for interface in psa['interfaces ']: 222 self. logger . info (" psa interface " + interface ['bridge '] + " " + interface ['name ']) 223 # commands . createNewPort ( interface ['bridge '] , interface ['name ']) 224 else: 225 ### end migration code ### 226 psaName = self.computeManager.instantiateNF(psa[' id '], psaProperties ) 227 psaProperties ['name '] = psaName 228 for interface in psaProperties ['interfaces ']: 229 self. logger. info (" psa interface " + interface [' bridge '] + " " + interface ['name ']) 230 self. logger . info (" lastinterface " + self. userInterface ) 231 self. psaList . append ( psaProperties ) 232 233 self. logger . info ("\ n\n [ userTVD ] PSAList :\n%s" % ( json . dumps ( self. psaList , indent =4, sort_keys = True))) 234 lastInterface = self. userInterface 235 for psa in self.psaList: 236 flow = {} 237 bridgeName = 'brData' 238 match = {} 239 match ['in_port '] = lastInterface 240 self. ofPorts [ lastInterface ] = commands . findPort ( bridgeName , lastInterface ) 241 flow['match '] = match 242 action = {} 243 action['output '] = psa['interfaces '][0]['name '] 244 self. ofPorts [ psa ['interfaces '][0]['name ']] = commands . findPort ( bridgeName , psa ['interfaces '][0]['name ']) 245 flow['action '] = action 246 self. networkManager . generateFlow ('brData ', flow ) 247 self. generatedFlows . append ( flow ) 248 flow = {} 249 match = {} 250 match ['in_port '] = psa['interfaces '][0]['name '] 251 flow['match '] = match 252 action = {} 253 action['output '] = lastInterface 254 flow['action '] = action 255 self. logger . info (" flows2 " + str ( flow )) 256 self. networkManager . generateFlow ('brData ', flow ) 74 257 self. generatedFlows . append ( flow ) 258 lastInterface = psa ['interfaces '][1]['name '] 259 flow = {} 260 bridgeName = 'brData' 261 match = {} 262 match ['in_port '] = lastInterface 263 self. ofPorts [ lastInterface ] = commands . findPort ( bridgeName , lastInterface ) 264 flow['match '] = match 265 action = {} 266 action['output '] = self.config.EXIT_INTERFACE 267 self.ofPorts[self. config . EXIT_INTERFACE ] = commands . findPort ( bridgeName , self.config.EXIT_INTERFACE) 268 flow['action '] = action 269 self. logger . info (" flows3 " + str ( flow )) 270 self. networkManager . generateFlow ('brData ', flow ) 271 self. generatedFlows . append ( flow ) 272 273 flow = {} 274 flow['priority '] = "10" 275 bridgeName = 'brData' 276 match = {} 277 match ['in_port '] = self.config.EXIT_INTERFACE 278 match ['dl_type '] = "0 x0806 " 279 match ['nw_dst '] = self.interfaceIP 280 flow['match '] = match 281 action = {} 282 action['output '] = lastInterface 283 self. ofPorts [ lastInterface ] = commands . findPort ( bridgeName , lastInterface ) 284 flow['action '] = action 285 self. logger . info (" flows4 " + str ( flow )) 286 self. networkManager . generateFlow ('brData ', flow ) 287 self. generatedFlows . append ( flow ) 288 289 flow = {} 290 flow['priority '] = "10" 291 bridgeName = 'brData' 292 match = {} 293 match ['in_port '] = self.config.EXIT_INTERFACE 294 match ['dl_type '] = "0 x0800 " 295 match ['nw_dst '] = self.interfaceIP 296 flow['match '] = match 297 action = {} 298 action['output '] = lastInterface 299 self. ofPorts [ lastInterface ] = commands . findPort ( bridgeName , lastInterface ) 300 flow['action '] = action 301 self. logger . info (" flows5 " + str ( flow )) 302 self. networkManager . generateFlow ('brData ', flow ) 303 self. generatedFlows . append ( flow ) 304 305 for ipAddr in self.psaIPaddresses.values(): 306 flow = {} 307 bridgeName = 'brData' 308 flow['priority '] = "10" 75 309 match = {} 310 match ['in_port '] = self.config.EXIT_INTERFACE 311 match ['dl_type '] = "0 x0806 " 312 match ['nw_dst '] = ipAddr 313 flow['match '] = match 314 action = {} 315 action['output '] = lastInterface 316 self. ofPorts [ lastInterface ] = commands . findPort ( bridgeName , lastInterface ) 317 flow['action '] = action 318 self. logger . info (" flows6 " + str ( flow )) 319 self. networkManager . generateFlow ('brData ', flow ) 320 self. generatedFlows . append ( flow ) 321 322 flow = {} 323 flow['priority '] = "10" 324 match = {} 325 match ['in_port '] = self.config.EXIT_INTERFACE 326 match ['dl_type '] = "0 x0800 " 327 match ['nw_dst '] = ipAddr 328 flow['match '] = match 329 action = {} 330 action['output '] = lastInterface 331 flow['action '] = action 332 self. logger . info (" flows7 " + str ( flow )) 333 self. networkManager . generateFlow ('brData ', flow ) 334 self. generatedFlows . append ( flow ) 335 336 for ipAddr in self.userIP: 337 flow = {} 338 flow['priority '] = "10" 339 match = {} 340 match ['in_port '] = self.config.EXIT_INTERFACE 341 match ['dl_type '] = "0 x0806 " 342 match ['nw_dst '] = ipAddr 343 flow['match '] = match 344 action = {} 345 action['output '] = lastInterface 346 flow['action '] = action 347 self. logger . info (" flows8 " + str ( flow )) 348 self. networkManager . generateFlow ('brData ', flow ) 349 self. generatedFlows . append ( flow ) 350 351 flow = {} 352 flow['priority '] = "10" 353 match = {} 354 match ['in_port '] = self.config.EXIT_INTERFACE 355 match ['dl_type '] = "0 x0800 " 356 match ['nw_dst '] = ipAddr 357 flow['match '] = match 358 action = {} 359 action['output '] = lastInterface 360 flow['action '] = action 361 self. logger . info (" flows9 " + str ( flow )) 362 self. networkManager . generateFlow ('brData ', flow ) 363 self. generatedFlows . append ( flow ) 76 287 self. instantiator . psas_tt [ tpsa .vm ][" fin "] = 288 datetime . datetime . utcnow () . strftime ("% Y-%m -%d %H :%M:%S.%f") 289 290 self. TsendTVD . join () 291 tMigration . join () 292 self.instantiator.tvdm_fin_psc = 293 datetime . datetime . utcnow () . strftime ("% Y-%m -%d %H:%M :%S.%f") 294 295 for psa in self.PSAList: 296 self.undefined_vm(psa['name ']) 297 298 self.undefined_vm(self.namePSC) 299 self. logger . info (" PSC migrated ") 300 301 302 def undefined_vm(self , vm): 303 self. local_dom = self. conn . lookupByName (vm) 304 self. local_dom . undefine () 305 306 307 def obtain_disk_base(self , path ): 308 ''' 309 obtain path VM disk base 310 ''' 311 try: 312 proc = subprocess . Popen (" qemu -img info " + path , 313 stdout = subprocess . PIPE , shell =True) 314 (out , err) = proc . communicate () 315 returnedValue = str ( out) 316 start = 'file: ' 317 end = '\n' 318 disk_base = (( returnedValue . split ( start )) [1]. split ( end )[0]) 319 320 except subprocess . CalledProcessError as e: 321 self. logger . info (" Calledprocerr :" + e) 322 323 return disk_base 324 325 def generate_remote_disk(self , original , disk_type , path , vm): 326 """ 327 Generate remote disk 328 """ 329 stderr = "" 330 331 try: 332 cmd = "[ -f " + path + "/" + vm + " ] || qemu -img create -b " 333 + original + " -f " + disk_type + " " + path 334 stdin , stdout , stderr = self. ssh . exec_command ( cmd) 335 stdin . close () 336 except Exception as e: 337 self. logger . info (" Error to create remote disk " + str ( 83 e)+"" 338 + str ( stderr )) 339 340 def rename_remote_disk (self , path , vm): 341 342 stderr = "" 343 344 try: 345 cmd = "mv " + path + "/" + vm + " " + path + "/" + vm + "backup" 346 stdin , stdout , stderr = self. ssh . exec_command ( cmd) 347 stdin . close () 348 349 except Exception as e: 350 self. logger . info (" Error to create remote disk " 351 + str (e) + " " + str ( stderr )) 352 353 354 def createSSHClient ( self , server , port , user , password ): 355 356 client = paramiko . SSHClient () 357 client . load_system_host_keys () 358 client . set_missing_host_key_policy ( paramiko . AutoAddPolicy ()) 359 client . connect ( server , port , user , password ) 360 return client 361 362 def execute_command ( self , ssh , cmd , sudo): 363 ''' 364 Create remote conection 365 ''' 366 try: 367 if sudo: 368 cmd = "sudo -S -u qemu ' ' %s" % cmd 369 stdin , stdout , stderr = ssh . exec_command ( cmd ) 370 if sudo: 371 stdin . write ('xxx \n ') 372 stdin . write ('x\n ') 373 stdin . flush () 374 375 except socket . timeout as serr: 376 self. logger . info (" Error1 : %s" % serr ) 377 378 except socket . error as serr: 379 print " Error2 : %s" % serr 380 381 except: 382 print "ANY1" 383 return ( stdout . readlines () , stderr . readlines ()) 384 385 386 class TMigration ( threading . Thread ): 387 def __init__(self , vm , sleep , local_host , remote_host , remote_port , 388 logger , group = None, target=None, name =None,args =() , 84 389 kwargs=None, verbose=None): 390 super ( TMigration , self). __init__ ( group = group , target = target, 391 name =name , verbose = verbose) 392 self.vm = vm 393 self. sleep = sleep 394 self. local_host = local_host 395 self.remote_host = remote_host 396 self.remote_port = remote_port 397 self.logger = logger 398 self. local_conn_string = " qemu :/// system " 399 __last_bytes = -1 400 __last_time = datetime . time () 401 402 try: 403 self. remote_conn_string = " qemu +ssh ://" 404 +self. remote_host + ":" 405 + str( self. remote_port ) + "/ system" 406 except: 407 self. logger . info (" Error Connecting remote VM " + self. remote_host) 408 409 try: 410 self. conn = libvirt . open ( self.local_conn_string) 411 except: 412 self. logger . info (" Error Connecting to VM hypervisor " 413 +self.local_conn_string) 414 try: 415 self. remote_conn = libvirt . open ( self. remote_conn_string ) 416 except: 417 self. logger . info (" Error connecting to remote hypervisor : " 418 +self. remote_conn_string ) 419 420 if (self. sleep > 0) : self. logger . info ( time . sleep ( self. sleep )) 421 422 self. logger . info ( 423 " Starting migration of VM domain '" + self. vm + "'from " 424 +self. local_host + " to " + self. remote_host + "...") 425 try: 426 self. local_dom = self.conn.lookupByName(self.vm) 427 except: 428 self. logger . info (" VM does not exist : " + self.vm) 429 self. executed = False 430 return 431 432 def run( self): 433 434 try: 435 self. logger . info (" RUN DE TMIGRATION ") 85 436 self. local_dom . migrate ( self. remote_conn , libvirt . VIR_MIGRATE_LIVE | 437 libvirt . VIR_MIGRATE_COMPRESSED , None, 438 None, 0) 439 self. logger . info (" Migration of VM domain '" + self.vm + "'from " 440 +self. local_host + " to " + self. remote_host 441 + " triggered OK !!") 442 self. executed = True 443 except Exception as e: 444 self. logger . info (" Error to migrate " + self.vm) 445 self. logger . error ( str (e)) 446 447 try: 448 remaining = self. vm_status () 449 while remaining [0] != 100: 450 if not remaining : 451 self. logger . info (" No migration in progress ") 452 else: 453 self. logger . info (" tmigration remaining to migrate %, psa : " 454 % (str( remaining ) , str (self. vm))) 455 time . sleep (1) 456 remaining = self. vm_status () 457 except Exception as e: 458 self. logger . info (" Error GETTING STATUS " + self.vm) 459 self. logger . error ( str (e)) 460 return 461 462 def vm_job_stats(self): 463 if self. local_dom . info () [0] != 5: 464 return self. local_dom . jobStats () 465 else: 466 return {} 467 468 def __update_migration_status(self): 469 dictionary = self.vm_job_stats() 470 if dict: 471 if not 'data_remaining 'in dictionary : # No migration in progress 472 if self. executed : 473 return [100] 474 return [ -1] 475 remaining_bytes = dictionary ['data_remaining '] 476 total_bytes = dictionary ['data_total '] 477 if total_bytes == 0: 478 if self. executed : 479 return [100] 480 return [ -1] 481 if self.__last_bytes < 0: 482 self. __last_bytes = remaining_bytes 483 self. __last_time = datetime . datetime . now (); 484 eta = datetime . timedelta () 86 485 elif remaining_bytes == 0: 486 self.__last_bytes = 0 487 self. __last_time = datetime . time (); 488 else: 489 byte_rate = self. __last_bytes - remaining_bytes 490 time_now = datetime . datetime . now () 491 time_between_queries = time_now - self.__last_time 492 eta_microsec = self. timedelta2microseconds ( time_between_queries) 493 * int ( remaining_bytes / byte_rate ) 494 eta = self. microseconds2timedelta ( eta_microsec ) 495 self. __last_time = time_now 496 self. __last_bytes = remaining_bytes 497 percent_done = remaining_bytes / total_bytes * 100 498 return [ percent_done , eta.days , eta. seconds , eta . microseconds] 499 else: 500 if self. executed : 501 return [100] 502 return [ -1] 503 504 def vm_status ( self): 505 try: 506 if not self. executed : 507 return [ -1] 508 return self.__update_migration_status() 509 except Exception as e: 510 self. logger . info (" vm_status vm not found %s" % (str(e. message ))) 511 return [100] 512 513 def timedelta2microseconds(self , time ): 514 if not time: 515 return -1 516 return (((24 * 60 * 60 * time . days ) + time . seconds )) * 10 ** 6 517 + time.microseconds 518 519 def time2microseconds(self , time ): 520 if not time: 521 return -1 522 return (((60 * time . hours ) + time . minutes ) * 60 + time . seconds) 523 * 1000000 + time . microseconds 524 525 def microseconds2timedelta(self , pass_microseconds): 526 given_microseconds = int(pass_microseconds) 527 microseconds = given_microseconds % (10 ** 6) 528 rest = int( given_microseconds / 10 ** 6) 529 seconds = int ( rest % (60 * 60 * 24)) 530 days = int ( rest / (60 * 60 * 24)) 531 return datetime . timedelta ( days =days , seconds = seconds , 532 microseconds=microseconds) 533 534 def microseconds2time(self , given_microseconds ): 535 microseconds = given_microseconds % (10 ** 6) 87 536 rest = int( given_microseconds / 10 ** 6) 537 seconds = int ( rest % 60) 538 rest = int ( rest / 60) 539 minutes = int ( rest % 60) 540 rest = int ( rest / 60) 541 hours = int ( rest % 60) 542 return datetime . time ( hours = hours , minutes = minutes , seconds =seconds , 543 microseconds=microseconds) B.3 Bibliografia 88 Bibliografia [1] SECURED: https://www.secured-fp7.eu [2] SECURED, consortium: https://www.secured-fp7.eu/about/consortium [3] Definicii´o de OPEN-FLOW: https://www.opennetworking.org/ sdn-resources/openflow [4] Definici´o QEMU: https://ca.wikipedia.org/wiki/QEMU [5] Descripci´o de Strongswan: https://www.strongswan.org [6] Ley Organica de Protecci´on de Datos: https://es.wikipedia.org/wiki/Ley_ Org%C3%A1nica_de_Protecci%C3%B3n_de_Datos_de_Car%C3%A1cter_Personal_de_ Espa%C3%B1a [7] OpenDayLight: https://www.opendaylight.org/ [8] Openvswitch: http://openvswitch.org/ [9] API REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_ arch_style.htm [10] Definici´o d’anti-phishing: https://en.wikipedia.org/wiki/Anti-phishing_ software 89 [11] Informaci´o de la llibreria libvirt: https://libvirt.org/migration.html [12] Informaci´o sobre JSON: https://ca.wikipedia.org/wiki/JSON [13] Definici´o dels flags: http://whatis.techtarget.com/definition/flag [14] Descripci´o de la llibreria Paramiko: http://www.paramiko.org [15] Descripci´o de la llibreria libvirt https://libvirt.org/migration.html [16] Infografia Sostenibilitat: https://libvirt.org/migration.html [17] Documentaci´o de Sharelatex per la relitzaci´o del TFG: https://libvirt.org/ migration.html [18] Informaci´o dels NUC: hhttps://en.wikipedia.org/wiki/Next_Unit_of_ Computing [19] Definici´o de la mobike: https://wiki.strongswan.org/projects/strongswan/ wiki/MobIke 90