On Jul 15, 2017 12:33 PM, "Roland Zink" <rol...@zinks.de> wrote:
see inline Roland Am 15.07.2017 um 03:40 schrieb Watson Ladd: > On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins <rdobb...@arbor.net> > wrote: > >> On 15 Jul 2017, at 1:01, Melinda Shore wrote: >> >> It might make sense to kick it over to ops for a discussion with people >>> whose meat and potatoes is monitoring, management, and >>> measurement. >>> >> >> As someone who is ops-focused, I think this is an excellent suggestion! >> >> There have been several assertions posted to the list recently regarding >> various aspects of security and their intersection with encryption. It may >> be useful to take a moment and clarify a few of them. >> >> With regards to DDoS mitigation as it relates to encrypted attack >> traffic, only a subset of attacks in a subset of situations can actually be >> adequately mitigated without full visibility into (and often the ability to >> interact with) the traffic within the cryptostream. There are various ways >> to approach this issue, including full session termination and >> 'transparent' detection/classification, the latter of which isn't of course >> feasible in a PFS scenario. Each of these general approaches has its >> advantages and drawbacks. >> > > DDoS mitigation can be done at endpoints, and indeed has to be given > that other tools do not know which endpoints need to be rate-limited > or are expensive. A lot of distinct things are being crammed together > into DDoS, and the fact is endpoints can deal with application layer > attacks via rate-limits, CAPTCHAs, and other techniques, while > not-application layer attacks don't require visibility to defeat. What > can a middlebox do that an endpoint cannot? Globbing a bunch of > distinct things together is not helping the debate. > One thing which can be done is identifying the sources and notifying the owner of the devices so they can be cleaned. How does an endpoint not know the source? > In many scenarios, one form or another of network-based visibility into >> encrypted traffic streams within the span of administrative control of a >> single organization is legitimate, vital and necessary. It is not >> 'wiretapping', any more than tools such as tcpdump or telemetry formats >> such as IPFIX and PSAMP can be categorized as 'wiretapping'. The fact is, >> the availability, confidentiality, and integrity of systems, applications, >> and networks that everyone on this list relies upon is highly dependent >> upon the ability of organizations to have visibility into encrypted traffic >> streams within their own networks, for purposes of security as well as >> testing and troubleshooting. >> >> >> How this can be accomplished is a matter for further discussion. But >> it's important that everyone focused on this topic understands that it is >> simply not possible to successfully defend against many forms of DDoS >> attacks nor to detect and classify hostile network traffic in the context >> of encrypted communications without visibility into the traffic in >> question, via some mechanism. The same goes for troubleshooting complex >> problems. >> > Which DDoS attacks specifically? And if the traffic isn't hitting > endpoints, does it matter? > Yes, DDoS cause damage to dumb networks in between as well. I'm not talking DDoS. I'm talking attack traffic. You need to talk about specifics you cannot solve other ways. DDOS isn't specific enough. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
