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 ------Original Message------ From: Positively Optimistic To: nanog@nanog.org Subject: IPv4 Exhaustion... Sent: Jul 23, 2010 12:11 PM How do ISPs handle RIAA notices when NATTING customers.. ? We have several customers that don't require public address space that could be moved to private.. We're reluctant to make the move due to legal liabilities..
On Jul 23, 2010, at 1:36 18PM, khatfield@socllc.net wrote:
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
On Fri, 23 Jul 2010 13:59:41 -0400, Steven Bellovin <smb@cs.columbia.edu> wrote:
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...) --Ricky
On 23 Jul 2010, at 1:40, Ricky Beam wrote: [...]
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... http://www.lightbluetouchpaper.org/2010/01/13/practical-mobile-internet-acce... http://www.lightbluetouchpaper.org/2010/01/14/mobile-internet-access-data-re... Regards, Leo
On Jul 23, 2010, at 1:40 PM, Ricky Beam wrote:
On Fri, 23 Jul 2010 13:59:41 -0400, Steven Bellovin <smb@cs.columbia.edu> wrote:
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...)
--Ricky
Rough translation: LSN + CALEA = Very Interesting Times for ISPs that deploy LSN and are subject to CALEA. Owen
On Sat, Jul 24, 2010 at 4:48 AM, Owen DeLong <owen@delong.com> wrote:
Rough translation: LSN + CALEA = Very Interesting Times for ISPs that deploy LSN and are subject to CALEA.
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)
On Sat, 24 Jul 2010 15:40:58 EDT, Christopher Morrow said:
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)...
On Sat, Jul 24, 2010 at 4:28 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sat, 24 Jul 2010 15:40:58 EDT, Christopher Morrow said:
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.)
On Sat, 24 Jul 2010 16:36:08 -0400, Christopher Morrow <morrowc.lists@gmail.com> wrote:
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.)
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. :)
On Mon, 26 Jul 2010 17:09:55 -0400, Deepak Jain <deepak@ai.net> wrote:
I think it's safe to say CALEA is a non-issue for this crowd.
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
On Sat, 24 Jul 2010 04:48:13 -0400, Owen DeLong <owen@delong.com> wrote:
... Very Interesting Times for ISPs that deploy LSN and are subject to CALEA.
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
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
participants (9)
-
Christopher Morrow -
Deepak Jain -
khatfield＠socllc.net -
Leo Vegoda -
Owen DeLong -
Ricky Beam -
Rubens Kuhl -
Steven Bellovin -
Valdis.Kletnieks＠vt.edu