Re: Vyatta as a BRAS

On Jul 13, 2010, at 10:58 PM, Joe Greco wrote: > It's interesting. One can get equally militant and say that hardware based > routers are irrelevant in many applications. When BCPs are followed, they don't tend to fall over the moment someone hits them with a few kpps of packets - which sho

Re: Vyatta as a BRAS

On Jul 13, 2010, at 3:00 PM, wrote: > I agree software-based deployments have their flaws but I do not agree that > it cannot be managed securely with comparable or exceeding uptime -vs- a drop > in appliance. I firmly believe it has it's place in 'today's internet'. When a single botted/mis

Re: Vyatta as a BRAS

On Jul 13, 2010, at 1:34 PM, Sharef Mustafa wrote: > do you recommend it? My comment would be that a software-based BRAS - 7200, Vyatta, et. al. - is no longer viable in today's Internet, and hasn't been for years, due to security/availability concerns. Same for peering/transit edge, custome

Re: A bit off topic: Video streaming/video on demand server

On Jun 22, 2010, at 9:57 PM, Eric J Esslinger wrote: > So I'm looking for some help, perhaps experience with products, I'm a big fan of QTSS for this type of application, myself: and use Wirecast for the broadcasting client:

Re: eBGP TTL matching requirement

On May 12, 2010, at 1:10 AM, Patrick W. Gilmore wrote: > No. Concur, but the original poster should also look at the GTSM, which doesn't do what he asked about but which does make use of TTL as a validation mechanism: ---

Re: Thailand Internet firewall?

On May 5, 2010, at 4:39 PM, Mikael Abrahamsson wrote: > I was also under the impression that it wasn't by IP but that they could > block specific youtube videos etc. They use a combination of IP blocking, DNS poisoning, and transparent HTTP proxy-based URL filtering.

Re: Thailand Internet firewall?

On May 4, 2010, at 11:03 PM, Drew Weaver wrote: > Is anyone aware whether or not Thailand has a centralized firewall on > Internet access? Thai SPs are required by law to block sites deemed objectionable by the government of Thailand; common reasons given include lese majeste and/or other mat

Re: legacy /8

On Apr 12, 2010, at 12:39 AM, wrote: > IPv6 isn't heavily used *currently*, so it may be perfectly acceptable to > deal with the mythological IPv6 DDoS The only IPv6-related DDoS attacks of which I'm aware to date is miscreants going after 6-to-4 gateways in order to disrupt one another's IP

Re: China prefix hijack

On Apr 10, 2010, at 12:17 AM, Paul Vixie wrote: > are we all freaking out especially much because this is coming from china > today, and we suppose there must be some kind of geopolitical intent because > china-vs-google's been in the news a lot today? There's been a fair amount of speculation

Re: Books for the NOC guys...

On Apr 2, 2010, at 7:09 PM, Robert E. Seastrom wrote: > So, what are you having your up-and-coming NOC staff read?

Re: OBESEUS - A new type of DDOS protector

On Mar 17, 2010, at 2:56 AM, Guillaume FORTAINE wrote: > What about Argus ? [1] Argus is OK, but I believe that it mainly relies upon packet capture - it does now support NetFlow v5, and v9 support as well as support for Juniper flow telemetry and others is supposed to be coming. I've persona

Re: OBESEUS - A new type of DDOS protector

On Mar 16, 2010, at 11:30 AM, Guillaume FORTAINE wrote: > What do you think about Obeseus ? Flow telemetry has demonstrated its extraordinary utility to network operators worldwide over the last decade, and continued advances such as Cisco's Flexible NetFlow and the IETF IPFIX/PSAMP effort sig

Re: OBESEUS - A new type of DDOS protector

On Mar 16, 2010, at 10:47 AM, Guillaume FORTAINE wrote: > Especially, where is Roland Dobbins ? At your service. ;> --- Roland Dobbins // Injustice is relatively easy to bear; what stings i

Re: Need some info about "Clean pipe"

On Mar 16, 2010, at 1:58 AM, Brandon Kim wrote: > Is this a new concept? I've never heard of this before. It's been around for the last 8 years or so - part of the reason folks may not've heard much about it is the inexplicable general underemphasis on the 'Availability' part of the 'Confident

Re: Need some info about "Clean pipe"

On Mar 16, 2010, at 1:06 AM, Michael Holstein wrote: > In short, instead of paying for a (n*)gbps circuit and buying your own DDOS > prevention gear, you buy $n worth of bandwidth that has somebody actively > managing the DDOS protection. And of course, if one's organization is an SP, one can

