Subject: [spfbis] on theoretical attacks (was: Draft agenda for IETF83)

From: Arthur Thisell <[email-masked]>
Date: Mon, 19 Mar 2012 20:06:34 -0700 (PDT)

Based on what I've read, I too feel that putting up a 20min session on the amplification factor would not be productive.

> As John pointed out,
> despite Doug vocally asserting this as a significant issue, he has not
> attracted significant (I was going to say any) support within the
> community of folks actively working in this space.

It isn't that the subject of a DDOS attack and the amplification factor hasn't gotten any support, it is Doug's presentation that hasn't.   Doug wasn't the first to raise the subject of SPF's amplification.  Indeed, the vastly more restrictive processing limits in libspf2 were added before Doug made his first post on the subject.

The problem is that Doug has done nothing new and is still presenting his old ID as if it hasn't been read, analyzed and rejected.   Indeed, he recently wrote:

> the use of macros and insensitivity to no-data errors permits a 1 KB message to generate (34.8KB +28.8 KB) x 4 or 254KB of victim traffic against any domain that simply supports DNS.

There is the problem.   A scary 254k number, but ignores the flaw that it isn't 1KB of traffic that the attacker needs to be able to generate in order to create that attack, it is far larger.

I have read Doug's paper, and I reject the conclusions due to false premises.   I have spelled out these problems years ago, and I do not think it would be productive to continue to rehash old arguments. This draft has been presented at at least one previous IETF meeting, isn't like it hasn't been given a fair hearing.  Obviously, nothing anyone says is going to change Doug's mind, and Doug hasn't changed anyone else's mind.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Mar 2012 17:09:19 -0700

On 3/19/12 8:06 PM, Arthur Thisell wrote:
>  Based on what I've read, I too feel that putting up a 20min session
>  on the amplification factor would not be productive.
>
> > As John pointed out, despite Doug vocally asserting this as a
> > significant issue, he has not attracted significant (I was going to
> > say any) support within the community of folks actively working in
> > this space.
>
>  It isn't that the subject of a DDOS attack and the amplification
>  factor hasn't gotten any support, it is Doug's presentation that
>  hasn't. Doug wasn't the first to raise the subject of SPF's
>  amplification. Indeed, the vastly more restrictive processing limits
>  in libspf2 were added before Doug made his first post on the
>  subject.

Dear Arthur,

This concern has continued from when SPF advocated 20 deep recursions as 
a method to constrain the DNS transactions that SPF generated from one 
message.

>  The problem is that Doug has done nothing new and is still presenting
>  his old ID as if it hasn't been read, analyzed and rejected. Indeed,
>  he recently wrote:
>
> > the use of macros and insensitivity to no-data errors permits a 1
> > KB message to generate (34.8KB +28.8 KB) x 4 or 254KB of victim
> > traffic against any domain that simply supports DNS.
>
>  There is the problem. A scary 254k number, but ignores the flaw
>  that it isn't 1KB of traffic that the attacker needs to be able to
>  generate in order to create that attack, it is far larger.

The number of resource records an attacker needs to publish in order to 
enable this reflected attack will not reduce the traffic experienced by 
victims.  This assertion also ignores different treatments for negative 
responses versus an attacker's positive responses.

The attacker has a significant advantage when requested negative 
durations by victim's domains are often shortened to avoid dealing with 
"disruption" induced support calls.  Once their campaign exceeds 
negative caching durations used by recipients and the attack sequence 
repeats, an attacker's resources will be locally cached with 
transactions repeated against their victims.  At this point, no new 
responses are required by the attacker!  There is nothing that prevents 
the same resources from being shared between an attacker's various Mail 
 From domains to leverage these hot and evil cached resources.

Regards,
Douglas Otis