http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/
<sigh>
Cheers,
-- jra
So everybody who's ever not bothered SWIP'ing an IPv4 allocation is helping the terrorists?
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.
R's,
John
PS: Why do you hate America?
I want some of that stupid for breakfast too. What brand is it?
That was my evaluation, yes.
Mr Curran: were you quoted accurately in this piece?
Cheers,
-- jra
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.
oops. typo. That last part should have been:
"then block sending IPs not within those specs"
another typo. I meant:
Certainly, 65,536 /64 blocks in a /48
allocation
Wouldn't BCP38 help?
/as
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.
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.
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
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
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
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
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.
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
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
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