looking for hosting sites for CAIDA Ark measurement infrastructure
folks, we are seeking additional Ark vantage points ( http://www.caida.org/projects/ark/ ) to support a variety of projects but especially motivated by our NSF-funded project to map and measure interconnection in the Internet: http://www.caida.org/funding/nets-congestion/ (recent paper describing the current method: http://www.caida.org/publications/papers/2015/measuring_interdomain_congestion/ ) we are looking to build as complete a map as we can of the interconnections between U.S. residential broadband access providers and their neighbors. so our priority is vantage points in the homes of U.S. access providers (especially high b/w access providers). but if you are interested in hosting an Ark node anywhere, please let me or monitor-i...@caida.org know where/when. we will send a raspberry pi monitor out to you stat. some faq info on hosting a monitor: http://www.caida.org/projects/ark/siteinfo.xml and the infrastructure project itself: http://www.caida.org/projects/ark/ thanks very much, k
CAIDA's 2012 IPv6 survey -- need network operators to fill out
[direct link to IPv6 operational deployment [plans] survey if you don't need background: http://www.surveygizmo.com/s3/749797/ipv6survey ] hello folks, we're trying to do some quantitative modeling of the IPv4-IPv6 transition, including the impact of IPv4 markets on likely future trajectories, but really need some empirical data to parametrize our model. with much help from many patient reviewers of the questions, we finally have a survey ready for operators to fill out. below i'll give an extremely terse description of the model just to give you an idea of why we need this granularity. there are another 10 dense pages describing the model pending peer review at NSF, which i can send to anyone interested in giving us feedback on it. but it's not necessary for responding to the survey. also note the checkbox to indicate you're amenable to further followup questions. survey will be available till 12 april 2012. (or tell us if you want to fill it out but need more time.) survey link, again: http://www.surveygizmo.com/s3/749797/ipv6survey thanks much, k, amogh, emile -- Most prior work on modeling the adoption of new technologies assumed a binary decision at the organization level -- in the context of IPv6, this decision means switching completely to IPv6 or not at all. We propose to account for the fact that an organization may deploy IPv6 incrementally in its network, meaning that it will continue to have both IPv4 and IPv6 space. A key aspect of our model is that instead of a binary state per organization, we work at the granularity of devices, which are entities that need to be assigned IP addresses. We consider a device to correspond to a single instance of an IP addressing need, which typically corresponds to an interface. Though there can be multiple interfaces (``devices'') on the same computer/router, and multiple addresses (``virtual interfaces'') on a single interface, we will model each need for an independent IP address as an independent device. We define device classes based on the nature of addresses used to number those devices, e.g., public IPv4, IPv6, dual-stack-NATv4, dual-stack-public-IPv4, etc. We model the network growth requirements of each network in terms of the number of additional devices in that network that need to be configured in one of these device classes. ... (then we catalog a list of costs and incentives associated with the decision to adopt IPv6 or satisfy one's addressing needs with IPv4-based technologies. costs parameters include the costs of IPv4 addresses, NAT deployment, renumbering, and translation between IPv4 and IPv6. we will also try to model incentives such as policies and regulations.) We will then model two separate decision processes for a network, based on whether it seeks to add new devices (to expand its network, provision for new customers, deploy new services, etc.), or whether it seeks to optimize the numbering of its existing devices from among the five device classes defined previously. The latter operation may be necessary if external factors and costs have changed such that the network could substantially lower its costs by numbering its devices differently. We want to structure the model (based on feedback from opsfolk like you) to capture both initial costs as well as ongoing operational costs of supporting a given configuration of devices for a specified window following the decision. Iteration of the decision process continues for each network until we reach a state where no network has the incentive to change the numbering of its devices, which represents the equilibrium.
Re: Spoofer project update -- need 3-5 minutes of your time to test
a call to fingers please run this test if you haven't already. we're trying to get a 2009 baseline on filtering. i've blogged a reminder at: http://blog.caida.org/best_available_data/2009/04/05/spoofer-measure-your-networks-hygiene/ and will post results there (and here) too, once we have some. if you run into any problems, email us. Internet science: can't do it without you, yada. k ps: if you want to host an Ark node so we can test topology near you in the future, read http://www.caida.org/projects/ark/siteinfo.xml and send us mail. On Tue, Mar 31, 2009 at 11:36:18AM -0400, Robert Beverly wrote: Hi, as many of you are acutely aware, IP source spoofing is still a common attack vector. The ANA spoofer project: http://spoofer.csail.mit.edu first began quantifying the extent of source verification in 2005. We've amassed several years worth of data -- data that has become particularly interesting in light of recent attacks. However, our data raised as many questions as it answered. Hence, we have developed a new version of the tester designed to answer these questions and improve our Internet-wide inferences. What's New: In addition to new tests, we've hooked into CAIDA's Ark infrastructure which allows us to perform multiple path-based measurements. This information is presented to the client now in visual form; see the screenshots for an example report: http://spoofer.csail.mit.edu/example/example.php How you can help: Simple -- take a few minutes to download and run the tester. The more points you can run the tester from, the better. Comments/Flames: Welcome, and we appreciate all feedback. Be sure to read the FAQ: http://spoofer.csail.mit.edu/faq.php Many thanks, rob
Re: an effect of ignoring BCP38
do that many networks really allow spoofing? i used to think so, based on hearsay, but rob beverly's http://spoofer.csail.mit.edu/summary.php suggests things are a lot better than they used to be, arbor's last survey echos same. are rob's numbers inconsistent with numbers anyone else believes to be true? i think you unfairly characterize UW's work, but i also think you make questionable inferences regarding the extent of spoofing, which seems more relevant to nanog. k On Fri, Sep 05, 2008 at 05:22:27AM +, [EMAIL PROTECTED] wrote: seems that some folks in the RE community, with institutional support from Cisco, Google, and the US NSF, are exploiting our inability to take even rudimentary steps toward providing a level of integrity in routing by teaching students that spoofing IP space is ok. This whole thing works at all because so few people use/deploy/maintain BCP-38 compliance. This was an eye-opener for me. http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf --bill
Re: Avg. Packet Size - Again?
most recent update on this question, with just a couple of data points: http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml (so, yes the peak has moved up to 1500.) note there are more tiny packets in our recent ipv6 data, but that could just be someone's ping experiment, it's too small a sample (76k pkts) k On Wed, Jul 16, 2008 at 08:24:59AM -0700, fred baker wrote: CAIDA has been doing a lot of that, at least in the past. Last I asked them, which was quite a while back, they said that O(35%) of traffic in their samples was at the path MTU (which included 576 bytes for historical reasons), O(40%) was about the size of a TCP SYN or ACK, for reasons that are apparent if you think about common TCP implementations, and sizes were scattered more or less uniformly in between - last packet in a burst or transaction exchanges. From the numbers that Valdis posted the other day, it sounds like the logic remains about the same but the relevance of 576 has largely gone away. On Jul 16, 2008, at 4:42 AM, Randy Bush wrote: Our network also shows peaks at the ethernet MTU (our MTU is higher than that) and the DNS packet size. so who has been tracking packet size distributions for some years and has published or could provide data? randy
