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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Ole Troan [mailto:[e-mail]]
> Envoyé : vendredi 27 octobre 2017 08:49
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Dave O'Reilly; [e-mail]; Tore Anderson
> Objet : Re: [SUSPECTED SPAM] RE: [v6ops] Google Alert - IPv6
> 
> 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.

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

> The operator of a stateless A+P solution like map-e or t or lw46 does not
> 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.   

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