Re: about udp 80,8080,0

On Feb 9, 2010, at 6:57 PM, 최종훈 wrote: > Is there anyone who have experiences controlling udp port 8,8080,0 ? > rate-limiting or block! Not a good idea to use rate-limiting to deal with DDoS attacks - the programmatically-generated bad traffic ends up crowding out legitimate traffic. All ki

Re: Mitigating human error in the SP

On Feb 2, 2010, at 10:28 AM, Suresh Ramasubramanian wrote: > Automated config deployment / provisioning. And sanity checking before > deployment. A lab in which changes can be simulated and rehearsed ahead of time, new OS revisions tested, etc. A DCN. --

Re: DDoS mitigation recommendations

On Jan 29, 2010, at 10:04 AM, Jonathan Lassoff wrote: > Something utilizing sflow/netflow and flowspec to block or direct traffic > into a scrubbing box gets you much better bang for your buck past a certain > scale. This is absolutely key for packet-flooding types of attacks, and other attack

Re: Using /126 for IPv6 router links

On Jan 24, 2010, at 6:07 AM, James Hess wrote: > Then obviously, it's giving every molecule in every soda can an IP address > that is the waste that matters. There are several orders of magnitude between > the number of molecules in a soda can (~65000 times > as many) as the number of addition

Re: Using /126 for IPv6 router links

On Jan 24, 2010, at 4:43 AM, Mark Smith wrote: > That's a new bit of FUD. References? It isn't 'FUD'. redistribute connected. --- Roland Dobbins // Injustice is relatively easy to bear; wha

Re: Using /126 for IPv6 router links

On Jan 23, 2010, at 7:56 PM, Mikael Abrahamsson wrote: > http://www.gossamer-threads.com/lists/nsp/ipv6/20788 A couple of points for thought: 1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years

Re: 2009 Worldwide Infrastructure Security Report available for download.

On Jan 22, 2010, at 8:08 AM, Danny McPherson wrote: > Yep, I think this is simply an artifact of a larger respondent pool > size, with many smaller respondents being represented. Correct, as noted in the text, the change in survey demographics appears to be the cause of this shift. ---

2009 Worldwide Infrastructure Security Report available for download.

