March 2005 - Test - lists.nanog.org

not operationally relevant until it's used in the wild
by k claffy 01 Mar '05

01 Mar '05

but in the interest of full and early disclosure, etc k ----- Forwarded message from k claffy <kc(a)caida.org> ----- Date: Tue, 1 Mar 2005 17:34:27 -0800 From: k claffy <kc(a)caida.org> Subject: [Caida] yoshi's study on remote physical device fingerprinting To: caida(a)caida.org Cc: Tadayoshi Kohno <tkohno(a)cs.ucsd.edu> Yoshi Kohno (doctoral student in UCSD's CSE program) just released an eye-opening paper demonstrating methods for remotely fingerprinting a physical device without any modification to or known cooperation from the fingerprintee. At a high level, these techniques exploit microscopic deviations in device hardware: clock skews. Specifically, they exploit the fact that most modern TCP stacks implement the TCP Timestamps Option (RFC 1323). When this option is enabled, outgoing TCPs packets leak information about the sender's clock. Yoshi's results further confirm a fundamental reason why securing real-world systems is so difficult: it is possible to extract security-relevant signals from data canonically considered to be noise. The equally disturbing corrolary is that there remain fundamental properties of networks that we have yet to integrate into our security models. please don't forward to any bad guys. </cough> k paper and abstract available here: ======================================================= <http://www.cse.ucsd.edu/users/tkohno/papers/PDF/> [mirror site] <http://www.caida.org/outreach/papers/2005/fingerprinting/> Our abstract: We introduce the area of remote physical device fingerprinting, or fingerprinting a physical device, as opposed to an operating system or class of devices, remotely, and without the fingerprinted device's known cooperation. We accomplish this goal by exploiting small, microscopic deviations in device hardware: clock skews. Our techniques do not require any modification to the fingerprinted devices. Our techniques report consistent measurements when the measurer is thousands of miles, multiple hops, and tens of milliseconds away from the fingerprinted device, and when the fingerprinted device is connected to the Internet from different locations and via different access technologies. Further, one can apply our passive and semi-passive techniques when the fingerprinted device is behind a NAT or firewall, and also when the device's system time is maintained via NTP or SNTP. One can use our techniques to obtain information about whether two devices on the Internet, possibly shifted in time or IP addresses, are actually the same physical device. Example applications include: computer forensics; tracking, with some probability, a physical device as it connects to the Internet from different public access points; counting the number of devices behind a NAT even when the devices use constant or random IP IDs; remotely probing a block of addresses to determine if the addresses correspond to virtual hosts, e.g., as part of a virtual honeynet; and unanonymizing anonymized network traces. _______________________________________________ Caida mailing list Caida(a)caida.org http://rommie.caida.org/mailman/listinfo/caida ----- End forwarded message -----

1 0

Fwd: Impending publication: draft-iab-dns-assumptions-02.txt
by Fergie (Paul Ferguson) 01 Mar '05

01 Mar '05

Of imminent interest to the operations community.... FYI, - ferg ---------- Forwarded Message ---------- The IAB is ready to ask the RFC-Editor to publish What's in a Name: False Assumptions about DNS Names draft-iab-dns-assumptions-02 as an Informational RFC. This document reviews the potential assumptions that may be made based on domain names, as well as the potential implications (and pitfalls) of those assumptions. The IAB solicits comments by March 29, 2005. Please send comments to the IAB (iab(a)iab.org) or to ietf(a)ietf.org. The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-assumptions-02.txt >From the Abstract: The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, URIs, and other application layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. A danger of this trend is that the humans and automata which consume and use these identifiers will make assumptions about the services that are or should be provided by the hosts associated with these identifiers. This document discusses this problem in more detail and makes recommendations on how it can be avoided. Leslie Daigle, For the IAB. _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

[ACM SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05)]
by k claffy 01 Mar '05

01 Mar '05

