Re: [v6ops] Google Alert - IPv6

[Dave O'Reilly <[e-mail]>]

Hi Erik,

Thanks for the mail. Some comments inline below.

daveor

> On 27 Oct 2017, at 15:21, Erik Nygren <[e-mail]> wrote:
> 
> On Fri, Oct 27, 2017 at 4:51 AM, Lee Howard <[e-mail]> wrote:
> >
> >One possible solution frequently cited to the problem of CGNAT is
> >migration to IPv6.However, does migration to IPv6 ACTUALLY solve the
> >problem of crime attribution due to large-scale address sharing?
> 
> Only if content providers deploy IPv6, including logging.
> 
> I'll note that that one of the major limitations for content providers deploying IPv6 
> (perhaps the #1 limitation?) has been making sure all systems that handle IP addresses
> can handle IPv6 addresses well.  This includes for logging, storing in databases,
> client reputation, ip-geo, bot detection, fraud management, authentication cookies, 
> parsing to partially pseudonymize (eg, stripping off bottom N bits), and the like.
> Plumbing "port" through many of these systems (even just logging and storage)
> is a non-trivial effort in many places (perhaps larger in some places than supporting
> IPv6 as now there is a {timestamp,IP,port) tuple that must be transported and stored
> rather than just an IP.

I totally agree. Two comments:

1. I have seen in some organisations that security guidance involves disabling IPv6.
2. I address this issue to a certain extent in my document in the section on “breaking existing tooling” and also in the deployment maturity model under the category of “Manageable” which is intended to cover the fact that downstream tooling will need to be built or adapted to support source ports. Admittedly, I had envisioned the problem in terms of breaking log processing due to changing log format but I recognise from your email that there are additional downstream consequences. I recently presented on this issue and I recommended that additional work needs to be done to measure/assess the downstream consequences of logging source port.

> 
> It would be much better if we can get onto a path where IPv6 can be relied on
> enough of the time to avoid having to make a large push on source port logging.
> A worst case would be if content providers had internal budget/resources to chose between
> one of "log source port" and "enable IPv6 and support logging IPv6", especially since
> some might decide to pick just the former and then might say "I went through a big
> project to log IPv4 source port, why should I also go through the effort to support IPv6?"
> despite the other good reasons to do so...
> 
> Note that reading the report, it seems like there are two issues:  the ability to attribute,
> and the risk of misattribution.  IPv6 may not always help to attribute (especially if some
> requests still come over IPv4), but it can help reduce the risk of misattribution (at least
> for those requests coming over IPv6).  The report almost seemed more concerned about
> the former than the latter.  Regardless, there is still the inherent risk that IP addresses 
> can be spoofed or be multi-tenant even absent CGNAT and thus there is danger in soley
> relying on addresses in logs.
> 

Very well put (attribution vs. misattribution). 

Also agree that there is always a risk outside the scope of this discussion relating to misattribution/inability to attribute. I mentioned this point in a previous email response that I just wrote.

daveor