At 17:11 +0000 3/28/06, bmanning@vacation.karoshi.com wrote:

>> 1) The attacks use spoofed source addresses. This ain't something
>> that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged.

>
> the real problem..


Yes, then we don't need to worry that DNS amplifies. I have no
problem with that.

> other applications do this too.


As in "but, ma, the other kids were throwing rocks too."

> kind of like http, eh?


Kind of, but no. HTTP uses stream based transport, which is not
suitable for the spoofed-packet-DNS-amplified attacks.

>> Item 3 is something that can be dealt with within the protocol. And
>> this is what my goofy idea addresses.


The only reason why I bothered to pursue this is that it would be
good if protocols "took care of their own laundry." They don't have
to, but it would be good.

>> Potential Solution:
>>

> so, we give the bad boys an -EXTRA- communications channel
> as an effective deterent?
> what could you do with those extra padding bits?


No, we aren't. What the padding is doesn't matter. It's not like I
can't hide secret messages in images or mail.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: