Hello,
From our past experience this can be accomplished without issue as long as you have good log records and tracking in place. Ensure you have long-term retention for the logs to cover yourself.
Many ISP's are moving to this sort of environment simply due to the reasoning stated.
-Kevin
Hello,
From our past experience this can be accomplished without issue as long as you have good log records and tracking in place.
Do the complaints you receive include port numbers? Do you log the translation for every TCP connection and UDP exchange? I don't see how logs would work without that.
Ensure you have long-term retention for the logs to cover yourself.
I'd consult a lawyer on that -- are you required to have such logs? Per the above, I'm not convinced that it's technically feasible to keep such logs for an operation of any size, nor do I think that most complaints have the right information (to wit, port numbers) to use them if they do exist.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
I've never seen one that did. I've not even seen one with an exact timestamp.
You would require the src and dst ip *and* port, plus the near exact timestamp of when the connection was opened and closed. Even then, that's one needle in a huge pile of identical needles. The netflow/sflow/etc. data needed to support such a lookup for a modern ISP network would be absolutely insane. (a decade ago for a small, regional ISP/telco, just prefix records were over 700MB per day -- back in the days of 2mb DSL, before bittorrent...)
--Ricky
[...]
Do the complaints you receive include port numbers?
I've never seen one that did. I've not even seen one with an exact
timestamp.You would require the src and dst ip *and* port, plus the near exact
timestamp of when the connection was opened and closed. Even then, that's
one needle in a huge pile of identical needles. The netflow/sflow/etc.
data needed to support such a lookup for a modern ISP network would be
absolutely insane. (a decade ago for a small, regional ISP/telco, just
prefix records were over 700MB per day -- back in the days of 2mb DSL,
before bittorrent...)
Richard Clayton wrote some interesting articles on this earlier this year. There's a UK flavour to them but I expect the concepts are transferable.
http://www.lightbluetouchpaper.org/2010/01/12/extending-the-requirements-for-traceability/
http://www.lightbluetouchpaper.org/2010/01/13/practical-mobile-internet-access-traceability/
http://www.lightbluetouchpaper.org/2010/01/14/mobile-internet-access-data-retention-not/
Regards,
Leo
Rough translation: LSN + CALEA = Very Interesting Times for ISPs that deploy LSN and are subject to CALEA.
Owen
why wouldn't you just do the intercept before the LSN? (also, calea
and it's ilk knew this was coming, 'your failure to plan...' and all
that jazz)
That gets interesting too, when several tens of thousands of users may all be
behind the same LSN. Making sure you intercept only the right user's traffic
gets a lot more interesting in front of the LSN. Doing it behind the LSN means
you can snarf up just the traffic heading to/from one NAT'ed IP, which is
hopefully changing not all that often. Doing it in front of the LSN means you
need to decide whether to capture the data in real time on a per-flow basis
(consider the fun involved in catching a SYN packet outbound - what's your time
budget between when the miscreant's packet leaves his host and when you have to
catch it on the outbound side of the LSN)...
why wouldn't you just do the intercept before the LSN?
That gets interesting too, when several tens of thousands of users may all be
behind the same LSN. Making sure you intercept only the right user's traffic
gets a lot more interesting in front of the LSN. Doing it behind the LSN means
you can snarf up just the traffic heading to/from one NAT'ed IP, which is
hopefully changing not all that often. Doing it in front of the LSN means you
need to decide whether to capture the data in real time on a per-flow basis
(consider the fun involved in catching a SYN packet outbound - what's your time
budget between when the miscreant's packet leaves his host and when you have to
catch it on the outbound side of the LSN)...
innocent until proven guilty... plus probably a large portion of the
calea things aren't for a 'miscreant' anyway but for other reasons.
say, i wonder how many actual calea requests have been sent out
anyway?? (I know one very large network has yet to get a single one,
or so the grape vine tells me.)
CALEA is not a time machine. When an order is received, the "collection agency" starts receiving traffic; nothing (or at most, very little) is known prior to the wiretap order. Put another way, you cannot be ordered to produce tapes of phone call that happened a month ago. (CALEA only says you must have the ability to monitor anyone; not that you must be monitoring everyone to have "stuff" available before being asked for it.)
With CALEA, you're innocent until there's a reason to think otherwise. With the RIAA/MPAA/et.al., we're all guilty, all the time, so everything should be monitored until they get around to suing, err, extorting us.
--Ricky
CALEA is not a time machine. When an order is received, the
"collection
agency" starts receiving traffic; nothing (or at most, very little) is
known prior to the wiretap order. Put another way, you cannot be
ordered
to produce tapes of phone call that happened a month ago. (CALEA only
says
you must have the ability to monitor anyone; not that you must be
monitoring everyone to have "stuff" available before being asked for
it.)
Another point about CALEA is that you don't *have* to have infrastructure in place in advance of the order. You simply have to provide Law Enforcement the wiretaps they are asking for -- however you accomplish it. You don't need to solve for every case, just the case they ask of you at the time. This keeps the cost of compliance way down (provided you don't need these for a significant percentage of your user base).
Between e-discovery and RIAA issues, retention times are probably shrinking even though capacity for retention is growing.
Deepak Jain
AiNET
I see this asked a lot...
http://www.askcalea.net/reports/wiretap.html
[2009] http://www.askcalea.net/reports/docs/2009wiretap.pdf (warning: 314pg verbose report)
I see this asked a lot...
http://www.askcalea.net/reports/wiretap.html
[2009] http://www.askcalea.net/reports/docs/2009wiretap.pdf (warning:
314pg verbose report)
To save yourself the trouble (pg 8 of the slow 5MB download):
Telephone wiretaps accounted for 98 percent (1,720
cases) of the intercepts installed in 2009, the majority
of them involving cellular telephones.
I think it's safe to say CALEA is a non-issue for this crowd. It's also safe to say that RIAA is more of a nuisance than a real issue. Manage your retention times with e-discovery in mind and you don’t need to worry about RIAA issues either. 
Between e-discovery and RIAA issues, retention times are probably shrinking even though capacity for retention is growing.
Capacity for retention has grown but one still needs fast searching of
data, or a few LEA requests on the same day or week will overflow your
capacity to answer them. Disks are cheap, a good DW is not, for logs
you probably need something in the middle. Simple tar-gzipping will
get you crazy some day.
Rubens
That's true for now. But with an increasingly data hungry world, and VoIP popularity, ISPs aren't going to escape CALEA forever. There are reasons IOS has provisions for CALEA
(and for the record, CALEA is a non-issue for most telcos. the telco I used to work for has never had a wiretap order, and didn't start any CALEA mess until 2003.)
--Ricky