Dear Stephen, See comments inline. On Oct 29, 2013, at 3:49 PM, Stephen Farrell <[email protected]> wrote:
>> (elided) ...some of us actually >> want that data to prevent and investigate real and legitimate fraud and >> abuse within the communications systems, optimize network transport etc. > > Countering fraud is a real requirement, agreed. I don't accept > that that implies a requirement that pervasive monitoring be > possible. But there are trade-offs and we do need to consider > those carefully. > > Optimising transport seems bogus though - can you provide a > reference or argument as to why you'd need to pervasively monitor > in a privacy unfriendly way to do that? A few distinctions might be useful. Packet routing itself (assuming BCP38 is used) clarifies where a message originated based on the source IP address. In the case of IPv4, this alone can defend a service from abuse. When dealing with encrypted traffic over IPv6, there is a much greater need to obtain validated identifiers of exchange initiators. From a transport perspective, this might be a certificate (PKI or DANE) associated with that of the client. Reverse DNS will be ineffective at dealing with abuse emitted from compromised systems. Most of these will employ privacy extensions which means caching offers little benefit. There will also be high levels of DNS server timeouts with delays consuming port resources. In addition, port exhaustion may not be noted in system logs. All of this offers users a poor and unfriendly Internet experience. Would having an ability to monitor source domains in conjunction with opaque content represent an unfriendly privacy exposure? For example, say the domain "telco.com" is validated, but none of the phone numbers exchanged can be determined. By knowing it is "telco.com" and not "abusive-telco.com", the receiving server can defend services without expending excessive port services or enduring delays waiting for DNS responses. Being able to validate a domain as the source of the exchange can be mitigated by allowing indirection to occur as an immediate next hop. While pervasive monitoring of all traffic to and from a service end point may give clues about intended recipients, underlying conversations are not exposed. It is even conceivable next hops could represent a type of domain randomizer resulting from some type of domain decoding. Something akin to BATV like proxy comes to mind. Regards, Douglas Otis _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