perhaps more relevant to nanog-futures list but i'll assume everyone cares. k ----- Forwarded message from Bob Braden <braden(a)ISI.EDU> ----- Date: Mon, 28 Feb 2005 08:50:30 -0800 (PST) From: Bob Braden <braden(a)ISI.EDU> Subject: [e2e] ACM SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05) To: end2end-interest(a)postel.org ------------------------------------------------------------------- Call for papers ****************************************************************** * * * SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05) * * * * (to be held with SIGCOMM 2005, Aug 20-26, Philadelphia, USA) * * * * http://www.acm.org/sigs/sigcomm/sigcomm2005/cfp-minenet.html * ****************************************************************** Today's IP networks are extensively instrumented for collecting a wealth of information including traffic traces (e.g., packet or flow level traces), control (e.g., router forwarding tables, BGP and OSPF updates), and management (e.g., alarms, SNMP traps) data. The real challenge is to process and analyze this vast amount of primarily unstructured information and extract structures, relationships, and "higher level knowledge" embedded in it and use it to aid network management and operations. The goal of this one day workshop is to explore new directions in network data collection, storage, and analysis techniques, and their application to network monitoring, management, and remediation. The workshop will provide a venue for researchers and practitioners from different backgrounds, including networking, data mining, machine learning, and statistics, to get together and collaboratively approach this problem from their respective vantage points. We are soliciting original/position papers on topics (including, but not limited to) listed below. - Collection, storage & access infrastructure: platform instrumentation (e.g. multi-modal, multi-resolution sensors), collection techniques (e.g. event sampling, filtering, aggregation, etc.), storage and access (e.g. retention policy, indexing techniques etc.). - Network data analytics techniques & tools: network stream mining, network graph mining, micro-clustering, temporal and statistical correlation, causality tracking, machine learning. - Applications to network operations & management: network problem determination, network reliability and performance, root-cause analysis, security, emerging phenomenon detection (e.g. DDoS, virus/worm, spam etc.), traffic classification. Of particular interest are (i) new solution techniques as well as applications of existing techniques from data mining, machine learning and statistics to IP network problems, (ii) experiences with the use of such techniques for IP networks, and (iii) open networking problems and challenges that would benefit from the use of such techniques. Selected papers will be forward-looking, with impact and implications for both operational networks and ongoing or future research. Submission Instructions ----------------------- Papers should be at most 6 pages long, in standard ACM format (single-spaced, double column, at least 10pt font). Accepted papers will appear in the workshop proceedings. Authors of accepted papers are expected to present their work at the workshop. Detailed submission guidelines will be available soon at http://www.acm.org/sigs/sigcomm/sigcomm2005/cfp-minenet.html. Important Dates --------------- Submission Deadline: Wed, April 6, 2005, 9.00 PM EST Notification Deadline: May 10, 2005 Camera Ready Deadline: May 30, 2005 Workshop Date: Aug 26, 2005 Workshop Organizing Chairs -------------------------- Subhabrata Sen, AT&T Research Chuanyi Ji, Georgia Tech Debanjan Saha, IBM Research Joe McCloskey, Dept. of Defense Technical Program Committee ---------------------------- Constantinos Dovrolis, Georgia Tech. Chuanyi Ji, Georgia Tech. Nick Koudas, Univ. of Toronto Vipin Kumar, Univ. of Minnesota Joe McCloskey, Dept. of Defense Robert Novak, Univ. of Wisconsin-Madison Rajeev Rastogi, Lucent Bell Labs John Reumann, IBM Research Jennifer Rexford, Princeton Univ. Mathew Roughan, Univ. of Adelaide Debanjan Saha, IBM Research Subhabrata Sen, AT&T Research William Szewczyk, Dept. of Defense Walter Willinger, AT&T Research Zhi-Li Zhang, Univ. of Minnesota ----- End Included Message ----- ----- End forwarded message -----

1 0

Heads up: Long AS-sets announced in the next few days
by Lorenzo Colitti 01 Mar '05

01 Mar '05

Hi, as announced to the RIPE routing working group mailing list [1] and elsewhere, over the next few days the Computer Networks research group at Roma Tre University, in collaboration with the RIPE NCC RIS project, will be performing experiments involving announcements with large AS-sets in the AS-path. We are doing this to test innovative network discovery methodologies we developed to allow ISPs to determine how their prefixes are seen by the rest of the Internet. The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654. We have been performing similar experiments over IPv6, in collaboration with the NAMEX internet exchange, since December 2004 with no ill effects; furthermore, our announcements are standard BGP, so conformant implementations should be able to process them, and very long AS-sets have already been observed in the past (e.g. [2], [3]). However, we want to be careful to avoid router bugs on legacy devices, old firmware versions and the like, so we are first sending out test announcements with progressively longer AS-sets. Should you encounter a problem with these advertisements, please let us know and we will withdraw them. The proposed timetable of the test announcements is as follows. 2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal and, if there are no problems: 2005-03-07: 14:00 UTC: 50-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 100-element AS-set 16:30 UTC: withdrawal Note: For reference, the AS-sets already observed in [2] and [3] contained 123 and 124 ASes respectively. For questions/comments, please contact compunet(a)dia.uniroma3.it or lorenzo(a)ripe.net. Regards, Lorenzo Colitti On behalf of the Roma Tre Computer Networks Research group [1] http://www.ripe.net/ripe/maillists/archives/routing-wg/2005/msg00021.html [2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html [3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html

