Subject: Re: [v6ops] Google Alert - IPv6

From: Fred Baker <[email-masked]>
Date: Wed, 18 Oct 2017 14:22:20 -0700

So, this may be a dumb question. IPv6 advocates will reflexively agree with comments on “CGNAT is a bad idea”. But as operators who very likely have some combination of IPv6 and CGNAT, do we have thoughtful experience-based comments on this topic?

> On Oct 18, 2017, at 2:01 PM, Google Alerts <[email-masked]> wrote:
> 
> 
>  	
> IPv6
> Daily update ⋅ October 18, 2017
> NEWS	
> Europol wants ISPs to aid law enforcement by dropping CGN technologies
> Help Net Security
> CGN was meant to be a temporary workaround for the problem arising from the slow transition from IPv4 to IPv6. But, according to Europol, for some ...
> Europol cops lean on phone networks, ISPs to dump CGNAT walls that 'hide' cyber-crooks - The Register
> CGN has created an "online capability gap" between cyber criminals and law enforcement, says ... - www.v3.co.uk
> Full Coverage
>   	  	  	Flag as irrelevant  
> Europol Calls on Internet Providers to End CGNAT IP Address Sharing
> ISPreview.co.uk (blog)
> However the shift from the old IPv4 (ran out of spare addresses) to newer IPv6 addressing system has caused some providers, which don't have a ...
>   	  	  	Flag as irrelevant  
> 
>

---

From: Paul Marks <[email-masked]>
Date: Wed, 18 Oct 2017 15:00:22 -0700

On Wed, Oct 18, 2017 at 2:22 PM, Fred Baker <[email-masked]> wrote:
> So, this may be a dumb question. IPv6 advocates will reflexively agree with
> comments on “CGNAT is a bad idea”. But as operators who very likely have
> some combination of IPv6 and CGNAT, do we have thoughtful experience-based
> comments on this topic?

CGNAT is unavoidable, until IPv4 is turned off completely.  There are
more humans than IPv4 addresses, so somebody needs to share.

Deploying CGNAT without deploying IPv6 first is a bad idea.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 19 Oct 2017 00:30:23 +0200

Fully agree and in fact this was the basis of my discussion with Europol last week.

We had a complete day workshop on this topic, plus many documents exchange in preparation for that.

After my presentation and all day long discussions, it was clear that the path is deploying IPv6 + voluntary code of conduct among ISPs + legislation.

I also showed that there are ways and ways to deploy IPv6, in terms of different transition mechanism.

Then as promoting (again) IPv6 deployment was decided as the first step from the EC and member states, I indicated that we need to provide example in our own institutions, so I asked (I knew the answer in advance) to raise the hand to all the member states that have already their institutions (police in this case), already IPv6 enabled … surprise surprise … none was ready.
 
So, I asked if we can agree in a short-term plan for all them to “at least” have public plan announced in the next 6 months. So that’s what I will be working now with them.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Paul Marks <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 19 de octubre de 2017, 0:01
Para: Fred Baker <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] Google Alert - IPv6

    
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Oct 2017 13:55:24 +1300

I would like to remind people that this WG already addressed the issue
a while back: https://tools.ietf.org/html/rfc6264

Of course the ecosystem has evolved since then. In particular, 464XLAT
was not an option, but I hope the basic idea is still valid.

Regards
   Brian

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 19 Oct 2017 01:33:58 +0000

Ditto, though I wish 6264 pointed out stateless techniques as well (under the broader umbrella).

Also, a bit of hair splitting below  -

IPv4 address sharing is unavoidable, but CGNAT is avoidable (thanks to MAP-T/E etc. employing Stateless Means) in many scenarios.

Charter communications is marching ahead with MAP-T deployments (no CGN), as per the recent NANOG presentation.

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

On Oct 18, 2017, at 8:55 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

Regards
  Brian

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]<mailto:[email-masked]>> en nombre de Paul Marks <[email-masked]<mailto:[email-masked]>>
Responder a: <[email-masked]<mailto:[email-masked]>>
Fecha: jueves, 19 de octubre de 2017, 0:01
Para: Fred Baker <[email-masked]<mailto:[email-masked]>>
CC: <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [v6ops] Google Alert - IPv6

   On Wed, Oct 18, 2017 at 2:22 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
So, this may be a dumb question. IPv6 advocates will reflexively agree with
comments on “CGNAT is a bad idea”. But as operators who very likely have
some combination of IPv6 and CGNAT, do we have thoughtful experience-based
comments on this topic?

   _______________________________________________
   v6ops mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ca By <[email-masked]>
Date: Thu, 19 Oct 2017 02:41:54 +0000

> was not an option, but I hope the basic idea is still valid.

A big peice of work left is getting more ipv6 content

When the flow is e2e ipv6, the LEA traceability story is very easy.

More v6 content and services please, looking in the direction of Apple and
Twitter and Bing

> > After my presentation and all day long discussions, it was clear that
> the path is deploying IPv6 + voluntary code of conduct among ISPs +
> legislation.
> >
> > Then as promoting (again) IPv6 deployment was decided as the first step
> from the EC and member states, I indicated that we need to provide example
> in our own institutions, so I asked (I knew the answer in advance) to raise
> the hand to all the member states that have already their institutions
> (police in this case), already IPv6 enabled … surprise surprise … none was
> ready.
> >
> > So, I asked if we can agree in a short-term plan for all them to “at
> least” have public plan announced in the next 6 months. So that’s what I
> will be working now with them.
> >
> > Regards,
> > Jordi
> >
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> >
> >
> >

---

From: Erik Kline <[email-masked]>
Date: Thu, 19 Oct 2017 11:47:14 +0900

> More v6 content and services please, looking in the direction of Apple and

