Re: [v6ops] [SUSPECTED SPAM] RE: Google Alert - IPv6

[Ole Troan <[e-mail]>]

Med,

> On 26 Oct 2017, at 23:43, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Ole, 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : v6ops [mailto:[e-mail]] De la part de Ole Troan
>> Envoyé : jeudi 26 octobre 2017 23:26
>> À : Dave O'Reilly
>> Cc : [e-mail]; Tore Anderson
>> Objet : Re: [v6ops] Google Alert - IPv6
>> 
>> 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
> 
> [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. 
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

> 
> , 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 <[e-mail]> 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.
>>> 
>>> 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 <[e-mail]> wrote:
>>>> 
>>>> On Thu, Oct 19, 2017 at 5:23 AM,  <[e-mail]> wrote:
>>>>> 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)
>>>>> 
>>>> 
>>>> 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
>>>> 
>>>> 
>>>>> 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:[e-mail]] De la part de Mikael
>>>>>> Abrahamsson
>>>>>> Envoyé : jeudi 19 octobre 2017 09:03
>>>>>> À : Tore Anderson
>>>>>> Cc : [e-mail]
>>>>>> Objet : Re: [v6ops] Google Alert - IPv6
>>>>>> 
>>>>>>> On Thu, 19 Oct 2017, Tore Anderson wrote:
>>>>>>> 
>>>>>>> * Mikael Abrahamsson <[e-mail]>
>>>>>>> 
>>>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> --
>>>>>> Mikael Abrahamsson    email: [e-mail]
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> --===============7090974386904564375==--
>>>> 
>>>> --===============4172498714441195205==
>>>> Content-Type: text/plain; charset="us-ascii"
>>>> MIME-Version: 1.0
>>>> Content-Transfer-Encoding: 7bit
>>>> Content-Description: Digest Footer
>>>> 
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>