RE: Silicon-germanium routers?
I also suspsect that the community is not ready to transition to liquid-cooled systems. I rather assumed 'at room temperature' implied a standard heat sink and fan. Perhaps there's not enough information in that article to draw a conclusion from. There are a few bits that folks should understand: first, SiGe has been around for awhile. It's not new. It's used when higher frequencies are necessary, such as when building a 40Ghz modulator for an OC-768c interface. SiGe is more expensive, less thermally efficient, and less dense than 'standard' CMOS. So it's already headed the wrong way for most of our applications. Second, you should know that there are lots of folks who really are experimenting with a single transistor. This may sound ludicrous, but the thought here is that process improvements will eventually scale. Thus, the conclusion that I'm leaping to is that this room temperature transistor at 350GHz really is at room temp, but may require something like a muffin fan all by itself. Obviously to scale that to a few hundred million transistors in a router, you then need a few hundred million little fans. ;-) The breakthrough that we're looking for is a high speed, high density, low power transistor that can be commercially scaled with good yield. Not there quite yet. Tony
Re: Silicon-germanium routers?
On Jun 20, 2006, at 11:11 PM, Tony Li wrote: The breakthrough that we're looking for is a high speed, high density, low power transistor that can be commercially scaled with good yield. Not there quite yet. In comparison to early-80s ECL, how do you think the scaling curve might match? I haven't found much material yet that shows any realistic projections for speed and yield ramp up for the new stuff. --lyndon
Re: key change for TCP-MD5
On Tue, Jun 20, 2006 at 05:18:20PM -0700, Randy Bush wrote: The added cost for CPU-bound systems is that they have to try (potentially) multiple keys before getting the **right** key but in real life this can be easily mitigated by having a rating system on the key based on the frequency of success. This mitigates the effect of authenticating valid packets. However, this does not appear to help at all in terms of minimizing the DOS effect of an intentional DoS attack that uses authenticated packets (with the processing time required to check the keys the intended damage of the attack). gstm this doesn't help if the vendor can't implement it correctly and does the md5 calc before checking the ttl :( - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: key change for TCP-MD5
The added cost for CPU-bound systems is that they have to try (potentially) multiple keys before getting the **right** key but in real life this can be easily mitigated by having a rating system on the key based on the frequency of success. This mitigates the effect of authenticating valid packets. However, this does not appear to help at all in terms of minimizing the DOS effect of an intentional DoS attack that uses authenticated packets (with the processing time required to check the keys the intended damage of the attack). gstm this doesn't help if the vendor can't implement it correctly and does the md5 calc before checking the ttl :( hard to imagine anything that will help such a vendor randy
RE: key change for TCP-MD5
At 04:23 PM 6/20/2006 -0700, Bora Akyol wrote: ...The DOS is a concern whether you have a valid key or not, correct? Yes, People who do NOT have a valid key can certainly launch DOS attacks. I can DOS the router with fake packets that it needs to verify as long as I want. Yes, but the attack needs to get past whatever packet filters (ACLs) are between them and the CPU that they are trying to overwhelm. This might include packet filters on ingress to whatever network the attacker is in, packet filters on ingress to the network of the victim, or on ingress to the router under attack. All the multiple keys do is to decrease the cost of the DOS. Yes ...For example, if we allow 4 keys at a time and the router dies at a 100 Mbps attack traffic, now it will die at 25 Mbps. While this may look like a big deal, I think the dark side has enough firepower that essentially 25 equals 100. There are of course two multiplicative effects: The effect of using authentication at all, and the effect of having multiple keys active at once. However, yes, the effect of having n keys active at once is no worse than n times the effect of using authentication. If DOS is such a large concern, IPSEC to an extent can be used to mitigate against it. And IKEv1/v2 with IPSEC is not the horribly inefficient mechanism it is made out to be. In practice, it is quite easy to use. Well, this one comment is the one that I don't understand. I don't see how IPSEC mitigates against DOS attacks. In fact, it seems to make things worse, since it hides the TCP header. If a packet is authenticated at the TCP level, then the attack packet needs to get past (hopefully line rate) packet filters on the IP header, and some fields in the TCP header before it can contribute to the DOS attack (but it can still contribute to DoS even if the authentication fails). If the TCP sequence number is out of range, then a smart implementation may indeed discard the packet before checking the authentication, but it still likely has gotten past the packet filters and gotten to the CPU. If a packet is authenticated using IPSEC (between IP and TCP), then it only needs to get past the IP packet filters before it can contribute to the DOS, and doesn't need to get past whatever checks occur at the TCP level (including not having to get past the sequence number check prior to having the authentication checked). Ross
Re: key change for TCP-MD5
At 07:29 PM 6/20/2006 -0400, Richard A Steenbergen wrote: On Tue, Jun 20, 2006 at 05:06:27PM -0400, Ross Callon wrote: ...I'd still like someone to explain why we're wasting man hours, CPU time, filling up our router logs, and potentially making DoS easier, for an attack that doesn't exist I think that it does make sense to be clear what attack or set of attacks we are trying to protect against. One type of attack is the TCP reset attack. I personally don't have a strong opinion regarding whether it is worth protecting against only this attack. Another potential attack is an attempt to insert information into a BGP session, such as to introduce bogus routes, or to even become a man in the middle of a BGP session. One issue that worries me about this is that if this allows routing to be compromised, then I can figure out how to make money off of this (and if I can think of it, someone even nastier will probably also think of this). Of course this would be much more difficult to pull off, and might require viewing packets between routers to pull off, but if pulled off and not quickly detected could be unfortunate. Ross
RE: key change for TCP-MD5
All the multiple keys do is to decrease the cost of the DOS. Yes let's try to remember that, in reality, this is all about allowing two bgp peers to move to a new key without having the operators on the phone to keep the bgp session from resetting. i.e., o it will be uncommon that there is more than one key active at any one time o it is not expected that there are more than two, current and new (soon to be current and old:-) active at any one time smb is proposing a simple, compatible, unilaterally implementable, and unilaterally deployable hack to solve a real ops problem. the RSs aside, a lot of very big and small networks use tcp/md5 on their bgp sessions, and key roll is a major pita and therefore a serious barrier to good key hygiene. randy
Re: key change for TCP-MD5
--- Ross Callon [EMAIL PROTECTED] wrote: Another potential attack is an attempt to insert information into a BGP session, such as to introduce bogus routes, or to even become a man in the middle of a BGP session. One issue that worries me about this is that if this allows routing to be compromised, then I can figure out how to make money off of this (and if I can think of it, someone even nastier will probably also think of this). Of course this would be much more difficult to pull off, and might require viewing packets between routers to pull off, but if pulled off and not quickly detected could be unfortunate. But it's safe to say that it would be a lot easier to crack a router itself than to unobtrusively insert useful false information, or if the ISP's routers are sufficiently hardened, it would be easier to crack a customer (or peer)'s router, and use that for the injection. The same mechanisa which can detect bogus prefixes from a peer/customer can detect them from a hijacked session. The cost/benefit ratio is better for securing the routers themselves. -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
insane over-regulation - what not to do
just so one can see how deep in a hole things can go if no grownups are present, look at what ghana is about to do to kill the goose that laid the golden egg http://rip.psg.com/~randy/ghana-insanity.pdf randy
RE: insane over-regulation - what not to do
Could you be more specific? Are you talking about Part VIII DOMAIN NAME REGISTAR or something else? rsw. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Bush Sent: Wednesday, June 21, 2006 12:59 PM To: [EMAIL PROTECTED] Subject: insane over-regulation - what not to do just so one can see how deep in a hole things can go if no grownups are present, look at what ghana is about to do to kill the goose that laid the golden egg http://rip.psg.com/~randy/ghana-insanity.pdf randy
Re: Tor and network security/administration
On 6/20/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote: You don't do your financial transactions over HTTPS? If you do, by the very design of SSL, the tor exit node cannot add any HTTP header. That would be a man-in-the-middle attack on SSL. Which, for an anonymizing network, could be a deliberate situation. The user then loses end-to-end encryption with the final server he want to connect to. Depends on your definition of end-to-end -- if one end is an agent on the user's computer, it still fits. But I think you misunderstand the reason for a filtering proxy in the context of anonymizing networks; read on: That is unacceptable for a whole range of uses. If a _user_ wants to control browser headers, he can instruct the _browser_ in what headers to send or not. The reason filtering proxies exist (and are popular with anonymizing networks) is because most browsers don't provide a deep level of configurability for this sort of thing. Let's suppose the tor exit node does this https-man-in-the-middle dance. It is not desirable for all connections, so you need some way for the user to say per connection what whether it should happen or not. SOCKS doesn't have such a thing in its protocol, so... With SOCKS, automated filter control based on IP address (and hostname, if using SOCKS4a or SOCKS5 with DOMAINNAME address type) is trivial. So suddenly this daemon needs an UI on every single user on the desktop of the user. Here's where your misunderstanding is evident. The filtering proxy is not at the Tor exit node; it's at the *entry*. Marrying the UI and the user using the proxy is precisely the point -- the filter is controlled by the person using it. Thus the UI is provided to the user who both installed, and is using, the filtering proxy. This is typically the way in which e.g. Privoxy+Tor is used, as Privoxy has no facility for per-user filter settings. And how do you handle client certificates in there? Install the client certs into the proxy agent. And how do you handle the verification of the server certificate? How do you know which CA's the client trusts? Use the proxy agent's UI to pop up the same sort of dialog-box validation that the browser would traditionally provide. There happen to be ready-made code libraries for just this purpose. And even if you have solved all this for SSL, then there is the _next_ protocol that you have to man in the middle fiddle with. This way lies madness. Filtering proxies target a somewhat narrow scope, but broad use, subset of possible protocols. HTTP + HTTPS cover a pretty huge chunk of traffic and user involvement. Certainly some other common protocols could be filtered for anonymizing purposes in their own ways. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: insane over-regulation - what not to do
Could you be more specific? Are you talking about Part VIII DOMAIN NAME REGISTAR or something else? rsw. I like Part XIII, Subsecton 115. Thing. myself. -Jerry
Re: insane over-regulation - what not to do
On Wed, 21 Jun 2006 12:21:34 CDT, Jerry Pasker said: I like Part XIII, Subsecton 115. Thing. myself. Actually, that serves a very important purpose - it codifies the concept that a string of ones and zeros can represent something with actual value. If it wasn't there, a defendant could argue that they didn't steal/forge a bank account withdrawal authorization, they just copied/created a stream of bits. pgp469JBcfKfx.pgp Description: PGP signature
RE: insane over-regulation - what not to do
Could you be more specific? Are you talking about Part VIII DOMAIN NAME REGISTAR or something else? the whole thing as a piece. it looks to be a, likely well-meaning, attempt by a gang of bureaucrats and a fancy consultant to put the universe in a glass jar and preserve it. from end user, to net operations, to infrastructure, to administration, to law. [ i do not do the GH domain. folk in ghana do, but i let them run it on one of my servers. ] randy rsw. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Bush Sent: Wednesday, June 21, 2006 12:59 PM To: [EMAIL PROTECTED] Subject: insane over-regulation - what not to do just so one can see how deep in a hole things can go if no grownups are present, look at what ghana is about to do to kill the goose that laid the golden egg http://rip.psg.com/~randy/ghana-insanity.pdf randy
RE: insane over-regulation - what not to do
On Wed, 21 Jun 2006, Randy Whitney wrote: Could you be more specific? Are you talking about Part VIII DOMAIN NAME REGISTAR or something else? Not presuming to answer for Randy, just for myself: This follows one of the typical failure-modes of technical legislation, which is that it contains quite a few good ideas (cryptographic signatures should be deemed to fulfill the role of signatures, nonrepudiatable electronic delivery should be deemed to constitute delivery, etc.) which are re-worded in less-specific more accessible language by lawyers, chopped into very small bits, mixed and blended until uniformly unrecognizable, and allowed to ferment until twelve times larger. These things typically create a bit of a baby-with-the-bathwater conundrum for people who think they know what _should_ be done, since many of the things that _should_ be done are in fact buried in the legalese, and starting over from scratch with the same seeds would, like as not, yield a very similar bloated bloated end-product, with another year or two wasted in the mean-time. Which all comes down to the old maxim: you can't legislate stupidity out of existence. Or, perhaps, legislation, by its very existence, brings some stupidity into existence. Less is more. -Bill
Re: Tor and network security/administration
On Wed, Jun 21, 2006 at 01:14:52PM -0400, Todd Vierling wrote: On 6/20/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote: You don't do your financial transactions over HTTPS? If you do, by the very design of SSL, the tor exit node cannot add any HTTP header. That would be a man-in-the-middle attack on SSL. Which, for an anonymizing network, could be a deliberate situation. The user then loses end-to-end encryption with the final server he want to connect to. Depends on your definition of end-to-end -- if one end is an agent on the user's computer, it still fits. But I think you misunderstand the reason for a filtering proxy in the context of anonymizing networks; read on: So suddenly this daemon needs an UI on every single user on the desktop of the user. Here's where your misunderstanding is evident. The filtering proxy is not at the Tor exit node; it's at the *entry*. If the proxy is not at the Tor exit node, how can the tor network enforce the addition of the this connection went through tor HTTP header that Kevin Day was asking for? Fundamentally, if you rely on a program sitting on the user's computer adding that header, then malevolent users can not add this header, so Kevin Day's purpose is not served. And that is what is being discussed here. Let's suppose the tor exit node does this https-man-in-the-middle dance. It is not desirable for all connections, so you need some way for the user to say per connection what whether it should happen or not. SOCKS doesn't have such a thing in its protocol, so... With SOCKS, automated filter control based on IP address (and hostname, if using SOCKS4a or SOCKS5 with DOMAINNAME address type) is trivial. What I was trying to say was: The SOCKS protocol has no mechanism for the SOCKS proxy to tell the SOCKS client before I establish that connection, please ask the user that question and report the answer back to me. -- Lionel
Comcast.net, Usa.net, Verizon
Are there anyone on the list from these organizations that could possibly put me in contact with the postmasters please? Thank you
Re: Tor and network security/administration
On Jun 21, 2006, at 12:43 PM, Lionel Elie Mamane wrote: If the proxy is not at the Tor exit node, how can the tor network enforce the addition of the this connection went through tor HTTP header that Kevin Day was asking for? Fundamentally, if you rely on a program sitting on the user's computer adding that header, then malevolent users can not add this header, so Kevin Day's purpose is not served. And that is what is being discussed here. Just to chime in before this gets any further off what I meant: I know any intermediary nodes can't inject headers into HTTPS connections, that kinda defeats the purpose of SSL. :) When doing any financial transaction, before any user enters anything sensitive, we bounce them to an HTTP page first, then look for common proxy headers on that request. If none are found, they're given a cookie that allows them to continue on that IP only for HTTPS transactions for the next 15 minutes. Failing that, having an exit node look at HTTP headers back from the server that contained a X-No-Anonymous header to say that the host at that IP shouldn't allow Tor to use it would work. *Anything* would be better for Tor users if we could keep Tor abuse off our financial services without having to just ban all Tor IPs at the border. On a credit card transaction page, you have no anonymity anyway, since you're having to give us your credit card number, home address, etc. Yet, until we banned as many known Tor IPs as we could find from our network, Tor IPs accounted for a pretty high percentage of our credit card fraud, and nearly zero non-fraudulent use. Tor IPs had some significant(legitimate) use on some of our other sites, but that's gone because they're all null routed at the border now. Tor may have some legit uses, but when it's costing us $BIGNUM in credit card fraud, I'm not going to spend too much time trying to only selectively ban it from our network.
Re: insane over-regulation - what not to do
On Wed, Jun 21, 2006 at 10:36:04AM -0700, Randy Bush wrote: the whole thing as a piece. it looks to be a, likely well-meaning, attempt by a gang of bureaucrats and a fancy consultant to put the universe in a glass jar and preserve it. from end user, to net operations, to infrastructure, to administration, to law. There is one thing in here which has great amusement appeal to me: g. ensure compliance with accepted International technical standards in the provision and development of electronic communications and transactions; The protocol police! It sounds like they're going to create an Industry Forum (GHANOG?), which may produce a voluntary industry code. About like our housing code in the US. That's going to be fun to watch. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpeSQViOyltm.pgp Description: PGP signature
Re: insane over-regulation - what not to do
That's going to be fun to watch. from the outside, not from the inside randy
Re: Tor and network security/administration
On 6/21/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote: Here's where your misunderstanding is evident. The filtering proxy is not at the Tor exit node; it's at the *entry*. If the proxy is not at the Tor exit node, how can the tor network enforce the addition of the this connection went through tor HTTP header that Kevin Day was asking for? And Tor users will desire to do this ... why? I have been referring to the proxying behavior *currently in use* on Tor and likely to be developed further in the near future. It is highly *unlikely* that Tor will add such a header by default, so there's little point in thinking that such a so-called solution might actually come to light. Note that nowhere have I implied that Tor HTTP requests would look like anything but regular HTTP requests, and in fact, that's exactly the point of Tor's design. I am NOT using this thread to comment on the appropriateness of that behavior (I have mixed personal opinions on that), but rather, to point out what its *users* want, which is what is likely to be implemented. Hence my earlier comment about addressing social vulnerabilities via solely technological methods. if you rely on a program sitting on the user's computer adding that header, then malevolent users can not add this header, And non-malevolent users who simply wish to avoid marketeers' statistical data tracking. There's more than one use for the technology, y'know. so Kevin Day's purpose is not served. If the point of the technology is to add a degree of anonymity, you can be pretty sure that a marker expressly designed to state the message Hi, I'm anonymous! will never be a standard feature of said technology. That's a pretty obvious non-starter. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Tor and network security/administration
On 6/21/06, Kevin Day [EMAIL PROTECTED] wrote: Failing that, having an exit node look at HTTP headers back from the server that contained a X-No-Anonymous header to say that the host at that IP shouldn't allow Tor to use it would work. What's to stop one or more exit node operators from hacking such a check right back out of the code? This is a better idea, but still has a bit of defeats-the-whole-point to it, as it would depend on people obeying that header voluntarily. Social vs. technological divide, again. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Tor and network security/administration
On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote: If the point of the technology is to add a degree of anonymity, you can be pretty sure that a marker expressly designed to state the message Hi, I'm anonymous! will never be a standard feature of said technology. That's a pretty obvious non-starter. Which begs the original question of this thread which I started: with that said, how exactly does one filter this technology? You can't doesn't make for a very practical solution, by the way. The same was said about BitTorrent (non-encrypted) when it came out, and the same is being said about encrypted BT (which has caused some ISPs to induce rate-limiting). I'm also left wondering something else, based on the Legalities Tor page. The justification seems to be that because no one's ever been sued for using Tor to, say, perform illegitimate transactions (Kevin's examples) or hack a server somewhere (via SSH or some other open service), that somehow that speaks for itself. I don't know about the rest of the folks on NANOG, but telling a court I run the Tor service by choice, but the packets that come out of my box aren't my responsibility, paraphrased, isn't going to save you from prison time (at least here in the US). Your box, your network port, your responsibility: period. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Re: Tor and network security/administration
On Jun 21, 2006, at 2:53 PM, Jeremy Chadwick wrote: On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote: If the point of the technology is to add a degree of anonymity, you can be pretty sure that a marker expressly designed to state the message Hi, I'm anonymous! will never be a standard feature of said technology. That's a pretty obvious non-starter. Which begs the original question of this thread which I started: with that said, how exactly does one filter this technology? Why bother? If the traffic is abusive, why do you care it comes from Tor? If there's a pattern of abusive traffic from a few hundred IP addresses, block those addresses. If you're particularly prone to idiots from Tor (IRC, say) then preemptively blocking them might be nice, but I doubt the number of new Tor nodes increases at a fast enough rate for it to be terribly interesting. If you want to take legal action you know exactly who is responsible for the traffic, so whether it's coming from a Tor exit node or not isn't terribly interesting in that case either. If you still do want to then there are some very obvious ways to do so, combining a Tor client and a server you run. (And this is from the perspective of someone who does not believe there is any legitimate use for Tor at all.) Cheers, Steve
Re: Tor and network security/administration
On Jun 21, 2006, at 4:08 PM, Todd Vierling wrote: On 6/21/06, Kevin Day [EMAIL PROTECTED] wrote: Failing that, having an exit node look at HTTP headers back from the server that contained a X-No-Anonymous header to say that the host at that IP shouldn't allow Tor to use it would work. What's to stop one or more exit node operators from hacking such a check right back out of the code? Nothing, but it's the same nothing that stops me from just blocking all Tor exit nodes at the border. If they showed a little bit of responsibility and allowed other people to make the decision if they wanted to deal with anonymous users or not, I'd be more than willing not to ban the whole lot of them. Areas where there already is no expectation of anonymity don't allow you to hide your identify in the real world, so I'm not sure why there is the notion that it's a right on the internet. Try applying for a credit card anonymously, or cashing a check in a bank wearing a ski mask and refusing to show any ID. I realize fighting open proxies(even ones like this that aren't the result of being trojaned/backdoored) is a losing battle, but the sheer ease in ANYONE being able to click Give me a new identity with Tor has really invited the masses to start playing with credit card fraud at a level I hadn't seen before. I'm willing to bet others are experiencing the same thing, but just don't realize they are because they're unfamiliar with Tor and don't know where to look. On top of all of that, I fully understand that the authors of Tor would have no desire to add such a feature. Their users are the end users, and placating pissy network operators gives them no benefit. All I can say is that if we had a better way of detecting Tor nodes automatically, and making policy decisions based around that fact, we'd be less likely to flat out ban them all. On Jun 21, 2006, at 4:53 PM, Jeremy Chadwick wrote: I'm also left wondering something else, based on the Legalities Tor page. The justification seems to be that because no one's ever been sued for using Tor to, say, perform illegitimate transactions (Kevin's examples) or hack a server somewhere (via SSH or some other open service), that somehow that speaks for itself. I don't know about the rest of the folks on NANOG, but telling a court I run the Tor service by choice, but the packets that come out of my box aren't my responsibility, paraphrased, isn't going to save you from prison time (at least here in the US). Your box, your network port, your responsibility: period. We had a sheriff in a small town in Alabama quite ready to test that theory at one point. A Tor exit node was used to purchase several hundred dollars of services on a 75 year old woman's credit card that had never used a computer in her life. It took a LOT of explaining, but after he and the county DA understood what Tor was about, they were completely willing to bring charges against the owner of the IP of the exit node. The credit card holder, however, asked that they drop the matter, so it never went anywhere. I would have been very curious to see how it turned out though. On Jun 21, 2006, at 5:18 PM, Steve Atkins wrote: Why bother? If the traffic is abusive, why do you care it comes from Tor? If there's a pattern of abusive traffic from a few hundred IP addresses, block those addresses. If you're particularly prone to idiots from Tor (IRC, say) then preemptively blocking them might be nice, but I doubt the number of new Tor nodes increases at a fast enough rate for it to be terribly interesting. Normally if we get a lot of fraud from one user, we force all transactions inside that /24 (or whatever the bgp announcement size is) to be manually approved. This is different because one cranky/pissed off/thieving user has control of hundreds of IPs scattered across the world. You can play whack-a-mole with them for hours, and they can keep coming back on a new IP. Each one can be a fraudulent credit card order, costing us hundreds of dollars each. We have preemptively blocked all the Tor exit nodes we can find, but they do change at a rate fast enough that a static list isn't sufficient. Many run off cable modems out of a DHCP pool that get a new address periodically.
Global Crossing/Ashburn - Anyone have RFO or ETA insight?
Folks - Since sometime early this morning, some traffic through Global Crossing in Ashburn has been experiencing packet loss and varying latency consistent with congestion. Global crossing's NOC confirms there is an multiple customer issue, but can't/won't/doesn't-know anything with respect to reason for outage or time to repair... Is anyone working on the other end of the problem who can share some insight? Thanks in advance; sorry to bother the list with operational matters... :-) /John
Re: Global Crossing/Ashburn - Anyone have RFO or ETA insight?
Since sometime early this morning, some traffic through Global Crossing in Ashburn has been experiencing packet loss and varying latency consistent with congestion. Global crossing's NOC confirms there is an multiple customer issue, but can't/won't/doesn't-know anything with respect to reason for outage or time to repair... Is anyone working on the other end of the problem who can share some insight? Thanks in advance; sorry to bother the list with operational matters... :-) presuming that they are working on it if they have symptoms, if you have actual technical symptoms, you may want to do a but more of a technical post. randy
Re: Internet 2010 - Predictions for 2010 from a Content Forum and NANOG 37 in San Jose
Wow - so many private messages surrounding this. I'll summarize and group the comments across the predictions below, but first answer some of the questions I received. One suggestion was to bury these in a timevault to be opened at NANOG in 2010. Another suggestion was to bury these where I want the crops to grow. Thanks for that suggestion. Of course, predictions are not certain as this person put it: Unlike market focus groups which pick the color of the product, the error rate of groups of humans predicting the future is multiplicative Several of you asked who provided the data. These were engineers, peering coordinators, some Director and VP level folks, network planners and architects from Content and ISP Companies that you probably all have heard about of and a handful of those you have not. There was no glue sniffing involved. Keep in mind too that to answer the initial question, the events had to be both *plausible *and* remarkable* to the group assembled around the table in 2010. I personally think many of these in the list fit the criteria, but a few of the usual suspects said that they believe almost none of these things are plausible (Stating this politely). Below are a couple data points from the field surrounding the predictions for 2010. Content Provider Predictions for 2010 -- Here is the question I put to a group of Content Providers at a content forum: We are sitting around this table in 2010 and we are commenting how remarkable the last few years have been, specifically that: 1. Video streaming volume has grown 100 fold 2. Last mile wireless replaced local loop These first two were echod by both the Content and ISP folks with a variation only regarding the degree. Personally I don't see the local loop going away in the next 4 years but a new wireless offering that is being taken up big time is possible. Video traffic for YouTube was said at the Peering BOF to grow 20%/month so there is a possibly compounding growth rate here, so maybe we would debate the degree of and length of the scaling growth. Clearly 100 fold increase would be remarkable. 3. Botnets (DDOS attacks) are still an issue I'm surprised noone protested this one - if botnets are still a problem for the much large capacity 2010 internet then we may have a much more significant problem to deal with. 4. Non-mechanical (i.e. Flash) Drives replaced internal hard drives on laptops One comment that this is not realisitic. 5. 10% of all cell phones are now video phones 6. We have cell phones that we actually like There appears to be debate surrounding this one - the person positing this believes all the cell phones on the market suck (everyone has some complaint about whatever phone and provider they have) and that there will be a PDA + service that overcomes these objections and become the new thing. 7. The U.S. is insignificant traffic wise relative to the rest of the world 8. Most popular question discussed around the table: 'How do we operate business in China?' 9. No online privacy. And the gov't watches everything anonymous note to me the future is now: http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2006/06/21/BUG9VJHB9C1.DTL and http://www.salon.com/news/feature/2006/06/21/att_nsa/ 10. 18-25 demographic is best reached w/ads on the Internet 11. Next Gen 3D on-line Social Networks are so successful 12. No physical network interfaces are needed For laptops, phones, desktops, upto the DSL modem that's certainly the case today. Beyond that we are into the wireless last mile stuff. 13. We will big brother ourselves (video cams 'who scraped my car?') 14. So many special purpose Internet apps – in car google maps, live traffic updates, etc. 15. So much of our personal information is on the net http://news.yahoo.com/s/ap/20060620/ap_on_bi_ge/police_phone_data 16. Video IM emerged as a dominant app 17. P2P will emerge for non-pirated videos – DRM in place and embraced Most comments back suggested that the studios don't move this fast releasing their crown jewels to unfamiliar and historically shameful technology. 18. Voice calls are free, bundled with other things Softbank in Japan does this now at least to other Softbank customers, and pennies per minute elsewhere. Come on, phone calls are almost free already! [some additional notable predictions from this group, but did not receive simple majority validation] IPTV replaces cable TV IPv6 is adopted Massive Internet Collapse – Metcalfe regurgitates his column Flexible screen deployment SPAM is no longer a problem in 2010 Windows embraces distributed computing Net is not Neutral Powerline Broadband emerges FTTH massive deployment Internet Service Providers Predictions for 2010 -- We didn't get to do this at the Peering BOF at NANOG, but I did some
RE: key change for TCP-MD5
Another potential attack is an attempt to insert information into a BGP session, such as to introduce bogus routes, or to even become a man in the middle of a BGP session. One issue that worries me about this is that if this allows routing to be compromised, then I can figure out how to make money off of this (and if I can think of it, someone even nastier will probably also think of this). Of course this would be much more difficult to pull off, and might require viewing packets between routers to pull off, but if pulled off and not quickly detected could be unfortunate. Ross This one is hard to pull off. I think the general conclusion a couple years ago in the study that Sean Convery and Matt Franz did was that it was less work to try to own the router or buy your own AS ;) Bora
Re: Global Crossing/Ashburn - Anyone have any SYMPTOMS?
john: on ops channel, gx senior eng says: o gx backbone crew knows of no multi-cust outage o gx noc knows of nomulti-cust outage so i very much doubt anyone on this list will have an eta for something no one seems to know about. maybe, rather than a public slam with no content, post some symptoms so someone can actually work on it. net geeks don't mind work, just need hard stuff on which to work. randy
RE: key change for TCP-MD5
This one is hard to pull off. I think the general conclusion a couple years ago in the study that Sean Convery and Matt Franz did was that it was less work to try to own the router or buy your own AS ;) this is the you don't have to run faster than the lion, you just have to run faster than your friend, theory. as those who survived to report are a biased sample, it is not well tested. black hats are opportunistic, but not lazy. they look for cracks with mamzing diligence. e.g the recent brilliant post on cracking the xbox http://www.xbox-linux.org/wiki/17_Mistakes_Microsoft_Made_in_the_Xbox_Security_System. when low-hanging fruit is unavailable, or when they see a really cool way to exploit the higher fruit, it would be prudent to have done something about it. who cares about openly recursive dns servers? there are easier ways to crack the host. oops! unfortunately, this is not just theory. few talk about the serious routing attacks that have been seen. randy
Re: Global Crossing/Ashburn - Anyone have any SYMPTOMS?
Randy - I actually intentionally didn't post the details or ticket number, as I was looking for other folks already involved (once their NOC said it was a multiple customer issue with the ar2.dca2 router). If you're also affected or engaged on the problem, let me know. Thanks! /John At 5:41 PM -0700 6/21/06, Randy Bush wrote: john: on ops channel, gx senior eng says: o gx backbone crew knows of no multi-cust outage o gx noc knows of nomulti-cust outage so i very much doubt anyone on this list will have an eta for something no one seems to know about. maybe, rather than a public slam with no content, post some symptoms so someone can actually work on it. net geeks don't mind work, just need hard stuff on which to work. randy
Re: key change for TCP-MD5
On Wed, Jun 21, 2006 at 05:55:21PM -0700, Randy Bush wrote: when low-hanging fruit is unavailable, or when they see a really cool way to exploit the higher fruit, it would be prudent to have done something about it. who cares about openly recursive dns servers? there are easier ways to crack the host. oops! There is a fine line between being dilligent about security, and wasting your time trying to solve problems that don't exist, which I think has been crossed in the discussion. Not to venture too far away from facts and into the realm of cute soundbites and quotable one-liners about lions and fruit, but let me propose what I think is a good one: If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. I have yet to hear a reasonable counter-argument to this. If there is one out there that had not yet been made then by all means now is the time to make it. Otherwise, you would really be better served by devoting your time and energy into solving real problems. If you're running low on real problems to solve, I would be happy to send you some of mine. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Tor and network security/administration
Jeremy Chadwick wrote: On Wed, Jun 21, 2006 at 05:02:47PM -0400, Todd Vierling wrote: If the point of the technology is to add a degree of anonymity, you can be pretty sure that a marker expressly designed to state the message Hi, I'm anonymous! will never be a standard feature of said technology. That's a pretty obvious non-starter. Which begs the original question of this thread which I started: with that said, how exactly does one filter this technology? ..and that is also the reason why SORBS and Tor have been a logger heads... This think that their answer addresses SORBS' position from their Abuse FAQ ( http://tor.eff.org/faq-abuse.html.en ): SORBS is putting some Tor server IPs on their email blacklist as well. They do this because they passively detect whether your server connects to certain IRC networks, and they conclude from this that your server is capable of spamming. We tried to work with them to teach them that not all software works this way, but we have given up. We recommend you avoid them, and teach your friends (if they use them) to avoid abusive blacklists too http://paulgraham.com/spamhausblacklist.html. Of course SORBS' position is actually this - if you are allowing Trojan traffic over the Tor network you will get listed (regardless of whether the Trojans can talk to port 25 or not) Considering they were told that, it shows the lack of concern, respect, intelligence or nettiqette for such issues. The new SORBS DB (coming soon) will include a Tor DNSbl (like the AHBL's) where administrators of services can choose to block this type of traffic. Our response to people whilst Tor is That's what you get for using Tor, if you must use Tor we recommend moving it to a server/IP that is not used for anything important and getting a good lawyer. You can't doesn't make for a very practical solution, by the way. The same was said about BitTorrent (non-encrypted) when it came out, and the same is being said about encrypted BT (which has caused some ISPs to induce rate-limiting). I'm also left wondering something else, based on the Legalities Tor page. The justification seems to be that because no one's ever been sued for using Tor to, say, perform illegitimate transactions (Kevin's examples) or hack a server somewhere (via SSH or some other open service), that somehow that speaks for itself. I actually know of someone who was caught trying to brute force an ISPs SSH server - he blamed it on Tor - that didn't stop legal action and getting his connection terminated. (Sorry I am not permitted to give details of who or which ISP - so don't ask) - I don't know whether he was the responsible party or not, but I do know he has had several accounts terminated for similar 'suspect' activity. He continues to run a Tor node. I don't know about the rest of the folks on NANOG, but telling a court I run the Tor service by choice, but the packets that come out of my box aren't my responsibility, paraphrased, isn't going to save you from prison time (at least here in the US). Your box, your network port, your responsibility: period. AFAIK nor here (Australia) nor in the UK - if the traffic is seen to be coming from your machine *you* are responsible unless *you* can show the traffic was generated by someone else. i.e. you cannot say 'sorry officer it was not me it was my machine' you have to be able to say (and prove), 'sorry officer it was not me it was someone else, I don't know who, but here is the information about the next step back to the source so that you can continue your investigation.' (same as speeding tickets - you can't just say I wasn't driving - you have to either say 'x was driving' or It wasn't me, I don't know who was driving but I lent the car to x you should ask them. ...and for what it's worth, I have no problems with anonymous networks for idealistic reasons, however they are always abused, they will continue to be abused, Tor is being abused, and I should be able to allow or deny traffic into my networks as I see fit All of my discussions with Tor people have indicated [they] do not think I should have the right to deny traffic based on IP address, and that I should find other methods of authenticating traffic into my networks. Regards, Mat
