Adam,
Regarding tapping at the edge between my upstream provider and me, I'm of the understanding that I need to be able to capture all of my customer's data, even that which passes between one customer and another, or between my customer and my mail server, or my customer and one of my other customers' colocated servers, etc. From that standpoint, the way I have been looking at it is to mirror the packets as close to the core of my network as possible, but no later than the first juncture where my customer's traffic can be routed or bridged to another customer or server. Since almost all of our customers have dedicated VLANs which terminate on a core layer 3 switch, for most of them I can just SPAN the corresponding layer 3 switch port. Some of them share a VLAN with other customers, though, so I will need to mirror a layer 2 switchport closer to the edge of my network for those.
This definitely seems true, and I'm not certain how you even deal with traffic between two clients on the same AP other than not allow that scenario (without coming through a central router). There are many advantages to running a session-based approach to subscriber management; CALEA, I think, will just add another reason to take that approach.
Regarding putting in a tap, is that something you put inline on the fiber / copper cable? If so, I wonder if that could be considered a completely compliant solution, as I was under the impression that the packet capture is not supposed to be noticeable to the customer at all. A tiny blip of downtime while I'm putting in the tap could theoretically be noticed ....
Yes, they do go inline. Usually, they have one in and two outputs and have a failsafe mechanism where, if they lose power or otherwise fail, will still function. For inline taps, they would have to be setup from the get-go; this is best done in a maintenance window, in any case, since the ideal tapping point would have all of your customers traffic flowing through it, meaning that a tap insertion will momentarily cause a major disruption. Using port mirroring on a switch bypasses this, but isn't always an option.
I also have the impression (maybe wrongly) that we may need to be able to establish a VPN between the device capturing the traffic and the law enforcement agency, to pipe the data to them ....
Yes, this seems to be the case, although some places stated this as "preferred". This is the only aspect, however, that I've not been able to find specifics of. On the good side, I've not seen anything "official" in the sense that it is in the actual law or the spec, meaning, in a legal sense, it may not be a requirement.
I agree it's really tough to know how to comply when the data format standards are simply not clear. That's why I'm really interested to hear from anyone who says they have a compliant solution already, to know what standard they are using ....
Take a look at the opencalea project (opencalea.org). Their application, although crude, does the packet captures and dumps to the basic format that is specified. -- Clint Ricker Kentnis Technologies 800.783.5753
I agree with those of us who are hoping that an open-source solution will be developed (for *nix or Windows) ... ... and here's an interesting document I found linked to from the Mikrotik threads: http://contributions.atis.org/UPLOAD/PTSC/LAES/PTSC-LAES-2006-084R8.doc ... Adam ----- Original Message ----- From: "Ralph" <[EMAIL PROTECTED]> To: "'WISPA General List'" <[email protected]> Sent: Tuesday, March 27, 2007 6:22 PM Subject: 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=results&sid=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 that some room be given to those of us > who >> also want to speak about implementation. >> >> I'm still interested if anyone has any point of view about any of the >> compliance methods that I discussed in my original post, from a technical >> standpoint. >> >> Thanks, >> Adam >> >> >> ----- Original Message ----- >> From: "wispa" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]>; "WISPA General List" <[email protected]> >> Sent: Tuesday, March 27, 2007 1:16 PM >> Subject: Re: [WISPA] CALEA compliance methods >> >> >> > On Tue, 27 Mar 2007 08:21:53 -0400, Peter R. wrote >> >> Mark, >> >> >> >> CALEA IS LAW. There are interpretations of that law, but they have >> >> been upheld by courts. >> > >> > YOu're arguing against things I'm not saying. >> > >> >> >> >> CALEA is not the opinion of the DOJ or FCC. It is not far-reaching >> >> (like say the Patriot Act) or secret and possibly illegal like the >> >> NSA-AT&T wiretapping / surveillance. >> > >> > The whole idea that WE are covered under CALEA is just FCC opinion, > which >> > is >> > as changeable and variable as the wind. The ruling is capricious and >> > founded >> > on VAPOR, not substance. >> > >> > I just cannot believe you approve of unfunded federal mandates for > public >> > purposes. CALEA was not. Misapplying CALEA is. >> > >> > This is not OSHA mandates. This is not the same as requiring that a > tower >> > service company require their climbers to use a safety system. Not >> > even >> > close. If the federal government is justified with making us provide, > AT >> > OUR >> > EXPENSE, law enforcement services, then we're one little itty bitty >> > non- >> > existent step from from being mandated to do ANYTHING they happen to > wish >> > for, and the wish lists from the swamp on the Potomac are so large they >> > boggle the mind. >> > >> > And don't give me the "we play dead for regulatory favors in the >> > future" >> > crap. Nothing we do will buy us one MOMENT's worth of consideration, >> > in >> > EITHER direction. >> > >> > -------------------------------------------- >> > Mark Koskenmaki <> Neofast, Inc >> > Broadband for the Walla Walla Valley and Blue Mountains >> > 541-969-8200 >> > >> > -- >> > WISPA Wireless List: [email protected] >> > >> > Subscribe/Unsubscribe: >> > http://lists.wispa.org/mailman/listinfo/wireless >> > >> > Archives: http://lists.wispa.org/pipermail/wireless/ >> > >> > >> > >> > >> > >> >> >> >> >> >> -- >> WISPA Wireless List: [email protected] >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ >> >> -- >> WISPA Wireless List: [email protected] >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ >> > -- > WISPA Wireless List: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > -- > WISPA Wireless List: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > > > > > -- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
-- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
