RTFM: New Attributes for Traffic Flow Measurement

Handelman, Sigmund; Stibler, S.; Brownlee, Nevil; Ruth, Greg

doi:10.17487/rfc2724

Cited by 20 publications

(7 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Instead, we propose that ow-level statistics should be collected at each ingress link. These measurements can be collected directly by the incident router 14,15]. A o w i s d e n e d a s a s e t o f p a c kets that match in the key IP and TCP/UDP header elds (such a s the source and destination addresses, and port numbers)and arrive on the same ingress link.…”

Section: Measurement Methodologymentioning

confidence: 99%

Deriving traffic demands for operational IP networks: methodology and experience

Feldmann¹,

Greenberg

Lund

et al. 2001

IEEE/ACM Trans. Networking

397

351

View full text Add to dashboard Cite

Engineering a large IP backbone network without an accurate, network-wide view of the tra c demands is challenging. Shifts in user behavior, changes in routing policies, and failures of network elements can result in signi cant (and sudden) uctuations in load. In this paper, we present a model of tra c demands to support tra c engineering and performance debugging of large Internet Service Provider networks. By de ning a tra c demand as a volume of load originating from an ingress link and destined to a set of egress links, we can capture and predict how routing a ects the tra c traveling between domains. To infer the tra c demands, we propose a measurement methodology that combines ow-level measurements collected at all ingress links with reachability information about all egress links. We d i scuss how to cope with situations where practical considerations limit the amount and quality of the necessary data. Speci cally, we show how to infer interdomain tra c demands using measurements collected at a smaller number of edge links | the peering links connecting to neighboring providers. We report on our experiences in deriving the tra c demands in the AT&T IP Backbone, by collecting, validating, and joining very large and diverse sets of usage, con guration, and routing data over extended periods of time. The paper concludes with a preliminary analysis of the observed dynamics of the tra c demands and a discussion of the practical implications for tra c engineering.

show abstract

Section: Measurement Methodologymentioning

confidence: 99%

Deriving traffic demands for operational IP networks: methodology and experience

Feldmann¹,

Greenberg

Lund

et al. 2001

IEEE/ACM Trans. Networking

397

351

View full text Add to dashboard Cite

show abstract

“…The network traffic utilized in our analysis is organized into bi-directional flow records by Argus (http://www.qosient.com/argus), which is a realtime flow monitor based on the RTFM flow model [42], [43]. Argus inspects each packet and groups together those within the same connection into one bi-directional record.…”

Section: Data Collectionmentioning

confidence: 99%

Are Your Hosts Trading or Plotting? Telling P2P File-Sharing and Bots Apart

Yen

Reiter

2010

2010 IEEE 30th International Conference on Distributed Computing Systems

View full text Add to dashboard Cite

Abstract-Peer-to-peer (P2P) substrates are now widely used for both file-sharing and botnet command-andcontrol. Despite the commonality of their substrates, we show that the different goals and circumstances of these applications give rise to behaviors that can be distinguished in network flow records. Using features related to traffic volume, persistence of network connections, amount of "churn" among peers, and differences between humandriven and machine-driven traffic, we develop a technique for identifying P2P bots (the Plotters) and, in particular, separating them from file-sharing hosts (the Traders). Evaluations performed on traffic recorded at the edge of a university network show that we can achieve, e.g., 87.50% detection of Storm bots with a 0.81% false positive rate. We also demonstrate the significant extent to which Plotter behaviors would need to change to evade our techniques.

show abstract

“…Argus is a real time flow monitor based on the RTFM flow model [21,22]. Argus inspects each packet and groups together those with the same attribute values into one bi-directional record.…”

Section: Data Setsmentioning

confidence: 99%

Browser Fingerprinting from Coarse Traffic Summaries: Techniques and Implications

Yen

Huang

Monrose

et al. 2009

Detection of Intrusions and Malware, and Vulnerability Assessment

View full text Add to dashboard Cite

Abstract. We demonstrate that the browser implementation used at a host can be passively identified with significant precision and recall, using only coarse summaries of web traffic to and from that host. Our techniques utilize connection records containing only the source and destination addresses and ports, packet and byte counts, and the start and end times of each connection. We additionally provide two applications of browser identification. First, we show how to extend a network intrusion detection system to detect a broader range of malware. Second, we demonstrate the consequences of web browser identification to the deanonymization of web sites in flow records that have been anonymized.

show abstract

RTFM: New Attributes for Traffic Flow Measurement

Abstract: The RTFM Traffic Measurement

Cited by 20 publications

References 7 publications

Deriving traffic demands for operational IP networks: methodology and experience

Deriving traffic demands for operational IP networks: methodology and experience

Are Your Hosts Trading or Plotting? Telling P2P File-Sharing and Bots Apart

Browser Fingerprinting from Coarse Traffic Summaries: Techniques and Implications

Contact Info

Product

Resources

About