BCP38 thread 93,871,738,435 + SPF

Gadi Evron ge at linuxbox.org
Sun Oct 29 15:40:25 UTC 2006

On Sun, 29 Oct 2006, Douglas Otis wrote:
> On Sat, 2006-10-28 at 00:52 -0500, Gadi Evron wrote:
> > If you believe SPF prevents you from doing it, can you elaborate how?
> Spam referencing malicious SPF scripts can result in PASS or NEUTRAL,
> where the message and message rates may be normal.  Recipients will not
> notice the role they are playing in an ongoing attack.  There would be
> few clues, and BCP38 or ACLs will not prevent an SPF attack.
> >From a victim's perspective, there could be tens or hundreds of
> thousands of attack sources.  No source represents an address of a
> Botnet.  An attack could be composed of A-record transactions for hosts
> not seen in any message, or related to the domains of any SPF script.
> These SPF scripts might also later morph to frustrate forensic analysis
> or real-time blocking.
> SPF scripts add indirection from what is within a message.  An attacking
> transaction would pass through DNS from one of the hundred thousand
> recipients.  Finding a recipient will not link a DNS transaction to a
> message.  The source of the message may also be a reputable provider.
> The recipient would need to trace the targets of all associated SPF
> scripts.  A particular SPF script might be one of a hundred other
> scripts targeting the same victim, however.  Analysis designed not to
> add to an attack can also be seen by the attacker. 
> Nothing in the experimental SPF or Sender-ID RFCs explain how such
> catastrophic attacks are avoided.  Their recommended premature
> termination of SPF scripts ensures there is no congestion avoidance as
> well.
> How would you identify and quell an SPF attack in progress?

Okay, now I understand.

You speak of an attack specfically utilizing SPF, not of how SPF relates
to botnets or attack traceback.

The same could be said for web servers, databases behind them, DNS-SEC
crypto calculations, etc.

> -Doug


More information about the NANOG mailing list