I think Brian has made a great point below. I’d like to provide a few more examples (all real) of scenarios where criminal investigations can rely heavily on the logs retained by the victim or the platform.
1. A person running a content business (e.g. blog) and their platform is compromised and defaced. 2. An organisation’s corporate website is compromised and used to host child porn (at a hidden URL). 3. Links that serve malware posted in comments of blogs, with malware hosted on separate (compromised) sites. 4. Email credentials of an employee in an organisation compromised, log in to employee’s webmail and send fake invoices to trick company to transfer money into wrong account (BEC fraud). 5. Compromise of email account and used to send fake invoices (same as above, but SMTP/POP rather than HTTP) 6. Banking credentials of customers are compromised, fraudster logs in and transfers funds out of customer account. 7. Purchase and sale of drugs, guns, etc. on dark web (although this is a whole other can of worms, Tor etc…). 8. Posting of “revenge porn” pictures. Before the group launches into a debate about the pros and cons of the examples that I provided above, I wanted to say that the only point I’m making is that there are at least some reasons why routine source port logging would be advantageous in cases where CGN (or other large-scale address sharing technologies) are involved. The question of how long these logs are retained for is, as Brian also probably rightly points out, not likely to be something that the IETF can meaningfully adopt a position on. daveor > On 24 Apr 2018, at 23:53, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > On 25/04/2018 01:25, Ted Lemon wrote: >> On Apr 24, 2018, at 9:11 AM, <mohamed.boucad...@orange.com> >> <mohamed.boucad...@orange.com> wrote: >>> What sort of trade-offs can be added to Dave’s document? Do you have in >>> mind something like: >>> (1) >>> - Warranting that logging may be misused for tracking users? >>> - Logging information can be used for profiling users? >>> - Not logging is also an option? >> >> I don't think Dave's document is a good starting point. Amelia (I think it >> was Amelia) already pointed out a number of things to talk about: for >> example, if you are going to log source ports, it should be possible to log >> them only when doing so is necessary, and not log them at other times. > > I have trouble with that. When a user complains that "my transaction at 23:59 > UTC > yesterday failed", it's too late to switch on logging. So I think in > practice, logging > for problem debugging needs to be switched on 24x7. Similarly for abuse > detection, > since you can't predict when abuse will happen. I don't think there's a get > out > of jail card here. The problem is what happens to the logged data later, and > that > is a regulatory issue that the IETF can do absolutely, utterly nothing about. > > Brian _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
