Colm MacCárthaigh | 1 Apr 01:40 2010
Picon

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
(Continue reading)

Matthew Dempsky | 1 Apr 01:46 2010

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.

Colm MacCárthaigh | 1 Apr 01:58 2010
Picon

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

Michael Graff | 1 Apr 02:04 2010

[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
Paul Vixie | 1 Apr 04:23 2010

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.

(Continue reading)

Michael StJohns | 1 Apr 04:50 2010
Picon
Picon

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.
(Continue reading)

Samuel Weiler | 1 Apr 04:58 2010

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

David Ulevitch | 1 Apr 17:24 2010

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

Edward Lewis | 1 Apr 18:25 2010

[dnsext] Question about content in EDNS0bis-03

Referring to:
http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-03

# 6.2.  OPT Record Format
#
...
#   Any OPTION-CODE values not understood by a responder or requestor
#   MUST be ignored.  Specifications of such options might wish to
#   include some kind of signaled acknowledgement.  For example, an
#   option specification might say that if a responder sees option XYZ,
#   it MUST include option XYZ in its response.

What does "MUST be ignored" entail?  Is the option repeated in the response "silently" copied into the reply or is it omitted from the response?  This question has arisen from an internal discussion.

The second sentence is what is making interpretation difficult.  If ignoring means to drop the option from the response, then the mere presence of the option in the response would be "some kind of signaled acknowledgement."  But then there's the mention of "might wish to include" one, which implies that there would always be the option in the response.

In the third sentence, what does "sees" mean - does it mean "understands"?  The dilemma here is if the implementation is to adhere to the example rule, the implementation had to be aware of the option's definition, therefore be cognizant of the option (despite perhaps not implementing it).

Is it thought that unrecognized (by the responder) EDNS0 options are not parsed, not read, and omitted in responses it emits?
-- --
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

New pithy statement under construction...
Paul Vixie | 1 Apr 18:58 2010

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.


Gmane