One of these three /was/ an official participant in World IPv6 Launch
(http://www.worldipv6launch.org/).  Ahem.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 19 Oct 2017 07:05:43 +0200 (CEST)

On Wed, 18 Oct 2017, Fred Baker wrote:

> So, this may be a dumb question. IPv6 advocates will reflexively agree 
> with comments on “CGNAT is a bad idea”. But as operators who very likely 
> have some combination of IPv6 and CGNAT, do we have thoughtful 
> experience-based comments on this topic?

On the IPv4 GUA side of any NAT, I recommend using "port block allocation" 
and logging the bindings. If possible, use 1024 ports per user, so circa 
60 users share the same IPv4 address. For NAT44 this means logging IPv4 
address to IPv4 GUA port block, for NAT64 in typical mobile application, 
it would mean logging /64 to IPv4 GUA port block (I would hope NAT64 
implementations support this).

Subscriber account 1 has L4 port 1024-2047
Subscriber account 2 has L4 port 2048-3071
etc

So when LEA (Law Enforcement Agency) comes knocking then the discussion 
becomes:

LEA: "What user used IPv4 address $IP at time $DATE"?
ISP: "Do you have an source L4 port to go along with that?"
LEA: "No."
ISP: "Here is the list of 60 subscribers behind that address at that time"

If they do have a port, then LEA can have a single subscriber.

This also means you don't have to log any traffic data. Traffic data 
is troublesome to have to log from both a technical and legal perspective.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Thu, 19 Oct 2017 08:35:06 +0200

* Mikael Abrahamsson <[email-masked]>

> If they do have a port, then LEA can have a single subscriber.

Reading the original article (linked below) I am left with the feeling
that the problem is that they generally *don't* know the source port,
and therefore end up, quote, «[unable] to identify internet subscribers
on the basis of an IP address».

https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online

The article proceeds to define «CGN» as «technologies which allow
sharing of IPv4 addresses with multiple internet users». In that
context, MAP, even though it is not technically CGNAT, is just as
problematic (to answer Rajiv).

C'est la vie! If Europol don't like IP address sharing, I think the
only thing they actually could do about it would be to put pressure on
regulators and/or lawmakers to accelerate IPv6 adoption. I understand
that's what already happened in Belgium with impressive results.

Tore

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 19 Oct 2017 09:03:19 +0200 (CEST)

> that's what already happened in Belgium with impressive results.

So I have no idea what's really going on here, but I can imagine someone 
doing CGN and just NATing people left and right, and not logging anything. 
Then it's near impossible to find who did what.

At least when I looked into this issue, the message I got back was that 
narrowing down the user list to a few tens of subscribers was still vastly 
better than no information at all. Of course LEAs don't like it, but it's 
a lot better than nothing.

Also, services who are typically involved in being targeted for crimes 
should start logging the source port of whoever is talking to them. This 
option is available in most web servers and has been for a considerable 
amount of time.

Mandating IPv6 is a hard sell. Mandating ISPs to log what subscriber 
accounts was behind an IPv4 address at a given point in time including 
port used by what account, that's less far fetched.

---

From: <[email-masked]>
Date: Thu, 19 Oct 2017 09:23:25 +0000

Hi Mikael, Tore, all,

You may want read: https://tools.ietf.org/html/draft-daveor-cgn-logging-00 which relies on the Europol threat assessment report (https://www.europol.europa.eu/sites/default/files/documents/europol_iocta_web_2016.pdf)

As far as the IETF is concerned, I do believe that we have done our part of the job: 

   1.   Identify logging as an issue in address sharing: RFC 6269

   2.   Require address sharing to enable a logging function: RFC 6269
        and RFC 6888

   3.   Identify a minimal set of information to be logged: RFC 6269,
        RFC 6888, and RFC 6908

   4.   Identify and discuss trade-offs of solutions to achieve logging:
        RFC 6269, RFC 6908

   5.   Specify means to optimize logging (port range allocation,
        deterministic NAT): draft-ietf-softwire-stateless-
        4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and
        RFC7422

   6.   Recommend servers to log source port: RFC 6302

   7.   An initial survey of servers supporting source port logging: RFC
        7768

   8.   Retrieve NAT session loggings: draft-ietf-behave-syslog-nat-
        logging, draft-ietf-behave-ipfix-nat-logging

   9.   Enable address sharing logging function by means of NETCONF:
        draft-ietf-opsawg-nat-yang

   10.  CPU and memory issues: RFC 6908

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Mikael
> Abrahamsson
> Envoyé : jeudi 19 octobre 2017 09:03
> À : Tore Anderson
> Cc : [email-masked]
> Objet : Re: [v6ops] Google Alert - IPv6
> 
> > https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-
> address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-
> increase-accountability-online
> >

---

From: Ca By <[email-masked]>
Date: Thu, 19 Oct 2017 12:14:59 +0000

> port used by what account, that's less far fetched.

I disagree. IPv6 is inevitable and therefore can be sold strategically.

Logging , on the other hand , is pure overhead with no long term value and
very very expensive. In my experience, deploying ipv6 is not expensive at
all. Ymmv.

I am with Tore, if the content and eyeballs cant make the business case,
govt should help make the case

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Oct 2017 21:23:26 +0900

On Thu, Oct 19, 2017 at 9:14 PM, Ca By <[email-masked]> wrote:

> IPv6 is inevitable

My, how far we've come. 3 years ago I wouldn't have believed this. But now,
maybe...

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Oct 2017 14:30:44 +0200

Le 19/10/2017 à 14:23, Lorenzo Colitti a écrit :
> On Thu, Oct 19, 2017 at 9:14 PM, Ca By <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     IPv6 is inevitable
> 
> 
> My, how far we've come. 3 years ago I wouldn't have believed this. But 
> now, maybe...

I must share I still encounter strong reluctance to deploying IPv6.  To 
such a point that I give up saying "IPv6" - I just say "IP" and example 
address 1::1 or 2001:db8::1.  That seems to raise less opposition.

Alex

---

From: Warren Kumari <[email-masked]>
Date: Thu, 26 Oct 2017 11:00:32 -0400

> You may want read: https://tools.ietf.org/html/draft-daveor-cgn-logging-00 which relies on the Europol threat assessment report (https://www.europol.europa.eu/sites/default/files/documents/europol_…

I'm somewhat hijacking an old thread, but it would be great if we
could get some more review of draft-daveor-cgn-logging -- I know Dave
would really appreciate comments / review.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 26 Oct 2017 21:15:28 +0100

Hello everybody,

I’m the author of https://tools.ietf.org/html/draft-daveor-cgn-logging-01. Warren brought this thread to my attention so I would like to throw in a few thoughts for people to consider, if I may. I have attempted to address as many as possible of the points raised by others in the thread in one big response below.

Thanks for taking the time to read this and I look forward to any feedback you might have,
daveor

On the topic of “CGNAT is a bad idea”
——————————————————————————————

I am not too sure how much mileage there is getting caught up in this point. CGNAT is out there in the world, along with a suite of other large-scale address sharing technologies, and although the transition to IPv6 is ongoing, it is painfully slow and transitionary arrangements will be required for the foreseeable future. 

It would be, in my opinion, remiss of the criminal justice system not to consider this issue. The argument that the CGNAT problem will go away if we were all to just move to IPv6 doesn’t help solve the murder that happened today or catch the person distributing child pornography on the Internet. 

Can we regulate our way out of this problem?
——————————————————————————————

There are plenty of business reasons why an operator might choose to deploy CGNAT, maybe they don’t like the risk associated with changing to IPv6, maybe they’re waiting for someone else to move first, maybe they can’t afford to migrate infrastructure, maybe they just don’t want to. 

Considering regulation as a way to adjust economic incentives, there is indeed an opportunity to help to shift things along in one or more countries through regulation, but to what extent will this help with the global issue of crime attribution? It is clear that if the number of subscribers that can be simultaneously behind a CGNAT is limited, the deployment of IPv6 increases, and the IPv6 adoption in Belgium bears that out. 

However, the obvious question to ask is - are the Belgian authorities catching any more criminals now that they have such a high adoption rate of IPv6? Has the problem of crime attribution due to CGNAT gone away for them, or does it actually require global adoption of IPv6? I don’t have answers to these questions, but before leaping on a regulatory solution it would be very useful to know whether the regulatory solution achieves the desired effect. 

Let’s also not forget that CGNAT is not uncommon in areas outside telecoms, such as in an increasing number of IoT deployments.

Does migration to IPv6 actually solve the problem
——————————————————————————————

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? 

Let’s also not forget that the problem is not limited to the set of technologies commonly referred to as CGNAT. Any large-scale IP address sharing technology will have a similar problem, including 4-to-6 technologies. Therefore, until there is total global adoption of IPv6, and in fact until IPv4 is no longer routable on the Internet, this problem is going to persist.

The evidence is very sparse and, again, I refer to the questions that I posed above about the effectiveness of regulation in the Belgian case towards achieving the actual goal, which (for the purposes of this discussion) is improved crime attribution, not migration to IPv6.

The reason I am making this point is to emphasise that the problem of crime attribution arising from large-scale address sharing is not going away in the medium term, perhaps even not in the long term.

Alternatives to source port logging for crime attribution
——————————————————————————————

There is already regulation in place requiring ISPs to be able to identify their subscribers, including the requirement to identify people behind a CGN (within the EU at least), which is the data retention directive. I know that the future of this directive is unsure right now but today, as we write this, the legislation of every country in the EU requires ISPs to keep this data. The problem is that law enforcement agencies do not have the required information to be able to ask the ISP for the subscriber identity - because source ports are required and not logged anywhere. 

So the question becomes how to address this information gap. One possibility is that ISPs must record all destination IP addresses for all TCP connections, and I think you also refer to this possibility. This solution has, in my opinion, two major challenges - firstly that the storage requirements (and therefore the cost) for ISPs is very substantial indeed and secondly there are significant privacy implications arising from the storage of such a volume of data on (predominantly) innocent people. Some of the references provided by Mohamed Boucadair touch on these points, and they are also addressed in my draft.

The alternative, that I propose in the Internet Draft, is that if there is a shift to routine logging of source port alongside IP address, this will achieve the same goal but with significantly less privacy implications and with significantly less impact on operator (meaning that, in my opinion at least, operators should favour this approach).

Support for logging source port
——————————————————————————————

This is something that I study in the Internet Draft. The majority of server software examined support logging of source port in some way, but in some cases it involves enabling a distressingly high level of logging verbosity, and this is a scenario where I refer to source port logging as “Possible” but not “Feasible”. About 70% of server software that I examined supported logging of source port in a way that could be considered “Feasible”. Only one had logging of source port enabled as a default.

The contribution of my Internet Draft
——————————————————————————————

The key RFC upon which my Internet Draft builds is RFC6302, which contains the recommendation that servers log source port. My document attempts to contribute to the discussion by considering (a) why, despite recommendations of RFC6302, source port logging is not routine and (b) to identify possible solutions and workarounds for some of these objections.

The role of the IETF in this
——————————————————————————————

Right from the front page of the IETF website: "The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.”

Large scale address sharing technologies present a challenge to the management of the Internet so that seems to fit right within the remit of the IETF to me. Correct me if I’m wrong...

Other things I have been doing
——————————————————————————————

Finally, and for your information, I thought you might be interested to know what else I have been doing to try to move this conversation forward.

You might be aware that of the OWASP (https://www.owasp.org/) who produce amongst many other fine documents, secure coding guidelines. One of the aspects of their guidance is logging and they have a list of fields that should be logged…and source port isn’t on it. I have been trying to reach out to people in OWASP to have the conversation about including source port in the list of fields to be logged in their guidance. So far I have received no response but I will keep trying. 

> On 26 Oct 2017, at 16:00, Warren Kumari <[email-masked]> wrote:
> 
> --===============7090974386904564375==--
> 
> --===============4172498714441195205==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Description: Digest Footer
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 26 Oct 2017 13:42:29 -0700

> On the topic of “CGNAT is a bad idea”
Dave,

The flip side to this coin is that if good guys are able to track IPv6
addresses more easily, then that means the bad guys will be able to
also. Today it may be the case that CGNAT inadvertently offers better
privacy for users that IPv6 would (without any consideration why users
want privacy). So there should be a concern about the privacy of IPv6.
The likely solution is to allow hosts to use untrackable IP addresses,
maybe they would want to use a different IP address for each
connection. There are proposals for this.

If hosts use untrackable addresses, then privacy properties of IPv6
and CGNAT should be nearly equivalent. So the solution to assist law
enforcement ends up being the the same as that for CGNAT. A provider
maintains a log of mappings from the IP addresses to users and
releases information to authorities under warrant. It seems like this
is a logical extension to your draft.

Tom

---

From: Ca By <[email-masked]>
Date: Thu, 26 Oct 2017 21:17:53 +0000

On Thu, Oct 26, 2017 at 1:17 PM Dave O'Reilly <[email-masked]> wrote:

> Hello everybody,
>
> I’m the author of https://tools.ietf.org/html/draft-daveor-cgn-logging-01.
> Warren brought this thread to my attention so I would like to throw in a
> few thoughts for people to consider, if I may. I have attempted to address
> as many as possible of the points raised by others in the thread in one big
> response below.
>
> I am not too sure how much mileage there is getting caught up in this
> point. CGNAT is out there in the world, along with a suite of other
> large-scale address sharing technologies, and although the transition to
> IPv6 is ongoing, it is painfully slow and transitionary arrangements will
> be required for the foreseeable future.
>
> It would be, in my opinion, remiss of the criminal justice system not to
> consider this issue. The argument that the CGNAT problem will go away if we
> were all to just move to IPv6 doesn’t help solve the murder that happened
> today or catch the person distributing child pornography on the Internet.
>
> There are plenty of business reasons why an operator might choose to
> deploy CGNAT, maybe they don’t like the risk associated with changing to
> IPv6, maybe they’re waiting for someone else to move first, maybe they
> can’t afford to migrate infrastructure, maybe they just don’t want to.
>
> Considering regulation as a way to adjust economic incentives, there is
> indeed an opportunity to help to shift things along in one or more
> countries through regulation, but to what extent will this help with the
> global issue of crime attribution? It is clear that if the number of
> subscribers that can be simultaneously behind a CGNAT is limited, the
> deployment of IPv6 increases, and the IPv6 adoption in Belgium bears that
> out.
>
> However, the obvious question to ask is - are the Belgian authorities
> catching any more criminals now that they have such a high adoption rate of
> IPv6? Has the problem of crime attribution due to CGNAT gone away for them,
> or does it actually require global adoption of IPv6? I don’t have answers
> to these questions, but before leaping on a regulatory solution it would be
> very useful to know whether the regulatory solution achieves the desired
> effect.
>
> Let’s also not forget that CGNAT is not uncommon in areas outside
> telecoms, such as in an increasing number of IoT deployments.
>
> 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?
>

Unequivocally YES.  Been there, done that. IPv6 is the only and best long
term solution. Future updates of this draft must underscore this fact.

The desire for port logging is an artifact of slow migrations on the part
of some. In mobile, most users in the USA are on ipv6 now

http://www.telecompetitor.com/mobile-ipv6-milestone-more-than-half-of-mobile-requests-now-ipv6/

We should encourage more ipv6 content providers (bing, twitter, apple, and
the big 3 cloud to default to ipv6 on)

> Let’s also not forget that the problem is not limited to the set of
> technologies commonly referred to as CGNAT. Any large-scale IP address
> sharing technology will have a similar problem, including 4-to-6
> technologies. Therefore, until there is total global adoption of IPv6, and
> in fact until IPv4 is no longer routable on the Internet, this problem is
> going to persist.
>
> The evidence is very sparse and, again, I refer to the questions that I
> posed above about the effectiveness of regulation in the Belgian case
> towards achieving the actual goal, which (for the purposes of this
> discussion) is improved crime attribution, not migration to IPv6.
>
> The reason I am making this point is to emphasise that the problem of
> crime attribution arising from large-scale address sharing is not going
> away in the medium term, perhaps even not in the long term.
>
> There is already regulation in place requiring ISPs to be able to identify
> their subscribers, including the requirement to identify people behind a
> CGN (within the EU at least), which is the data retention directive. I know
> that the future of this directive is unsure right now but today, as we
> write this, the legislation of every country in the EU requires ISPs to
> keep this data. The problem is that law enforcement agencies do not have
> the required information to be able to ask the ISP for the subscriber
> identity - because source ports are required and not logged anywhere.
>
> So the question becomes how to address this information gap. One
> possibility is that ISPs must record all destination IP addresses for all
> TCP connections, and I think you also refer to this possibility. This
> solution has, in my opinion, two major challenges - firstly that the
> storage requirements (and therefore the cost) for ISPs is very substantial
> indeed and secondly there are significant privacy implications arising from
> the storage of such a volume of data on (predominantly) innocent people.
> Some of the references provided by Mohamed Boucadair touch on these points,
> and they are also addressed in my draft.
>
> The alternative, that I propose in the Internet Draft, is that if there is
> a shift to routine logging of source port alongside IP address, this will
> achieve the same goal but with significantly less privacy implications and
> with significantly less impact on operator (meaning that, in my opinion at
> least, operators should favour this approach).
>
> This is something that I study in the Internet Draft. The majority of
> server software examined support logging of source port in some way, but in
> some cases it involves enabling a distressingly high level of logging
> verbosity, and this is a scenario where I refer to source port logging as
> “Possible” but not “Feasible”. About 70% of server software that I examined
> supported logging of source port in a way that could be considered
> “Feasible”. Only one had logging of source port enabled as a default.
>
> The key RFC upon which my Internet Draft builds is RFC6302, which contains
> the recommendation that servers log source port. My document attempts to
> contribute to the discussion by considering (a) why, despite
> recommendations of RFC6302, source port logging is not routine and (b) to
> identify possible solutions and workarounds for some of these objections.
>
> Right from the front page of the IETF website: "The mission of the IETF is
> to make the Internet work better by producing high quality, relevant
> technical documents that influence the way people design, use, and manage
> the Internet.”
>
> Large scale address sharing technologies present a challenge to the
> management of the Internet so that seems to fit right within the remit of
> the IETF to me. Correct me if I’m wrong...
>
> Finally, and for your information, I thought you might be interested to
> know what else I have been doing to try to move this conversation forward.
>
> You might be aware that of the OWASP (https://www.owasp.org/) who produce
> amongst many other fine documents, secure coding guidelines. One of the
> aspects of their guidance is logging and they have a list of fields that
> should be logged…and source port isn’t on it. I have been trying to reach
> out to people in OWASP to have the conversation about including source port
> in the list of fields to be logged in their guidance. So far I have
> received no response but I will keep trying.
>
>
>
>
> >> You may want read:
> https://tools.ietf.org/html/draft-daveor-cgn-logging-00 which relies on
> the Europol threat assessment report (
> https://www.europol.europa.eu/sites/default/files/documents/europol_iocta_web_2016.pdf
> )
> >>
> >

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Oct 2017 14:25:51 -0700

Dave,

Thanks for an eloquently written draft!

Just a few things that occurred to me while reading through.

Two minor comments.

1) You might want to reference the other IPv4 sharing mechanisms too (RFC7598, 7599 etc). Although they don't require logging by the IPv4 sharing operator, they have the same issue with source port + timestamp required.

2) I'd suggest you drop mentioned of suspects and criminal activity in general. Also it reads in places like it is written with too much of a particular jurisdiction in mind.

Major comment:
3) The document talks about identifying an individual, and in places a subscriber endpoint. What it does identify, is the _originating network_. What you get is the public interface address of the customer CPE. Which looks like a network from the inside.
Make it very clear that this does not identify individual hosts. And it might be worth noting that traffic my enter the originating network from outside. E.g. through VPNs, TOR exits, shared WIFI and whatnot.

