back to article APNIC boffins may enlist TCP to defend DNS

Could defending the Domain Name System (DNS) infrastructure against amplification attacks be as simple as switching protocols in resolvers? Probably not – but an experiment conducted at APNIC has far-reaching implications. As Geoff Huston, chief scientist at APNIC, writes, DNS amplification attacks are easy to launch and can be …

COMMENTS

This topic is closed for new posts.
WTF?

DamifIknow...

how to test my home kit to see if it's up to snuff on this.

1
0
Silver badge
Facepalm

RPF

RPF. If a packet arrives on an an interface that it can't possibly logically arrive through, you JUST DROP IT; bill the customer for the traffic if you so desire, but JUST DROP IT...

How hard is this?

2
0
Unhappy

Re: RPF

The ignorance of network operators just knows no bounds.

1
0
Anonymous Coward

Re: RPF

Or implement BCP38 but that's only been around for 13 years without people bothering with it!

3
0
Gold badge
Unhappy

So half assed end point implementations of the standard? That includes Applye's

The other issue is throughput

Presumably most DNS servers handle a huge number of requests and multiplying the size and number of standard requests is going to have a substantial impact on that.

<sigh>

But maybe that's the price you have to pay for a more robust internet that cannot be partly broken by some skiddie with a grievance against their boss/bank/mommy/The Trilateral Commission etc.

7
0
Silver badge

Latency.

UDP:

[Client]: Give me an A-record for theregister.co.uk

[Server] 95.52.96.89

Time taken: 1x RT

Packets: 2

TCP:

[Client] Give me an A-record for theregister.co.uk

[Server] No can do. TCP only.

[client] SYN! Request conversation!

[server] Acknowledge. Fire away!

[Client]: Conversation ok. Give me an A-record for theregister.co.uk

[server]: 95.52.96.89. I'm done talking.

[Client] Me too. Over and out.

Time taken: 3x RT (not including final packet).

Packets: 7

At an RT of 300ms (Hardly unusual), that's more than half a second extra delay. Now multiply that by all the domains holding different scripts, static image servers, ads and such on a typical webpage...

4
0
Gold badge
Unhappy

Re: Latency.

"Packets: 7

At an RT of 300ms (Hardly unusual), that's more than half a second extra delay. Now multiply that by all the domains holding different scripts, static image servers, ads and such on a typical webpage..."

Exactly

That's what I was afraid of.

Too bad, it seemed like a plausible quick fix.

Oh well....

0
0
FAIL

Nope, this won't work

Won't work - as TCP is stateful it requires storage on the host. It now becomes vulnerable to a syn flood DDOS clogging it up.

http://en.wikipedia.org/wiki/SYN_flood

This is a no-go dead-end.

2
0
Silver badge

Re: Nope, this won't work

Mmm. I fear you may well be right.

Perhaps the answer to asymmetric attacks, is to require all UDP packets to be at least 512 bytes, or get dropped.

thus removing the asymmetry.

0
0

Re: Nope, this won't work

Are you ignoring the eight countermeasures listed in the Wikipedia reference you gave?

1
0
FAIL

Re: Nope, this won't work

The post was about using TCP - I was pointing out that it won't work. A one liner of 'you can do this' means nothing. With regards to the 'fixes' in RFC4987, no, they're not being ignored:

Filtering - if you can filter, you can filter UDP

Increasing Backlog - RFC 4987 states this 'has serious negative aspects' and no-one's got it to work.

Reducing SYN-RECEIVED Timer - best you look up how long this timer stays open and how much would you cut it down to - then consider how much memory you have and how much a TCB costs.

Recycling the Oldest Half-Open TCB - this doesnt stop being swamped, it stops running out of memory - you can still be flooded with TCB from a DDOS and stop it working. Also a DDOS attack will knock out a valid connection if its half-open mode so its still broken.

SYN Cache - a decent DDOS will break this.

SYN cookies - this will increase the time before you're flooded - you still store a TCB, just smaller. And its complicated.

Hybrid Approaches - this isnt an approach - its a mixture of others.

Firewalls and Proxies - use these to filter UDP and its fixed as well.

See the above? That's called research.

So no, it won't work. You have a separate set of just-as-complex problems.

0
0

Compromise

Use UDP normally, but switch to TCP only if a DNS server is under attack. Might even deter attacks, if attackers know the results will be limited.

1
1

This post has been deleted by its author

Bronze badge
Childcatcher

Re: Compromise

And yet in order for attackers to be deterred, they would probably have to be aware why their attack would not work, allowing them to come up with a workaround. Perhaps they might start a reflection attack and then move on to a DDoS once the switch had been made to TCP., or run both simultaneously.

0
0
Bronze badge

Who the hell made those slides?

The NSA?

0
0
Silver badge

This was a problem 15 years ago along with ICMP amplification

And mostly solved by rate limiting queries coming from any given IP address (claimed or real).

The REAL problem (as with open mail relays) is that there are a LOT of systems running very old code or with no administrators (or both) and unless someone goes around doing the elctronic equivalent of knocking a few hats off on the street, they won't get fixed.

Moving to TCP would help a little but isn't much use against DDoS attacks.

0
0

Me thinks...

We'll just come full circle again, once we find another exploit, and some hacktivist programers turn it into a simple method for attack.

0
0
This topic is closed for new posts.

Forums