Re: Best practices for abuse@ mailbox and network abuse complaint handling?
On 5/11/07, K K <[EMAIL PROTECTED]> wrote: Can anybody point me at best practices for monitoring and responding to abuse complaints, and good solutions for accepting complaints about network abuse? Any recommended outsourced services for processing abuse complaints? Well, there's a few things 1. Mitigate [port 25 management, walled gardens and such] => Cut down on the number of abuse causing issues 2. Automate => Abacus or other abuse desk optimized ticketing system, as John Levine said => Feedback loops (ARF formatted) from various ISPs => Ditto, automated feeds from Phishtank, Netcraft, your local CERT 3. Spread the load intelligently => Whatever can be handled by tier 1 should be handled by tier 1 Probably 98% of the mailbox is from are spammers who've harvested or randomly targeted abuse@ addresses for male enhancement, maybe 1.99% So? A little filtering should handle a lot of that, procmail even. At least to file the obvious crap into a different folder that can be looked at and blown away to educate management on responsible mass mailing). But every once in a while there is a legitimate network-related "incident", and my team does need to see those messages in a timely manner. Separate POCs as far as possible (postmaster for block related issues, abuse for spam related issues, and a block interface like the one we have around - http://spamblock.outblaze.com/ip.add.re.ss), and quick, automated escalations. Ditto tools to automate as much of the "search" stuff as possible. Prioritizing incidents in your queue as well (stuff like LE requests, largescale network incidents etc can usually be spotted from the subject line itself) Takes time to build that kind of setup, but the time spent is well worth it MAAWG's working on an abuse desk best practice doc over the last few meetings, it should be well worth reading when it does come out. --srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Broadband routers and botnets - being proactive
Gadi, I and numerous others (including some whom any reasonable NANOG-L poster would respect and listen to) have asked you repeatedly to stop trolling NANOG-L with this botnet crap. It is off-topic here. The last time you pulled this (starting a 4-day troll-fest about a nonexistent "INNURNET EMERGENCY") I asked you to stop it, and not one of the legions of supporters you talk about spoke up to say "Wait, I want to see botnet crap on NANOG-L." Even if all 6 of your botnet-loving supporters spoke up, it would not change the fact that your botnet posts are off topic, unwanted, and disruptive. It's time for you to stop it. Please.
Broadband routers and botnets - being proactive
In this post I'd like to discuss the threat widely circulated insecure broadband routers pose today. We have touched on it before. Today, yet another public report of a vulnerable DSL modem type was posted to bugtraq, this time about a potential WIRELESS flaw with broadband routers being insecure at Deutsche Telekom. I haven't verified this one myself but it refers to "Deutsche Telekom Speedport w700v broadband router": http://seclists.org/bugtraq/2007/May/0178.html If you all remember, there was another report a few months ago about a UK ISP named BeThere with their wireless router being accessible from the Internet and exploitable, as another example: http://blogs.securiteam.com/index.php/archives/826 Two issues here: 1. Illegitimate access to broadband routers via wireless communication. 2. Illegitimate access to broadband routers via the WAN. I'd like to discuss #2. Some ISPs which provide such devices (as in the example of #2 above) use them as bridges only, preventing several attack vectors (although not all). Many others don't. Most broadband ISPs have a vulnerable user-base on some level. Many broadband ISPs around the world distribute such devices to their clients. Although the general risk is well known, like with many other security issues many of us remained mostly quiet in the hope of avoiding massive exploitation. As usual, we only delayed the inevitable. I fear that the lack of awareness among some ISPs for this "not yet widely exploited threat" has resulted in us not being PROACTIVE and taking action to secure the Internet in this regard. What else is new, we are all busy with yesterday's fires to worry about tomorrow's. Good people will REACT and solve the problem when it pops up in wide-exploitation, but what we may potentially be facing is yet another vector for massive infections and the creation of eventual bot armies on yet another platform. My opinion is, that with all these public disclosures and a ripe pool of potential victims, us delaying massive exploitation of this threat may not last. I believe there is currently a window of opportunity for service providers to act and secure their user-base without rushing. Nothing in security is ever perfect, but actions such as changing default passwords and preventing connections from the WAN to these devices would be a good step to consider if you haven't already. My suggestion would be to take a look at your infrastructure and what your users use, and if you haven't already, add some security there. You probably have a remote login option for your tech support staff which you may want to explore - and secure. That's if things were not left at their defaults. Then, I'd also suggest scanning your network for what types of broadband routers your users make use of, and how many of your clients have port 23 or 80 open. Whether you provide with the devices or not, many will be using different ones set to default which may pose a similar threat. Being aware of the current map of vulnerable devices of this type in your networks can't hurt. It is not often that we can predict which of the numerous threats out there that we do not address currently, is going to become exploited next. If you can spare the effort, I'd strongly urge you to explore this front and be proactive on your own networks. The previous unaddressed threat which most of us chose to ignore was spoofing. We all knew of it for a very long time, but some of us believed it did not pose a threat to the Internet or their networks for no other reason than "it is not currently being exploited" and "there are enough bots out there for spoofing to not be necessary". I still remember the bitter argument I had with Randy Bush over that one. This is a rare opportunity, let's not waste it. We are all busy, but I hope some of you will have the time to look into this. I am aware of and have assisted several ISPs, who spent some time and effort exploring this threat and in some cases acting on it. If anyone can share their experience on dealing with securing their infrastructure in this regard publicly, it would be much appreciated. Thanks. Gadi Evron.
Re: HSRP availability in datacenters?
On routers, you have your choice as of 12.2 (I believe). On the small 3550/3560 type MLS products only HSRP is offered. Sorry- wasn't thinking. Of course the "new" animal in town is GLBP which offers load sharing. GLBP being completely Cisco proprietary unfortunately. -Don
Re: HSRP availability in datacenters?
On routers, you have your choice as of 12.2 (I believe). On the small 3550/3560 type MLS products only HSRP is offered. The 4948, being a cat4500 with a modern sup, offers both. Of course the "new" animal in town is GLBP which offers load sharing. j. Donald Stahl wrote: No, in fact those are very interesting as they're a stop-gap between 3750s and 4500s at a good price per port. Are there any HSRP limitations on them? Guess I need to do some more research, as those are pretty hot. Hasn't Cisco said for years that HSRP should not be used in new deployments and that VRRP should be used instead? Just curious. -Don
Re: Best practices for abuse@ mailbox and network abuse complaint handling?
K K wrote: [..] > I'm hoping to find either a better and widely accepted way to handle > non-spam-related network abuse complaints (hacking, DoS, etc), or at > least best practices for triage on the huge volume of mail that comes > into abuse@, procedures such that the rare legitimate complaint about > non-spam network abuse can be routed to my team in a timely manner. whois is the right one. But IMHO the ARIN whois is a bit limited and also odd, but that might be because I am used to seeing a different kind of data ;) In RIPE db we have a nice IRT (Incident Response Team) object which is meant for this, see amongst others: http://www.ripe.net/info/ncc/presentations/irt-tfcsirt6/sld001.html http://www.ripe.net/db/support/security/irt/irt-h2.html Next to that there is the 'abuse-mailbox' line which can be inserted with most objects, similarly to irt. These will at least allow your users to find you. Some of the tools out there that auto-spam abuse@ when they get a silly portscan use those fields, so at least you will get it at the right address and not at every other single address that is listed in whois. Greets, Jeroen signature.asc Description: OpenPGP digital signature
RE: HSRP availability in datacenters?
No, in fact those are very interesting as they're a stop-gap between 3750s and 4500s at a good price per port. Are there any HSRP limitations on them? Guess I need to do some more research, as those are pretty hot. Hasn't Cisco said for years that HSRP should not be used in new deployments and that VRRP should be used instead? Just curious. -Don
Re: Best practices for abuse@ mailbox and network abuse complaint handling?
The issue I see with most of the options (abuse.net, spamcop, etc) is they're focused on the spam problem, while my department is made up of network operations, information security, and CERT, anything to do with web servers, domains, and SMTP is handled by a different business unit in another state entirely. While 99.99% of our abuse@ mail is either spam or complaints about spoofed spam forging our domains as the source and has nothing to do with network operations, about once a month something truly network related will come into that mailbox, and my team won't be alerted to these events in a timely manner. Only fix I can see right now is for us to make it part of our daily workload to troll the abuse@ mailbox on the off chance that something in there is relevant to network operations/security/CERT. Is this what other NANOs do? The clueful victims will look up our ASN/ARIN records and eventually make the right phone call -- or report the problem to law enforcement, who definitely know how to reach us ;) I'm hoping to find either a better and widely accepted way to handle non-spam-related network abuse complaints (hacking, DoS, etc), or at least best practices for triage on the huge volume of mail that comes into abuse@, procedures such that the rare legitimate complaint about non-spam network abuse can be routed to my team in a timely manner. Thanks, Kevin
RE: HSRP availability in datacenters?
No, in fact those are very interesting as they're a stop-gap between 3750s and 4500s at a good price per port. Are there any HSRP limitations on them? Guess I need to do some more research, as those are pretty hot. Thanks for the heads up, we'll definitely take a closer look. Regards, Randal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jason Matthews > Sent: Friday, May 11, 2007 3:14 PM > To: Randal Kohutek > Cc: 'Mike Lyon'; nanog@merit.edu > Subject: Re: HSRP availability in datacenters? > > > > > I use 4948 series. > I pay $8400 for 4948-e and $6500 for 4948-s (non-10GE models). > > The price delta isnt so great from the 3560G series. At the > end of the day, it is a cat4500 in a 1u chassis. > > Are these out of your budget? > j. > > Randal Kohutek wrote: > > I agree, 6500s or 4500s for distribution are where it's at ... > > Unfortunately they cost a lot. Which is why the suits are > considering > > financing them by charging for the features they provide. > > > >
Re: HSRP availability in datacenters?
I use 4948 series. I pay $8400 for 4948-e and $6500 for 4948-s (non-10GE models). The price delta isnt so great from the 3560G series. At the end of the day, it is a cat4500 in a 1u chassis. Are these out of your budget? j. Randal Kohutek wrote: I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately they cost a lot. Which is why the suits are considering financing them by charging for the features they provide.
Re: How many others are nullrouting BT?
On May 11, 2007, at 1:50 PM, Niels Bakker wrote: Maybe, just maybe, they are under (British) police orders to keep those scammers connected to gather more evidence. Happened in the Netherlands with an apartment full of Nigerian scammers connected to UPC. They have refused all of the evidence we have offered to date. They refer us to the UK law enforcement. We ask for contact information for their local office, and they responded with the (fictional) address of Scotland Yard from the popular tv show. That's sarcasm, not helpfulness. It's reckless, inconsiderate behavior. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550
Re: ISP CALEA compliance
On Fri, 11 May 2007 12:47:56 -0700 (GMT-07:00) Todd Glassey <[EMAIL PROTECTED]> wrote: > Gee Steven, that's what everyone thought prior to a Federal Judge > ordering Microsoft to produce seven years of Email... > We're getting off-topic here, but I'll respond. First -- the context of the conversation is wiretap law, including the stored communications and customer records provisions. This covers what communications providers do for their customers, not internal emails. Second: (a) The judge's order was for a civil lawsuit, under discovery procedures; (b) The order was for records that they apparently had. If Microsoft had had and enforced a policy, prior to that lawsuit, of not retaining internal email older than 30 days, they'd have been in the clear. Microsoft got in trouble because the judge believed they were not complying with his order to turn over data he believed they had, either deliberately or by not exerting sufficient effort; (c) you may have business reasons to retain certain records for longer, including the requirements of external auditors. For example, if you do usage-sensitive billing, you may need to retain certain records for a while so that your accounting firm can verify that your financial records accurately reflect actual customer behavior. (d) What doesn't exist can't be subpoenaed; what does exist, in general, can be, subject to other specialized exceptions (i.e., attorney work product) Third -- that isn't what I'm talking about. Please see, among others, http://news.com.com/Gonzales+pressures+ISPs+on+data+retention/2100-1028_3-6077654.html http://www.theregister.co.uk/2006/09/20/gonzales_calls_for_data_retention/ http://news.com.com/2100-1028_3-6156948.html Note especially that last one, since it's only 3 months old and provides for jail time for "employees of any Internet provider who fail to store that information", and not just fines for the company. I've tried hard to keep this discussion factual, with copious references. But I think I've run out of things to say that are even vaguely on-topic, so I'll shut up. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Best practices for abuse@ mailbox and network abuse complaint handling?
My experience is that there's no substitute for a human abuse administrator. You can't manage your abuse queue with a script; not even a really fancy script; not even if it's so fancy that it's called a "Software Suite." You need a human (with clue about things like SMTP and email headers) to be reading the abuse mailbox so that they can recognize and deal with the complaints that represent genuine issues. For a small number of complaints this can be a small part of someone's job; for a larger number you will need one or more people doing abuse full-time. Many aspects of the abuse-handling process can be automated by a savvy abuse admin, but the abuse admin cannot be eliminated if you want to preserve your ability to appropriately respond to network incidents in a reasonable time. To see what happens when you eliminate the humans from your abuse handling, try sending an abuse complaint to yahoo or hotmail. Outsourcing could theoretically work, but the "outside" abuse administrator would need significant access to your network to track down and deal with issues. A powerless abuse admin with no ability to fix the issues he finds would be pretty useless. I haven't seen such a service. There are email management services like Postini but they mostly just filter incoming email for spam and virii. Here's a list of email abuse related best-practices; some of these are great; some are total crap (and some I didn't look at): http://spamcon.org/directories/best-practices.shtml The bestprac.org stuff looks pretty good; this appears to be relevant: http://www.bestprac.org/principles/isp.htm K K wrote: Can anybody point me at best practices for monitoring and responding to abuse complaints, and good solutions for accepting complaints about network abuse? Any recommended outsourced services for processing abuse complaints?
Re: ISP CALEA compliance
On 5/11/07, Todd Glassey <[EMAIL PROTECTED]> wrote: Gee Steven, that's what everyone thought prior to a Federal Judge ordering Microsoft to produce seven years of Email... I believe that was because they knew MS *had* that email. Of course, any missing email can probably be tossed together pretty quickly using some fairly simple algorithms, perhaps by using many of the BS generators already on the Internet.. :) That said, if you really don't have 7 years worth of email, then the Federal Judge can order till he's red in the face. TSG/ -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
RE: HSRP availability in datacenters?
While I'm not a huge fan of running more than 32 instances on a 3550, using the FAQ posted earlier to get above 16 works quite well. I'm not following the argument about failing 16 vlans at a time because they're in the same group. Running a quick test in the lab, this wasn't my experience at all. I'm not aware of the group instance having any synchronization impact (such as it would with VRRP) when it comes to HSRP -- only a single vlan interface failed over when I did a shut on the primary. The group simply determines the virtual mac address, but if I'm wrong on this let me know. The documentation/configuration synchronization issues are really more an issue of how refined provisioning is. If your upstream links from these aggregation devices are layer 3, and I hope they are, the vlans carry only locally significance anyway. When the aggrs are spun up, the vlan interfaces and groups could all be pre-defined before they're even needed. Yes, you may not know the IP addresses or block sizes to pre-configure all of the HSRP data, but you can hold the "standby x authentication" line within a configuration without knowing any of the layer 3 information. At a later point when the vlan interface is actually needed for a customer, the provisioning group simply needs to match the group number they already see in the configuration. To get back to the original question, yes, I think HSRP is worth keeping around and shouldn't really have a line-item cost associated with it to the customer. I've worked with providers that charge an "HA" fee during provisioning (and often a recurring one as well) for customers that want it, but personally I think offering an HA network as a service provider should almost be a given. If you're still uncomfortable with the multiple vlans bound to one group issue, there's also the 4948 model to consider. It removes the issue of having a million eggs in one basket at the customer aggregation level, effectively has a 4000 series sup, and Cisco tested this out for us with 1500 HSRP instances running (lab documents available offline if you'd like to see). Alas, it does rise the aggregation costs a bit though. Hope that helps, Brad McConnell CCIE #16147 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randal Kohutek Sent: Friday, May 11, 2007 2:21 PM To: 'Mike Lyon' Cc: nanog@merit.edu Subject: RE: HSRP availability in datacenters? I had read that on our original deployment, and it's a nightmare to keep the documenation and configuration in synch. My personal opinion is that potentially failing 16 VSIs over to the standby at once (because they're all in the same group) - instead of just the affected ones - is poor policy. I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately they cost a lot. Which is why the suits are considering financing them by charging for the features they provide. This has been a hot topic around the office, with all of us network guys saying `keep hsrp everywhere` because it makes our phones ring less, but we realize that network upgrades aren't free, which is making the non-IT folks all antsy. Regards, Randal > -Original Message- > From: Mike Lyon [mailto:[EMAIL PROTECTED] > Sent: Friday, May 11, 2007 1:11 PM > To: Randal Kohutek > Cc: nanog@merit.edu > Subject: Re: HSRP availability in datacenters? > > Check out this article: > > http://www.cisco.com/en/US/products/hw/switches/ps646/products > _qanda_item09186a00801cb707.shtml#q1 > > Get rid of the 3550. Get youself a 6509 or 6513 :0 > > -Mike > > > On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: > > We currently offer HSRP everywhere, the problem is that it doesn't > > scale on a budget. For example, a 3550 can do 16 HSRP > groups, limiting > > the number of customers that we can attach to (2x 3550s) to > 16. That's > > a lot of distribution infrastructure for 16 customers. Then > to scale > > that, say, to > > 200+ customers, that means we have 12-13 pairs of distribution > > 200+ routers, each > > with 2x gigE uplinks to the core ... Which means that > either (A) the > > core has to be really big or (b) we get fewer, more powerful > > distribution devices. > > > > This is where my employer is at now - I admit, we're tiny in the > > datacenter world - but the cost to aggregate 100+ HSRP > groups into the > > core, with room to grow, is pretty staggering for a smb. > > > > This why the suits are wondering if there is a revenue opportunity > > hiding somewhere to finance such a thing. Ah, the joys of > growing out > > of your britches :) > > > > Thanks for any continued response, > > Randal > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > > > Of Mike Lyon > > > Sent: Friday, May 11, 2007 12:40 PM > > > To: Randal Kohutek > > > Cc: nanog@merit.edu > > > Subject: Re: HSRP availability in datacenters? > > > > > > > > > So is the q
Re: ISP CALEA compliance
On Fri, 11 May 2007, Steven M. Bellovin wrote: As Bill Simpson has quite correctly pointed out, you're also not required to roll over and play dead when someone from the government asks you for some data. There are laws they're obligated to follow, too. Even if you want to look at it from a purely selfish position, you and/or your company may be liable if you co-operate with an improper or illegal request. Have a look at http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_2520000-.html which provides for civil liability for illegal wiretaps. You're clear, under that statute, if you have good reason to believe the request is legal under certain very specific sections of the wiretap law, but not otherwise. An important thing to remember in this discussion is CALEA does not expand, contract or otherwise change other laws concerning electronic survellance. The government can not intercept anything under CALEA. All interception orders must be authorized by some other statute or some other lawful authority (e.g. claims of Executive Power). You might never, ever receive an lawful interception order, but still be in violation of CALEA. Likewise you might be 100% CALEA compliant, and still decline or be unable to perform some intercept orders. CALEA does enhance some monetary penalties for not being able to perform a lawful intercept authorized by some other statute or authority; but CALEA doesn't authorize the interception itself. Despite attempts by some folks, CALEA compliance != Wiretap authority.
Re: HSRP availability in datacenters?
Since you are already deploying redundant hardware, why not just run two links to the customer? 3550s support simple routing as well as BGP and this protects your customer from things like your 3550 failing... And causes less HSRP and other chatter. I would encourage my competitors to engineer customers on L2 interfaces with a redundancy protocol on-top all day long. DJ Randal Kohutek wrote: My cohorts in suits have begun wondering if HSRP is standard for customer gateways, and from there wondering if it is something we should charge for. I did some research and came up with mixed results; I'd like to hear nanogers experiences with this: In your experience, do datacenters provide free HSRP gateways, or do they make you pay for it? Real world examples are better than Google :) Thanks, Randal
RE: HSRP availability in datacenters?
On Fri, 11 May 2007, Randal Kohutek wrote: I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately they cost a lot. Which is why the suits are considering financing them by charging for the features they provide. One way I've seen providers address is this to have two different classes of service offerings. One has redundancy built in and the other doesn't - then you price the offerings accordingly. That could apply to basic ping-and-power colo, managed services, or anything in between. The cost difference could be justified by the fact that the redundant service takes up resources (finite resources at that) on two different big expensive switches. This has been a hot topic around the office, with all of us network guys saying `keep hsrp everywhere` because it makes our phones ring less, but we realize that network upgrades aren't free, which is making the non-IT folks all antsy. And that's a very valid point. Many organizations pay different amounts of attention to manpower costs vs. capex to buy the big expensive switches and opex to keep things running. Manpower is (hopefully ;) in your organization) not cheap. jms
How many others are nullrouting BT?
We've long been aware that BT *never* deals with spammers or DoS attacks that originate from their network, but a new issue has come to light. BT has a number of users who are apparently testing out stolen credit card numbers from their network against stores of all flavors. 3 months of attempts by US banks, US police departments, FBI, etc to get any action taken on these issues has gone nowhere. BT is "protecting the interests of their users". Meanwhile the stolen credit card attempts continue unabated. We're considering null-routing all BT netblocks. I'm wondering how many others have already come to the same conclusion? -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550
Re: ISP CALEA compliance
On Fri, 11 May 2007 12:17:04 -0400 Jared Mauch <[EMAIL PROTECTED]> wrote: > If there is interest, perhaps I can make a call to DoJ and > see if someone can present on CALEA at nanog in a few weeks? (incase > the PC can accomodate them). > And perhaps someone from CDT? I mean that in all seriousness. DoJ and the FBI have pushed the statutory envelope on CALEA, in my opinion. Different lawyers will often disagree on what the law actually requires (I'm not even talking about what it should require); it's worth getting other perspectives. Education on this subject is good. When NANOG met in DC a few years ago, I personally invited a DoJ attorney to speak on Sunday on wiretap law (http://www.nanog.org/mtg-0010/justice.html). I'm not unsympathetic to legitimate law enforcement or national security needs, and I'm aware that ISPs need to obey the law. But DoJ needs to obey it, too. --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: ISP CALEA compliance
On Fri, 11 May 2007 10:52:21 -0400 William Allen Simpson <[EMAIL PROTECTED]> wrote: > > David Lesher wrote: > > > Speaking on Deep Background, the Press Secretary whispered: > >> You work so hard to defend people that exploit children? > >> Interesting. We are >> talking LEA here and not the latest in > >> piracy law suits. The #1 request from a >> LEA in my experience > >> concerns child exploitation. > > That's nonsense, or his (press secretary's) experience consists of > > watching > /Law & Order/ and /Without a Trace/. > > No official statistics backs that up. Where in the world does he > operate? > > > > I think you'll find most intercept orders are drug cases. > So I've > > heard, but my experience was the Ashcroft 'net p0rn crackdown. > What a waste of time and resources for a perfectly legal activity! > > Of course, CALEA (and PATRIOT) were supposed to be about tracking > terrorists, not common criminals. That was never the real purpose; > it was just a wish list. > > Also, with so many college students, we *are* talking about piracy > lawsuits. But that's civil law, not CALEA or PATRIOT. Hopefully, > they haven't tried to expand into that, too? > The latest revisions to copyright law did provide for more criminal penalties... Let me toss in a few more factual URLs. First, on this topic: Federal wiretap warrants can only be issued for specific crimes. That list is in 18 USC 2516; see http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_2516000-.html The list is long, but it doesn't seem to include the RIAA's least favorite activities -- at least, not yet... (The list has also been expanded significantly in recent years. I haven't bothered to check the details, but I think that most of the expansion was via the PATRIOT Act. Much of the PATRIOT Act, I might add, was a long set of DoJ/FBI wish list amendments, things they'd wanted for years but couldn't get through Congress until after 9/11. My source for that, btw, is conversations with people in DoJ.) For CALEA deployment status, see http://www.usdoj.gov/oig/reports/FBI/a0613/final.pdf Note in particular how much more expensive CALEA taps are... For the latest wiretap report, just out last week, see http://www.uscourts.gov/wiretap06/contents.html Pay particular attention to Table 3. The highlight: 80% of all wiretaps were for narcotics offenses. There is *no* separate category for pornography, child or otherwise, which caps the percentage at the 3.5% for "Other". To be sure, the report notes that sensitive ongoing cases are not counted; this may reflect ongoing sting operations or national security wiretaps, There are no national security or terrorism wiretaps listed, possibly because those fell under FISA (50 USC 1801 -- http://www4.law.cornell.edu/uscode/html/uscode50/usc_sec_50_1801000-.html ). For those who remember the Crypto Wars of the 1990s, it's interesting to note this section of the wiretap report: Public Law 106-197 amended 18 U.S.C. 2519(2)(b) to require that reporting should reflect the number of wiretap applications granted for which encryption was encountered and whether such encryption prevented law enforcement officials from obtaining the plain text of communications intercepted pursuant to the court orders. In 2006, no instances were reported of encryption encountered during any federal or state wiretap. The situation may be different for national security wiretaps, but of course that's where compliance with any US anti-crypto laws are least likely. Folks, the factual and legal data is out there, and it's not that hard to find. Interpreting it is harder, and frequently does require a lawyer who really knows the field. (My favorite example there is 18 USC 2072(c)(6), which *permits* communications providers to disclose customer records (except for content) to "any person other than a governmental entity". I was surprised enough when I first read that that I went and looked up the legislative history, and it means exactly what it says. *But* -- such activity is no longer legal. Why? The Telecom Reform Act of 1996 bars telcos, at least, from certain forms of information sharing internally, to promote competition in the telephony market. They weren't trying to fix the privacy flaw in the older statute; fortunately, they did -- by accident...) As Bill Simpson has quite correctly pointed out, you're also not required to roll over and play dead when someone from the government asks you for some data. There are laws they're obligated to follow, too. Even if you want to look at it from a purely selfish position, you and/or your company may be liable if you co-operate with an improper or illegal request. Have a look at http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_2520000-.html which provides for civil liability for illegal wiretaps. You're clear, under that statute, if you have good reason to believ
Re: HSRP availability in datacenters?
Well, the suits will realize the support nightmare (which equals $$$) if they don't keep HSRP. Hopefully, they won't have to learn that the hard way. -Mike On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: I had read that on our original deployment, and it's a nightmare to keep the documenation and configuration in synch. My personal opinion is that potentially failing 16 VSIs over to the standby at once (because they're all in the same group) - instead of just the affected ones - is poor policy. I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately they cost a lot. Which is why the suits are considering financing them by charging for the features they provide. This has been a hot topic around the office, with all of us network guys saying `keep hsrp everywhere` because it makes our phones ring less, but we realize that network upgrades aren't free, which is making the non-IT folks all antsy. Regards, Randal > -Original Message- > From: Mike Lyon [mailto:[EMAIL PROTECTED] > Sent: Friday, May 11, 2007 1:11 PM > To: Randal Kohutek > Cc: nanog@merit.edu > Subject: Re: HSRP availability in datacenters? > > Check out this article: > > http://www.cisco.com/en/US/products/hw/switches/ps646/products > _qanda_item09186a00801cb707.shtml#q1 > > Get rid of the 3550. Get youself a 6509 or 6513 :0 > > -Mike > > > On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: > > We currently offer HSRP everywhere, the problem is that it doesn't > > scale on a budget. For example, a 3550 can do 16 HSRP > groups, limiting > > the number of customers that we can attach to (2x 3550s) to > 16. That's > > a lot of distribution infrastructure for 16 customers. Then > to scale > > that, say, to > > 200+ customers, that means we have 12-13 pairs of distribution > > 200+ routers, each > > with 2x gigE uplinks to the core ... Which means that > either (A) the > > core has to be really big or (b) we get fewer, more powerful > > distribution devices. > > > > This is where my employer is at now - I admit, we're tiny in the > > datacenter world - but the cost to aggregate 100+ HSRP > groups into the > > core, with room to grow, is pretty staggering for a smb. > > > > This why the suits are wondering if there is a revenue opportunity > > hiding somewhere to finance such a thing. Ah, the joys of > growing out > > of your britches :) > > > > Thanks for any continued response, > > Randal > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > > > Of Mike Lyon > > > Sent: Friday, May 11, 2007 12:40 PM > > > To: Randal Kohutek > > > Cc: nanog@merit.edu > > > Subject: Re: HSRP availability in datacenters? > > > > > > > > > So is the question: you are selling transit to your customers and > > > you are wondering if you should charge your customer for allowing > > > them to use your HSRP gateway instead of a physical interface on > > > your router? > > > > > > Personally, if I saw a provider charging for that > service, I would > > > shy away from them. Only because it tells me they are > piece-mealing > > > their services and are cheap. I would think a good provider would > > > include that (and/or not sell it WITHOUT > > > HSRP) in their sales offering. If for the only reason of customer > > > support nightmares. If you have your customers on HSRP > and you have > > > a router go down, you wont have them calling you every > five minutes > > > bitching at you... > > > > > > -Mike > > > > > > > > > On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: > > > > > > > > My cohorts in suits have begun wondering if HSRP is > standard for > > > > customer gateways, and from there wondering if it is > > > something we should charge for. > > > > I did some research and came up with mixed results; I'd > > > like to hear > > > > nanogers experiences with this: > > > > > > > > In your experience, do datacenters provide free HSRP > > > gateways, or do > > > > they make you pay for it? > > > > > > > > > > > > Real world examples are better than Google :) Thanks, Randal > > > > > > > > > > > > > > > >
RE: HSRP availability in datacenters?
I had read that on our original deployment, and it's a nightmare to keep the documenation and configuration in synch. My personal opinion is that potentially failing 16 VSIs over to the standby at once (because they're all in the same group) - instead of just the affected ones - is poor policy. I agree, 6500s or 4500s for distribution are where it's at ... Unfortunately they cost a lot. Which is why the suits are considering financing them by charging for the features they provide. This has been a hot topic around the office, with all of us network guys saying `keep hsrp everywhere` because it makes our phones ring less, but we realize that network upgrades aren't free, which is making the non-IT folks all antsy. Regards, Randal > -Original Message- > From: Mike Lyon [mailto:[EMAIL PROTECTED] > Sent: Friday, May 11, 2007 1:11 PM > To: Randal Kohutek > Cc: nanog@merit.edu > Subject: Re: HSRP availability in datacenters? > > Check out this article: > > http://www.cisco.com/en/US/products/hw/switches/ps646/products > _qanda_item09186a00801cb707.shtml#q1 > > Get rid of the 3550. Get youself a 6509 or 6513 :0 > > -Mike > > > On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: > > We currently offer HSRP everywhere, the problem is that it doesn't > > scale on a budget. For example, a 3550 can do 16 HSRP > groups, limiting > > the number of customers that we can attach to (2x 3550s) to > 16. That's > > a lot of distribution infrastructure for 16 customers. Then > to scale > > that, say, to > > 200+ customers, that means we have 12-13 pairs of distribution > > 200+ routers, each > > with 2x gigE uplinks to the core ... Which means that > either (A) the > > core has to be really big or (b) we get fewer, more powerful > > distribution devices. > > > > This is where my employer is at now - I admit, we're tiny in the > > datacenter world - but the cost to aggregate 100+ HSRP > groups into the > > core, with room to grow, is pretty staggering for a smb. > > > > This why the suits are wondering if there is a revenue opportunity > > hiding somewhere to finance such a thing. Ah, the joys of > growing out > > of your britches :) > > > > Thanks for any continued response, > > Randal > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > > > Of Mike Lyon > > > Sent: Friday, May 11, 2007 12:40 PM > > > To: Randal Kohutek > > > Cc: nanog@merit.edu > > > Subject: Re: HSRP availability in datacenters? > > > > > > > > > So is the question: you are selling transit to your customers and > > > you are wondering if you should charge your customer for allowing > > > them to use your HSRP gateway instead of a physical interface on > > > your router? > > > > > > Personally, if I saw a provider charging for that > service, I would > > > shy away from them. Only because it tells me they are > piece-mealing > > > their services and are cheap. I would think a good provider would > > > include that (and/or not sell it WITHOUT > > > HSRP) in their sales offering. If for the only reason of customer > > > support nightmares. If you have your customers on HSRP > and you have > > > a router go down, you wont have them calling you every > five minutes > > > bitching at you... > > > > > > -Mike > > > > > > > > > On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: > > > > > > > > My cohorts in suits have begun wondering if HSRP is > standard for > > > > customer gateways, and from there wondering if it is > > > something we should charge for. > > > > I did some research and came up with mixed results; I'd > > > like to hear > > > > nanogers experiences with this: > > > > > > > > In your experience, do datacenters provide free HSRP > > > gateways, or do > > > > they make you pay for it? > > > > > > > > > > > > Real world examples are better than Google :) Thanks, Randal > > > > > > > > > > > > > > > >
Re: HSRP availability in datacenters?
Check out this article: http://www.cisco.com/en/US/products/hw/switches/ps646/products_qanda_item09186a00801cb707.shtml#q1 Get rid of the 3550. Get youself a 6509 or 6513 :0 -Mike On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: We currently offer HSRP everywhere, the problem is that it doesn't scale on a budget. For example, a 3550 can do 16 HSRP groups, limiting the number of customers that we can attach to (2x 3550s) to 16. That's a lot of distribution infrastructure for 16 customers. Then to scale that, say, to 200+ customers, that means we have 12-13 pairs of distribution routers, each with 2x gigE uplinks to the core ... Which means that either (A) the core has to be really big or (b) we get fewer, more powerful distribution devices. This is where my employer is at now - I admit, we're tiny in the datacenter world - but the cost to aggregate 100+ HSRP groups into the core, with room to grow, is pretty staggering for a smb. This why the suits are wondering if there is a revenue opportunity hiding somewhere to finance such a thing. Ah, the joys of growing out of your britches :) Thanks for any continued response, Randal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mike Lyon > Sent: Friday, May 11, 2007 12:40 PM > To: Randal Kohutek > Cc: nanog@merit.edu > Subject: Re: HSRP availability in datacenters? > > > So is the question: you are selling transit to your customers > and you are wondering if you should charge your customer for > allowing them to use your HSRP gateway instead of a physical > interface on your router? > > Personally, if I saw a provider charging for that service, I > would shy away from them. Only because it tells me they are > piece-mealing their services and are cheap. I would think a > good provider would include that (and/or not sell it WITHOUT > HSRP) in their sales offering. If for the only reason of > customer support nightmares. If you have your customers on > HSRP and you have a router go down, you wont have them > calling you every five minutes bitching at you... > > -Mike > > > On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: > > > > My cohorts in suits have begun wondering if HSRP is standard for > > customer gateways, and from there wondering if it is > something we should charge for. > > I did some research and came up with mixed results; I'd > like to hear > > nanogers experiences with this: > > > > In your experience, do datacenters provide free HSRP > gateways, or do > > they make you pay for it? > > > > > > Real world examples are better than Google :) Thanks, Randal > > > > >
Re: ISP CALEA compliance
A _much_ longer version of this was sent privately- but I had to take public exception to the following comment: I'm not surprised that when they are dealing with companies that delete all evidence they might need or push as much red tape as possible, that the LEA turns around and scrutinizes the company to find where they might be in breach of the law. You are saying it's ok for people in power to be vindictive assholes. You are saying it is ok to govern through intimidation. I am both incredulous as well as fearful for the future of our country. -Don
Re: ISP CALEA compliance
On Fri, 11 May 2007 10:42:14 -0400 "Jason Frisvold" <[EMAIL PROTECTED]> wrote: > > On 5/11/07, Brandon Galbraith <[EMAIL PROTECTED]> wrote: > > My understanding was data you had needed to be turned over when > > requested, but CALEA provides no specification/guidance on log > > retention. > > Agreed. My understanding, to date, is that the data to be turned over > is data collected from the beginning of the CALEA tap. Historical > data can be requested, but I'm not aware of any official legal > guidelines on retention time. > There are no legal requirements on proactive data retention in the US. Gonzales has suggested that there should be one, but at this point it's just that -- a suggestion. I think that at the moment, the odds of Congress enacting a Gonzales proposal are rather low; they'd much rather impeach him than listen to him... There is now an EU requirement on retention, but the EU's jurisdiction rules are, shall we say, complex. --Steve Bellovin, http://www.cs.columbia.edu/~smb
RE: HSRP availability in datacenters?
We currently offer HSRP everywhere, the problem is that it doesn't scale on a budget. For example, a 3550 can do 16 HSRP groups, limiting the number of customers that we can attach to (2x 3550s) to 16. That's a lot of distribution infrastructure for 16 customers. Then to scale that, say, to 200+ customers, that means we have 12-13 pairs of distribution routers, each with 2x gigE uplinks to the core ... Which means that either (A) the core has to be really big or (b) we get fewer, more powerful distribution devices. This is where my employer is at now - I admit, we're tiny in the datacenter world - but the cost to aggregate 100+ HSRP groups into the core, with room to grow, is pretty staggering for a smb. This why the suits are wondering if there is a revenue opportunity hiding somewhere to finance such a thing. Ah, the joys of growing out of your britches :) Thanks for any continued response, Randal > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mike Lyon > Sent: Friday, May 11, 2007 12:40 PM > To: Randal Kohutek > Cc: nanog@merit.edu > Subject: Re: HSRP availability in datacenters? > > > So is the question: you are selling transit to your customers > and you are wondering if you should charge your customer for > allowing them to use your HSRP gateway instead of a physical > interface on your router? > > Personally, if I saw a provider charging for that service, I > would shy away from them. Only because it tells me they are > piece-mealing their services and are cheap. I would think a > good provider would include that (and/or not sell it WITHOUT > HSRP) in their sales offering. If for the only reason of > customer support nightmares. If you have your customers on > HSRP and you have a router go down, you wont have them > calling you every five minutes bitching at you... > > -Mike > > > On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: > > > > My cohorts in suits have begun wondering if HSRP is standard for > > customer gateways, and from there wondering if it is > something we should charge for. > > I did some research and came up with mixed results; I'd > like to hear > > nanogers experiences with this: > > > > In your experience, do datacenters provide free HSRP > gateways, or do > > they make you pay for it? > > > > > > Real world examples are better than Google :) Thanks, Randal > > > > >
Re: HSRP availability in datacenters?
So is the question: you are selling transit to your customers and you are wondering if you should charge your customer for allowing them to use your HSRP gateway instead of a physical interface on your router? Personally, if I saw a provider charging for that service, I would shy away from them. Only because it tells me they are piece-mealing their services and are cheap. I would think a good provider would include that (and/or not sell it WITHOUT HSRP) in their sales offering. If for the only reason of customer support nightmares. If you have your customers on HSRP and you have a router go down, you wont have them calling you every five minutes bitching at you... -Mike On 5/11/07, Randal Kohutek <[EMAIL PROTECTED]> wrote: My cohorts in suits have begun wondering if HSRP is standard for customer gateways, and from there wondering if it is something we should charge for. I did some research and came up with mixed results; I'd like to hear nanogers experiences with this: In your experience, do datacenters provide free HSRP gateways, or do they make you pay for it? Real world examples are better than Google :) Thanks, Randal
HSRP availability in datacenters?
My cohorts in suits have begun wondering if HSRP is standard for customer gateways, and from there wondering if it is something we should charge for. I did some research and came up with mixed results; I'd like to hear nanogers experiences with this: In your experience, do datacenters provide free HSRP gateways, or do they make you pay for it? Real world examples are better than Google :) Thanks, Randal
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>. Routing Table Report 04:00 +10GMT Sat 12 May, 2007 Report Website: http://thyme.apnic.net This report:http://thyme.apnic.net/ap-data/2007/05/12/0400 Analysis Summary BGP routing table entries examined: 219961 Prefixes after maximum aggregation: 117145 Deaggregation factor: 1.88 Unique aggregates announced to Internet: 106816 Total ASes present in the Internet Routing Table: 25145 Prefixes per ASN: 8.75 Origin-only ASes present in the Internet Routing Table: 21900 Origin ASes announcing only one prefix: 10598 Transit ASes present in the Internet Routing Table:3245 Transit-only ASes present in the Internet Routing Table: 78 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (15941) 12 Prefixes from unregistered ASNs in the Routing Table: 6 Unregistered ASNs in the Routing Table: 7 Prefixes from 32-bit ASNs in the Routing Table: 5 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 11 Number of addresses announced to Internet: 1718002624 Equivalent to 102 /8s, 102 /16s and 163 /24s Percentage of available address space announced: 46.4 Percentage of allocated address space announced: 62.9 Percentage of available address space allocated: 73.7 Total number of prefixes smaller than registry allocations: 115143 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:50626 Total APNIC prefixes after maximum aggregation: 20239 APNIC Deaggregation factor:2.50 Prefixes being announced from the APNIC address blocks: 47626 Unique aggregates announced from the APNIC address blocks:21252 APNIC Region origin ASes present in the Internet Routing Table:2938 APNIC Prefixes per ASN: 16.21 APNIC Region origin ASes announcing only one prefix:789 APNIC Region transit ASes present in the Internet Routing Table:437 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 292851136 Equivalent to 17 /8s, 116 /16s and 141 /24s Percentage of available APNIC address space announced: 72.5 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 116/6, 120/6, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:106230 Total ARIN prefixes after maximum aggregation:62027 ARIN Deaggregation factor: 1.71 Prefixes being announced from the ARIN address blocks:78316 Unique aggregates announced from the ARIN address blocks: 30543 ARIN Region origin ASes present in the Internet Routing Table:11559 ARIN Prefixes per ASN: 6.78 ARIN Region origin ASes announcing only one prefix:4431 ARIN Region transit ASes present in the Internet Routing Table:1052 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 21 Number of ARIN addresses announced to Internet: 332297344 Equivalent to 19 /8s, 206 /16s and 116 /24s Percentage of available ARIN address space announced: 73.4 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks24/8,
Best practices for abuse@ mailbox and network abuse complaint handling?
Can anybody point me at best practices for monitoring and responding to abuse complaints, and good solutions for accepting complaints about network abuse? Any recommended outsourced services for processing abuse complaints? My interest in this is to more effectively respond to complaints about "bad" network traffic and abuse originating from IP addresses allocated to my employer and to the not-for-profit ISP I help run. (Two similar needs, two very different budgets). My employer has multiple Internet-connected networks, several IP allocations, and several hundred active domains. Currently [EMAIL PROTECTED] is sporadically monitored by a Messaging team, and any complaints which seem relevant to the Network or Security groups are forwarded to the appropriate internal contact. This is inefficient and untimely. Probably 98% of the mailbox is from are spammers who've harvested or randomly targeted abuse@ addresses for male enhancement, maybe 1.99% are email abuse complaints from customers who subscribed to company-run mailing lists and then forgot about it (I've worked hard to educate management on responsible mass mailing). But every once in a while there is a legitimate network-related "incident", and my team does need to see those messages in a timely manner. How do other network operators address the need for timely notification of network abuse? Some people are clueful enough to pull up the ARIN records and contact us by phone, but I don't want to depend on the victim of an attack sourced from our network being bright and persistent. Thanks, Kevin Kadow
Re: ISP CALEA compliance
On Fri, 11 May 2007, Jared Mauch wrote: > > If there is interest, perhaps I can make a call to DoJ and > see if someone can present on CALEA at nanog in a few weeks? (incase > the PC can accomodate them). that seems like a great idea, atleast a lightning talk would be nice.
OT: ISP Security BOF @NANOG 40
Folks, Kevin Lanning (ATT) and I will be moderating the ISP Security BOF at NANOG 40 in Bellevue. As usual, if there are security-related topics you'd like to hear about, would rather not hear about, or would like like to present, please drop us a line ASAP. Thanks! -danny & kevin = NANOG 39 ISP Security BOF Agenda: - The root of a log: Extracting Intelligence from the Woods - Botnet C&C: Extirpate or Infiltrate? - netdisco introduction - Bill Fenner - Defending the NANOG Network: How the local net is geared for security (Randy B. moderator) - Open Microphone
Bell South Postmaster?
Looking for postmaster at BellSouth. Please contact me off list. Thanks. Vish Yelsangikar Netflix.
Re: ISP CALEA compliance
On Fri, May 11, 2007 at 10:42:14AM -0400, Jason Frisvold wrote: > > On 5/11/07, Brandon Galbraith <[EMAIL PROTECTED]> wrote: > > My understanding was data you had needed to be turned over when requested, > > but CALEA provides no specification/guidance on log retention. > > Agreed. My understanding, to date, is that the data to be turned over > is data collected from the beginning of the CALEA tap. Historical > data can be requested, but I'm not aware of any official legal > guidelines on retention time. CALEA is not a subscriber records type of subponea or similar. I'm very concerned with the comments here that folks may come up with an opinion that CALEA is something they don't need to pay attention to. You may luck out and never see a request, nor a Title III, nor FISA, NSL, or any other lawful request. This is not a political thing the way some here on the list appear to be coloring it. We (as an industry) need to comply with a lawful request, the same as any other industry (eg: financial services, or otherwise). If you take a casual moment to read the CALEA statute, you will notice it's a capability to perform intercepts, not logs, etc.. If you do not have experience in dealing with court orders, when you get one, engage some legal counsel immediately. There are some small things that you can inadvertently do that can either compromise the evidence for the LEA, or possibly place your company at significant legal risk. I know that DoJ specifically has trained folks about CALEA. Call your local FBI office. Also CALEA isn't just a DoJ thing, it could be your local police, state police, or otherwise. You will need to have the capability to relay to them (in realtime or pseudo-realtime) via the LES protocol. If your customer is a 10G or 40G customer, you need to have the ability to perform that intercept. There is not a cutting-edge technology safe-harbor. Your only safe-harbor for problems is "the industry standard", which currently is interpreted for internet stuff as the T1.IAS. You can buy it for $185 (or $164) here: https://www.atis.org/docstore/product.aspx?id=22665 You really need to be talking to a mediation device provider and/or your vendors. They each have a lawful-intercept story. Don't expect any of these solutions to be elegant, as most of them use stuff like snmp-set and other things to hide the configuration, as per your Systems Security and Integrity Plan that you had to file already (you did file this, right? as well as filing form 445 ;) not everyone in your company should know about the intercept. If there is interest, perhaps I can make a call to DoJ and see if someone can present on CALEA at nanog in a few weeks? (incase the PC can accomodate them). - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: ISP CALEA compliance
David Lesher wrote: Speaking on Deep Background, the Press Secretary whispered: You work so hard to defend people that exploit children? Interesting. We are talking LEA here and not the latest in piracy law suits. The #1 request from a LEA in my experience concerns child exploitation. That's nonsense, or his (press secretary's) experience consists of watching /Law & Order/ and /Without a Trace/. No official statistics backs that up. Where in the world does he operate? I think you'll find most intercept orders are drug cases. So I've heard, but my experience was the Ashcroft 'net p0rn crackdown. What a waste of time and resources for a perfectly legal activity! Of course, CALEA (and PATRIOT) were supposed to be about tracking terrorists, not common criminals. That was never the real purpose; it was just a wish list. Also, with so many college students, we *are* talking about piracy lawsuits. But that's civil law, not CALEA or PATRIOT. Hopefully, they haven't tried to expand into that, too? And no matter what, we still have a Constitutionsort of... Which brings up my point be sure and let your Hill Critters know what shit you are going though Thanks! I said that a bit more politely, but it should be emphasized: report each and every request to your Congress critters. Remind them how much it's costing business, and an utter waste of effort.
Re: ISP CALEA compliance
On 5/11/07, Brandon Galbraith <[EMAIL PROTECTED]> wrote: My understanding was data you had needed to be turned over when requested, but CALEA provides no specification/guidance on log retention. Agreed. My understanding, to date, is that the data to be turned over is data collected from the beginning of the CALEA tap. Historical data can be requested, but I'm not aware of any official legal guidelines on retention time. -brandon -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: ISP CALEA compliance
Donald Stahl wrote:
Working hard to defend privacy does not automatically equal protecting
people who exploit children- and I'm getting sick and tired of people
screaming "Think of the children!" It's a stupid, fear mongering tactic-
and hopefully one day people will think of it in the same way as crying
wolf.
Confirming a warrant == working hard to defend privacy.
Making sure check clears != working hard to defend privacy
("Yep, you are protected from the government until they pay me.")
Deleting logs to inhibit valid warrants != working hard to defend privacy.
CALEA itself is only for taps, and does not cover record storage. We'll
be hit with that next, and it probably won't be nice legislation based
on what other countries have passed. Lack of maintaining any more of
records and even purposefully deleting them to inhibit law enforcement
will leave the government no choice but to let a bunch of non-technical
people design how we should store records.
The new rules for cnpi come into effect later this year, designed to
keep telco's a little sharper on maintaining customer privacy.
As for CALEA and data taps, who are you fooling? Do you tell customers
they have an expectation of privacy on the Internet? Does anyone here
actually believe that? If so, why are there rantings and ravings about
the weakness in encryption protocols? Why encrypt data at all over the
Internet? Why sign code? If there's an expectation of privacy, then
there should be an expectation of security. If my data can't be viewed,
it won't be modified. Perhaps you believe that criminals have the right
to invade privacy, but the government doesn't have that right even when
they do have just cause.
Great- so a bunch of people who want the laws bent for them go on a
power trip because you expect them to OBEY THE LAW and you end up with
no recourse against them. Yeah- this is the America I want to live in.
You're absolutely right- it's a crying shame we aren't all buddies with
the fed's- after all- they only want what's best for us! I'm looking
forward to the day when the government tells me what to think- thinking
is hard after all.
I have no problem with expecting a LEA to follow the law. I do have an
issue with making life as difficult as possible for them to do their job
when they are within the law. I'm not surprised that when they are
dealing with companies that delete all evidence they might need or push
as much red tape as possible, that the LEA turns around and scrutinizes
the company to find where they might be in breach of the law.
If you don't have anything to hide- then why should you care right?
Privacy is always a large concern. However, privacy should be addressed
through proper channels, not by trying to circumvent the laws that have
passed.
On the other hand- these sorts of laws may just be enough to push
everyone to use encryption- and then what will LE do?
I agree that it will most likely push criminals to use encryption. On
the other hand, lots of criminals are stupid, so perhaps some good will
come out of it. If it pushes everyone to use encryption, we are better
for it. See above, what expectation of privacy did we have to begin
with? Encryption good.
Jack
Re: Policy of Dial-up session processing
We handle it through RADIUS interim accounting packets. You then get periodic accounting updates. It has its own issues however (think of how busy your RADIUS server becomes receiving, say, 10,000 users worth of interim users off one BRAS by receiving a RADIUS packet every few minutes per user. It quietly adds up.) Adrian
Re: Policy of Dial-up session processing
Joe, There are lot of issues here. One thing to consider is that it is not a good policy to "cut off" the client ADSL at 0:00hs... they may complain for that policy ! You may just let him close the session and then, with the accounting stop ticket you may account part of it on the past month and the rest the current month. :) You may also set a maximum connection time for one session (some ISP do this also)... say for example 12 hours... so each 12 hours the RAS closes the connection (the thig is that this timer is for each connection, so you do not close all the connections at same time)... you may do this using standar radius attribute 27 (Session-Timeout) by modifying this attribute in the access-accept response from the radius to the RAS. You may also use interims... but Im not sure if you have traffic information on this... This are some ideas... there are a lot more... Hope it help, Nicolas. On Fri, 11 May 2007, william(at)elan.net wrote: willia > willia > willia >Radius can and should report both on and off times, look into your willia >configuration. As far as 1st of the month, consider it virtually willia >closed & open at midnight on 30th/31st in accounting. Example how willia >to do it could be to write a script that when processes radius log willia >at the end of the month and looks at all open sessions adding "end" willia >radius accounting data in there as well as adding start session for willia >next month's log. willia > willia >P.S. I've not ran dialup ISP and used radius for LONG time but did willia >exactly as above for hourly customers before. The biggest issue I willia >remember was when your dialup server itself dies (rare but happened) willia >since then you do not have record of customers getting off, same willia >script was used to virtually "close" sessions. willia > willia >On Fri, 11 May 2007, Joe Shen wrote: willia > willia >> hi, willia >> willia >> Maybe this is out-of-topic ,but I can't find any willia >> place where could find answer for this question. willia >> If this is intrusive, just ingore it please. willia >> willia >> my question is : willia >> how does ISP do with DSL dial-up sessions which willia >> pass the accouting period time. willia >> willia >> willia >> E.g. If a customer subscribe DSL service at willia >> 15USD/month for 150hours. If the subscriber used willia >> 145hours by 30th May. He get online at 21:00 on 31th, willia >> and get offline at 5:00 on June 2th. willia >> willia >> The radius server could only export the customer's willia >> session when he get offline. So, problem comes to willia >> accouting system which was designed to calculate willia >> customer usage on first day of each month. The willia >> cut-off line of each month usage is set to 00:00 on willia >> first day of each month. willia >> willia >> Someone says , ISP should force those session willia >> closed at 00:00 on first day of each month, because willia >> they must ensure dial-up session of last month sould willia >> not be accouted in next month. Is this true ? willia >> willia >> thanks in advance. willia >> willia >> Joe willia >
Re: ISP CALEA compliance
On 5/10/07, Jack Bates <[EMAIL PROTECTED]> wrote: I think what he meant was "My DSL has been broke for 3 months now, and I haven't not be able to use it. You can't charge me for something which wasn't working!" Question #1 - Did you bother to call our technical support hotline? No? Well then it can hardly be our fault that you're not working. Oh, you did call? (checks support records) .. No, no I don't see that in there.. Please pay the bill. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: Policy of Dial-up session processing
Radius can and should report both on and off times, look into your configuration. As far as 1st of the month, consider it virtually closed & open at midnight on 30th/31st in accounting. Example how to do it could be to write a script that when processes radius log at the end of the month and looks at all open sessions adding "end" radius accounting data in there as well as adding start session for next month's log. P.S. I've not ran dialup ISP and used radius for LONG time but did exactly as above for hourly customers before. The biggest issue I remember was when your dialup server itself dies (rare but happened) since then you do not have record of customers getting off, same script was used to virtually "close" sessions. On Fri, 11 May 2007, Joe Shen wrote: hi, Maybe this is out-of-topic ,but I can't find any place where could find answer for this question. If this is intrusive, just ingore it please. my question is : how does ISP do with DSL dial-up sessions which pass the accouting period time. E.g. If a customer subscribe DSL service at 15USD/month for 150hours. If the subscriber used 145hours by 30th May. He get online at 21:00 on 31th, and get offline at 5:00 on June 2th. The radius server could only export the customer's session when he get offline. So, problem comes to accouting system which was designed to calculate customer usage on first day of each month. The cut-off line of each month usage is set to 00:00 on first day of each month. Someone says , ISP should force those session closed at 00:00 on first day of each month, because they must ensure dial-up session of last month sould not be accouted in next month. Is this true ? thanks in advance. Joe
Re: Policy of Dial-up session processing
On Fri, 11 May 2007 20:17:02 +0800, Joe Shen said: > Someone says , ISP should force those session > closed at 00:00 on first day of each month, because > they must ensure dial-up session of last month sould > not be accouted in next month. Is this true ? Or they could apply a little more kloo, and at 23:59 poll all the active sessions, and bill them "this" month for the time-since connected. In your example, they got on at 21:00, so you bill them this month for 3 hours. Then when their session ends at 05:00, you notice that the session time is more than the time so far this month, and just bill them for 5 hours. Or you can simplify your accounting infrastructure a *lot* by just sending them a bill for $21.95 no matter how much time they spent connected - that's what a lot of DSL providers do, at least in the US. pgp2SdQOPS4RR.pgp Description: PGP signature
Re: Policy of Dial-up session processing
On Fri, May 11, 2007 at 08:17:02PM +0800, Joe Shen wrote: > > hi, > > Maybe this is out-of-topic ,but I can't find any > place where could find answer for this question. > If this is intrusive, just ingore it please. > > my question is : >how does ISP do with DSL dial-up sessions which > pass the accouting period time. > > > E.g. If a customer subscribe DSL service at > 15USD/month for 150hours. If the subscriber used > 145hours by 30th May. He get online at 21:00 on 31th, > and get offline at 5:00 on June 2th. > > The radius server could only export the customer's > session when he get offline. So, problem comes to > accouting system which was designed to calculate > customer usage on first day of each month. The > cut-off line of each month usage is set to 00:00 on > first day of each month. > > Someone says , ISP should force those session > closed at 00:00 on first day of each month, because > they must ensure dial-up session of last month sould > not be accouted in next month. Is this true ? One could always send a session-limit in the radius authentication to keep them under their usage for the month, including sending something that terminates the session at whatever you call for the start of month. this obviously could cause a spike in auth requests around . the other choices include intelligent accounting software that can take this situation into account. I've not used it in years, but radiator was nice back in the day. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Policy of Dial-up session processing
hi, Maybe this is out-of-topic ,but I can't find any place where could find answer for this question. If this is intrusive, just ingore it please. my question is : how does ISP do with DSL dial-up sessions which pass the accouting period time. E.g. If a customer subscribe DSL service at 15USD/month for 150hours. If the subscriber used 145hours by 30th May. He get online at 21:00 on 31th, and get offline at 5:00 on June 2th. The radius server could only export the customer's session when he get offline. So, problem comes to accouting system which was designed to calculate customer usage on first day of each month. The cut-off line of each month usage is set to 00:00 on first day of each month. Someone says , ISP should force those session closed at 00:00 on first day of each month, because they must ensure dial-up session of last month sould not be accouted in next month. Is this true ? thanks in advance. Joe __ Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/
The Cidr Report
This report has been generated at Fri May 11 21:50:19 2007 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
04-05-07216692 139686
05-05-07216689 139955
06-05-07216687 139977
07-05-07216641 139989
08-05-07216738 139604
09-05-07216352 140127
10-05-07216892 140124
11-05-07217002 140252
AS Summary
25064 Number of ASes in routing system
10603 Number of ASes announcing only one prefix
1480 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - AT&T WorldNet Services
90324224 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 11May07 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 217147 1402807686735.4% All ASes
AS4134 1255 315 94074.9% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4755 1119 190 92983.0% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS4323 1262 364 89871.2% TWTC - Time Warner Telecom,
Inc.
AS9498 979 96 88390.2% BBIL-AP BHARTI BT INTERNET
LTD.
AS6478 1094 244 85077.7% ATT-INTERNET3 - AT&T WorldNet
Services
AS18566 1006 160 84684.1% COVAD - Covad Communications
Co.
AS8151 1208 432 77664.2% Uninet S.A. de C.V.
AS11492 1048 361 68765.6% CABLEONE - CABLE ONE
AS22773 712 55 65792.3% CCINET-2 - Cox Communications
Inc.
AS19262 774 209 56573.0% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6197 1034 511 52350.6% BATI-ATL - BellSouth Network
Solutions, Inc
AS18101 536 32 50494.0% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS7018 1480 982 49833.6% ATT-INTERNET4 - AT&T WorldNet
Services
AS17488 676 178 49873.7% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS19916 568 101 46782.2% ASTRUM-0001 - OLM LLC
AS17676 504 65 43987.1% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS4766 740 317 42357.2% KIXS-AS-KR Korea Telecom
AS2386 1133 755 37833.4% INS-AS - AT&T Data
Communications Services
AS4812 453 77 37683.0% CHINANET-SH-AP China Telecom
(Group)
AS5668 597 249 34858.3% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS7029 584 238 34659.2% WINDSTREAM - Windstream
Communications Inc
AS16852 400 76 32481.0% BROADWING-FOCAL - Broadwing
Communications Services, Inc.
AS721596 274 32254.0% DISA-ASNBLK - DoD Network
Information Center
AS7011 791 472 31940.3% FRONTIER-AND-CITIZENS -
Frontier Communications, Inc.
AS4668 3137 30697.8% LGNET-AS-KR LG CNS
AS14654 3035 29898.3% WAYPORT - Wayport
AS6198 561 265 29652.8% BATI-MIA - BellSouth Network
Solutions, Inc
AS855566 273 29351.8% CANET-ASN-4 - Bell Aliant
AS15270 528 239 28954.7% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS16814 362 84 278
BGP Update Report
BGP Update Report Interval: 27-Apr-07 -to- 10-May-07 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS477535803 2.7% 288.7 -- GLOBE-TELECOM-AS Telecom Carrier / ISP Plus + 2 - AS123923919 1.8% 29.9 -- SPRINTLINK - Sprint 3 - AS306 20164 1.5% 110.8 -- DNIC - DoD Network Information Center 4 - AS17974 17698 1.3% 66.3 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 5 - AS701816753 1.3% 11.1 -- ATT-INTERNET4 - AT&T WorldNet Services 6 - AS24731 16522 1.2% 384.2 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 7 - AS647814579 1.1% 13.2 -- ATT-INTERNET3 - AT&T WorldNet Services 8 - AS238612859 1.0% 11.2 -- INS-AS - AT&T Data Communications Services 9 - AS11492 12246 0.9% 16.4 -- CABLEONE - CABLE ONE 10 - AS619811369 0.9% 18.5 -- BATI-MIA - BellSouth Network Solutions, Inc 11 - AS580310710 0.8% 119.0 -- DDN-ASNBLK - DoD Network Information Center 12 - AS8151 9511 0.7% 7.9 -- Uninet S.A. de C.V. 13 - AS9121 8560 0.7% 44.6 -- TTNET TTnet Autonomous System 14 - AS9829 8500 0.6% 32.6 -- BSNL-NIB National Internet Backbone 15 - AS5786 8386 0.6% 79.1 -- UPRENET - University of Puerto Rico 16 - AS340408316 0.6% 332.6 -- CZTTNET-AS TTNET Czech Republic 17 - AS702 7926 0.6% 11.5 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 18 - AS6197 7781 0.6% 7.5 -- BATI-ATL - BellSouth Network Solutions, Inc 19 - AS2901 7057 0.5% 190.7 -- OGT-AS - Oso Grande Technologies, Inc. 20 - AS115566931 0.5% 45.6 -- Cable & Wireless Panama TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS315941682 0.1%1682.0 -- FORTESS-AS Fortess LLC Network 2 - AS303751364 0.1%1364.0 -- TEVA-NA - Teva Pharmaceuticals USA, INC 3 - AS1708 883 0.1% 883.0 -- FR-CNET-ISSY - Centre National d'Etudes des Telecommunication -- CNET 4 - AS20133 861 0.1% 861.0 -- CASS-COL - CASS INFORMATION SYSTEMS 5 - AS34378 854 0.1% 854.0 -- RUG-AS Razguliay-UKRROS Group 6 - AS297002170 0.2% 723.3 -- CYPRESS-SEMICONDUCTOR - Cypress Semiconductor 7 - AS306001319 0.1% 659.5 -- CSDI-ASN01 - Corbett Systems Development, Inc. 8 - AS289771253 0.1% 626.5 -- UN-UNLB United Nations Logistics Base Brindisi, Italy 9 - AS176456108 0.5% 555.3 -- NTT-SG-AP ASN - NTT SINGAPORE PTE LTD 10 - AS41555 550 0.0% 550.0 -- NOVATKL-AS FW Austria, Kundl 11 - AS307071610 0.1% 536.7 -- 12 - AS332321066 0.1% 533.0 -- ERXNETWORK - eRx Network 13 - AS7234 531 0.0% 531.0 -- RUSSELL - Frank Russell 14 - AS12408 481 0.0% 481.0 -- BIKENT-AS Bikent Ltd. Autonomous system 15 - AS22720 459 0.0% 459.0 -- LEXENT-INC-3NYP-301 - Lexent, Inc. 16 - AS8225 415 0.0% 415.0 -- ASTELIT-MSK-AS Astelit Autonomous System 17 - AS101784543 0.3% 413.0 -- KBTUS-AS Korea Baptist Theological University/Seminary 18 - AS41866 398 0.0% 398.0 -- INTERFAXINC-AS Interfax Inc 19 - AS33630 390 0.0% 390.0 -- FIRMLOGICWS - FIRMLOGIC 20 - AS24731 16522 1.2% 384.2 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.177.10.0/24 13212 0.8% AS4775 -- GLOBE-TELECOM-AS Telecom Carrier / ISP Plus + 2 - 203.177.132.0/24 12972 0.8% AS4775 -- GLOBE-TELECOM-AS Telecom Carrier / ISP Plus + 3 - 62.204.228.0/234032 0.2% AS34040 -- CZTTNET-AS TTNET Czech Republic 4 - 62.204.230.0/234007 0.2% AS34040 -- CZTTNET-AS TTNET Czech Republic 5 - 89.4.128.0/24 3419 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 6 - 89.4.130.0/24 3367 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 7 - 89.4.131.0/24 3325 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 8 - 89.4.129.0/24 3264 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 9 - 89.4.158.0/24 2602 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 10 - 81.212.197.0/242580 0.2% AS9121 -- TTNET TTnet Autonomous System 11 - 81.213.47.0/24 2285 0.1% AS9121 -- TTNET TT
