Am 16.07.2017 um 00:07 schrieb Watson Ladd:
On Jul 15, 2017 12:33 PM, "Roland Zink" <rol...@zinks.de
<mailto: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 <mailto: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?
An endpoint has information about the source IP address. It may not have
an IP adress before NAT, email adress, postal adress or information
about building / desk number. A middle box having more exact information
about the source may notify the source owners which often are victims
themselves.
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.
I was not talking about how it could be detected or prevented only that
it matters before it is hitting the endpoint and if there is a way to
avoid it then it should be avoided.
_______________________________________________
TLS mailing list
TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
