Re: Naive question on multiple TCP/IP channels

[Christopher Morrow <[e-mail]>]

On Wed, Feb 4, 2015 at 4:23 PM, Phillip Hallam-Baker
<[e-mail]> wrote:
>
>
> On Wed, Feb 4, 2015 at 4:00 PM, Christopher Morrow <[e-mail]>
> wrote:
>>
>> On Wed, Feb 4, 2015 at 3:47 PM, Phillip Hallam-Baker
>> <[e-mail]> wrote:
>>
>> > I know that traditionally we have considered congestion control to be a
>> > per
>> > connection thing rather than per process or per user. Those don't
>> > exactly
>> > exist in the Internet model. But if we consider DDoS to be an extreme
>> > form
>> > of congestion, we have to look at the O/S implementing broader rate
>> > limiting
>> > anyway.
>>
>> I'm not sure this scales in a useful manner...especially if you want
>> (for instance) to be able to read from your cloud/nas/etc at 'line
>> rate' but then limit access rates to other places because of 'dos'
>> concerns.
>
>
> No it is not simple at all!

I'm glad we agree about this.

> At a gut level, there is something wrong if a node is generating vast
> numbers of
> SYN messages and never doing anything more. But only looking for SYN floods
> at the network border means the attackers will attempt some Data as well.
>
> Working at the endpoint is a lot simpler but then we rely on the endpoint
> not
> being compromised which is a bad assumption for a machine doing DDoS
> attacks.
>

yes. there are a god number of 'not compromised' endpoints which also
are used for dos attacks. Complicit users are also a 'problem' to keep
in mind.

> The reason I am doing this work is to try to work out what controls to place
> where.Traditionally a firewall has been seen as a device that protects the
> local
> network from attacks coming in. But preventing outbound attacks is equally
> important. Nobody is going to bother attacking Comcast's customers if
> all their residential gateways have egress controls that make them
> useless as bots. Conversely nobody is going to pay for Comcast service
> if the egress controls makes it useless for browsing etc.
>

Right, this was my 'the controls are not that simple nor reasonable' comment.
ArborNetworks (for one simple example) has some decent heuristics in
place for 'anomalous traffic identification', you might ask them about
how some of that scales to 'residential gateway' sorts of locations.

Keep in mind that if you have 100,000 bots 10pps of icmp which seems
'reasonable' is 1mpps of icmp in aggregate at the far end of the
network. Individual end systems don't have to contribute much to cause
a problem.

Change icmp (becuse icmp is evil, right?) to http or https .. and
change 10pps to 1pps ... you still have a significant canon to aim
that will cause an outage for almost all websites (over 95% probably?
[note no citation] enough that 'almost all' counts). You also,
clearly, don't have to aim your http request to an actual webserver...
100kpps if syn traffic is really quite a lot for 'almost all'
endpoints on the internet to sink.

The problem of classification of traffic like this, without
coordination amongst your monitoring nodes, is ... hard.

>> Policy for that is not going to be clear, or simple, or reasonable.
>>
>> > If the case for multiple streams is better performance based on
>> > friendlier
>> > slow start parameters, maybe these should be allowed without the end
>> > run. If
>> > the net is surviving with people starting five streams instead of one,
>> > maybe
>> > the slow start parameters could start at five packets per destination
>> > host
>> > instead of one per connection. It would be a little more code to
>> > implement
>> > but speed is hardly an issue where its purpose is throttling anyway.
>>
>> More connections means you may avoid the 'random early drop' problem
>> for some of your connections, right? Presuming somewhere between
>> src/dest there's a thinner pipe (or more full pipe) and RED/etc is
>> employed (or just queue drops in general), putting all your eggs in
>> one connection basket is less helpful than 5 connection baskets.
>
>
> Hmm, again sounds like gaming the congestion parameters rather than
> an argument for a particular approach.
>

maybe? but if you look at SPDY/http2 I think the goal there is to stop
serializing, change to a binary and compressed format for data and add
channels inside the single tcp/udp stream. Fill the pipe as quickly as
possible and keep it full for the maximal amount of time.

>> One connection (one traditional http/tcp connection) also means object
>> serialization gets you as well. (I think roberto alludes to this
>> above)
>
>
> There are several necessary functions. One of them is MUX and another of
> them is serializing data from API calls. The question being which function
> each belongs at which layer.