Best regards,
Ole

> On 26 Oct 2017, at 13:15, Dave O'Reilly <[email-masked]> wrote:
> 
> Hello everybody,
>

---

From: <[email-masked]>
Date: Fri, 27 Oct 2017 06:43:17 +0000

Hi Ole, 

Please see inline. 

Cheers,
Med

> De : v6ops [mailto:[email-masked]] De la part de Ole Troan
> Envoyé : jeudi 26 octobre 2017 23:26
> À : Dave O'Reilly
> Cc : [email-masked]; Tore Anderson
> 1) You might want to reference the other IPv4 sharing mechanisms too
> (RFC7598, 7599 etc). Although they don't require logging by the IPv4
> sharing operator

[Med] A logging/binding is needed to be done by the v4 sharing operator even for A+P. Perhaps you meant the logging is not required at the BR for MAP/E-T. 

, they have the same issue with source port + timestamp
> required.
> 
> 2) I'd suggest you drop mentioned of suspects and criminal activity in
> general. Also it reads in places like it is written with too much of a
> particular jurisdiction in mind.
> 
> Major comment:
> 3) The document talks about identifying an individual, and in places a
> subscriber endpoint. What it does identify, is the _originating network_.
> What you get is the public interface address of the customer CPE. Which
> looks like a network from the inside.
> Make it very clear that this does not identify individual hosts. And it
> might be worth noting that traffic my enter the originating network from
> outside. E.g. through VPNs, TOR exits, shared WIFI and whatnot.
> 
> Best regards,
> Ole
> 
> 
> 
> 
> > I’m the author of https://tools.ietf.org/html/draft-daveor-cgn-logging-
> 01. Warren brought this thread to my attention so I would like to throw in
> a few thoughts for people to consider, if I may. I have attempted to
> address as many as possible of the points raised by others in the thread
> in one big response below.
> >
> point. CGNAT is out there in the world, along with a suite of other large-
> scale address sharing technologies, and although the transition to IPv6 is
> ongoing, it is painfully slow and transitionary arrangements will be
> required for the foreseeable future.
> >
> consider this issue. The argument that the CGNAT problem will go away if
> we were all to just move to IPv6 doesn’t help solve the murder that
> happened today or catch the person distributing child pornography on the
> Internet.
> >
> catching any more criminals now that they have such a high adoption rate
> of IPv6? Has the problem of crime attribution due to CGNAT gone away for
> them, or does it actually require global adoption of IPv6? I don’t have
> answers to these questions, but before leaping on a regulatory solution it
> would be very useful to know whether the regulatory solution achieves the
> desired effect.
> >
> > There is already regulation in place requiring ISPs to be able to
> identify their subscribers, including the requirement to identify people
> behind a CGN (within the EU at least), which is the data retention
> directive. I know that the future of this directive is unsure right now
> but today, as we write this, the legislation of every country in the EU
> requires ISPs to keep this data. The problem is that law enforcement
> agencies do not have the required information to be able to ask the ISP
> for the subscriber identity - because source ports are required and not
> logged anywhere.
> >
> indeed and secondly there are significant privacy implications arising
> from the storage of such a volume of data on (predominantly) innocent
> people. Some of the references provided by Mohamed Boucadair touch on
> these points, and they are also addressed in my draft.
> >
> > The alternative, that I propose in the Internet Draft, is that if there
> is a shift to routine logging of source port alongside IP address, this
> will achieve the same goal but with significantly less privacy
> implications and with significantly less impact on operator (meaning that,
> in my opinion at least, operators should favour this approach).
> >
> server software examined support logging of source port in some way, but
> in some cases it involves enabling a distressingly high level of logging
> “Possible” but not “Feasible”. About 70% of server software that I
> examined supported logging of source port in a way that could be
> considered “Feasible”. Only one had logging of source port enabled as a
> default.
> >
> > The key RFC upon which my Internet Draft builds is RFC6302, which
> contains the recommendation that servers log source port. My document
> attempts to contribute to the discussion by considering (a) why, despite
> > Right from the front page of the IETF website: "The mission of the IETF
> is to make the Internet work better by producing high quality, relevant
> > You might be aware that of the OWASP (https://www.owasp.org/) who
> produce amongst many other fine documents, secure coding guidelines. One
> of the aspects of their guidance is logging and they have a list of fields
> that should be logged…and source port isn’t on it. I have been trying to
> reach out to people in OWASP to have the conversation about including
> source port in the list of fields to be logged in their guidance. So far I
> have received no response but I will keep trying.
> >
> >
> >
> >
> >>> You may want read: https://tools.ietf.org/html/draft-daveor-cgn-
> logging-00 which relies on the Europol threat assessment report
> (https://www.europol.europa.eu/sites/default/files/documents/europol_iocta
> _web_2016.pdf)
> >>>
> >>

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Oct 2017 23:49:09 -0700

Med,

> On 26 Oct 2017, at 23:43, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Ole, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 

Not sure what you mean. 
The operator of a stateless A+P solution like map-e or t or lw46 does not need logging. Do you disagree with that?

The server operator of course still need to log source port. While timestamp is of less importance . 

Ole

---

From: <[email-masked]>
Date: Fri, 27 Oct 2017 07:02:24 +0000

Re-,

Please see inline.

Cheers,
Med

> De : Ole Troan [mailto:[email-masked]]
> Envoyé : vendredi 27 octobre 2017 08:49
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Dave O'Reilly; [email-masked]; Tore Anderson
> Objet : Re: [SUSPECTED SPAM] RE: [v6ops] Google Alert - IPv6
> 
> Med,
> 
> > [Med] A logging/binding is needed to be done by the v4 sharing operator
> even for A+P. Perhaps you meant the logging is not required at the BR for
> MAP/E-T.
> 
> Not sure what you mean.

[Med] We need to distinguish between what is required from an "operator of an address sharing domain" vs. a feature to be supported by an address sharing device.

> need logging. Do you disagree with that?

[Med] Disagree. The **IPv4 sharing operator** will need to maintain the association between the host to which a shared IPv4 address + port set was assigned together with the timestamp when that allocation was made (https://tools.ietf.org/html/rfc6269#section-13.1). 

Of course, for A+P this information may be retrieved from sources such as DHCP leases, but still that "host/IP@+port set, timestamp" information need to be maintained. 

Just like for the CGN case, the logging information may be reduced to the configuration inputs to an algorithm and the timestamp when those config are applied.   

> large-
> >>>>>>> only thing they actually could do about it would be to put
> pressure
> >> on
> >>>>>> better than no information at all. Of course LEAs don't like it,
> but
> >> it's

---

From: Lee Howard <[email-masked]>
Date: Fri, 27 Oct 2017 12:51:15 +0400

Without any IETF hat on. . .

>Can we regulate our way out of this problem?

Probably not. Countries with the highest IPv6 deployment have had either
no government influence, or little more than government talking with
industry about their IPv6 deployment plans. Countries with IPv6 mandates
on industry seem to have very low actual deployment.

>global issue of crime attribution?

To the degree that IPv6 and/or proper port/timestamp logging is adopted.
Either will work, but this is becoming much more of a content operator
problem than an ISP or mobile carrier problem.

>It is clear that if the number of subscribers that can be simultaneously
>behind a CGNAT is limited, the deployment of IPv6 increases, and the IPv6
>adoption in Belgium bears that out.

Yes, and I think you’re right, but the Belgian interpretation that address
sharing must not exceed 16:1 may not be generalizable. That is: Belgium is
one country, and we don’t know if their rule would work everywhere.

>them, or does it actually require global adoption of IPv6?

The question is more like, “Are Belgian authorities catching more
criminals than other countries in proportion to their IPv6 deployment?”
They’re probably not catching more bad guys than they were before CGN,
they’re just trying not to lose ground.
And the answer is probably not good, because although Belgium has great
numbers on eyeballs, their IPv6 deployment on content sites is still weak
(https://www.vyncke.org/ipv6status/detailed.php?country=be ).

>problem of crime attribution due to large-scale address sharing?

Only if content providers deploy IPv6, including logging.

>The problem is that law enforcement agencies do not have the required
>information to be able to ask the ISP for the subscriber identity -
>because source ports are required and not logged anywhere.
>
>TCP connections, 

If the problem is that content providers are not logging enough
information to identify users reaching their content, why in the world
would this gap become the ISPs' problem? Regulate the content providers if
they’re the ones providing insufficient information.

>The role of the IETF in this

Not entirely, but this seems more operational to me, and might be better
targeted as a recommendation for how to manage servers.

Lee

>>>the Europol threat assessment report
>>>(https://www.europol.europa.eu/sites/default/files/documents/europol_ioc
>>>ta_web_2016.pdf)
>>> 
>>

---

From: Erik Nygren <[email-masked]>
Date: Fri, 27 Oct 2017 10:21:36 -0400

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

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.

     Erik

[thoughts/opinions here are my own and do not necessarily represent my
employer]

---

From: Lee Howard <[email-masked]>
Date: Fri, 27 Oct 2017 18:59:45 +0400

Still offering solely my personal opinion.

> On Oct 27, 2017, at 6:21 PM, Erik Nygren <[email-masked]> wrote:
> 
> 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 think you're saying that logging IPv6 address is not trivial, but neither is logging IPv4 + port. Maybe not the same cost, but same order of magnitude?

> 
> 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?"

Yes, that would be a worst case.
As a general rule, regulation should describe what is needed (attribution) not how to do it (log format or IPv6). So, make content providers, ISPs, mobile companies, and consumer electronics (IoT) manufacturers liable for failing to comply with a subpoena if they are unable to provide attribution information in sufficient detail. Content providers (e.g.) can look at their budgets and Vyncke's projection of IPv6 eyeballs and say, "More than half of all users will be IPv6 capable in X months." They can even look at APNIC's data and think about which countries' users generate the most traffic. Then they can do the math on how many subpoenas they'll see requiring IPv4+source+timestamp versus how many they'll see for IPv6, and rationally decide which to deploy, if not both.

That way, IPv6 becomes a sort of safe harbor, or at least safer than not. Of course, it only applies if you move toward regulation. Personally, I don't want regulators thinking they understand the Internet well enough to regulate it. 

Lee
> 
>      Erik
> 
> 
> [thoughts/opinions here are my own and do not necessarily represent my employer]
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 27 Oct 2017 19:21:54 -0700

> one country, and we don’t know if their rule would work everywhere.

We are digressing from the draft in question, but since I'm sitting somewhere over Oregon at the moment I have ample time.
It is not at all clear that the number of subscribers behind a CGN is "limited".

I'd certainly would have liked to see some research on this.
If you are clever and use endpoint dependent connections where you can. You can stretch address sharing very very far.
Since you can reuse source ports for multiple connections, assuming the destination port is largely constant at 443, the number of connections for a single port is bounded by the distribution of destinations on the Internet.

You will burn one source port for each concurrent connection to the _same_ destination address.

The bitter truth is that we can make IPv4 'scale' forever. ;-(

Best regards,
Ole

---

From: Fred Baker <[email-masked]>
Date: Sat, 28 Oct 2017 06:54:39 +0400

> On Oct 28, 2017, at 6:21 AM, Ole Troan <[email-masked]> wrote:
> 

Actually, from what I have been told, we can't. We can make it work for a number of sources per translated address (Xing Li gave a talk on his experiments in that regard a few years back, although I would have to do some research to find it). As I recall, he started getting user complaints when he had 100-or-so active sessions on each external address. That's far from "forever".

---

From: Ole Troan <[email-masked]>
Date: Sat, 28 Oct 2017 05:15:21 +0200

Fred,

> Actually, from what I have been told, we can't. We can make it work for a number of sources per translated address (Xing Li gave a talk on his experiments in that regard a few years back, although…

Complaints about what?
You might be assuming the IPv4 Internet isn't changing to accommodate address sharing. And there are many ways of building NAT.
The mechanisms I described earlier do work. It's on my todo list to get hold a sufficiently large traffic sample to run the numbers of how what sharing ratio you could achieve. It is orders of magnitude more than 1:100 (if you intended s/sessions/users).

Each session to 8.8.8.8:53 would burn a port.
But a single port could be reused for millions of connections as long as DA+DP was different.
(And you could of course be nice to things like SIP and give those endpoint-independent behaviour).

That said the path, of extending A+P to the end host is also open to us. Similarly to what Brian C proposed at IETF 29.
No state in network. Each host gets a single port. I.e. we have expanded the address space to 48 bits.
Requires new transport protocol on top of IP+UDP of course. With it's own name space. But that's pretty much happening over in transport now anyway, right?

Ole

---

From: Fred Baker <[email-masked]>
Date: Sat, 28 Oct 2017 09:19:42 +0400

> On Oct 28, 2017, at 7:15 AM, Ole Troan <[email-masked]> wrote:
> 
> Fred,
> 

What I'm thinking about specifically is slide 6 of https://www.ietf.org/proceedings/92/slides/slides-92-v6ops-3.pdf, and some of the other slides around it. I got the number wrong: he saw issues when he had more than 512 addressed machines sharing a single address using NAT address. I believe that the context was splitting the port number so that any given address had a certain number of ports that could be tracked to it rather than fussing with logging.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Oct 2017 00:43:20 -0300

> <[email-masked] on behalf of [email-masked]> wrote:
[....]
> Only if content providers deploy IPv6, including logging.

... and as long as they disable v4. Otherwise, given an option that
helps cover his tracks, it shouldn't be a surprise which option would a
clueful attacker use.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Gert Doering <[email-masked]>
Date: Sun, 29 Oct 2017 10:44:42 +0100

Hi,

On Sat, Oct 28, 2017 at 06:54:39AM +0400, Fred Baker wrote:
> Actually, from what I have been told, we can't. We can make it
> work for a number of sources per translated address (Xing Li gave
> a talk on his experiments in that regard a few years back, although
> I would have to do some research to find it). As I recall, he started
> getting user complaints when he had 100-or-so active sessions on
> each external address. That's far from "forever".

That would more hint at a poor implementation of the CGN than a 
theoretical limit.  What Ole says - no need to use a new source port
per TCP session, as long as the destination address is new.  But most
NAT implementations don't seem to do that.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:10:57 +0000

Hi Tom,

Thanks for your mail. 

I’m delighted to see that there have been a few replies to this thread. I am working through them now and yours is the first! 

> On 26 Oct 2017, at 21:42, Tom Herbert <[email-masked]> wrote:
> 
>> 
>> 

I agree with you that the choice of CGNAT vs. IPv6 doesn’t, and cannot possibly, address the issue of crime attribution on the Internet. I also agree that there is a balance to be struck between crime attribution (in general) and individual right to privacy. 

It has been my experience that the general approach that has been adopted to date is that:

1. ISPs are obliged through regulation to keep sufficient information to be able to identify their subscribers from their online activity
2. Law enforcement send requests for subscriber information to the ISPs concerned, with appropriate legal safeguards (whatever that means in any particular jurisdiction!!)

All of this might change (within the EU at least) due to the ECJ ruling on the invalidity of the data retention directive (the basis upon which ISPs are required to keep subscriber identity), but I don’t know how that’s going to work out.

You raise a very interesting point about how all of this will work in the case of IPv6 and I have made a note in my list of research ideas to investigate how crime attribution/subscriber identification might work in an IPv6 world. It’s a little beyond the scope of the problem I’m thinking about right now (CGNAT), but definitely worthy of consideration in due course, so thanks for that suggestion.

Regarding your comments on the use of untraceable addresses, I’m not a law enforcement officer, but I don’t think you would find a law enforcement officer anywhere in the world that would tell you that they think they could possibly catch every criminal (particularly in the cybercrime world). There are plenty of techniques and technologies out there that obfuscate the source of communication beyond the point of attribution, but this is not a reason for doing nothing - and I think this is the point I was making in my original email. CGNAT is out there, it’s a problem right now, and it’s a problem that is amenable to a solving, to a greater or lesser extent. 

I see the problem as basically an information gap problem - there is a gap between the information being retained by the ISPs and the information being logged by victims/platforms/hosting providers. There are, as far as I can tell three solutions to the problem:

1. Oblige ISPs retain more information (e.g. logging of all destination IP addresses for each subscriber)
2. Oblige ISPs to move to IPv6 either directly or indirectly
3. Victims/platforms/hosting providers look out for themselves and log the information required

Option 1, in my opinion, has horrendous privacy implications. Option 2 is also very difficult to recommend as an approach because regulation regimes vary so much across the world, and criminals tend to seek out favourable regulatory/legal regimes in which to operate (see, for example the problem of bulletproof hosting). Without regulatory pressure, IPv6 transition is only likely to happen at the slow, shall we say organic rate, that it has been taking place at until now. 

This leaves only the “self help” approach of people looking after themselves to address the immediate problem presented by CGNAT. This was the line of thinking that led to me drafting up the document for consideration of all of you good people in the IETF! 

Interested in any thoughts you might have on the above,
daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:12:26 +0000

> Unequivocally YES.  Been there, done that. IPv6 is the only and best long term solution. Future updates of this draft must underscore this fact. 
> 
> The desire for port logging is an artifact of slow migrations on the part of some. In mobile, most users in the USA are on ipv6 now
> 
> We should encourage more ipv6 content providers (bing, twitter, apple, and the big 3 cloud to default to ipv6 on)
> 
> 
Thanks Ca,

I had hoped I had made the point that IPv6 is the ultimate solution clear in the draft. I will review the wording and submit an additional draft if required.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:19:01 +0000

Hi Ole,

Thanks for the email.
> 1) You might want to reference the other IPv4 sharing mechanisms too (RFC7598, 7599 etc). Although they don't require logging by the IPv4 sharing operator, they have the same issue with source port…

I have included reference to these in the introduction to the -01 revision of the draft. 

> 2) I'd suggest you drop mentioned of suspects and criminal activity in general. Also it reads in places like it is written with too much of a particular jurisdiction in mind.

Thanks for this comment. Could you provide a specific example of this please - I was hoping that I had adopted a reasonably international approach to the problem. Obviously I live in a specific jurisdiction, and operate/work within a particular regime (the EU), which may have coloured my thinking in a way I haven’t identified.

> Make it very clear that this does not identify individual hosts. And it might be worth noting that traffic my enter the originating network from outside. E.g. through VPNs, TOR exits, shared WIFI a…

Yes, I completely agree. 

I do address this point in the -01 revision scope section:

"Clearly no single solution will address the problem of crime attribution on the Internet.  Load balancers, proxies and other network infrastructure may also, intentionally or as a side-effect, obfuscate the true source of Internet traffic and these problems will continue to exist with or without the presence of large-scale address sharing technologies (like Carrier-Grade NAT and A+P).”

I wanted to mention the point without getting dragged into details of all of the possible scenarios where an IP address does not represent an individual or subscriber endpoint (apart from CGNAT). I was of the opinion that there is a risk of trying to “boil the ocean” with a  document like this so I was trying to keep the focus as tightly as possible on the issues raised by CGNAT.

In light of this, do you think this needs to be more explicitly discussed or clarified? 

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:32:52 +0000

Hi Lee,

some comments inline below,

daveor

> on industry seem to have very low actual deployment.

I completely agree with you that there are too many regulatory models around the world for a recommendation of regulatory solutions to this problem to be likely to meet with much success. However, Belgium has the highest IPv6 adoption rate on the planet according to https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption&tab=per-country-ipv6-adoption and I understand that the reason for this is that the telecoms regulator in Belgium required that a maximum of (I think it was) 16 people can be sharing a single IP address on a CGNAT at any given time. I forget the exact figures but it was definitely a regulatory intervention.

> problem than an ISP or mobile carrier problem.

Actually I see it as a “people helping themselves" versus a “wait for the problem to go away” solution. True to say, however, that the solution (source port logging) needs to be implemented by content providers rather than ISPs.

> one country, and we don’t know if their rule would work everywhere.

Absolutely agree with you - regulatory solutions are not general solutions.

> (https://www.vyncke.org/ipv6status/detailed.php?country=be ).

Exactly! So they can attribute domestic IPv6 activity to domestic IPv6 addresses but the second IPv4 to IPv6 transition takes place they’re no better off than anyone else.

> they’re the ones providing insufficient information.

Well, here again we’re back to regulation as a possible solution. Practically everywhere in the world there is already a regulatory framework in place for ISPs and therefore the easy answer is to enforce additional regulation on ISPs - requiring them to solve this problem. 

As I mentioned in a previous email response that I just wrote, I see this as an information gap problem - there is a gap between the records ISPs are keeping and the available records at (most) content providers. The question is how best to fill this gap.

> targeted as a recommendation for how to manage servers.

Well, the IETF has already published such recommendations (RFC6302). The question is what, if anything, else the IETF can/should do. 

I wrote this document and I didn’t really know what to do with it, so I published it as an internet draft and have been trying to collect input on what/where the best places to progress the conversation are…and here we are.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:39:26 +0000

Hi Erik,

Thanks for the mail. Some comments inline below.

daveor

> On 27 Oct 2017, at 15:21, Erik Nygren <[email-masked]> wrote:
> 

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.

> 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

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

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:43:59 +0000

More comments inline below:

> On 27 Oct 2017, at 15:59, Lee Howard <[email-masked]> wrote:
> 

I think the short answer to this is that nobody knows. As I mentioned in an email response I just wrote, I have recommended that further research is required in this area to assess the downstream consequences of logging source port, and these should be considered in the context of a comparably sized project to migrate to IPv6.

> As a general rule, regulation should describe what is needed (attribution) not how to do it (log format or IPv6). So, make content providers, ISPs, mobile companies, and consumer electronics (IoT)…
I can imagine the conversation, however, where an ISP using CGNAT says that I COULD identify the suspect with my logs but it is YOUR problem (law enforcement/content provider/victim) that there is insufficient information available. The point is that there is an information gap, as I have mentioned in several responses, and we need to consider how we’re going to fill it.

> That way, IPv6 becomes a sort of safe harbor, or at least safer than not. Of course, it only applies if you move toward regulation. Personally, I don't want regulators thinking they understand the…

Also don’t forget that regulatory regimes (and indeed competence levels) vary across the world so a regulatory solution is unlikely to be a general solution.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:47:54 +0000

> On 28 Oct 2017, at 03:21, Ole Troan <[email-masked]> wrote:
> 

Some links I found (hardly research, but links anyway!):

https://www.intgovforum.org/multilingual/content/igf-2017-ws-214-how-can-we-limit-the-negative-impact-of-carrier-grade-nat-technologies-and
http://www.ipv6conference.ch/wp-content/uploads/2015/06/T04a-Vyncke-ch-council-iPv6-in-Belgium-June-2015.pdf

> The bitter truth is that we can make IPv4 'scale' forever. ;-(

Exactly the problem and this means the business case needs to be there for moving to IPv6. The upshot of this appears to be that, at least for the foreseeable future, CGNAT is going to be with us.

daveor

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:49:05 +0000

Hi Fred,

that would be a really useful reference for me if you could find it and it’s not too much trouble.

Thanks,
daveor

> On 28 Oct 2017, at 03:54, Fred Baker <[email-masked]> wrote:
> 
> 
>

---

From: Dave O'Reilly <[email-masked]>
Date: Sun, 29 Oct 2017 16:49:46 +0000

….and there it is. Sorry, that’s what I get for reading through the thread in order from earliest to most recent posts!

Apologies!

daveor

> On 28 Oct 2017, at 06:19, Fred Baker <[email-masked]> wrote:
> 
> 
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 30 Oct 2017 06:48:54 +1100

Geoff Huston's article on

Metadata Retention and the Internet

https://telsoc.org/ajtde/2015-04-v3-n1/a4

might be of interest.

"The Metadata Retention measures being considered in Australia make some
sweeping assumptions about the semantics of IP addresses and their
association with individual subscribers to the Internet. But are these
assumptions warranted?"

On 30 Oct. 2017 3:50 am, "Dave O'Reilly" <[email-masked]> wrote:

> ….and there it is. Sorry, that’s what I get for reading through the thread
> in order from earliest to most recent posts!
>
> Apologies!
>
> daveor
>
> >>> Actually, from what I have been told, we can't. We can make it work
> for a number of sources per translated address (Xing Li gave a talk on his
> experiments in that regard a few years back, although I would have to do
> some research to find it). As I recall, he started getting user complaints
> when he had 100-or-so active sessions on each external address. That's far
> from "forever".
> >>
> >> Complaints about what?
> >
> > What I'm thinking about specifically is slide 6 of https://www.ietf.org/
> proceedings/92/slides/slides-92-v6ops-3.pdf, and some of the other slides
> around it. I got the number wrong: he saw issues when he had more than 512
> addressed machines sharing a single address using NAT address. I believe
> that the context was splitting the port number so that any given address
> had a certain number of ports that could be tracked to it rather than
> fussing with logging.
> >
> >> You might be assuming the IPv4 Internet isn't changing to accommodate
> address sharing. And there are many ways of building NAT.
> >> The mechanisms I described earlier do work. It's on my todo list to get
> hold a sufficiently large traffic sample to run the numbers of how what
> sharing ratio you could achieve. It is orders of magnitude more than 1:100
> (if you intended s/sessions/users).
> >>
> >> That said the path, of extending A+P to the end host is also open to
> us. Similarly to what Brian C proposed at IETF 29.
> >> Requires new transport protocol on top of IP+UDP of course. With it's
> own name space. But that's pretty much happening over in transport now
> anyway, right?
> >>
> >> Ole
> >
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Oct 2017 06:41:17 +0400

> On Oct 29, 2017, at 11:48 PM, Mark Smith <[email-masked]> wrote:
> 
> "The Metadata Retention measures being considered in Australia make some sweeping assumptions about the semantics of IP addresses and their association with individual subscribers to the Internet. But are these assumptions warranted?"

In that context, the European Data Retention Directive (which has now been struck down by the European Privacy Court) and the activities by the "Five Eyes" in that regard, notably the US NSA, have been very much about metadata. I asked a Dutch agency representative once what their reason for lawful intercept in general and metadata capture specifically was, and he indicated "mapping criminal networks". They wanted to determine who spoke with whom, with a view to identifying members of a community, presumably an evil community.

I note that the European Privacy Court has (apparently) specified that an IP address is "Individually Identifiable Information", the kind of thing that might be discussed in https://tools.ietf.org/html/rfc7721. I have asked repeatedly what privacy folks think might be an IID below the application layer, and that is the one thing they have come up with. On the point, I would argue that data of that type is not *identification*, but it might be possible to correlate it with other information due to operational practice. To my mind, stomping out correlations is a game of whack-a-mole; someone that desperately wants to find a correlation will probably find something that mostly works for their purposes, even if they have to discard spurious correlations to do so. In my view, that's what we see here: we might be able to correlate an IP address with a computer or subscriber, but we can't stop people in a business or family from using each other's computers. It is at best an investigative tool, not proof of something in particular.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 30 Oct 2017 08:04:10 +0100

In 2003, I was involved with the EU working party (art. 29) in charge for the decision about considering or not IPs as personal data.

We didn’t succeed, and finally they concluded that IP is personal data.

My arguments, about that included many topics, including the possibility to use privacy addresses, many prefixes, and what Fred mentions, that there is no way you can actually say even if this is your computer, that any specific action is being done by you, a friend, a bot, or somebody that is using remotely your computer/network.

I also was explaining that the most interesting way for any “bad guy” to track someone, is actually not the IP address, but information disclosed by the browsers and many other apps that we commonly use. I recall having seen several web sites that actually dig into your browser and tell you how much you’re disclosing.

At the end, the EU courts accept that you, store IP data, like any other personal data that can be captured automatically, if you have a valid purpose for that (for operational purposes of the network), or it is your customer, but you disclose that data.

For example, to explain it better, I will do it with another type of personal data “emails”. I could capture in my database any email publicly found if I’ve a valid purpose for that (“I’m going to do a research of what are the most common domains or text used in emails”). To do so, you need to inform the data owner that you have registered it and the way he can access, amend, or cancel that data in your database. What I can’t do, for example, is to use that data to send any kind of commercial info which has not previous and explicitly accepted by the owner of the email. Not informing the user for having captured the email is an unlawful act, sending spam is another unlawful act. Both can be fined up to 600.000 euros by data protection agencies, and the owner can request also economical compensation for the use of his/her personal data in the courts.

Of course, if you’re customer of an operator, or customer from a hotspot, etc., you accept a contract, that explicitly should say that they are capturing that data (including IP) as it is required for the network operation, etc.

Regards,
Jordi

---

From: Ole Troan <[email-masked]>
Date: Mon, 30 Oct 2017 10:03:41 +0100

Hi Dave,

> In light of this, do you think this needs to be more explicitly discussed or clarified?

I think that's fine.
As long as you make it clear that:
 - the IP address _never_ identifies an individual.
 - it identifies a host, a source network, or the obfuscated result of a TOR gateway, VPN, another NAT, LB etc, etc...

But never, ever by itself an individual person.

Best regards,
Ole

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Oct 2017 13:15:44 +0400

> On Oct 30, 2017, at 1:03 PM, Ole Troan <[email-masked]> wrote:
> 

I'd add the word "interface". An address is primarily an interface identifier; in contains a prefix, which may correlate to something else.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 30 Oct 2017 07:48:33 -0700

>  - the IP address _never_ identifies an individual.

Ole,

I don't think this is something that can be part of the definition of
an IP address, it's more of a desirable property of how IP addresses
are assigned and used. For instance, a smartphone is given an IP
address and technically identifies the host. But given that there is a
likely one to one correspondence between personal device (and its
address) to an individual user, the IP address of the device
effectively identifies the individual or at least can be used with a
little more information to do so. In this case, the IP address seems
to be Personally Identifiable Information.

Tom

---

From: Ole Troan <[email-masked]>
Date: Mon, 30 Oct 2017 15:53:44 +0100

Tom,

> to be Personally Identifiable Information.

I am in no way trying to define an IP address.

My one and only point was that in this document one should not give the indication that an IP address by itself identifies an individual. Which revision -00 did.

(Sure, if the IP address leads to a single-user device with strong user authentication, there is a reasonable chance that it identifies an individual or an individual that knows who has been using it (e.g. their kids). Unless it is already owned by the NSA or a similar organisation.) Where did you interpret that as if I was trying to "define" an IP address?

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Mon, 30 Oct 2017 08:40:12 -0700

> (Sure, if the IP address leads to a single-user device with strong user authentication, there is a reasonable chance that it identifies an individual or an individual that knows who has been using…

It was the "_never_" part of your sentence :-). That seems to imply an
invariant property of IPv6 addresses that could then be part of its
definition.

Tom

---

From: Ole Troan <[email-masked]>
Date: Mon, 30 Oct 2017 17:19:38 +0100

Tom,

> On 30 Oct 2017, at 16:40, Tom Herbert <[email-masked]> wrote:
> 

Ah, I was purely talking about the draft, and therefore IPv4 addresses and I tried to include the “by itself”. :/)

Cheers 
Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 1 Nov 2017 12:42:31 +1100

On 31 Oct. 2017 01:48, "Tom Herbert" <[email-masked]> wrote:

>> "Clearly no single solution will address the problem of crime
attribution on the Internet.  Load balancers, proxies and other network
infrastructure may also, intentionally or as a side-effect, obfuscate the
true source of Internet traffic and these problems will continue to exist
with or without the presence of large-scale address sharing technologies
(like Carrier-Grade NAT and A+P).”
>>
>> I wanted to mention the point without getting dragged into details of
all of the possible scenarios where an IP address does not represent an
individual or subscriber endpoint (apart from CGNAT). I was of the opinion
that there is a risk of trying to “boil the ocean” with a  document like
this so I was trying to keep the focus as tightly as possible on the issues
raised by CGNAT.

Ole,

The trouble is, unless we hand-cuff devices to people, the binding between
a device and an individual isn't very strong. It is quite easy for a device
to be shared, intentionally or not, with more portable (and therefore
stealable,) devices making the coupling even weaker.

I think attribution of an action is an authentication problem. Machine
identifiers aren't very good analogues for individuals' identify and
authenticity. In the "what you have, what you are, and what you know" group
of authentication factors, I think the "what you have" is the weakest.

There really needs to be something else that supports or proves use of a
device other than an assumption that an IP address is tightly coupled to a
device's owner, and therefore all actions associated with an IP address are
those of the device's owner.

Regards,
Mark.

Tom

>  - it identifies a host, a source network, or the obfuscated result of a
TOR gateway, VPN, another NAT, LB etc, etc...

---

From: DY Kim <[email-masked]>
Date: Wed, 1 Nov 2017 10:47:29 +0900

When unlocking your smart phone, you might use the ‘finger touch’ identification, in which case the device use might identify the individual.

When a password or swipe pattern is used, the association might be weaker since those could be stolen.

---
DY

> On 1 Nov 2017, at 10:42, Mark Smith <[email-masked]> wrote:
> 
> There really needs to be something else that supports or proves use of a device other than an assumption that an IP address is tightly coupled to a device's owner, and therefore all actions associated with an IP address are those of the device's owner.

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Nov 2017 05:59:19 +0400

I think that misses the point. If you identify yourself to the phone, it knows that you are holding it. You might then pass it to someone else, who uses it. The phone doesn't know who is holding it, only that you unlocked it.

But that's not the point. The point is that someone *else* observing your phone's traffic or location data makes the assumption that the phone is with or being used by you. You didn't present your fingerprint to them; they are observing after the fact and making inferences.

Now, as an investigative tool, that makes sense - in a high percentage of cases, the person using your phone is you. So they can use that as a working assumption in the conduct of an investigation. But the working assumption doesn't prove anything, it only gives hints that have to be further verified to turn into proof.

> On Nov 1, 2017, at 5:47 AM, DY Kim <[email-masked]> wrote:
>

---

From: DY Kim <[email-masked]>
Date: Wed, 1 Nov 2017 12:08:19 +0900

Points taken. Thanks.

---
DY

> On 1 Nov 2017, at 10:59, Fred Baker <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 31 Oct 2017 21:54:31 -0700

On Tue, Oct 31, 2017 at 6:42 PM, Mark Smith <[email-masked]> wrote:
>>> "Clearly no single solution will address the problem of crime attribution
>>> on the Internet.  Load balancers, proxies and other network infrastructure
>>> may also, intentionally or as a side-effect, obfuscate the true source of
>>> Internet traffic and these problems will continue to exist with or without
>>> the presence of large-scale address sharing technologies (like Carrier-Grade
>>> NAT and A+P).”
>>>
>>> I wanted to mention the point without getting dragged into details of all
>>> of the possible scenarios where an IP address does not represent an
> The trouble is, unless we hand-cuff devices to people, the binding between a
> device and an individual isn't very strong. It is quite easy for a device to
> be shared, intentionally or not, with more portable (and therefore
Mark,

I think the point is that for privacy we _don't_ want IP addresses to
identify individuals, but it is work to ensure that they don't. The
fact that a device can be shared makes the coupling weaker, but
probably not weak enough to be considered good privacy unless the
population sharing the device is large enough to avoid statistical
inference.

> thoe se of the device's owner.

I believe there is. It is common for apps, like email, social
networking, etc. to login to a service with username and password.
When login is done, the service now has a mapping of an individual to
an IP address. That mapping could then be exploited to identify the
same individual in completely unrelated communications, hence breaking
privacy. This could be done external to the device and the network
provider and across different jurisdictions. The problem is
exacerbated if the app is always connected so that whenever the
devices gets a new IP address to user mapping maintained by some third
party is kept up to date. Also, in this case, randomizing addresses at
some frequency may no provide much benefit to privacy unless every
connection gets a different source address (which is effectively is
what CGNAT gives).

Tom