Achieving Reproducible Network Environments with INSALATA
Transcript of Achieving Reproducible Network Environments with INSALATA
Chair of Network Architectures and ServicesDepartment of InformaticsTechnical University of Munich
Achieving Reproducible Network Environments with INSALATA
Nadine Herold, Matthias Wachs, Marko Dorfhuber, Cristoph Rudolf, Stefan Liebald, GeorgCarle
Tuesday 11th July, 2017
Chair of Network Architectures and ServicesDepartment of Informatics
Technical University of Munich
Chair of Network Architectures and ServicesDepartment of InformaticsTechnical University of Munich
Motivation
Requirements and Related Work
INSALATA Architecture
Case Study: iLab
Conclusion and Future Work
Literature
S. Liebald — INSALATA 1
Motivation
Why do we want reproducible network environments?
• Requirement for reproducible experiments• e.g. from other testbeds
• Test changes before deployment in operational network• Routing• Software updates• Firewall rules• Configuration changes• . . .
S. Liebald — INSALATA 2
Motivation
Why do we want reproducible network environments?
• Requirement for reproducible experiments• e.g. from other testbeds
• Test changes before deployment in operational network• Routing• Software updates• Firewall rules• Configuration changes• . . .
S. Liebald — INSALATA 2
Motivation
Why do we want reproducible network environments?
• Requirement for reproducible experiments• e.g. from other testbeds
• Test changes before deployment in operational network• Routing• Software updates• Firewall rules• Configuration changes• . . .
S. Liebald — INSALATA 2
Our Solution: INSALATA
Manual replication:
• Error prone, time consuming• Keeping it up-to-date is hard• Multitude of Tools/Software used manually
The goal:
• Automate complete replication process• Scan an environment and deploy it on a testbed
Our Framework: IT NetworkS AnaLysis And deploymenT Application (INSALATA)
• Network information model• Information collection component• Infrastructure deployment component
S. Liebald — INSALATA 3
Our Solution: INSALATA
Manual replication:
• Error prone, time consuming• Keeping it up-to-date is hard• Multitude of Tools/Software used manually
The goal:
• Automate complete replication process• Scan an environment and deploy it on a testbed
Our Framework: IT NetworkS AnaLysis And deploymenT Application (INSALATA)
• Network information model• Information collection component• Infrastructure deployment component
S. Liebald — INSALATA 3
Our Solution: INSALATA
Manual replication:
• Error prone, time consuming• Keeping it up-to-date is hard• Multitude of Tools/Software used manually
The goal:
• Automate complete replication process• Scan an environment and deploy it on a testbed
Our Framework: IT NetworkS AnaLysis And deploymenT Application (INSALATA)
• Network information model• Information collection component• Infrastructure deployment component
S. Liebald — INSALATA 3
Requirements and Related WorkInformation ModelRequirements and Related Work
Requirements IF-M
AP[1
, 20,
21]
IDS
Ont
olog
y[2
2]IN
DL
[18,
10, 8
]N
ML
[24,
23]
R1: Network components 3 3 3 3
R2: Connections 3 3 3 3
R3: Addressing 3 7 7 7
R4: Reachability of components 7 7 7 7
R5: Network services 3 3 3 7
R6: Hardware information 3 7 3 7
R7: Extensibility of information elements 3 3 3 3
R8: History 7 7 7 3
3 fulfilled, 7 not fulfilled
S. Liebald — INSALATA 4
Requirements and Related WorkInformation Collection ComponentRequirements and Related Work
Requirements IO-F
ram
ewor
k[4
, 12]
cNIS
[9]
Mon
ALIS
A[6
, 5]
PerfS
ON
AR[1
9]O
penV
AS[1
6]N
map
[13,
14]
R1: Configurability 7 3 3 3 3 3
R2: Collection of required topoloy information 3 7 3 7 7 7
R3: Extensible modules 3 3 3 3 3 3
R4: Periodical information collection 7 3 3 3 3 7
R5: Adaptable intervals 7 7 7 3 3 7
R6: Continuous monitoring 7 3 7 7 7 7
R7: Multiple environments 7 7 3 3 3 7
R8: Extensible export 7 3 7 7 7 7
3 fulfilled, 7 not fulfilled
S. Liebald — INSALATA 5
Requirements and Related WorkInfrastructure Deployment ComponentRequirements and Related Work
Requirements Laas
Net
Exp
[17]
vBET
[11]
Balti
kum
Test
bed
NEP
TUN
E[3
]Al
goriz
mi [
2]Em
ulab
[25]
R1: Basic network components 7 3 7 7 7 3
R2: Description language for configuration ? 3 3 3 3 3
R3: Virtual and physical components 7 7 3 7 7 3
R4: Software independent design ? ? 7 3 7 7
R5: Public availability 7 7 3 3 3 3
R6: Separated and persistent components 3 7 3 3 3 3
R7: Multiple users per testbed 3 7 7 7 3 3
R8: Common usage of central components 3 3 7 3 7 7
R9: Incremental Changes 7 7 7 7 7 7
3 fulfilled, 7 not fulfilled, ? insufficient informationS. Liebald — INSALATA 6
Architecture: Overview
Management Unit
Pre-
processor
upload
User
virtual
physical
Collector Setup
Database
loadstore
import apply
scan deploy/change
S. Liebald — INSALATA 7
Architecture: Information Model
1use0..*
1..*
in1
1..*
contains1..*
1
use
0..*
1
use
0..*
1
has
0..*0..*
in 1
0..*1
0..*
connected to 0..1
0..*0..1 0..*1
0..*hop 1
0..*
start 1
0..*
end 1
0..*
destNet1
0..*
srcNet1
0..*
interface 1
0..*
hop1
0..*
interface1
0..* 1
NetworkComponent
id : String
cpus : IntegercpuSpeed : IntegermemoryMin : IntegermemoryMax : IntegerpowerState : Stringtemplate : String
Disk
id : String
size : Integer
Interface
mac: String
rate : Integermtu : Integer
Layer2Network
id : String
Location
id : String
Layer3Address
address : String
netmask : Stringgateway : Stringstatic : Boolean
Route
genmask : Stringmetric : Integer
FirewallRule
chain : Stringaction : Stringprotocol : StringsrcPorts : listdestPorts : list
Layer3Network
address : String
netmask : String
FirewallRaw
firewall : String
data : String
Service
port : Integer
type : Stringprotocol : Stringproduct : Stringversion : String
DnsService
domain : String
DhcpService
lease : Integer
connected to configured on running on
destination
S. Liebald — INSALATA 8
Architecture: Information Collection Component
Management Unit
Pre-
processor
upload
User
virtual
physical
Collector Setup
Database
loadstore
import apply
scan deploy/change
S. Liebald — INSALATA 9
Architecture: Information Collection Component
Management Unit
.ini
Env1.ini
Mod1,2Mod1,1 Mod1,3
Net1
Env2 .ini
Mod2,1 Mod2,2
Net2
Collector
S. Liebald — INSALATA 10
Architecture: Information Collection Component
Approaches for Information Collection
Manua
l (xml)
Passiv
e scan
s (tcpd
ump)
Active
scan
s (NMAP)
proto
col b
ased
(SNMP)
Direct
acce
ss(ss
h)
Client
softw
are (Z
abbix
)
Network traffic overhead o o ++ + + +Client software o o o + + ++Direct access o + o o ++ +Reliability + ++ + ++ ++ ++Topicality o o + + + ++Information variety o + + + ++ ++Information updatability + o ++ ++ ++ ++
S. Liebald — INSALATA 11
Architecture: Infrastructure Deployment Tool
Management Unit
Pre-
processor
upload
User
virtual
physical
Collector Setup
Database
loadstore
import apply
scan deploy/change
S. Liebald — INSALATA 12
Architecture: Infrastructure Deployment Tool
Deployment Process
ConfigPre-
processor
Configuration
c1
CollectorConfiguration
c2
Change
detection
Planning
Problem
parserProblem
PlannerDomain
PlanBuilder
Builder
module n
Builder
module 1
... uses
Testbedbuilds
scans
S. Liebald — INSALATA 13
Case Study: iLabPhysical setup
Cisco-Router 1
Linux-Router
Cisco-Router 2
Switch
PC1 PC2 PC3 PC4
eth0 10.0.1.254/24eth0 10.0.2.254/24
eth0 10.0.3.254/24
eth0 10.0.1.1/24 eth0 10.0.1.2/24 eth0 10.0.2.1/24 eth0 10.0.3.1/24
eth2 10.0.6.1/24 eth2 10.0.6.2/24
eth1 10.0.4.1/24 eth1 10.0.5.2/24
eth2 10.0.4.1/24 eth1 10.0.5.1/24
S. Liebald — INSALATA 14
Case Study: iLabDeployment Phase
• Execution plan computed in <1 second• 92 steps• Contains: setup of virtual machines, networks, interfaces, routes,...
• Setup in our virtual testbed took ~42 minutes• Our builder modules utilize the XEN xapi toolstack• Most of the time required to clone the virtual machines and hard disk images
• Validation of setup in the testbed using the ping and traceroute tools
S. Liebald — INSALATA 15
Conclusion and Future Work
• Conclusion:• Automated scanning and deployment of network environments can be done• Modularisation of such a tool is beneficial
• Contribution:• Extensible framework for reproducible network setups• Applicable for virtual/physical/mixed environments• Incremental deployment process• Multiple collector/builder implementations• Case studie as prove of applicability
• Future Work:• Implement additional collector/builder modules• Parallelize the deployment process• Include experiment execution
S. Liebald — INSALATA 16
Conclusion and Future Work
• Conclusion:• Automated scanning and deployment of network environments can be done• Modularisation of such a tool is beneficial
• Contribution:• Extensible framework for reproducible network setups• Applicable for virtual/physical/mixed environments• Incremental deployment process• Multiple collector/builder implementations• Case studie as prove of applicability
• Future Work:• Implement additional collector/builder modules• Parallelize the deployment process• Include experiment execution
S. Liebald — INSALATA 16
Conclusion and Future Work
• Conclusion:• Automated scanning and deployment of network environments can be done• Modularisation of such a tool is beneficial
• Contribution:• Extensible framework for reproducible network setups• Applicable for virtual/physical/mixed environments• Incremental deployment process• Multiple collector/builder implementations• Case studie as prove of applicability
• Future Work:• Implement additional collector/builder modules• Parallelize the deployment process• Include experiment execution
S. Liebald — INSALATA 16
Literature
[1] V. Ahlers, F. Heine, B. Hellmann, C. Kleiner, L. Renners, T. Rossow, and R. Steuerwald.Integrated Visualization of Network Security Metadata from Heterogeneous Data Sources.In S. Mauw, B. Kordy, and S. Jajodia, editors, Graphical Models for Security: Second International Workshop (GraMSec),pages 18–34, 2016.
[2] K. Ali.Algorizmi: A configurable virtual testbed to generate datasets for offline evaluation of Intrusion Detection Systems.Master’s thesis, University of Waterloo, 2010.
[3] R. Bifulco, G. D. Stasi, and R. Canonico.NEPTUNE for fast and easy deployment of OMF virtual network testbeds [Poster Abstract].2010.
[4] H. Birkholz, I. Sieverdingbeck, K. Sohr, and C. Bormann.IO: An Interconnected Asset Ontology in Support of Risk Management Processes.In Availability, Reliability and Security (ARES), 7th International Conference on, pages 534–541, 2012.
[5] A. Carpen-Amarie, J. Cai, A. Costan, G. Antoniu, and L. Bougé.Bringing Introspection Into the BlobSeer Data-Management System Using the MonALISA Distributed Monitoring Frame-work.In Complex, Intelligent and Software Intensive Systems (CISIS), International Conference on, pages 508–513, 2010.
[6] C. Dobre, R. Voicu, and I. Legrand.Monitoring large scale network topologies.In Intelligent Data Acquisition and Advanced Computing Systems (IDAACS), IEEE 6th International Conference on, vol-ume 1, pages 218–222, 2011.
[7] M. Fox and D. Long.PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains.J. Artif. Int. Res., 20(1):61–124, 2003.
S. Liebald — INSALATA 17
Literature
[8] M. Ghijsen, J. van der Ham, P. Grosso, C. Dumitru, H. Zhu, Z. Zhao, and C. de Laat.A semantic-web approach for modeling computing infrastructures.Computers & Electrical Engineering, 39(8):2553 – 2565, 2013.
[9] GÉANT.GEANT2 common Network Information Service (cNIS) Schema Specification, http://www.geant2.net.
[10] Jeroen Johannes van der Ham.A Semantic Model for Complex Computer Networks: The Network Description Language.PhD thesis, University of Amsterdam, 2010.
[11] X. Jiang and D. Xu.vBET: A VM-based Emulation Testbed.In Proceedings of the ACM SIGCOMM Workshop on Models, Methods and Tools for Reproducible Network Research,pages 95–104, 2003.
[12] L. Lorenzin and N. Cam-Winget.Security Automation and Continuous Monitoring (SACM) Requirements.Internet-Draft draft-ietf-sacm-requirements-15, Internet Engineering Task Force, 2016.
[13] G. Lyon.The Offical Nmap Project Guide to Network Discovery and Securtiy Scanning.2009.
[14] G. Lyon.nmap(1) – Linux man page, 2015.
[15] D. McDermott, M. Ghallab, A. Howe, C. Knoblock, A. Ram, M. Veloso, D. Weld, and D. Wilkins.PDDL – The Planning Domain Definition Language.1998.
S. Liebald — INSALATA 18
Literature[16] OpenVAS.
Project Homepage http://www.openvas.org.
[17] P. Owezarski, P. Berthou, Y. Labit, and D. Gauchard.LaasNetExp: A Generic Polymorphic Platform for Network Emulation and Experiments.In Proceedings of the 4th International Conference on Testbeds and Research Infrastructures for the Development ofNetworks & Communities, number 24, pages 1–9, 2008.
[18] T. Taketa and Y. Hiranaka.Network Design Assistant System based on Network Description Language.In Advanced Communication Technology (ICACT), 15th International Conference on, pages 515–518, 2013.
[19] B. Tierney, J. Metzger, J. Boote, E. Boyd, A. Brown, R. Carlson, M. Zekauskas, J. Zurawski, M. Swany, and M. Grigoriev.perfSONAR: Instantiating a Global Network Measurement Framework.In In SOSP Workshop on Real Overlays and Distributed Systems (ROADS09). ACM, 2009.
[20] Trusted Network Connect Work Group.TNC IF-MAP Bindings for SOAP, Version 2.2, Revision 10, 2014.
[21] Trusted Network Connect Work Group.TNC MAP Content Authorization, Version 1.0, Revision 36, 2014.
[22] J. Undercoffer, J. Pinkston, A. Joshi, and T. Finin.A Target-Centric Ontology for Intrusion Detection.In Proceding of the 9th Workshop on Ontologies and Distributed Systems, pages 47–58, 2004.
[23] J. van der Ham, F. Dijkstra, R. Lapacz, and A. Brown.The Network Markup Language (NML): A Standardized Network Topology Abstraction for Inter-domain and Cross-layerNetwork Applications, 2013.
[24] J. van der Ham, F. Dijkstra, R. Łapacz, and J. Zurawski.Network Markup Language Base Schema version 1, 2013.
S. Liebald — INSALATA 19
Literature
[25] B. White, J. Lepreau, L. Stoller, R. Ricci, S. Guruprasad, M. Newbold, M. Hibler, C. Barb, and A. Joglekar.An Integrated Experimental Environment for Distributed Systems and Networks.pages 255–270, 2002.
S. Liebald — INSALATA 20
Change Detection
networks:I net-1I net-2
hosts:I router-1
• interfaces:– eth0: 10.10.1.254/24– eth1: 10.10.2.1/24
I host-1• interfaces:
– eth0: 10.10.1.1/24
Change
detection
networks:I net-1I net-2
hosts:I router-1
• interfaces:– eth0: 10.10.1.254/24– eth1: 10.10.2.254/24
I host-1• interfaces:
– eth0: 10.10.1.1/24I host-2
• interfaces:– eth0: 10.10.2.1/24
The change detection marks router-1.eth1.ip as changed and host-2 as new.
S. Liebald — INSALATA 21
Planning
• Based on the input, the planner creates a deployment plan• Currently the Planning Domain Definition Language (PDDL [15, 7]) is used
• Domain description: describes the problem domain, static• Describes object types, predicates, actions• Actions apply to objects, have preconditions and have an effect• Provided with INSALATA for our information model
• Problem description: describes the instance of the domain• Depends on current/desired state
• Output is given to the Builder which chooses fitting builder modules to realize the deploy-ment
S. Liebald — INSALATA 22
Planning Example
+ DNS/DHCP
+ DNS/DHCP
+ DNS/DHCP/Firewall
+ DNS/DHCP
+ DNS/DHCP
7
S. Liebald — INSALATA 23
Planning Example
+ DNS/DHCP
+ DNS/DHCP
+ DNS/DHCP/Firewall
+ DNS/DHCP
+ DNS/DHCP
7
S. Liebald — INSALATA 23
Planning example
new• router-3
changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0
removed• host-4• host-4-hdd
1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)
S. Liebald — INSALATA 24
Planning example
new• router-3
changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0
removed• host-4• host-4-hdd
1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)
S. Liebald — INSALATA 24
Planning example
new• router-3
changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0
removed• host-4• host-4-hdd
1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)
S. Liebald — INSALATA 24
Planning example
new• router-3
changed• router-1.firewall• router-1.routing• router-2.routing• host-3.eth0
removed• host-4• host-4-hdd
1. (createhost router-3)2. (configurefirewall router-1)3. (configurerouting router-1)4. (configurerouting router-2)5. (createnetwork net-3)6. (shutdown host-4)7. (removehost host-4)8. (removedisk host-4-hdd host-4)9. (createinterface router-3.eth0)10. (createinterface router-3.eth1)11. (bootunnamed router-3)12. (configureinterface router-3.eth0)13. (configureinterface router-3.eth1)14. (configurerouting router-3)15. (name router-3)16. (rebootandnamed router-3)17. (shutdown host-3)18. (configurenetwork host-3.eth0)19. (boot host-3)20. (configuredhcp 172.16.246.1:67_udp_dhcp)21. (configuredns 172.16.246.1:53_udp_dns)
S. Liebald — INSALATA 24
Intrusiveness of Information Collection
Manual
Passive Network Scanning
Active Network Scanning
Protocols
Direct Access
Agent-based
Intrusiveness
S. Liebald — INSALATA 25