Re: NIST NTP servers
Since we are on the subject, I would strongly recommend that you don't run NTP on Linux 2.2.13, since its especially vulnerable to our IPv4 fragmentation attack. "SunOS" also seems vulnerable, but I am not 100% sure what systems that say they are "SunOS" actually are. These OS will fragment packets to 64 bytes, and are vulnerable to frag attacks using "tiny" fragments. See Section VI of our paper: https://eprint.iacr.org/2015/1020.pdf You can also test your OS here (scroll to the bottom). http://www.cs.bu.edu/~goldbe/NTPattack.html On Fri, May 13, 2016 at 10:46 AM, Chuck Anderson <c...@wpi.edu> wrote: > On Fri, May 13, 2016 at 10:12:49AM -0400, Lamar Owen wrote: > > On 05/11/2016 09:46 PM, Josh Reynolds wrote: > > >maybe try [setting up an NTP server] with an odroid? > > > > > ... > > > > I have several ODroid C2's, and the first thing to note about them > > is that there is no RTC at all. Also, the oscillator is just a > > garden-variety non-temperature-compensated quartz crystal, and not > > necessarily a very precise one, either (precise quartz oscillators > > can cost more than the whole ODroid board costs). The XU4 and other > > ODroid devices make nice single-board ARM computers, but have pretty > > ratty oscillator precision. > > > > You really have to have at least a temperature compensated quartz > > crystal oscillator (TCXO) to even begin to think about an NTP > > server, for anything but the most rudimentary of timing. Ovenized > > quartz oscillators (OCXO) and rubidium standards are the next step > > up, and most reasonably good GPS-disciplined clocks have at least an > > ovenized quartz oscillator module (the Agilent Z3816 and kin are of > > this type). > > Does anyone know of any COTS NTP servers that are based on non-ancient > Linux kernel versions? In 2012 we bought new GPS/CDMA NTP servers > with OCXO that are based on Linux 2.4, but they are fiddly as you can > imagine with such an ancient software stack. > > What would people recommend for NTP server hardware/software? > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: NIST NTP servers
With the caveat that if some of the servers are inside your own private network then learning who the servers are might be less useful. But this could be an issue for targets who use servers that are exclusively on the public internet. On Wed, May 11, 2016 at 3:15 PM, Sharon Goldberg <gol...@cs.bu.edu> wrote: > Well, if you really want to learn about the NTP servers a target is using > you can always just sent them a regular NTP timing query (mode 3) and just > read off the IP address in the reference ID field of the response (mode 4). > > > Reference ID reveals the target that the client is sync'd to. > > If you do this over and over as the client changes the servers it sync's > to, you learn all the servers. > > Or if you are really keen you can use our "kiss-of-death" attack to learn > all the servers a client is willing to take time from. See sections V.B-V.C > of our paper. > > https://eprint.iacr.org/2015/1020.pdf > > Sharon > > > > On Wed, May 11, 2016 at 3:07 PM, Florian Weimer <f...@deneb.enyo.de> wrote: > >> * Chris Adams: >> >> > First, out of the box, if you use the public pool servers (default >> > config), you'll typically get 4 random (more or less) servers from the >> > pool. There are a bunch, so Joe Random Hacker isn't going to have a >> > high chance of guessing the servers your system is using. >> >> A determined attacker will just run servers in the official pool. >> >> > > > -- > Sharon Goldberg > Computer Science, Boston University > http://www.cs.bu.edu/~goldbe > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: NIST NTP servers
Well, if you really want to learn about the NTP servers a target is using you can always just sent them a regular NTP timing query (mode 3) and just read off the IP address in the reference ID field of the response (mode 4). Reference ID reveals the target that the client is sync'd to. If you do this over and over as the client changes the servers it sync's to, you learn all the servers. Or if you are really keen you can use our "kiss-of-death" attack to learn all the servers a client is willing to take time from. See sections V.B-V.C of our paper. https://eprint.iacr.org/2015/1020.pdf Sharon On Wed, May 11, 2016 at 3:07 PM, Florian Weimer <f...@deneb.enyo.de> wrote: > * Chris Adams: > > > First, out of the box, if you use the public pool servers (default > > config), you'll typically get 4 random (more or less) servers from the > > pool. There are a bunch, so Joe Random Hacker isn't going to have a > > high chance of guessing the servers your system is using. > > A determined attacker will just run servers in the official pool. > > -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: BGPMON Alert Questions
On Sat, Apr 5, 2014 at 7:11 AM, Mark Tinka mark.ti...@seacom.mu wrote: So do you know whether anyone has any idea about what the top 10 global carriers are doing re: RPKI? Thinking? Justifying? Testing? Ignoring? These looking glasses are helpful: http://www.labs.lacnic.net/rpkitools/looking_glass/ http://www-x.antd.nist.gov/rpki-monitor/ http://certification-stats.ripe.net/ http://rpki.surfnet.nl/index.html But naturally it's harder to see who has turned on origin validation. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: BGPMON Alert Questions
On Fri, Apr 4, 2014 at 1:15 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Friday, April 04, 2014 05:06:22 AM Sharon Goldberg wrote: We also looked at prefix filtering and found that it has better partial deployment characteristics. Our analysis assumed that ISPs only filter routes from their *stub* customers. (We defined a stub an AS that does not have its own customers.) Just curious; in your considerations, how would/did you treat cases where ISP's filter their downstreams, to include their downstream's downstreams? Right, we didn't include that in our analysis because we didn't have a good sense for how many ISPs actually do filter their downstream downstreams. So we chose to give a conservative estimate of the impact of prefix filtering in partial deployment: we assumed that no one filters their downstreams downstreams. I'm honestly not sure exactly what including this assumption would do to our results, except to say that it would make them better (ie. that more attacks would be stopped). Might be a good experiment for one of my summer interns. Actually, since this is NANOG, might as well ask: Do you all view filtering your downstream's downstreams as much more difficult than filtering only downstreams, or only stub ASes? Do you have a sense for how many networks filter only their direct downstreams but no further, versus those that also filter downstreams downstreams? Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Re: BGPMON Alert Questions
On Fri, Apr 4, 2014 at 11:17 AM, Sharon Goldberg gol...@cs.bu.edu wrote Actually, since this is NANOG, might as well ask: Do you all view filtering your downstream's downstreams as much more difficult than filtering only downstreams, or only stub ASes? Do you have a sense for how many networks filter only their direct downstreams but no further, versus those that also filter downstreams downstreams? I set up a quick anonymous survey (2 questions) to gather some info on this. If you have a minute, go here: https://docs.google.com/forms/d/1x6Bbe7OYvuWeOzO8xpxbIZzW3N14wI1SVVbQer4FSa4/viewform We will share our anonymized results on NANOG. Thanks, Sharon
Re: BGPMON Alert Questions
On Thu, Apr 3, 2014 at 8:50 PM, Randy Bush ra...@psg.com wrote: Good point, which makes me ask: So which 5 to 10 networks, implementing source validation, could result in the greatest coverage or protection for the largest part of the Internet to the best of my knowledge, no one has looked at this for origin validation. sharon goldberg and co-conspirators have done a lot of work in the area, see her pubs at https://www.cs.bu.edu/~goldbe/. but the concentration seems to be on bgpsec which deploys quite differently Right, we (and others) have not looked at the efficacy of a partial deployment of origin validation (using the RPKI) yet. But, we did look at partial deployments of BGPSEC. We found that a large number of networks (around 50% of ASes) need to deploy BGPSEC before its security benefits really kick in. The reasons for this include (1) routing policies during partial deployment might not prioritize the BGPSEC validity over its AS path or local pref, (2) you need every node on an AS path to deploy BGPSEC before it works. Full paper here: https://www.cs.bu.edu/~goldbe/papers/partialSec.pdf We also looked at prefix filtering and found that it has better partial deployment characteristics. Our analysis assumed that ISPs only filter routes from their *stub* customers. (We defined a stub an AS that does not have its own customers.) Then we looked at the fraction of attacks that would be eliminated, if the X largest ISPs correctly implemented prefix filtering. (Large was measured in terms of the number of customers ASes the ISP had.) See Figure 18 on pg 15 of this paper, and the text explaining it in the middle of the right column on pg 15: http://research.microsoft.com/pubs/120428/BGPAttack-full.pdf Finally, like Randy says, RPKI deploys quite different from BGPSEC. My intuition says that (1) once the RPKI is fully populated with ROAs for all originated prefixes, then (2) a partial deployment of origin validation at a few large ISPs should be fairly effective. But I would have to validate this with experiments before I can be sure, or say exactly how many ISPs, etc. Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
Soliciting your opinions on routing research: A routing policies survey
Hi NANOG, 27 ops have already responded to our routing policies survey; we're hoping to gather more responses before the week is over. We're collecting information about how you configure routing policies in your network to improve the models we use in our research on routing and security. We'll also share the aggregated results with the NANOG list. The survey is anonymous and should take under 5 minutes to complete. Feel free to answer all our questions, or just a few: http://www.cs.toronto.edu/~phillipa/measurement/opsurvey/survey.php We’d also be grateful if you could forward the survey to ops at other organizations who may not be reading NANOG. Thanks all of you that have responded so far! Phillipa Gill (U of Toronto), Michael Schapira (Princeton), Sharon Goldberg (Boston University)
Routing policies study [was: Preferring peers over customers]
Hi NANOG, Based on recent discussions (of our paper and other topics) on this list, it seems like research on interdomain routing could really benefit from a better understanding of current routing policies. But we researchers need your help here. So, we created a short survey: http://www.cs.toronto.edu/~phillipa/measurement/opsurvey/survey.php We'll keep the survey data anonymous, and use it to improve research on interdomain routing and security. We'll also post aggregated results to the NANOG list. We'd appreciate if you could take 5 minutes to complete our survey; feel free to answer all of our questions, or just a few. Thanks! Phillipa Gill, Sharon Goldberg Michael Schapira
Re: Do Not Complicate Routing Security with Voodoo Economics
Nick Feamster wrote: 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. We think a key point is getting lost here. Routing policies affect our result in the following crucial way -- they determine the size of ASes' tiebreak sets (section 6.6). A tiebreak set is a set of equally good routes that an source AS has to a destination AS; in our model, an AS should prefer to route along the _secure_ routes in its tiebreak set. Simply put, with a larger tiebreak set, there should be more competition over customer traffic, and thus more widespread S*BGP deployment. In our simulations we assumed that tiebreak sets were determined by Local-Pref (economic considerations) and AS-Path considerations. In practice, tiebreak sets could be larger (e.g., if ASes prefer shorter paths over customer paths) or smaller (e.g., if intradomain considerations, like hot potato routing, affect tiebreak sets) than those in our simulations. Like Nick said, this is a place where more data from the ops community would be helpful to help us figure out how big tiebreak sets really are. However, the key point we want to emphasize is that in the simulations we ran, the tiebreak sets are actually quite small: 1) The size of the average AS tiebreak set in our simulations is only 1.18; which mean that 80% of tiebreak sets have only one path, see also Figure 8. 2) Security does not play a role in the vast majority (96%) of routing decisions made in our simulations (Section 6.7). In other words, S*BGP deployment can be driven even by a fairly small amount of competition for customer traffic. 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. Our paper does not assume all destinations are equally valuable. 1) As mentioned in our response to Randy, we weight content providers more heavily (see Section 6.8.1; we ran experiments where the content providers collectively source 10%, 20%, 33% or 50% of Internet traffic). 2) From Section 6.8.1: We test the robustness of our results... by modeling traffic locality [the idea that ASes are likely to send more traffic to ASes that are closer to them]... Section 6.8.2 shows our results are insensitive to this assumption. Sincerely, Phillipa Gill, Michael Schapira, and Sharon Goldberg 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
Re: Do Not Complicate Routing Security with Voodoo Economics
Randy's specific criticisms with direct quotes from our paper: Randy: The paper also completely ignores the rise of the content providers as described so well in SIGCOMM 2010 by Labovitz et alia[2] It is not clear how to ‘fix’ the economic model, especially as[3] says you can not do so with rigor. Once one starts, e.g. the paper may lack Tier-N peering richness which is believed to be at the edges, we have bought into the game for which there is no clear end. Section 6.8.1: Published AS-level topologies are known to have poor visibility into peering links at the edge of the AS-level topology [31]. This is particularly problematic for CPs, because they peer with many other ASes to cut down costs of delivering content [14] .. Thus, for sensitivity analysis, we created an augmented AS graph with ... additional peering edges from the five Content Providers. For more details on this graph, see Appendix D AS graph Sensitivity analysis. Also, based on Labovitz's paper, we ran simulations where the content providers were assumed to source a vast majority (up to 50%) of total Internet traffic (as discussed in Section 3.1 and 6.8.1). Please see Section 6.8.2 to see how these assumptions affected our results. Randy: The paper's simulations really should be shown not to rely on the popular but highly problematic Gao-Rexford model of inter-provider relationships, that providers prefer customers over peers (in fact, a number of global Tier-1 providers have preferred peers for decades), and that relationships are valley free, which also has significant exceptions. Yet these invalid assumptions may underpin the simulation results. Section 8.3: In practice,... the local routing policies used by each AS, ... are arbitrary and not publicly known. Thus, we use a standard model of routing policies (Appendix A) based on business relationship and path length [16, 6]. Here we'll interject to say that while there are definitely examples that lie outside this model (e.g. ASes the prefer peer routes over provider routes), it currently remains the only general model we have, to date, of interdomain routing. As such, we note in Section 8.3: Routing policies are likely to impact our results by determining (a) AS path lengths (longer AS paths mean it is harder to secure routes), and (b) tiebreak set size (Section 6.6). For example, we speculate that considering shortest path routing policy would lead to overly optimistic results; shortest-path routing certainly leads to shorter AS paths, and possibly also to larger tiebreak sets. Thus, while we cannot hope to accurately model every aspect of interdomain routing, nor predict how S*BGP deployment will proceed in practice, we believe that ISP competition over customer traffic is a significant economic lever for driving global S*BGP deployment. Sincerely, Sharon Goldberg and Michael Schapira -- Sharon Goldberg Assistant Professor, Computer Science, Boston University http://www.cs.bu.edu/~goldbe On Sun, Sep 4, 2011 at 6:02 AM, Randy Bush ra...@psg.com wrote: [ http://archive.psg.com/110904.broadside.html ] Do Not Complicate Routing Security with Voodoo Economics a broadside A recent NANOG presentation and SIGCOMM paper by Gill, Schapira, and Goldberg[1] drew a lot of 'discussion' from the floor. But that discussion missed significant problems with this work. I raise this because of fear that uncritical acceptance of this work will be used as the basis for others' work, or worse, misguided public policy. o The ISP economic and incentive model is overly naive to the point of being misleading, o The security threat model is unrealistic and misguided, and o The simulations are questionable. Basic ISP economics are quite different from those described by the authors. Above the tail links to paying customers, the expenses of inter-provider traffic are often higher than the income, thanks to the telcos' race to the bottom. In this counter-intuitive world, transit can often be cheaper than peering. I.e. history shows that in the rare cases where providers have been inclined to such games, they usually shed traffic not stole it, the opposite of what the paper presumes. The paper also completely ignores the rise of the content providers as described so well in SIGCOMM 2010 by Labovitz et alia[2] It is not clear how to ‘fix’ the economic model, especially as[3] says you can not do so with rigor. Once one starts, e.g. the paper may lack Tier-N peering richness which is believed to be at the edges, we have bought into the game for which there is no clear end. But this is irrelevant, what will motivate deployment of BGP security is not provider traffic-shifting. BGP security is, as its name indicates, about security, preventing data stealing (think banking transactions[4]), keeping miscreants from originating address space of others (think YouTube incident) or as attack/spam sources, etc. The largest
