ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!
http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-... <sigh> Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said:
http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-...
So everybody who's ever not bothered SWIP'ing an IPv4 allocation is helping the terrorists?
On Fri, Jun 15, 2012 at 11:34 AM, John Levine <johnl@iecc.com> wrote:
So everybody who's ever not bothered SWIP'ing an IPv4 allocation is helping the terrorists?
Yes, of course. Mindless, irrational reactions to overblown threats are everyone's job.
I want some of that stupid for breakfast too. What brand is it? -- William McCall
----- Original Message -----
From: "valdis kletnieks" <valdis.kletnieks@vt.edu>
On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said:
http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-...
So everybody who's ever not bothered SWIP'ing an IPv4 allocation is helping the terrorists?
That was my evaluation, yes. Mr Curran: were you quoted accurately in this piece? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On 6/15/2012 11:59 AM, Jay Ashworth wrote:
http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-...
I don't know how much of this has been covered on NANOG, and I personally have a healthy innate distrust of government power grabs and intrusive government information grabs. However, having said that, as someone on the anti-spam front lines, I think that IPv6 may well be a tremendous gift to spammers if accepting mail from IPv6 becomes a free-for-all, as I understand it to be. First, it is NOT a problem to accept your own authenticated user's mail via their IPv6 connection to your server. Therefore, for the point I'm raising, consider that the millions of a large ISP's *own* customers can transition to sending their mail through that ISP's mail server vi IPv6 without any problems. (if problems arise, it would probably be more a problem with weak authentication?) But for all other mail, such as mail sent from valid mail servers to other valid mail servers... then the following two suggestions would go a long way: (1) simple don't accept IPv6 mail for the foreseeable future. (In this case, scarcity of IPv4 addresses is a FEATURE, not a bug.) (2) And/or limit (what would be considered) valid IPv6 mail servers to those assigned a particular IP on particularly large-sized block... then sending IP not within those specs. (3) MANY hosters who aren't deliberate spammers, but really don't care to police abusive customers much except when dragged kicking and screaming... and there are MANY such hosters... have a motivation to keep their IPv4 mail server addresses "clean". in an IPv6 world, I think they'll not care because they'll get these huge allocations where they'll figure that they have YEARS of IP blocks to burn through before recycling them. As it stands now, if they get too sloppy, then their next customer isn't happy when senderbase.org has their new IPs as already in the "poor" category. Again, THAT is a feature, not a bug. Moreover, as I said, scarcity of IPs, with regards to mail servers, is a feature... not a bug. If these suggestions are not followed/heeded, MANY reading this right now will look back a decade from now and say, "wouldn't it have been great if we could have somehow created a situation where valid mail server IPs for IPv6 could have been more scarce and not a free-for-all?" In the "free for all" world, a spammer could send thousands or even millions of spams, each from a different IPv6 address... with each IP indexed back to the sender (to aid in "listwashing" of recipient addresses that triggered blacklistings), and not use a single IP twice. Furthermore, even if the IPs are blacklisted at the /64 level, as I understand it, some of the allocations happening are so generous, this statement could still be somewhat true where the spammer send each spam from a separate /64 block? Certainly, 65,536 /64 blocks in a /24 allocation is a hell of a lot more /64 blocks to burn through than the 256 IPs in an IPv4 /24 allocation!!! Again, keep in mind that the massive expansion of sending IP from a customer that is routed via to their own ISP's mail server, hopefully using authentication, is unaffected by this suggestion. So your future refrigerator and oven can STILL send you an e-mail from its IPv6 ip address. -- Rob McEwen http://dnsbl.invaluement.com/ rob@invaluement.com +1 (478) 475-9032
On 6/15/2012 4:30 PM, Rob McEwen wrote:
And/or limit (what would be considered) valid IPv6 mail servers to those assigned a particular IP on particularly large-sized block... then sending IP not within those specs.
oops. typo. That last part should have been: "then block sending IPs not within those specs" -- Rob McEwen http://dnsbl.invaluement.com/ rob@invaluement.com +1 (478) 475-9032
On 6/15/2012 4:30 PM, Rob McEwen wrote:
Certainly, 65,536 /64 blocks in a /24 allocation
another typo. I meant: Certainly, 65,536 /64 blocks in a /48 allocation -- Rob McEwen http://dnsbl.invaluement.com/ rob@invaluement.com +1 (478) 475-9032
Wouldn't BCP38 help? /as On 15 Jun 2012, at 11:59, Jay Ashworth wrote:
http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-...
<sigh>
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said:
Wouldn't BCP38 help?
The mail I'm replying to has as the first Received: line: Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT) Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote that literally last century. ;) So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to? *THAT* is the problem that needs solving. (And who *does* own that IP? I admit not knowing. ;)
On 6/17/12 10:24 , valdis.kletnieks@vt.edu wrote:
On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said:
Wouldn't BCP38 help?
The mail I'm replying to has as the first Received: line:
Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT)
Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote that literally last century. ;)
So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to?
so first of you introduced a typo 2800:af:ba30:e8cf:4881:973a:c68 2800:af:ba30:e8cf:d06f:4881:973a:c68 which like the wrong address in a search warrant can be a problem. jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:4881:973a:c68 ^ invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at '2800:af:ba30:e8cf:4881:973a:c68' jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:d06f:4881:973a:c68 inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 hidden) + = Active Route, - = Last Active, * = Both 2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from 2620:102:8004::10 AS path: 7922 12956 6057 I XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net 2800:af:ba30:e8cf:d06f:4881:973a:c68 inetnum: 2800:a0::/28 status: allocated aut-num: N/A owner: Administracion Nacional de Telecomunicaciones ownerid: UY-ANTA-LACNIC responsible: ANTELDATA ANTEL URUGUAY address: Treinta y Tres, 1418, P.3 address: 11000 - Montevideo - country: UY phone: +598 2 9028819 [] owner-c: ANU tech-c: ANU abuse-c: ANU inetrev: 2800:a0::/28 nserver: NS1.ANTELV6.NET.UY nsstat: 20120615 AA nslastaa: 20120615 created: 20070115 changed: 20070115 nic-hdl: ANU person: ANTELDATA ANTEL URUGUAY e-mail: ipadmin@ANTEL.NET.UY address: Mercedes, 876, P. 2 address: 11100 - Montevideo - country: UY phone: +598 2 9002877 [] created: 20020910 changed: 20111014 scopes it to not being a problem you can solve with policy in the arin region.
*THAT* is the problem that needs solving.
(And who *does* own that IP? I admit not knowing. ;)
was trivial enough to find the origin, I have nothing to indicate that any of that information is wrong.
On Sun, 17 Jun 2012 10:53:52 -0700, Joel jaeggli said:
On 6/17/12 10:24 , valdis.kletnieks@vt.edu wrote:
So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to?
so first of you introduced a typo
Aha. Somebody's paying attention :) That's exactly the sort of thing you'll end up seeing a lot more of if you have to start chasing through 2 and 3 hops of provider-customer-subcustomer. It's easy to notice that an IPv4 address is missing an octet - a lot harder to tell you have 7 chunks rather than 8, plus you're left wondering whether you dropped 16 bits, or if one of the : should be a :: instead. But Joel - you *really* need to get out more. ;)
On 6/17/12 13:22 , valdis.kletnieks@vt.edu wrote:
On Sun, 17 Jun 2012 10:53:52 -0700, Joel jaeggli said:
On 6/17/12 10:24 , valdis.kletnieks@vt.edu wrote:
So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to?
so first of you introduced a typo
Aha. Somebody's paying attention :) That's exactly the sort of thing you'll end up seeing a lot more of if you have to start chasing through 2 and 3 hops of provider-customer-subcustomer.
Yes, in a previous $job I have been served court authorized requests that are incorrect. I have provided helpful advice.
It's easy to notice that an IPv4 address is missing an octet - a lot harder to tell you have 7 chunks rather than 8, plus you're left wondering whether you dropped 16 bits, or if one of the : should be a :: instead.
If one enters the wrong number the right answer will rarely be forthcoming.
But Joel - you *really* need to get out more. ;)
yes
On Jun 17, 2012, at 10:53 AM, Joel jaeggli wrote:
On 6/17/12 10:24 , valdis.kletnieks@vt.edu wrote:
On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said:
Wouldn't BCP38 help?
The mail I'm replying to has as the first Received: line:
Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT)
Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote that literally last century. ;)
So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to?
so first of you introduced a typo
2800:af:ba30:e8cf:4881:973a:c68
2800:af:ba30:e8cf:d06f:4881:973a:c68
which like the wrong address in a search warrant can be a problem.
jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:4881:973a:c68 ^ invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at '2800:af:ba30:e8cf:4881:973a:c68'
jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:d06f:4881:973a:c68
inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 hidden) + = Active Route, - = Last Active, * = Both
2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from 2620:102:8004::10 AS path: 7922 12956 6057 I
XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net 2800:af:ba30:e8cf:d06f:4881:973a:c68
scopes it to not being a problem you can solve with policy in the arin region.
Lather rinse repeat with a better choice of address... 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 This is in the ARIN region... It's from within a particular ISP's /32. Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois. Same for 2001:550:10:20:62a3:3eff:fe19:2909 I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence. Owen
Hello everyone, Yes the FBI can't just rely on Whois for apart of their investigation. yes I will agree it's a big part but also those records are spoofed alot. But reverse Ip looks I can understand. James Smith CEO, CEH SmithwaySecurity Toronto, Canada On 12-06-17 08:29 PM, Owen DeLong wrote:
On Jun 17, 2012, at 10:53 AM, Joel jaeggli wrote:
On 6/17/12 10:24 , valdis.kletnieks@vt.edu wrote:
On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said:
Wouldn't BCP38 help? The mail I'm replying to has as the first Received: line:
Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT)
Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote that literally last century. ;)
So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to? so first of you introduced a typo
2800:af:ba30:e8cf:4881:973a:c68
2800:af:ba30:e8cf:d06f:4881:973a:c68
which like the wrong address in a search warrant can be a problem.
jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:4881:973a:c68 ^ invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at '2800:af:ba30:e8cf:4881:973a:c68'
jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:d06f:4881:973a:c68
inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 hidden) + = Active Route, - = Last Active, * = Both
2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from 2620:102:8004::10 AS path: 7922 12956 6057 I
XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net 2800:af:ba30:e8cf:d06f:4881:973a:c68
scopes it to not being a problem you can solve with policy in the arin region. Lather rinse repeat with a better choice of address...
2001:550:3ee3:f329:102a3:2aff:fe23:1f69
This is in the ARIN region...
It's from within a particular ISP's /32.
Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois.
Same for 2001:550:10:20:62a3:3eff:fe19:2909
I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence.
Owen
On 6/17/12 16:29 , Owen DeLong wrote:
On Jun 17, 2012, at 10:53 AM, Joel jaeggli wrote:
On 6/17/12 10:24 , valdis.kletnieks@vt.edu wrote:
On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said:
Wouldn't BCP38 help?
The mail I'm replying to has as the first Received: line:
Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT)
Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote that literally last century. ;)
So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to?
so first of you introduced a typo
2800:af:ba30:e8cf:4881:973a:c68
2800:af:ba30:e8cf:d06f:4881:973a:c68
which like the wrong address in a search warrant can be a problem.
jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:4881:973a:c68 ^ invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at '2800:af:ba30:e8cf:4881:973a:c68'
jjaeggli@cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:d06f:4881:973a:c68
inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 hidden) + = Active Route, - = Last Active, * = Both
2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from 2620:102:8004::10 AS path: 7922 12956 6057 I
XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net 2800:af:ba30:e8cf:d06f:4881:973a:c68
scopes it to not being a problem you can solve with policy in the arin region.
Lather rinse repeat with a better choice of address...
2001:550:3ee3:f329:102a3:2aff:fe23:1f69
This is in the ARIN region...
Actually it's not a valid address at all, because it also has a typo. one might assume with a typo that the most significant bits are probably correct but potentially compounding errors doesn't sound like a good idea.
It's from within a particular ISP's /32.
Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois.
Same for 2001:550:10:20:62a3:3eff:fe19:2909
I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence.
If you're asserting that cogent is not swiping their delegations then do so. they have certain obligations as an LIR under the policy under which resources were delegated to them. future prefix assignments will clearly require that the demonstrate utilization much as they are required to in ipv4.
Owen
Lather rinse repeat with a better choice of address...
2001:550:3ee3:f329:102a3:2aff:fe23:1f69
This is in the ARIN region...
Actually it's not a valid address at all, because it also has a typo. one might assume with a typo that the most significant bits are probably correct but potentially compounding errors doesn't sound like a good idea.
Yes... Should have been 2001:550:3ee3:f329:02a3:2aff:fe23:1f69. Not sure how the extra 1 got in there.
It's from within a particular ISP's /32.
Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois.
Same for 2001:550:10:20:62a3:3eff:fe19:2909
I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence.
If you're asserting that cogent is not swiping their delegations then do so. they have certain obligations as an LIR under the policy under which resources were delegated to them. future prefix assignments will clearly require that the demonstrate utilization much as they are required to in ipv4.
I'm making no assertion about cogent whatsoever. Since I don't know whether those addresses I chose at random within the ARIN region happen to be delegated or not, I have no ability to determine whether they should be registered as delegated or not. I said this in the above paragraph you quoted. I was attempting to demonstrate the potential problem, not point to an extant example as I do not have an extant example handy, though I suspect such do actually exist. Owen
On 6/17/12, Joel jaeggli <joelja@bogus.com> wrote: [snip]
resources were delegated to them. future prefix assignments will clearly require that the demonstrate utilization much as they are required to in ipv4.
Sure. But they don't necessarily have to have WHOIS listings up to date in order to successfully demonstrate utilization; it is possible they provide private documentation or utilize the spreadsheet method of demonstrating utilization, without publishing details in WHOIS, and indicate they themselves serve as contact. The IP address WHOIS database is a system for identifying valid network contacts to report connectivity and operational issues to, and the contact listed in WHOIS for a network does not necessarily have to be an organization capable of identifying an individual user or customer. WHOIS is not a system for tracing IP addresses down to an individual user level, not with IPv6, not with IPv4.
Owen -- -JH
On 6/17/2012 10:22 PM, Jimmy Hess wrote:
On 6/17/12, Joel jaeggli <joelja@bogus.com> wrote: [snip]
resources were delegated to them. future prefix assignments will clearly require that the demonstrate utilization much as they are required to in ipv4.
Sure. But they don't necessarily have to have WHOIS listings up to date in order to successfully demonstrate utilization; it is possible they provide private documentation or utilize the spreadsheet method of demonstrating utilization, without publishing details in WHOIS, and indicate they themselves serve as contact.
The IP address WHOIS database is a system for identifying valid network contacts to report connectivity and operational issues to, and the contact listed in WHOIS for a network does not necessarily have to be an organization capable of identifying an individual user or customer.
WHOIS is not a system for tracing IP addresses down to an individual user level, not with IPv6, not with IPv4. Thanks for clearly stating this, Jimmy. This is largely my point with WHOIS as well, although I may not have expressed it clearly.
Along the same lines, WHOIS is not Geolocation (as poorly as that technology works, frequently because it's partly or mostly built on WHOIS data to begin with). The registered place of business an assignment points to, which may be completely accurate for valid network contacts at a company headquarters, doesn't dictate satellite offices are at the same address, city, state or country which may make up 90% of the use of the entire allocation... just as one example. This is abundant in enterprises. -Vinny
On Jun 17, 2012 7:46 PM, "Vinny Abello" <vinny@abellohome.net> wrote:
On 6/17/2012 10:22 PM, Jimmy Hess wrote:
On 6/17/12, Joel jaeggli <joelja@bogus.com> wrote: [snip]
resources were delegated to them. future prefix assignments will clearly require that the demonstrate utilization much as they are required to in ipv4.
Sure. But they don't necessarily have to have WHOIS listings up to date in order to successfully demonstrate utilization; it is possible they provide private documentation or utilize the spreadsheet method of demonstrating utilization, without publishing details in WHOIS, and indicate they themselves serve as contact.
The IP address WHOIS database is a system for identifying valid network contacts to report connectivity and operational issues to, and the contact listed in WHOIS for a network does not necessarily have to be an organization capable of identifying an individual user or customer.
WHOIS is not a system for tracing IP addresses down to an individual user level, not with IPv6, not with IPv4. Thanks for clearly stating this, Jimmy. This is largely my point with WHOIS as well, although I may not have expressed it clearly.
Along the same lines, WHOIS is not Geolocation (as poorly as that technology works, frequently because it's partly or mostly built on WHOIS data to begin with). The registered place of business an assignment points to, which may be completely accurate for valid network contacts at a company headquarters, doesn't dictate satellite offices are at the same address, city, state or country which may make up 90% of the use of the entire allocation... just as one example. This is abundant in enterprises.
-Vinny
+1 to Jimmy and Vinny, and going back to the OP. .. This is why the article is poorly formed. Whois evolution and practices are NOT a speedbump for ipv6 deployment. Traceroute is likely more informative than whois. ...or looking at a bgp as path... For both ipv4 and ipv6 You think whois traceability is a problem in ipv6? It is nothing compared to ipv4 CGN traceability challenges.... Which the article also mentions. CB
On 17 Jun 2012, at 20:29, Owen DeLong wrote:
Lather rinse repeat with a better choice of address...
2001:550:3ee3:f329:102a3:2aff:fe23:1f69
This is in the ARIN region...
It's from within a particular ISP's /32.
Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois.
Same for 2001:550:10:20:62a3:3eff:fe19:2909
I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence.
Owen
Not being in the whois is not an indicator that the ISP (to whom the address block has been delegated) does not know about which customer has an IP (v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish delegations in the whois but have a huge excel worksheets where they record every suballocation. You just need a warrant to see that info. Ergo, the FBI, interpol or you name it should not have problem to get them. /as
On Jun 18, 2012, at 4:50 AM, Arturo Servin wrote:
On 17 Jun 2012, at 20:29, Owen DeLong wrote:
Lather rinse repeat with a better choice of address...
2001:550:3ee3:f329:102a3:2aff:fe23:1f69
This is in the ARIN region...
It's from within a particular ISP's /32.
Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois.
Same for 2001:550:10:20:62a3:3eff:fe19:2909
I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence.
Owen
Not being in the whois is not an indicator that the ISP (to whom the address block has been delegated) does not know about which customer has an IP (v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish delegations in the whois but have a huge excel worksheets where they record every suballocation.
You just need a warrant to see that info. Ergo, the FBI, interpol or you name it should not have problem to get them.
/as
Right... However... 1. That's a violation of resource policy. 2. It's an extra step and multi-day delay in a situation where time may be of the essence. Further, we're not talking about the recording of every end-user assignment so much as the fact that in some cases, large delegations to down-stream ISPs are not recorded in whois. My understanding from talking to the FBI/DEA people is that they want to be able to serve the correct ISP on the first try rather than iterating through multiple layers of delegations. That does not seem an unreasonable expectation. Owen
On 18 Jun 2012, at 09:48, Owen DeLong wrote:
On Jun 18, 2012, at 4:50 AM, Arturo Servin wrote:
On 17 Jun 2012, at 20:29, Owen DeLong wrote:
Lather rinse repeat with a better choice of address...
2001:550:3ee3:f329:102a3:2aff:fe23:1f69
This is in the ARIN region...
It's from within a particular ISP's /32.
Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois.
Same for 2001:550:10:20:62a3:3eff:fe19:2909
I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence.
Owen
Not being in the whois is not an indicator that the ISP (to whom the address block has been delegated) does not know about which customer has an IP (v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish delegations in the whois but have a huge excel worksheets where they record every suballocation.
You just need a warrant to see that info. Ergo, the FBI, interpol or you name it should not have problem to get them.
/as
Right...
However...
1. That's a violation of resource policy. 2. It's an extra step and multi-day delay in a situation where time may be of the essence.
Further, we're not talking about the recording of every end-user assignment so much as the fact that in some cases, large delegations to down-stream ISPs are not recorded in whois. My understanding from talking to the FBI/DEA people is that they want to be able to serve the correct ISP on the first try rather than iterating through multiple layers of delegations.
That does not seem an unreasonable expectation.
Owen
Not at all an unreasonable expectation. And that's the way it should be IMO. My point is that v6 is not very different than IPv4 in that respect. /as
You would go to the whois: whois -h whois.lacnic.net 2800:af::/32 You will find that it is assigned to ISP "Whatever". If you are the cops you will find who I am asking them. BCP 38 would work. The problem is that many ISPs do not ingress filter, so I can use whatever unnallocated IPv6 space (2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and use another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68) Regards, as On 17 Jun 2012, at 13:24, Valdis.Kletnieks@vt.edu wrote:
On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said:
Wouldn't BCP38 help?
The mail I'm replying to has as the first Received: line:
Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT)
Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote that literally last century. ;)
So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to?
*THAT* is the problem that needs solving.
(And who *does* own that IP? I admit not knowing. ;)
BCP 38 would work. The problem is that many ISPs do not ingress filter, so I can use whatever unnallocated IPv6 space (2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and use another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68)
How do you plan to get the return packets? DNS bombing with forged address UDP packets is one thing, but anything that runs over TCP won't work without return routes. If the bad guy can inject routes, you have worse problems than lack of SWIP. (This assumes the target is not using a 20 year old TCP stack with predictable sequence numbers, but in the IPv6 world we should be able to assume that particular security hole is closed.) I expect bad guys to hop around within a /64 or whatever size allocation the ISP assigns to customers, but that's still easily handled by SWIP, or by subpoena to the ISP if they didn't get around to SWIP. R's, John
If the ISP fails to filter my bogus space and leak that route to the Internet (which happens today everyday with IPv4, and will with IPv6) I would get my return path. Again, if every ISP followed BCP 38 that would not happen (IPv6 and IPv4). But they are not, and probably they won't. .as On 17 Jun 2012, at 15:41, John Levine wrote:
BCP 38 would work. The problem is that many ISPs do not ingress filter, so I can use whatever unnallocated IPv6 space (2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and use another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68)
How do you plan to get the return packets? DNS bombing with forged address UDP packets is one thing, but anything that runs over TCP won't work without return routes. If the bad guy can inject routes, you have worse problems than lack of SWIP.
(This assumes the target is not using a 20 year old TCP stack with predictable sequence numbers, but in the IPv6 world we should be able to assume that particular security hole is closed.)
I expect bad guys to hop around within a /64 or whatever size allocation the ISP assigns to customers, but that's still easily handled by SWIP, or by subpoena to the ISP if they didn't get around to SWIP.
R's, John
----- Original Message -----
From: "Arturo Servin" <arturo.servin@gmail.com>
Again, if every ISP followed BCP 38 that would not happen (IPv6 and IPv4). But they are not, and probably they won't.
I disagree with Arturo's assertion that BCP38 would help the "people don't SWIP their subdelegations" problem, but that doesn't mean it wouldn't help on lots of other points. The vector sum of the responses I (didn't) get when I asked about this last Friday, though, was somewhere between crickets and giggles. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-...
<sigh>
Cheers, -- jra I fail to see the problem the media and FBI are worried about. If the regional registries are accurately documenting who they are allocating assignments to, the authorities have somewhere to start. Even if everything is properly documented via SWIP or WHOIS, the FBI requests far more information in a subpena from ISP's than is provided by those tools and I don't think they generally really even rely on them to be accurate. They go straight to the ISP from what I've seen. They don't want the criminal to know the FBI is on to them and won't first go
On 6/15/2012 11:59 AM, Jay Ashworth wrote: direct to the end user. A /64, /56 or even /48 will be one customer, so regardless if a criminal keeps changing IP's inside those blocks, it still points to that customer which the ISP can provide to the FBI. Where is the issue? I don't see how this is that hard to track down. What's the difference with an ISP that didn't SWIP an IPv4 /29 allocation to a company with all RFC1918 space behind the address. <sarcasm> How oh how will they ever find the criminal within all of that IPv4 address space behind the ISP assigned /29 without someone documenting the RFC1918 space in the customer's network??!?! </sarcasm> If anything, I feel like this is a ploy by the FBI feeding the media to get criminals to adopt IPv6 thinking they're harder to track and drop their guard so they'll be easier to catch. -Vinny
On Jun 17, 2012, at 4:01 PM, Vinny Abello wrote:
I fail to see the problem the media and FBI are worried about. If the regional registries are accurately documenting who they are allocating assignments to, the authorities have somewhere to start. Even if everything is properly documented via SWIP or WHOIS, the FBI requests far more information in a subpena from ISP's than is provided by those tools and I don't think they generally really even rely on them to be accurate.
Indeed, there are subpoenas which request a lot more information, (particularly if you are in a lengthy investigation.) However, if they are trying to figure out where a missing kid or person in danger person might be located based on email headers, then time can be of the essence and being able to follow the subassignments (that are already supposed to be in Whois) can make the difference. I would not say they rely on Whois to be accurate, but they certainly take its contents into consideration in some situations along with all the other various data points they may have.
They go straight to the ISP from what I've seen. They don't want the criminal to know the FBI is on to them and won't first go direct to the end user.
Depends on circumstance. If you're talking about investigations of front companies for various nefarious commercial activities, then that is indeed the case, but that is not the only type of law enforcement activity.
A /64, /56 or even /48 will be one customer, so regardless if a criminal keeps changing IP's inside those blocks, it still points to that customer which the ISP can provide to the FBI.
If the ISP has a lawful response desk which is available at 3 PM on a Sunday afternoon or holiday weekend, then going to the ISP would indeed be equivalent. Also, this presumes that the ISP in question isn't serving a smaller ISP or hosting firm which would then also need to be queried to find the actual customer.
Where is the issue? I don't see how this is that hard to track down. What's the difference with an ISP that didn't SWIP an IPv4 /29 allocation to a company with all RFC1918 space behind the address. <sarcasm> How oh how will they ever find the criminal within all of that IPv4 address space behind the ISP assigned /29 without someone documenting the RFC1918 space in the customer's network??!?! </sarcasm>
There is no difference. The question is whether the ISP who had to SWIP the /29 under IPv4 as part of showing utilization to get their next block will bother to record subdelegations under IPv6 when they don't need to come back for _a long time_...
If anything, I feel like this is a ploy by the FBI feeding the media to get criminals to adopt IPv6 thinking they're harder to track and drop their guard so they'll be easier to catch.
No, it's a real concern that law enforcement has with the current incentives for keeping the Whois up to date, and what happens with IPv6. Feel free to come to an ARIN meeting and chat with the folks from US, Canada, and various Caribbean governments about their issue. By the way, it is not that there is _no_ incentive... Any _large_ ISP ends up having to provide lawful response duties (often the same team that handles spam/abuse/copyright issues) and that means staff. For networks that put subdelegations into Whois reliably, there are less requests for routine information (ergo less staff & less co$t needed to respond.) Not many ISPs are the size where such inquires are routine enough for having a dedicated team, but those who do generally realize the pleasant side effect of keeping Whois up-to-date. This isn't really seen by ISPs who only get the occasional LEA request, so it's not a meaningful incentive on its own for many service providers. FYI, /John John Curran President and CEO ARIN
Hey John, Thanks for taking the time for the detailed response. I always enjoy reading your posts. On 6/17/2012 7:16 PM, John Curran wrote:
On Jun 17, 2012, at 4:01 PM, Vinny Abello wrote:
If anything, I feel like this is a ploy by the FBI feeding the media to get criminals to adopt IPv6 thinking they're harder to track and drop their guard so they'll be easier to catch.
No, it's a real concern that law enforcement has with the current incentives for keeping the Whois up to date, and what happens with IPv6. Feel free to come to an ARIN meeting and chat with the folks from US, Canada, and various Caribbean governments about their issue.
It would seem to me if the if law enforcement is concerned about incentives to make networks do this, then it should be made a law within their operating jurisdiction to enforce this compliance. Failure to comply would have legal and possibly financial consequences in the form of fines or other penalties. We have many more obtuse laws about us (at least in the US that I'm familiar with) that this doesn't seem infeasible or impractical of a goal that will benefit the majority of people via law enforcement's ability to protect and serve. Hoping for a technical solution or self governing "document IPv6 allocations just because we're supposed to, even though there is no consequence either way" won't result in any action. Incentives are also not equally received among 100% of the population. Not everyone likes cookies. :)
By the way, it is not that there is _no_ incentive... Any _large_ ISP ends up having to provide lawful response duties (often the same team that handles spam/abuse/copyright issues) and that means staff. For networks that put subdelegations into Whois reliably, there are less requests for routine information (ergo less staff & less co$t needed to respond.) Not many ISPs are the size where such inquires are routine enough for having a dedicated team, but those who do generally realize the pleasant side effect of keeping Whois up-to-date. This isn't really seen by ISPs who only get the occasional LEA request, so it's not a meaningful incentive on its own for many service providers.
That right there is the problem. The Internet isn't just large ISP's (thank God). You're never going to get an incentive that appeals equally across all types of businesses to comply. Some just don't have the resources like you stated, to even document the allocations despite being required to. If a company were to downsize and looked at someone's job who SWIP'ed allocations or maintained WHOIS, the question would be asked of what would happen if they stopped. In IPv6 land for the small to medium ISP, the answer would be nothing as is illustrated by this article. They would be let go by upper management that didn't know any better, and the company would stop documenting even if they initially did the right thing. Even if ARIN refunded 100% of the fees to networks who properly documented everything and only charged those who were not in compliance, you'd still find people not documenting because it costs less to pay the fee than pay someone to manage that. Incentives are not the solution. Congress should consider passing a law in the US if this of that much concern. I'm unfamiliar with other jurisdiction's law processes covered within the ARIN region, but from the US standpoint, that's the only way I see something actually happening. Technical problems are frequently solved best by technical solutions; legal problems by legal solutions. This is a law enforcement problem and I feel it should be properly solved by a legal solution, but I'm sure someone will be glad to oppose my stated opinion with their own. :) I'm also sure a die hard technical advocate of some technology who is much smarter than myself will illustrate just how technology can solve the problem, so please prove me wrong so we don't need to rely on more government "solutions". I beg of you! :) -Vinny
participants (13)
-
Arturo Servin -
Cameron Byrne -
James -
Jay Ashworth -
Jimmy Hess -
Joel jaeggli -
John Curran -
John Levine -
Owen DeLong -
Rob McEwen -
valdis.kletnieks＠vt.edu -
Vinny Abello -
William McCall