Re: [dnsext] Comments on draft-vandergaast-edns-client-ip-00

On Tue, Mar 30, 2010 at 5:09 PM, Matthew Dempsky <matthew <at> dempsky.org> wrote:
> The current draft suggests to me that the cache should send two
> queries concurrently to the authoritative server:
>
>    www.example.com A? [client-ip: 1.2.3/24]
>    www.example.com A? [client-ip: 5.6.7/24]
>
> An attacker could send a forged response that claims to be valid for
> the entire 0/0 address block, and the cache would potentially match it
> against either of these outstanding queries, thereby increasing his
> chance of successfully poisoning the cache.

My reading of section 4.2 was that this type of attack is not
possible, because the address and family in the response must reflect
that of the request. So 0/0 would not be a valid reply - but 1.2.3/0
and 5.6.7/0 would be valid. This seems to suggest that the protocol
actually permits for more entropy in the request/response transaction,
rather than less. Up to 128 bits in the IPv6 case, and 32 bits in the
IPv4 case.

> The "For privacy reasons, ..." paragraph seems redundant with the
> earlier mention of "The address SHOULD be truncated ...".  If not, the
> requirement that "the address MUST be truncated to a certain number of
> bits" is unclear.  I don't see a reason to forbid sending the full IP
> address, and as no specific number is given, it's impossible to comply
> anyway.  (Section 8 suggests 24 bits for IPv4, but offers no advice
> for IPv6.)

There is no established filtering size yet established amongst the
BGP-using IPv6 community. Personally I think that /48 would be

Re: [dnsext] Comments on draft-vandergaast-edns-client-ip-00

2010/3/31 Colm MacCárthaigh <colm <at> allcosts.net>:
> My reading of section 4.2 was that this type of attack is not
> possible, because the address and family in the response must reflect
> that of the request. So 0/0 would not be a valid reply - but 1.2.3/0
> and 5.6.7/0 would be valid.

No, see paragraph 5 of section 4.2, particularly the second sentence:

   Conversely, a lower NETMASK indicates that more bits than necessary
   were provided.  In this case, the ADDRESS in the reply MUST be
   truncated according to the new NETMASK value, as described in
   Section 3.

Re: [dnsext] Comments on draft-vandergaast-edns-client-ip-00

2010/3/31 Matthew Dempsky <matthew <at> dempsky.org>:
> No, see paragraph 5 of section 4.2, particularly the second sentence:
>
>   Conversely, a lower NETMASK indicates that more bits than necessary
>   were provided.  In this case, the ADDRESS in the reply MUST be
>   truncated according to the new NETMASK value, as described in
>   Section 3.

Oh, then I agree that that should be changed.

--

-- 
Colm

[dnsext] draft-vandergaast-edns-client-ip-00 and combining queries

BIND 9 will combine queries currently.  That is, if a query for foo.com
is already in progress another query from a client will cause it to
merge into that same work item.  I think this was likely a premature
optimization, but my gut also tells me that this is going to be very
useful for DNSSEC validation, which can take a while and requires a bit
of work.  There is no need to ask org 100 times for isc.org after all
just because 100 clients asked for it in rapid succession.

Now, with this client-ip idea, it seems this may no longer work as
expected.  Many more queries may be issued to servers which otherwise
would be pooled together.

I know this is a single implementation's issue perhaps, but it is
something that may be an observable change in the wild.

--Michael

Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries

> Date: Wed, 31 Mar 2010 19:04:52 -0500
> From: Michael Graff <mgraff <at> isc.org>
> 
> BIND 9 will combine queries currently.  That is, if a query for foo.com
> is already in progress another query from a client will cause it to merge
> into that same work item.  I think this was likely a premature
> optimization, ...

it's necessary and correct in the face of dns birthday attacks.

	https://www.kb.cert.org/vuls/id/457875

> ... but my gut also tells me that this is going to be very useful for
> DNSSEC validation, which can take a while and requires a bit of work.
> There is no need to ask org 100 times for isc.org after all just because
> 100 clients asked for it in rapid succession.

agreed.

> Now, with this client-ip idea, it seems this may no longer work as
> expected.  Many more queries may be issued to servers which otherwise
> would be pooled together.

client-ip is a bad idea for other better reasons than this.

> I know this is a single implementation's issue perhaps, but it is
> something that may be an observable change in the wild.

and it's not a single implementation's issue.

Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit

This appears to have black-holed yet again.   Could we please work this through to a valid and supportable
conclusion?  The language in -11 is wrong.

Mike

At 03:51 AM 3/24/2010, Michael StJohns wrote:
>Attached is a first cut at the processing diagram.
>
>Note that non-validating resolvers get treated as if they are validating resolvers that have no
configured trust anchors - because of caching issues.
>
>The definition of "covering trust anchor" is as described in the discussion below.  e.g. a name is covered
if it has a covering trust anchor and has no covering exception.
>
>Feel free to mark this up and repost.
>
>Mike
>
>
>
>At 02:59 AM 3/24/2010, Michael StJohns wrote:
>>At 05:59 PM 3/23/2010, Samuel Weiler wrote:
>>>During today's meeting, MSJ asked what happened to this.  As doc editor, I apologize for not catching
this explicitly during this revision cycle, but (editor hat off) I don't entirely agree with the
recommendations below.
>>>
>>>On Thu, 15 Jan 2009, Michael StJohns wrote:
>>>
>>>>"If the validating recursive resolver has a trust anchor covering a request, it MUST set the CD bit on
its upstream query regardless of the CD bit setting of the request.

Re: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08 - Setting of CD Bit

On Wed, 31 Mar 2010, Michael StJohns wrote:

> This appears to have black-holed yet again.  Could we please work 
> this through to a valid and supportable conclusion?  The language in 
> -11 is wrong.

It's not black-holed, I just didn't delve into it in depth during the 
meeting week.  Both this and the rollover-and-die fixes need work.
Would you feel better if we pushed a -12 saying "this section is still 
broken"?

-- Sam

Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries

On Wed, Mar 31, 2010 at 7:23 PM, Paul Vixie <vixie <at> isc.org> wrote:
>> Date: Wed, 31 Mar 2010 19:04:52 -0500
>> From: Michael Graff <mgraff <at> isc.org>

>
>> Now, with this client-ip idea, it seems this may no longer work as
>> expected.  Many more queries may be issued to servers which otherwise
>> would be pooled together.
>
> client-ip is a bad idea for other better reasons than this.

Can you elaborate? Is it because it provides more specific, better
answers (read: different) based on who is querying much like Akamai,
Google, Yahoo, Amazon, etc. do today on the authoritative side?  Or
are you opposed to something more fundamental about the idea or
implementation itself?

-David

[dnsext] Question about content in EDNS0bis-03

Re: [dnsext] draft-vandergaast-edns-client-ip-00 and combining queries

> Date: Thu, 1 Apr 2010 08:24:54 -0700
> From: David Ulevitch <david <at> ulevitch.com>
> 
> > client-ip is a bad idea for other better reasons than this.
> 
> Can you elaborate? Is it because it provides more specific, better
> answers (read: different) based on who is querying much like Akamai,
> Google, Yahoo, Amazon, etc. do today on the authoritative side?  Or are
> you opposed to something more fundamental about the idea or
> implementation itself?

before i elaborate, can ed lewis talk about complexity and q-tuples again plz.