Re: [WISPA] CALEA compliance methods- For Clint
Clint, Thanks for the great information, in this and your other posts. One of the Linux guys here downloaded the opencalea package and started testing it. It sure is nice seeing the information it generates. And activity is picking up on the mailing list. I feel a glimmer of hope ... Adam - Original Message - From: Clint Ricker [EMAIL PROTECTED] To: WISPA General List wireless@wispa.org Sent: Wednesday, March 28, 2007 12:01 AM Subject: Re: [WISPA] CALEA compliance methods- For Clint Ralph, My apologies for the confusion. I think we are more or less on the same page method-wise for gathering that information; I made some assumptions that may have been applicable to your network. Now, as far as the pretty red package and bow for transferring the information to a law enforcement agency (LEA), I'll take a stab at that, although, as I'm not a lawyer, my usefulness is limited. Still, having paid for and read through the spec, it's not all that complicated of a red package. I don't think that it's worth the $10,000+ commercial solutions are going for. However, I've not been able (yet) to track down the actual transmission to the LEA, other than it is over some sort of VPN, so I am missing that piece of the puzzle. But the format itself is seems fairly simple to implement and, indeed, is already at least somewhat implemented with opencalea. Good resources to look at: - OpenCALEA (http://www.opencalea.org/) OpenCALEA is an initiative to create an open source platform to comply with CALEA. The mailing list is a very good resource. The software is rough, but already covers the basic needs of most ISPS to a point except the actual handoff to the law enforcement agency (LEA) OpenCALEA Overview (PDF) (http://www.nanog.org/mtg-0702/presentations/karir.pdf) PDF overview of OpenCalea along with some conceptual network diagrams. Draft Specification (http://contributions.atis.org/UPLOAD/PTSC/LAES/PTSC-LAES-2006-084R8.doc) Reference specification for data portion of CALEA. Is functionally the same as the current (pay required) Baller Herbst Law Group CALEA Page (http://www.baller.com/calea.html) Great page with most of the important links. Look here for legal explanation, especially in the Plain Language Summary section. Cisco CALEA Webinar (http://www.opastco.org/docs/SP_CALEA_Webinar.ppt) CALEA Standards (http://www.askcalea.net/standards.html) Official list of standards CALEA interface. -- Notes from the above 1. The commercial packages are effectively devices that query a radius/authentication server and sniff on the network and then format the information to send to the law enforcement agency. No real magic. 2. OpenCALEA already has the basics of the system, although it doesn't seem to have any support (yet) for the authentication (AAA) portion. Future features will possibly include handoff to the LEA and more complex infrastructure for handling a wide, disparate network. 3. The only real requirements are 1. That the tap happens 2. The tap gathers both authentication/control information AND a complete capture of the session 3. That the output of 2 gets formatted according the the standard 4. That the information be transmitted to the LEA (seemingly through a VPN). 4. Based on 3, most of the equipment/solutions out there are heavily overengineered (see Cisco Webinar for an example). Most of the solutions are geared to a process that can be managed across carrier networks with subscribers into the millions. This is overkill for most WISPS :) On a given WISP of 1,000 subs, how often is a CALEA order actually going to happen? Infrequently enough that having to do some manual work each time is better than a high upfront cost (by manual work, I mean turning on a monitoring port/tap and manually initiating a VPN to the law enforcement agency as necessary). -- Clint Ricker Kentnis Technologies 800.783.5753 On 3/27/07, Ralph [EMAIL PROTECTED] wrote: Hello Clint. You are confusing me. When I mention MT, I said routers, not CPE. We don't use non type accepted CPE and therefore don't have MT in any form at the customer end. However our site routers and even the edge router ARE MT- even the edge router. Those are what I am talking about. I didn't say anything about putting any certain number of units in. And I really don't see how that would turn into hundreds of monitoring nodes. I'd just as soon only have to mess with it at one or two places. Our network is fed from two different points, but from the same provider. This provider told another WISP in the area (that he also upstreams) that he would not be able to do CALEA capture for us, but has now publicly said that he can. We'll have to see how that goes as it develops. If he will, then that makes him an even more valuable provider. Cisco's CALEA solution is at the router level. This seems to be the most logical place to do the tap- especially if the equipment/license/whatever is costly
RE: [WISPA] CALEA compliance methods- For Clint
Hello Clint. You are confusing me. When I mention MT, I said routers, not CPE. We don't use non type accepted CPE and therefore don't have MT in any form at the customer end. However our site routers and even the edge router ARE MT- even the edge router. Those are what I am talking about. I didn't say anything about putting any certain number of units in. And I really don't see how that would turn into hundreds of monitoring nodes. I'd just as soon only have to mess with it at one or two places. Our network is fed from two different points, but from the same provider. This provider told another WISP in the area (that he also upstreams) that he would not be able to do CALEA capture for us, but has now publicly said that he can. We'll have to see how that goes as it develops. If he will, then that makes him an even more valuable provider. Cisco's CALEA solution is at the router level. This seems to be the most logical place to do the tap- especially if the equipment/license/whatever is costly. The fewer costly licenses that need to be bought, the better it is for the small guy. We are very small (make that tiny). We all know that a decent switch can mirror a port. We also know how to sniff packets. What we don't know is how to package this data up with a nice pretty red bow the way Joe Law wants it. As far as I understand it, this is what Cisco is saying they will do (although I'm sure it will not be free). Imagestream is promising something as well. Those of us who don't use Cisco or Imagestream have to hope that our hardware provider will come up with a way, too. Aren't we really on the same page, here? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clint Ricker Sent: Tuesday, March 27, 2007 3:31 PM To: WISPA General List Subject: Re: [WISPA] CALEA compliance methods Just as a general rule, CALEA monitoring is not something that you need to--or want to--do at each individual CPE or router. Likewise, although assistance from manufacturors is nice, it is not requisite and in some ways may complicate matters since you can end up with hundreds of different monitoring nodes and several different interfaces unless you have complete uniformity across your network. Generally, the easiest and most cost effective approach is to place taps at key points in your network that give you access to traffic. If you backhaul all of your wireless traffic to a central points, a single tap at the central point can monitor all of the traffic from the wireless cells. The tapping process itself does not need to be expensive or complicated. Any decent switch (if it doesn't, you probably shouldn't be using it to begin with) has some sort of port mirroring built in that can easily function as a tap. If not, ethernet and fiber taps are fairly cheap ($100-$200 or so on the second hand market). The tap can be hooked into a server running tcpdump or similiar software or various commercially available. This provides complete compliance for a fairly reasonable cost. Having a tap on each wireless access point, etc...needlessly complicates the whole affair and increases cost drastically. If you are doing backhaul via an Internet T1 or similiar, the upstream carrier may be doing some of this for you. However, you do have to analyze carefully to ensure that you are compliant in this situation. Note that this actually is a good idea to have even without CALEA as you can get a good idea as to what traffic is actually running on your network and can better track down virus/hackers/other malicious traffic. - I have posted a couple of messages over on the Mikrotik forum over the last month or so. Mikrotik first basically said why should we care- we are in Latvia. After a little pressure from users, they began to ask for more information about the subject. I'm not at all knowledgeable enough to discuss the technical specs of the format, but I'm sure there are some folks around that are. Let's get MT users and prospective users rallied and do what we can to ebcourage MT to comply. It can only help us more and should also create a yardstick for other manufacturers. Here is a link to the threads http://forum.mikrotik.com/search.php?mode=resultssid=723d81c229563812d900d2 0b3a31a900 Ralph -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Greene Sent: Tuesday, March 27, 2007 1:08 PM To: WISPA General List Subject: Re: [WISPA] CALEA compliance methods Hi, While I appreciate Mark's comments and point of view, I for one would like to also start looking for ways to possibly comply with CALEA in a cost-effective way. I'm afraid that if the conversation here is limited to whether we should comply or not, we might lose the opportunity to share with each other about technical implementation. Don't get me wrong, I'm not suggesting that the conversation about whether to comply should be halted, just
Re: [WISPA] CALEA compliance methods- For Clint
Ralph, My apologies for the confusion. I think we are more or less on the same page method-wise for gathering that information; I made some assumptions that may have been applicable to your network. Now, as far as the pretty red package and bow for transferring the information to a law enforcement agency (LEA), I'll take a stab at that, although, as I'm not a lawyer, my usefulness is limited. Still, having paid for and read through the spec, it's not all that complicated of a red package. I don't think that it's worth the $10,000+ commercial solutions are going for. However, I've not been able (yet) to track down the actual transmission to the LEA, other than it is over some sort of VPN, so I am missing that piece of the puzzle. But the format itself is seems fairly simple to implement and, indeed, is already at least somewhat implemented with opencalea. Good resources to look at: - OpenCALEA (http://www.opencalea.org/) OpenCALEA is an initiative to create an open source platform to comply with CALEA. The mailing list is a very good resource. The software is rough, but already covers the basic needs of most ISPS to a point except the actual handoff to the law enforcement agency (LEA) OpenCALEA Overview (PDF) (http://www.nanog.org/mtg-0702/presentations/karir.pdf) PDF overview of OpenCalea along with some conceptual network diagrams. Draft Specification (http://contributions.atis.org/UPLOAD/PTSC/LAES/PTSC-LAES-2006-084R8.doc) Reference specification for data portion of CALEA. Is functionally the same as the current (pay required) Baller Herbst Law Group CALEA Page (http://www.baller.com/calea.html) Great page with most of the important links. Look here for legal explanation, especially in the Plain Language Summary section. Cisco CALEA Webinar (http://www.opastco.org/docs/SP_CALEA_Webinar.ppt) CALEA Standards (http://www.askcalea.net/standards.html) Official list of standards CALEA interface. -- Notes from the above 1. The commercial packages are effectively devices that query a radius/authentication server and sniff on the network and then format the information to send to the law enforcement agency. No real magic. 2. OpenCALEA already has the basics of the system, although it doesn't seem to have any support (yet) for the authentication (AAA) portion. Future features will possibly include handoff to the LEA and more complex infrastructure for handling a wide, disparate network. 3. The only real requirements are 1. That the tap happens 2. The tap gathers both authentication/control information AND a complete capture of the session 3. That the output of 2 gets formatted according the the standard 4. That the information be transmitted to the LEA (seemingly through a VPN). 4. Based on 3, most of the equipment/solutions out there are heavily overengineered (see Cisco Webinar for an example). Most of the solutions are geared to a process that can be managed across carrier networks with subscribers into the millions. This is overkill for most WISPS :) On a given WISP of 1,000 subs, how often is a CALEA order actually going to happen? Infrequently enough that having to do some manual work each time is better than a high upfront cost (by manual work, I mean turning on a monitoring port/tap and manually initiating a VPN to the law enforcement agency as necessary). -- Clint Ricker Kentnis Technologies 800.783.5753 On 3/27/07, Ralph [EMAIL PROTECTED] wrote: Hello Clint. You are confusing me. When I mention MT, I said routers, not CPE. We don't use non type accepted CPE and therefore don't have MT in any form at the customer end. However our site routers and even the edge router ARE MT- even the edge router. Those are what I am talking about. I didn't say anything about putting any certain number of units in. And I really don't see how that would turn into hundreds of monitoring nodes. I'd just as soon only have to mess with it at one or two places. Our network is fed from two different points, but from the same provider. This provider told another WISP in the area (that he also upstreams) that he would not be able to do CALEA capture for us, but has now publicly said that he can. We'll have to see how that goes as it develops. If he will, then that makes him an even more valuable provider. Cisco's CALEA solution is at the router level. This seems to be the most logical place to do the tap- especially if the equipment/license/whatever is costly. The fewer costly licenses that need to be bought, the better it is for the small guy. We are very small (make that tiny). We all know that a decent switch can mirror a port. We also know how to sniff packets. What we don't know is how to package this data up with a nice pretty red bow the way Joe Law wants it. As far as I understand it, this is what Cisco is saying they will do (although I'm sure it will not be free). Imagestream is promising something as well. Those of us who don't use Cisco or Imagestream have to
