Help Us Measure Fixed 5G Networks
Hello, We are working on a project to measure the performance of Fixed 5G wireless networks. If you or anyone you know are a subscriber of: * Starlink * Verizon * T-Mobile you are eligible to help us with this study. Participation is simple: We send a Raspberry Pi with some pre-installed measurement software (Netrics), you plug it into the wall and your cable modem, and we give you a performance dashboard with your network performance, including comparisons to other networks. We offer a small participation incentive, as well. We’d ask for participation for 1-2 months, although you are welcome to continue your participation longer. See the form below for more information, including how to participate: https://uchicago.co1.qualtrics.com/jfe/form/SV_eCFrZhRhNphkVGm Thanks, Nick Feamster and Francesco Bronzino
Re: Prefix hijacking, how to prevent and fix currently
Hi Doug, All,
We’ve seen similar things, including hijacks of less specific IP prefixes (even
/8s), correlated with spam behavior.
We presented on this at NANOG 35:
http://nanog.org/meetings/nanog36/presentations/feamster.pdf
Slide 4 shows a short-lived BGP announcement for IP space that was the source
of spam. Interestingly, many of the short-lived annoucements that we observed
were /8s. Subsequent slides explain why. Subsequent slides explain these
observations in more detail, and we had a paper in SIGCOMM’06 describing this
activity in more detail:
http://www.cc.gatech.edu/~feamster/papers/p396-ramachandran.pdf
We have a couple of pieces of follow-up work:
- It turns out that you can use BGP dynamics as features to design filters for
spam and other attack traffic (we have a couple of papers on this)
- Some of these observable dynamics are also useful for establishing AS
reputation (a la Hostexploit) - we have some ongoing work here
Happy to talk more, either on-list or off-list.
Cheers,
-Nick
On Aug 31, 2014, at 2:04 PM, Doug Madory dmad...@renesys.com wrote:
FWIW, this is from an IP squatting operation I came across in recent weeks. I
encounter these things regularly in the course of working with BGP data -
probably others do too. Usually I look up the ASN or prefix and often it has
already been added to someone's spam source list. When I see that, I assume
the system is working and move on.
In this case, starting late Jun, we have seen IP address ranges from around
the world (most ranges are unused, sometimes hijacked space) announced by one
of two (formerly unused) ASNs and routed through another formerly unused ASN,
57756, then on to Anders (AS39792) and out to the Internet in the following
form:
... 39792 57756 {3.721, 43239} prefix
The prefixes are only routed for an hour or two before it moves on to the
next range of IP address space. Not sure if this is for spam or something
else. Either way, it is probably associated with something bad. Earlier this
month I reached out to a contact at Anders in Russia and gave him some
details about what was happening. I didn't get a response, but within a
couple of days the routing (mostly) shifted from Anders to through Petersburg
Internet Network (AS44050). I have no idea if this was due to my email. The
day it moved to PIN I sent similar emails to addresses I could find at PIN,
but haven't seen any response. Now the these routes take one of two forms:
... 39792 57756 {3.721, 43239} prefix
Or
... 44050 57756 {3.721, 43239} prefix
This is mostly routed through Cogent (AS174), but Anders (AS39792) also has a
lot of peers. I would advise that people treat any route coming through
AS57756 is probably bad. AS57756 doesn't originate anything and hasn't since
28-Jun when it very briefly hijacked some NZ space.
Also, Pierre-Antoine Vervier from Symantec gave a good talk at NANOG in Feb
about IP squatting for spam generation. Pierre and I have since compared
notes on this topic.
-Doug Madory
- Original Message -
From: Tarun Dua li...@tarundua.net
To: nanog@nanog.org
Sent: Thursday, August 28, 2014 12:55:25 PM
Subject: Prefix hijacking, how to prevent and fix currently
AS Number 43239
AS Name SPETSENERGO-AS SpetsEnergo Ltd.
Has started hijacking our IPv4 prefix, while this prefix was NOT in
production, it worries us that it was this easy for someone to hijack
it.
http://bgp.he.net/AS43239#_prefixes
103.20.212.0/22 - This belongs to us.
103.238.232.0/22 KNS Techno Integrators Pvt. Ltd.
193.43.33.0/24 hydrocontrol S.C.R.L.
193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
Where do we complain to get this fixed.
-Tarun
AS132420
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Do Not Complicate Routing Security with Voodoo Economics
Three thoughts on the thread so far. 1. I think Randy raises an interesting point about the complexity of contracts. We had a paper in SIGCOMM this year on the increasing use of more complicated interconnection contracts (and, in particular, tiered pricing). See Section 2 of our paper [1]: http://www.gtnoise.net/papers/library/valancius-tiers.pdf Some of us academics are trying to get more clued up on what providers actually do. :-) [I may start a discussion on the pricing models in this paper in a separate thread later] 2. I question what fraction of routing decisions come down to a blind tiebreak---nearly all of them are likely to be driven by some other consideration (reliability, cost, etc.). Our paper details a richer economic model by which ASes actually select paths, for example, but it's still unclear to me how coarse or fine-grained route selection really is in practice, and to what extent more complicated contracts have evolved. I wonder how common blind tiebreaking is in BGP, in real networks; the approach in Sharon's paper definitely may overstate how common that is if route selection considerations commonly involve things that are not visible in the AS graph (e.g., traffic ratios, congestion, performance), but academics could really benefit from some more insight into how rich these decisions are in practice. 3. I think the discussion on the list so far misses what I see as the central question about the economic assumptions in that paper. The paper assumes that all destinations are equally valuable, which we know is not the case. This implicitly (and perhaps mistakenly?) shifts the balance of power to tier-1 ISPs, whereas in practice, it may be with other ASes (e.g., Google). In practice, ISPs may be willing to spend significant amounts of money to reach certain destinations or content (some destinations are more valuable than others... e.g., Google). If the most valuable destinations deployed S-BGP and made everyone who wanted to connect to them deploy it, that would be more likely to succeed than the approach taken in the paper, I think. Conclusion: All of these questions above make me wonder about two more general assumptions that it would be good to get some more insight into: * Who holds the cards, in terms of dictating the terms of interconnection? Content providers? Access networks/eyeballs? Tier-1s? (many of the recent peering spats recently seem to indicate that various ASes are trying to shake the current balance(s) of power, it seems) * How complicated are interconnection contracts today, and how have they evolved? (i.e., how common is a random tiebreak, and how does that differ by network?) -Nick - [1] Valancius, V. and Lumezanu, C. and Feamster, N. and Johari, R. and Vazirani, V.V. How Many Tiers? Pricing in the Internet Transit Market In ACM SIGCOMM, 2011 On Sep 5, 2011, at 11:36 AM, Joe Maimon wrote: Owen DeLong wrote: On Sep 5, 2011, at 7:24 AM, Jennifer Rexford wrote: One could argue that rejecting routes which you previously had no way to know you should reject will inherently alter the routing system and that this is probably a good thing. Good point. Also, tie breaking in favor of signed-and-verified routes over not-signed-and-verified routes does not necessarily affect your traffic positively or negatively -- rather, if you are letting an arbitrary final tie break make the decision anyway, you are arguably *neutral* about the outcome... -- Jen This is true in terms of whether you care or not, but, if one just looks at whether it changes the content of the FIB or not, changing which arbitrary tie breaker you use likely changes the contents of the FIB in at least some cases. The key point is that if you are to secure a previously unsecured database such as the routing table, you will inherently be changing the contents of said database, or, your security isn't actually accomplishing anything. Owen Except if you believe we have been lucky until now and security is all about the future where we may be less lucky. What I would be interested in seeing is a discussion on whether any anti-competitive market distortion incentives exist for large providers in adopting secured BGP. We might be lucky there too. Perhaps this will finally help solve the routing slot scalability problem. Might also jumpstart LISP. Which may put some more steam into v6. Welcome to the brave new internet. Good for everyone, right? Are you feeling lucky? Joe
Re: Announcing Project BISMark: ISP Performance Measurements from Home Routers
Thanks for the feedback! On Jun 28, 2011, at 6:13 AM, Mikael Abrahamsson wrote: On Mon, 27 Jun 2011, Nick Feamster wrote: We've launched Project BISMark, a project that performs active performance measurements of upload and download throughput, latency, etc. from OpenWRT-based routers running inside of homes. We have tested our OpenWRT image on the NetGear WNDR 3700v2 and are currently shipping out NetGear routers with the BISMark firmware to anyone who is interested. Please, pretty please, with sugar on top, don't just do active measurement, but also do passive measurement of real traffic. Doing test traffic is one case, but the really important thing to look at is real traffic. I tried to get traction for this on IETF75, but there seems to be little interest. We would very much like to. There are a number of reasons that regular users seem to be asking for passive measurement, such as monitoring of traffic usage of different applications (e.g., How much is streaming eating into my usage cap?). A few years ago, we had a tool that would do all of this with passive measurement (http://gtnoise.net/nano/), and we'd certainly like to resume this line of inquiry, if we can figure out how to address people's privacy concerns. We are developing a passive measurement suite for BISMark, which is also available on github. On a NAT router there is a state table, what would the performance penality be to look at TCP sequence numbers, RTTs (TCP timestamps) to be able to discern PDV and loss of the actual traffic the customer is doing? There are a lot of test suites, they solve one problem, but a passive monitoring system that would show how the real traffic is behaving would yield a lot more valuable information that just relying on active testing (which will cause harm to customer traffic when the test is run). Definitely good points, and we've thought about this, for sure. The key question seems to be how to handle user privacy in a way that everyone can be happy with. Ultimately, we might take a survey of our users about this (e.g., certain people have said they don't mind tracking application performance/usage as long as the specific Web sites or destinations are not logged). It would be really helpful to get an understanding of what users might find acceptable, as far as passive measurements. -Nick
Re: Announcing Project BISMark: ISP Performance Measurements from Home Routers
Hi Alex, On Jun 28, 2011, at 6:30 AM, Alex Brooks wrote: Is this similar to the UK (Ofcom, http://www.ofcom.org.uk/) and US (FCC, http://www.fcc.gov/) regulators scheme that is being run by Sam Knows at http://www.samknows.com/broadband/test_my_isp and http://www.samknows.com/broadband/broadband_performance ? Yes, it's very closely related, and we've been in close contact with them (we have a paper upcoming at SIGCOMM that is based on the US data that we've jointly authored). One of the differences is that the platform is open / open-source. For example, anyone would be able to develop and run their own tests from the box. Another difference is that we're looking into a variety of other things (e.g., measurements of performance inside the home, deployments in other regions, maybe ultimately passive measurements if we can figure out how to balance the more sensitive aspects of that). Our goal is to have some sets of tests that are running/could be run on either platform. We're interested in helping to improve the tests that are run on the SK routers, as well. -Nick
please help - survey on network operations costs
Hello, We are developing a tool that helps ISPs optimize for cost when making decisions about both internal routing and interconnection for planning and traffic management. To develop the underlying algorithms, we need a better sense of how various factors contribute to an ISP's overall operational costs. Our objective is not to obtain specific numbers---we understand that individual ISPs may have very confidential information about pricing, and that you may not want to share that with us. Rather, we are seeking to build a model that any operator could use by plugging in specific numbers. Constructing this model still requires some understanding of the relative costs of various factors. We would appreciate any help you can provide. In return, we will (1) share the results of the survey with you (after anonymizing appropriately); (2) work with you to apply our optimization technique to your network to see if it can help reduce your overall costs. Thank you very much for any help you can provide, Nick and Murtaza - 1. Are you a: * access ISP network * transit provider * content distribution network * other (please specify) 2. How do you account for recurring costs incurred in carrying IP traffic on your backbone? Do you incorporate both backhaul and interconnect costs? Which one of these factors tends to be more dominant? Are there other factors that are significant enough to consider explicitly? (If you have a template cost model, that would be very helpful.) 3. What are the relative costs of each of the following for interconnection? (If you feel comfortable doing so, please rank them.) * port/interface costs (e.g., 1G, 10G, etc.) * type of transmission (e.g., IP, WDM, SONET, etc.) * transit costs * others (please specify) 4. What factors affect internal network costs for carrying traffic? * port/interface costs * distance travelled (e.g., # of hops, geography - local, regional, backbone, trans-continental) * real estate costs (e.g., carrier hotel, fiber leasing...) * traffic demand or congestion in a region (e.g., is northeast corridor more expensive than other parts of the network?) * other (please specify) 5. When pricing your own IP connectivity services, do you use average cost models? Do you use the same cost structure for each customer, regardless of how much of your backbone and interconnect infrastructure they use?
Re: Repeated Blacklisting / IP reputation
Hi Tom (and NANOG), You may be interested in an alternative approach, motivated by the very problem you are facing (see below). Our system, SNARE, develops IP reputation automatically based on a combination of network features. We'll discuss the pros and cons of this approach at MAAWG. The additional information that SNARE provides might be helpful. -Nick Detecting Spammers with SNARE: Spatio-temporal Network-level Automatic Reputation Engine Shuang Hao, Nadeem Ahmed Syed, Nick Feamster, Alexander Gray, Sven Krasser Usenix Security '09, Montreal, Canada, August 2009 Users and network administrators need ways to filter email messages based primarily on the reputation of the sender. Unfortunately, conventional mechanisms for sender reputation -- notably, IP blacklists -- are cumbersome to maintain and evadable. This paper investigates ways to infer the reputation of an email sender based solely on network-level features, without looking at the contents of a message. First, we study first-order properties of network-level features that may help distinguish spammers from legitimate senders. We examine features that can be ascertained without ever looking at a packet's contents, such as the distance in IP space to other email senders or the geographic distance between sender and receiver. We derive features that are lightweight, since they do not require seeing a large amount of email from a single IP address and can be gleaned without looking at an email's contents -- many such features are apparent from even a single packet. Second, we incorporate these features into a classification algorithm and evaluate the classifier's ability to automatically classify email senders as spammers or legitimate senders. We build an automated reputation engine, SNARE, based on these features using labeled data from a deployed commercial spam-filtering system. We demonstrate that SNARE can achieve comparable accuracy to existing static IP blacklists: about a 70% detection rate for less than a 0.3% false positive rate. Third, we show how SNARE can be integrated into existing blacklists, essentially as a first-pass filter. http://gtnoise.net/pub/index.php?detail=14 On Tue, Sep 8, 2009 at 4:58 PM, Tom Pipes tom.pi...@t6mail.com wrote: I am amazed with the amount of thoughtful comments I have seen, both on and off list. It really illustrates that people are willing to try to help out, but there is an overall lack of clear direction on how to improve things. Most of us seem to adopt that which has always just worked for us. Don't get me wrong, I'm sure there are a lot of improvements/mods going on with RBL operators in terms of the technology and how they choose who to block. I'm also certain that most of the carriers are doing their best to follow RFCs, use e-mail filtering, and perform deep packet inspection to keep themselves off of the lists. AND there seems to be some technologies that were meant to work, and cause their own sets of problems (example: allowing the end user to choose what is considered spam and blacklisting based on that). As was said before, it's not the WHY but rather how can we fix it if it's broke. The large debate seems to revolve around responsibility, or lack thereof. In our case, we are the small operator who sits in the sidelines hoping that someone larger than us, or more influential has an opinion. We participate in lists, hoping to make a difference and contribute, knowing that in a lot of cases, our opinion is just that: an opinion. I suppose that could spark a debate about joining organizations (who shall go nameless here), power to the people, etc. It seems as though a potential solution *may* revolve around ARIN/IANA having the ability to communicate an authoritative list of reassigned IP blocks back to the carriers. This could serve as a signal to remove a block from the RBL, but I'm sure there will be downfalls with doing this as well. In my specific case, I am left with a legacy block that I have to accept is going to be problematic. Simply contacting RBL operators is just not doing the trick. Most of the e-mails include links or at least an error code, but some carriers just seem to be blocking without an error, or even worse, an ACL... We will continue to remove these blocks as necessary, reassign IPs from other blocks where absolutely necessary, and ultimately hope the problem resolves itself over time. Thanks again for the very thoughtful and insightful comments, they are greatly appreciated. Regards, --- Tom Pipes T6 Broadband/ Essex Telcom Inc tom.pi...@t6mail.com - Original Message - From: Tom Pipes tom.pi...@t6mail.com To: nanog@nanog.org Sent: Tuesday, September 8, 2009 9:57:58 AM GMT -06:00 US/Canada Central Subject: Repeated Blacklisting / IP reputation Greetings, We obtained a direct assigned IP block 69.197.64.0/18 from ARIN in 2008. This block has been cursed
