Advanced Computer Networks IN Dec 2015

Transcription

1 Chair for Network Architectures and Services Technische Universität München Advanced Computer Networks IN Dec 2015 Prof. Dr.-Ing. Georg Carle Chair for Network Architectures and Services Department of Computer Science Technische Universität München

2 Chair for Network Architectures and Services Technische Universität München Network Measurements

3 Network Measurements Introduction Architecture & Mechanisms Active Measurements Passive Measurements Scenarios 3

4 Why do we measure the network? Network Provider View Manage traffic Predict future, model reality, plan network Avoid bottlenecks in advance Reduce cost Accounting Service Provider View Get information about the client Adjust service to demands Reduce load on service Accounting Client View Get the best possible service Check the service ( Do I get what I have paid for?) Researcher View Performance evaluation (e.g., could our new routing algorithm handle all this real-world traffic? ) Security view Detect malicious traffic, malicious hosts, malicious networks, 4

5 But why should we do it at all? Do we really have to? The network is well engineered Well documented protocols, mechanisms, Everything built by humans ð no unknowns (compare this to, e.g., physics: is theory on cosmic inflation phase sound? etc.) In theory, we can know everything that is going on ð There should/might be no need for measurements But: Information in a distributed multidomain network only partly available Moving target: Requirements change Growth, usage, structure changes Highly interactive system Heterogeneity in all directions The total is more than the sum of its pieces And: The network is built, driven and used by humans Detection of errors, misconfigurations, flaws, failures, misuse, 5

6 Active Measurements Methodology Probe packets exchanged between specific nodes Measurement of packet loss, one-way delay, round-trip times, packet inter-arrival time Analysis Sender Complete packet loss ð link down, invalid route, router defect Partial packet loss ð available bandwidth, level of congestion Delay = propagation time + buffer time ð distance estimation, filling level of buffers Interarrival times of packet pairs/trains ð path capacity Network Receiver 6

7 Active Measurements - Assessment Active measurements Disadvantages intrusive Additional load Network traffic is affected by the measurement Measurements are influenced by (possibly varying) network load Measurement packets may be treated differently than packets of interest (e.g. ICMP frequently treated differently to TCP/UDP packets) Advantages Straightforward Does not depend on existing traffic by active applications Allows measurement of specific parts of the network Does not require access to internal network components 7

8 Active Measurement Example: Packet pair probing Packet Pair (P-P) technique c.f. work by Jacobson & Keshav Send two equal-sized packets back-to-back Packet size: L Packet Tx time at link i: L/C i P-P dispersion = time interval between last bit of two packets Without any cross traffic, the dispersion at receiver is determined by bottleneck link (i.e., slowest link): Δ out = max L Ci = max = R i= 1,..., H Δ C.f paper Nettimer: A Tool for Measuring Bottleneck Link Bandwidth in Usenix, Kevin Lai, Mary Baker, nettimer-tool-measuring-bottleneck-link-bandwidth If two packets are sent close enough together in time to cause the packets to queue together at the bottleneck link, then the packets will arrive at the destination with the same spacing as when they exited. Δ L C in, L C i 8

9 Active Measurement Example: Traceroute Traceroute: possible anomalies due to load balancing Solution: Paris traceroute UDP TTL=3 UDP TTL=4 9

10 Recapitulation - Multipath routing: Solution Hash consistently and use packet headers as random values: Result: Packets from same TCP connection yield same hash value No reordering within one TCP connection possible 10

11 Paris Traceroute Paris traceroute Varying header fields that are within the first 28 octets TCP: sequence number UDP: checksum field This requires manipulating the payload to yield the desired checksum, as packets with an incorrect checksum are liable to be discarded. ICMP: combination of ICMP identifier and sequence number Experiment results: certain routers use first four octets after IP header combined with IP fields for load balancing 11

12 Passive Measurements Methodology Observation of existing traffic using monitoring probes in the network Measurement of traffic volume, traffic composition, packet interarrival times Different levels of granularity: packet-level, flow-level, link-level Analysis Network Measurement of network utilization for accounting and traffic engineering Monitoring Probe Measurement of quality-of-service parameters (e.g., throughput, delay) Detection of failures, traffic anomalies, flooding attacks and scans Traffic characterization with deep packet inspection 12

