Re: [v6ops] Google Alert - IPv6

[<[e-mail]>]

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. 

, 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