1 0

Multihoming for the small ISP ( search engine) ala 2005
by Geoff White 01 Mar '05

01 Mar '05

Greetings folks, (It's been a long time :) I have some questions about multihoming that I can't seem to find by Google-ing for answers 1.) What ever happened to (Avi Freedman's?) Multihoming strategy using DNS(?), there are links to archives circa 1997 but nothing recent. 2) What is the "preferred or correct" way for a relatively small outfit (a small search engine) to implement Multihoming? Especially when most of the machines are a VLS cluster so we are not talking about a large address space here. It seems the outfit is having difficulty getting blocks that they can even run BGP with, (I know I'm missing a lot here) They can't even fill a /24, let alone anything greater :) I am willing to take my answers off line. I'm sure there is a way to do this that is so trivial to folks on this list that it's not talked about, but since I haven't done this type of thing in about 5 years I am really out of the loop. Thanks in advance and for all the great work over the years! Cheers Geoff White

4 3

RE: High volume WHOIS queries
by Hannigan, Martin 01 Mar '05

01 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Paul G > Sent: Tuesday, March 01, 2005 5:03 AM > To: nanog(a)merit.edu > Subject: Re: High volume WHOIS queries > > > > > ----- Original Message ----- > From: "Stephen J. Wilcox" <steve(a)telecomplete.co.uk> > To: "joe mcguckin" <joe(a)via.net> > Cc: "Dan Lockwood" <dlockwood(a)shastacoe.org>; "NANOG" > <nanog(a)merit.edu> > Sent: Tuesday, March 01, 2005 4:53 AM > Subject: Re: High volume WHOIS queries > > > > > > altho arguably its not up to arin to provide processing > power for all > these > > deployments. > > > > if you can get a local copy why not have your clients > resolve back to > that? > > that is the point of his post actually - arin told him that > he can't do that > without pointing out where this is prohibited in the aup. i > can see their > point - they're trying to restrict the practicality of > attempting to harvest > the data and an open to the public whois server with no > access restrictions > would defeat that. I don't know that this is the case, I suspect it's resource management. If the database is getting slaughtered by applications on uncontrolled auto pilot, it's unusable for the rest of us. -M<

4 3

RE: High volume WHOIS queries
by Hannigan, Martin 01 Mar '05

01 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Paul G > Sent: Tuesday, March 01, 2005 9:22 AM > To: nanog(a)merit.edu > Subject: Re: High volume WHOIS queries > > > > > ----- Original Message ----- > From: "Hannigan, Martin" <hannigan(a)verisign.com> > To: "Paul G" <paul(a)rusko.us>; <nanog(a)merit.edu> > Sent: Tuesday, March 01, 2005 9:17 AM > Subject: RE: High volume WHOIS queries > > > > > >> -----Original Message----- > >> From: owner-nanog(a)merit.edu > [mailto:owner-nanog@merit.edu]On Behalf Of > >> Paul G > >> Sent: Tuesday, March 01, 2005 5:03 AM > >> To: nanog(a)merit.edu > >> Subject: Re: High volume WHOIS queries > > --- snip --- > > >> point - they're trying to restrict the practicality of > >> attempting to harvest > >> the data and an open to the public whois server with no > >> access restrictions > >> would defeat that. > > > I don't know that this is the case, I suspect it's > > resource management. If the database is getting > > slaughtered by applications on uncontrolled auto pilot, > > it's unusable for the rest of us. > > well, the OP quoted a portion of the aup that requires bulk > whois data recipients to take measures to prevent harvesting, > so i presume that arin does care about that and, in fact, that > consideration is likely the reason they declined to permit the > OP to run *his own* whoisd off of his *local* copy of the data. The AUP also says for "internet operational or research purposes only." Maybe they don't consider the use to fit in the defintion? There's an easier fix, IMO. Run a two stage query, 50 and 50, and then append the second 50 to the bottom of the first. -M< -M<

1 0

Send-Safe spam tool gang evicted by MCI...
by Fergie (Paul Ferguson) 01 Mar '05

01 Mar '05

The Register is reporting that: "US telco MCI Worldcom has caved in to mounting pressure and booted a site that sells spamming software off its network." http://www.theregister.co.uk/2005/03/01/send-safe_evicted/ - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0