[ratelimits] RRL vs other approaches

[Paul Vixie]

...

David Miller wrote:
> On 2/19/2013 10:02 AM, Paul Vixie wrote:
>> ...
>>
>> Jared Mauch wrote:
>>
>>> Sending back TC to "authenticate" clients would likely help reduce the abuse of 'udp any'
>> no. really. not. the subsequent udp queries you would prospectively
>> receive following a successful tcp session in the above scenario need
>> not be truly sourced. using a successful tcp session as a gate to a
>> lightweight udp session is entirely wrong in terms of protecting
>> spoofed-source victims from your orbiting death ray projector. (i'm
>> touchy about this since i had the same idea and vernon had to straighten
>> me out on the subject.)
>
> Agreed, if you are only "authenticating" source IP.  If TC->TCP was
> "authenticating" other characteristics as well I would hope for better
> results.  Some characteristics that could be used, off the top of my
> head, would be TTL, DO bit, EDNS/bufsize.

i don't see why the IP.TTL or DNS.BUFSIZE should be similar between
successive tcp and udp queries from a given client to a given server.
the kernel will usually have a different IP.TTL default for tcp than for
udp, and i expect that a dns initiator will use a 4K bufsize in the tcp
case but a 1500 byte (or 1280 byte, or 1024 byte) bufsize in the udp
case. middleboxes could also modify UDP in transit while leaving TCP
intact, or vice versa. not even successive UDP queries need necessarily
have similar IP TTL or DNS BUFSIZE values.

if we want a lightweight session protocol to assure ourselves that a UDP
datagram's IP source address is not forged, then we should be looking
harder at SIG(0) or TKEY or RFC6013/TCPCT or
http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-02. we're not
going to get anything that will help us with hints or implementation
details or half measures.

paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/ratelimits/attachments/20130219/2efb4169/attachment-0001.htm>