[Apologies for any duplication if you've seen this notification on other lists.] We've just posted the 2009 Worldwide Infrastructure Security Report for download at this URL: This year's WWISR is based upon the broadest set of survey data collected by Arb

Re: I don't need no stinking firewall!

On Jan 14, 2010, at 12:37 PM, Warren Kumari wrote: > I can now place a checkbox in the "Is there a firewall?" column of the > audit. mod_security is your friend. ;> --- Roland Dobbins //

Re: I don't need no stinking firewall!

On Jan 11, 2010, at 12:56 PM, George Bonser wrote: > One would probably have a load balancer of some sort in front of those > machines. That is the device that would be fielding any DoS. Yes, and as you've noted previously, it should be protected via stateless ACLs in hardware capable of han

Re: I don't need no stinking firewall!

On Jan 11, 2010, at 4:55 AM, James Hess wrote: > I don't agree with "You never need a proxy in front of a server, it's only > there to fail". Again, reverse proxy *caches* are extremely useful in front of Web farms. Pure proxying makes no sense. -

Re: D/DoS mitigation hardware/software needed.

On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote: > The only thing you've said that is being disputed is the the claim that a > firewall > under a DDoS type of attack will fail before a server under the same type > of attack. It's so obvious that well-crafted programmatically-generated attack

Re: I don't need no stinking firewall!

On Jan 10, 2010, at 3:48 PM, James Hess wrote: > Firewalls do not need to build a state entry for > partial TCP sessions, there are a few different things that can be > done, such as the firewall answering on behalf of the server (using > SYN cookies) and negotiating connection with the serve

Re: I don't need no stinking firewall!

On Jan 10, 2010, at 1:32 PM, Dobbins, Roland wrote: > One can spout all the buzzwords and catchphrases one wishes, but at the end > of the day, it's all dead wrong - and anyone naive enough to fall for it is > setting himself up for a world of hurt. mike , You deserve a better

Re: D/DoS mitigation hardware/software needed.

On Jan 10, 2010, at 1:27 PM, Roger Marquis wrote: > Reads like a sales pitch to me. My employer's products don't compete with firewalls, they *protect* them; if anything, it's in my pecuniary interest to *encourage* firewall deployments, so said firewalls will fall down and need protection, he

Re: I don't need no stinking firewall!

On Jan 10, 2010, at 1:22 PM, harbor235 wrote: > Again, a firewall has it's place just like any other device in the network, > defense in >>> depth is a prudent philosophy to reduce the chances of > compromise, it does not >>>eliminate it nor does any architecture you can > think of, period Wh

Re: D/DoS mitigation hardware/software needed.

On Jan 10, 2010, at 10:33 AM, Christopher Morrow wrote: > separate the portions of the pie... only let the attack break the minimal > portion of your deployment. Use the right tool in the right place. An excellent point. A Web front-end server should be that - merely the front-end. Situation

Re: D/DoS mitigation hardware/software needed.

On Jan 10, 2010, at 10:05 AM, Roger Marquis wrote: > Ok, I'll bite. What firewalls are you referring to? Hardware-based commercial firewalls from the major vendors, open-source/DIY, and anything in between. All stateful firewalls ever made, period (as discussed previously in the thread). >

Re: D/DoS mitigation hardware/software needed.

On Jan 10, 2010, at 9:03 AM, Roger Marquis wrote: > That hasn't been my experience but then I'm not selling anything that might > have a lower ROI than firewalls, in small to mid-sized installations. I loudly evinced this position when I worked for the world's largest firewall vendor, so that

Re: I don't need no stinking firewall!

On Jan 10, 2010, at 5:51 AM, harbor235 wrote: > Other security features in an Enterprise Class firewall; >-Inside source based NAT, reinforces secure traffic flow by allowing > outside to inside flows based on >configured translations and allowed security policies Terrible from an a

Re: D/DoS mitigation hardware/software needed.

On Jan 10, 2010, at 12:57 AM, Jeffrey Lyon wrote: > I would love to provide you with some new experiences. I get new experiences of this type and plenty of new ideas every day, thanks. ;> --- Roland Dobbins //

Re: D/DoS mitigation hardware/software needed.

On Jan 9, 2010, at 9:57 PM, Stefan Fouant wrote: > Firewalls do have their place in DDoS mitigation scenarios, but if used as > the "ultimate" solution you're asking for trouble. In my experience, their role is to fall over and die, without exception. I can't imagine what possible use a statef

Re: I don't need no stinking firewall!

On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote: > see my post in the subject, a reasonably complete performance report for the > device is a useful place to start. The problem is that one can't trust the stated vendor performance figures, which is why actual testing is required. I've seen in

Re: I don't need no stinking firewall!

On Jan 8, 2010, at 9:02 PM, bill from home wrote: > And maybe there is no way to tell, but I feel I need to ask the question. Situationally-dependent; the only way to really tell, not just theorize, is to test the firewall to destruction during a maintenance window (or one like it, in the lab)

Re: I don't need no stinking firewall!

On Jan 8, 2010, at 8:22 PM, bill from home wrote: > Or as I suspect we are talking about a larger scale? Even an attacker with relatively moderate resources can succeed simply by creating enough well-formed, programatically-generated traffic to 'crowd out' legitimate traffic.

Re: I don't need no stinking firewall!

On Jan 8, 2010, at 3:21 PM, Arie Vayner wrote: > Further on, if you want to really protect against a real DDoS you would most > likely would have to look at a really distributed solution, where the > different geographical load balancing solutions come into play. GSLB or whatever we want to ca

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

On Jan 7, 2010, at 10:19 AM, Dobbins, Roland wrote: > Which goes to show that they just really don't get it when it comes to > security. Maybe they should look here at all the entries for 'default > credentials': Actually, sho

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

On Jan 7, 2010, at 10:12 AM, Joe Hamelin wrote: > they got quite a chuckle out of this thread. Which goes to show that they just really don't get it when it comes to security. Maybe they should look here at all the entries for 'default credentials':

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 8:42 PM, Jared Mauch wrote: > The reality is they just have not been attacked yet, and hence have no > experience in what to do about the problem... And they've been bombarded with misinformation for years by 'security' vendors, wildly unrealistic certification training cour

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 8:25 PM, juttazalud wrote: > How do you define "firewall"? This threat was about stateful firewalls in particular. --- Roland Dobbins // Injustice is relatively easy to be

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 5:38 PM, William Waites wrote: > A properly configured firewall will prevent latter. So will stateless ACLs, running in hardware capable of handling mpps. ;> --- Roland Dobbins //

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

On Jan 6, 2010, at 4:24 PM, George Bonser wrote: > having physical access pretty much trumps any other security measure. The fact that there's a factory default means that lots of folks won't change it when they configure the unit with an IP address; they follow this with failing to implement

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

On Jan 6, 2010, at 4:18 PM, Matthew Palmer wrote: > The closest I can come to a solution is to set a random password and flash it > using a front-panel LED using morse. heh No password at all, operator prompted at the console during startup unless/until he sets one. No IP address, et. al.

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

On Jan 6, 2010, at 3:44 PM, Nathan Eisenberg wrote: > I must not have been very clear. I'm resetting these switches to factory > defaults using the hardware reset button, and attempting to log in using > whatever the factory default passwords are. Right - what I'm saying is the fact that the

Re: Default Passwords for World Wide Packets/Lightning Edge Equipment

On Jan 6, 2010, at 3:17 PM, Nathan Eisenberg wrote: > Does anyone know the default passwords for World Wide Packets 427 and 311v > switches? One should think the fact that there are default passwords at all should be a cause for alarm, in and of itself. ---

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 3:03 PM, William Pitcock wrote: > So, in fact, all incoming packets should > be considered unsolicited until proven otherwise. Concur - it works this way, as well. At one extreme, completely pathological, at the other extreme, perfectly normal - just faux. ;> > It should

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 2:47 PM, James Hess wrote: > "Overflowing the state table" then becomes only a possible > outcome that has some acceptable level of probability, assuming > that your other protections have already failed... Wrong. The attacker just programmatically generates semanti

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 11:52 AM, Jonathan Lassoff wrote: > However, the "well managed" part seems to be a sticking point for most > organizations I've seen. No doubt, shops that use this effectively have some > sort of homebrew or commercial firewall management platform that let's you > place poli

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 11:43 AM, George Bonser wrote: > Yes, you have to take some of the things that were done in one spot and do > them in different locations now, but the results are an amazing increase > in service capacity per dollar spent on infrastructure. I strongly agree with the majority

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 4:24 AM, Robert Brockway wrote: > Hi Roland. I disagree strongly with this position. You can disagree all you want, but it's still borne out by real-world operational experience. ;> > The problem is that your premise is wrong. Just what about my premise is wrong? Nothing

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 4:07 AM, Mark Foster wrote: > I'm interested by this assertion; surely Stateful Inspection is meant to > facilitate the blocking of out-of-sequence packets, ones which aren't part > of valid + recognised existing sessions - whilst of course allowing valid > SYN session-start

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 3:58 AM, Brielle Bruns wrote: > It's all how you configure and tweak the firewall. Recommending people > run servers without a firewall is bad advice - do you really want your > Win2k3 server exposed, SMB, RPC, and all to the world? Nope - I use stateless ACLs in hardware,

Re: I don't need no stinking firewall!

On Jan 6, 2010, at 3:16 AM, Brian Johnson wrote: > Given this information, and not prejudging any responses, exactly what is a > firewall for and when is statefull inspection useful? In the most basic terms, a stateful firewall performs bidirectional classification of communications between no

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 9:44 PM, Rob Shakir wrote: > If you're an SP who has some existing NetFlow solution, and don't really > justify a spend for traffic intelligence within your network (or have > something home-grown), is there an alternative scrubber that one might be > able to use in a more s

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 9:59 PM, Jeffrey Lyon wrote: > My somewhat educated opinion on the matter is that appliance developers want > to sit on the edge and see all your traffic merely to protect their own > interests and market share. This isn't generally a smart approach; the value of providing m

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 5:04 PM, Darren Bolding wrote: > To reiterate- my entire point is that stateful firewalls are at least > sometimes useful in front of large websites. I understand completely; I simply disagree, stating my reasons for doing so in detail inline. It's my contention that under

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 3:58 PM, Darren Bolding wrote: > I believe their is strong evidence that the use of web application firewalls > to meet this DSS requirement is smaller than you might think. I would not be > surprised if it was significantly less than 50%- perhaps 20%. This directly contrad

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote: > PCI DSS does not require a "Web application firewall". Since no business is going to allow an external 'code review' (if it's even possible, given th

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote: > * Defense in depth. You've never had a host that received external traffic > ever accidentally have iptables or windows firewall turned off? Even when > debugging a production outage or on accident? Again, policy should be enforced via stat

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 11:57 AM, Dobbins, Roland wrote: > You and Barry and Tim Battles and Sean Donelan and Danny McPherson and Don > Smith and Steve Bellovin and Jared Mauch and John Kristoff and a lot of other > folks too numerous to mention . . . including Paul Vixie, Darrel Le

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 12:39 PM, Rick Ernst wrote: > I think you, Roland, and I are all agreeing on the same argument. GMTA. ;> --- Roland Dobbins // Injustice is relatively easy to bear; what

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 12:39 PM, Stefan Fouant wrote: > The trick is to try to automate as much around the process as possible - I've > worked in environments where just making little changes to incident handling > response methods reduced the time to mitigate an attack from hours to > minutes, al

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 12:39 PM, Adrian Chadd wrote: > I mean, I assume that there's checks and balances in place to limit > then number of routes being injected into the network so one doesn't > overload the tables, but what's the behaviour if/when this limit is > reached? Does mitigation cease bein

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 12:19 PM, Rick Ernst wrote: > I'd argue just the opposite. If your monitoring/mitigation system changes > dependent on the situation (normal vs under attack), you are adding > complexity to the system. > "What mode is the system in right now? Is this customer having conne

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 12:19 PM, Suresh Ramasubramanian wrote: > ... and manual wont scale in ddos Actually, it can and does. ;> I'm referring to the employment and selection of situationally-appropriate tools, mind. The tools themselves must of necessity perform their work in a largely automat

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote: > > A solution preferably that integrates with NetFlow and RTBH. An in-line > solution obviously requires an appliance, or at least special/additional > hardware. The key is to not be inline all the time, but only inline *when needed*. This re

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 11:41 AM, Christopher Morrow wrote: > (note I think Roland may have been party to some of the presenations I linked > in this... Yes, sir, and thanks for posting those links! You and Barry and Tim Battles and Sean Donelan and Danny McPherson and Don Smith and Steve Bellovin

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 11:05 AM, Jeffrey Lyon wrote: > I'm sure Arbor is really neat but I disagree that any DDoS appliance is a > standalone solution. I disagree with this proposition, too. S/RTBH and/or flow-spec are great DDoS mitigation tools which don't require any further investment beyond

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 10:18 AM, Suresh Ramasubramanian wrote: > 5 Ditch the stateful firewall and exclusively use a netflow device NetFlow analysis is very useful for network visibility, and detection/classification/traceback. There are both open-source and commercial NetFlow collection and anal

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 10:06 AM, Jeffrey Lyon wrote: > We have such a configuration in progress, it works great without any of the > issues you're proposing. Then you aren't testing it to destruction, heh. ;> If it's a stateful firewall, and state-tracking is turned on, it's quite possible to cr

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 10:14 AM, Dobbins, Roland wrote: > If it's a stateful firewall, and state-tracking is turned on, it's quite > possible to craft sufficient pathological traffic which conforms to the > firewall policies and yet which leads to state-table inspection. That

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 9:17 AM, Tim Eberhard wrote: > I would argue that firewalls place is in fact directly infront of servers > and load balancers to protect them. The very idea of placing a stateful firewall in front of a Web/DNS/email/etc. server, in which *every single incoming packet is uns

Re: D/DoS mitigation hardware/software needed.

On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: > Use a robust firewall such as a Netscreen in front of your mitigation > tool. Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in t

Re: ip-precedence for management traffic

On Dec 29, 2009, at 6:02 PM, Luca Tosolini wrote: > this leaves out only ipp 7 for management traffic, on the premise that > routing and management should not share the same queue and resources. Management-plane traffic should be sent/received via your DCN/OOB network, so that it's not com

Re: Revisiting the Aviation Safety vs. Networking discussion

On Dec 25, 2009, at 9:27 AM, George Bonser wrote: > Capt. Sullenberger did not need to fill out an incident > report, bring up a conference bridge, and give a detailed description of > what was happening with his plane, the status of all subsystems, and his > proposed plan of action (subject to c

Re: Revisiting the Aviation Safety vs. Networking discussion

On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote: > It would be interesting to see what others have to say about this answer. I think it's a pretty accurate summation of how these things work in a lot of big organizations, all over the world. There's a detrimental side to it, in that in the e

Re: IGMP and PIM protection

On Dec 23, 2009, at 9:19 PM, Glen Kent wrote: > Just integrity protection to ensure that my reports, etc. are not mangled > when i recv them. OR to make sure that i only receive reports/leaves from the > folks who are supposed to send them. I echo the previous respondent who noted that this is

Re: IGMP and PIM protection

On Dec 23, 2009, at 6:41 PM, Glen Kent wrote: > Any idea if folks use AH or ESP to protect IGMP/PIM packets What are you trying to 'protect' them against? --- Roland Dobbins // Injustice is

Re: Chinese bgp metering story

On Dec 19, 2009, at 6:42 PM, Randy Bush wrote: > this is particularly impressive given the complete absense of any facts > about the alleged proposal. I think the whole brouhaha is the merely result of someone saying 'BGP-speaking routers' vs. saying 'peering/transit edge routers', combined w

Re: Chinese bgp metering story

On Dec 19, 2009, at 11:09 AM, James Hess wrote: > Otherwise, new router hardware could more easily provide suitable counters > and IPFIX data (with suitable changes to ip flow export formats) to track the > tarrifs due to all "tarrif payee IDs", or whatever that would be. Existing hardware

Re: Chinese bgp metering story

On Dec 19, 2009, at 2:49 AM, Bill Woodcock wrote: > The decision on that will mostly be made in mid-March. By whom? The RIRs aren't just going to say, "OK, ITU folks, it's all yours," heh. --- Roland Dobbins //

Re: Chinese bgp metering story

On Dec 19, 2009, at 1:47 AM, Fred Baker wrote: > But what is all this about "is the ITU interested in changing BGP"? If the > word "metering" makes any sense in context, BGP doesn't meter anything. Neither the reporter nor the Chinese proponents nor the ITU seem to understand that making use o

Re: Chinese bgp metering story

On Dec 19, 2009, at 2:26 AM, Deepak Jain wrote: > "A proposal has been made, and is being studied, to use BGP routers to > collect traffic flow data, which could be used, by bilateral agreement, by > operators for billing purposes." Lots of 'BGP routers' are used to collect traffic flow data (

Re: Chinese bgp metering story

On Dec 19, 2009, at 2:24 AM, Jonny Martin wrote: > Mixing billing with > the reachability information signalled through BGP just doesn't seem > like a good idea. This is done all the time via combinatorial BGP/NetFlow analysis, for peering/transit analysis reports, offnet/on-net billing dif

Re: About IPv6 performance

On Dec 11, 2009, at 3:59 PM, David Pérez wrote: > could anybody point to a report that deals with all these issues? Also be sure to pay attention to IPv4/IPv6 feature parity gaps. --- Roland Dobbins //

Re: More ASN collissions

On Dec 11, 2009, at 1:35 AM, Jared Mauch wrote: > As always, good research by renesys. What happens when an ASN is requested, and it's discovered that said ASN is already in use by an unauthorized network, and that some proportion of the Internet are accepting it due to a lack of appropriate r

Re: AT&T blocking individual IP addresses

On Dec 9, 2009, at 11:03 PM, Scott Howard wrote: > They are (authenticated-required) proxy servers with 10's of thousands of > users behind them, so it's possible that they were seeing some bot-like > traffic from them, although the volume would have been tiny compared to the > volume of legit

Re: AT&T blocking individual IP addresses

On Dec 9, 2009, at 10:22 PM, Scott Howard wrote: > Traceroute to the neighboring IP addresses don't go anywhere near the above > path, so it's apparently a blackhole of sorts. Are they bots or C&C servers, or open DNS recursors? -

Re: What DNS Is Not

On Nov 27, 2009, at 2:25 AM, Dan White wrote: > Anytime this issue has been brought up in a public setting (here, slashdot, > etc.) has resulted in terrible press > and even corrective action. Does anyone have any idea of the financial 'rewards' SPs who do this kind of thing reap from it? I'

Mail.app threading (was Re: Policy News)

On Nov 19, 2009, at 2:13 AM, Matthew Dodd wrote: > Sadly I don't know of any feature that does this in Mail.app, b If you set the Mail.app GUI to use 'threaded view', it's easy to zap a whole thread. --- Roland Dobbins //

Re: Pros and Cons of Cloud Computing in dealing with DDoS

On Nov 8, 2009, at 2:33 AM, Stefan Fouant wrote: > if the discussion hasn't shifted from that of DDoS to EDoS, it > should. All DDoS is 'EDoS' - it's a distinction without a difference, IMHO. DDoS costs opex, can cost direct revenue, can induce capex spends - it's all about economics at bo

<    1   2   3   4   5   6