ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!

Mon Jun 18 01:34:31 UTC 2012

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 at 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 at 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 at 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
> 
> 