13 Passive Measurements - Assessment Passive measurements (or Network Monitoring) Monitoring of existing traffic ð Requires installation of monitoring probes at appropriate locations in the network Advantages Non-intrusive ð Does not affect applications Does not modify the network behavior Disadvantages Requires suitable existing (active) network traffic Limited to analysis of existing / current network behavior, situations of high load, etc. cannot be simulated/enforced Does not allow the transport of additional information (time stamps, etc.) within measured traffic 13

14 Flow-Level Passive Measurements Flow-Collector Internal Network Flow Data (e.g. encoded in IPFIX) Internet Network devices create flow data Export them to some central collector You can look at communication patterns 14

15 Flow-Level Passive Measurements Data visualisation 15

16 Network Measurements Hybrid Measurements Hybrid measurements Modification of packet flows Piggybacking Header modification Advantages Same as for passive additional information can be included (time-stamps, etc.) Disadvantages Modifying of data packets may cause problems if not used carefully 16

17 Measurement types (summary) Active Measurements Intrusive Find out what the network is capable of Changes the network state Passive Measurements (or network monitoring) Non-intrusive Find out what the current situation is Does not influence the network state (more or less) Hybrid Alter actual traffic Reduce the impact of active measurements Might introduce new bias for applications 17

18 Network Monitoring Applications of network monitoring Traffic analysis Traffic engineering Anomaly detection Accounting Resource utilization Accounting and charging Security Intrusion detection Detection of prohibited data transfers (e.g., P2P applications) Research Issues Traffic Analysis Accounting Monitoring Protection of measurement data against illegitimate use (encryption, ) Applicable law ( lawful interception, privacy laws, ) Security applications 18

19 International Telecommunication Union - ITU Technical Aspects of Lawful Interception: Lawful Interception (LI) describes the lawfully authorized interception and monitoring of telecommunications pursuant to an order of a government body, to obtain the forensics necessary for pursuing wrongdoers. LI has existed from the times of shortrange telegraphy to today s worldspanning Next-Generation Networks (NGNs). ð Basis: In accordance with local law reasonable suspicion of severe criminal offense 19

20 Lawful Interception Interfaces and Standards Vendor Specifications Cisco, others ETSI Standardisation Documents ETSI TS , Telecommunications security; Lawful Interception (LI); Requirements of law enforcement agencies ETSI TS v6.7.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Handover Interface for Lawful Interception (Release 6) IETF Please note: RFC 1984, IAB and IESG Statement on Cryptographic Technology and the Internet, August 1996, RFC 2804, IAB, IESG: IETF Policy on Wiretapping, May 2000, RFC 3924, Fred Baker, Bill Foster, Chip Sharp, Cisco Architecture for Lawful Intercept in IP Networks, October 2004, 20

21 Vendor Specification on Lawful Interception Example: Cisco Service Independent Intercept (SII) Architecture 21

22 RFC 1984 Informational RFC by IAB and IESG, August 1996 The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy.... The IAB and IESG are therefore disturbed to note that various governments have actual or proposed policies on access to cryptographic technology that either: (a) impose restrictions by implementing export controls; and/or (b) restrict commercial and private users to weak and inadequate mechanisms such as short cryptographic keys; and/or (c) mandate that private decryption keys should be in the hands of the government or of some other third party; and/or (d) prohibit the use of cryptology entirely, or permit it only to specially authorized organizations. We believe that such policies are against the interests of consumers and the business community, are largely irrelevant to issues of military security, and provide only a marginal or illusory benefit to law enforcement agencies,... 22

23 IETF Policy on Wiretapping RFC 2804, May 2000, by IAB and IESG The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards. The IETF restates its strongly held belief, stated at greater length in [RFC 1984], that both commercial development of the Internet and adequate privacy for its users against illegal intrusion requires the wide availability of strong cryptographic technology. On the other hand, the IETF believes that mechanisms designed to facilitate or enable wiretapping, or methods of using other facilities for such purposes, should be openly described, so as to ensure the maximum review of the mechanisms and ensure that they adhere as closely as possible to their design constraints. The IETF believes that the publication of such mechanisms, and the publication of known weaknesses in such mechanisms, is a Good Thing. 23

24 Cisco Architecture for Lawful Intercept c.f RFC 3924 (Informational RFC) 24

25 RFC Cisco Architecture for Lawful Intercept Published only for informational purposes IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. ð Analogy: Academic community would publish of known weaknesses in the view of known adversaries publish possible (and likely applied) attacks of known adversaries develop and provide solutions to improve privacy 25