headers
Kevin Darcy | 1 Sep 2006 06:00
Picon

Re: RFC proposal on DNS spoofing prevention

Robert Story wrote:
> On Thu, 31 Aug 2006 15:18:10 +0300 Andreas wrote:
> AG> >  Given the above, a resolver MUST:
> AG> >
> AG> >   o  Use a new random source port from its available range for each
> AG> >      outgoing query
> AG> 
> AG> I don't think this MUST is realistic for high-volume servers.  In
> AG> practice, most caching servers run on operating systems that require a
> AG> separate open file descriptor for each port, and on a busy server the
> AG> number of outstanding queries can easily exceed the number of
> AG> available file descriptors.
>
> What about relaxing this rule a bit? Simply deleting the word 'new'
> would allow for using a pool of N random ports, where 1 < N < OS
> file descriptor limit. And if N is small, periodically cycling some/all
> of the pool might be a good idea too.
>
>   
Thinking as an implementor, the term "random source port" to me means 
invoking a randomization function every time a source port is chosen, 
regardless of whether the term is preceded by the adjective "new" or 
not. If it is the intent to allow a "two-stage" randomization, in which 
random source ports are periodically chosen from the available range, 
and source ports are randomly chosen from that pool as they are needed, 
then perhaps the document should be more explicit about allowing that 
approach, as well as giving a recommendation for how frequently the pool 
should be re-randomized (as you imply in your note, the frequency of 
re-randomization should probably be a function of how large the pool 
is), and recommending _against_ making either stage
(Continue reading)

Permalink | Reply | 3 comments |
headers
Olaf Kolkman | 1 Sep 2006 08:35
Picon
Favicon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Andrews | 6 Sep 2006 04:58

Re: leading zeros, odd digit counts in salt


   *  The Salt field is represented as a sequence of case-insensitive   
      hexadecimal digits.  Whitespace is not allowed within the
      sequence.  The Salt Field is represented as "-" (without the  
      quotes) when the Salt Length field has value 0.

	I think the above needs to be tightend to say that leading
	zeros *are* significant and that there be pairs of hexadecimal
	digits.  A salt is not a number and shouldn't be treated as
	such.

   *  The Salt field is represented as a sequence of pairs of
      case-insensitive hexadecimal digits.  Leading zeros are significant.
      Whitespace is not allowed within the sequence.  The Salt Field
      is represented as "-" (without the quotes) when the Salt
      Length field has value 0.

	e.g. 00ff indicates a salt of length 2 with the first 8 bits set
	to zero and the second 8 bits set to 1.

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 501 comments |
headers
Roy Arends | 6 Sep 2006 12:17
Picon
Favicon

Re: leading zeros, odd digit counts in salt

owner-namedroppers <at> ops.ietf.org wrote on 09/06/2006 04:58:43 AM:

> 
>    *  The Salt field is represented as a sequence of case-insensitive 
>       hexadecimal digits.  Whitespace is not allowed within the
>       sequence.  The Salt Field is represented as "-" (without the 
>       quotes) when the Salt Length field has value 0.
> 
>    I think the above needs to be tightend to say that leading
>    zeros *are* significant and that there be pairs of hexadecimal
>    digits.  A salt is not a number and shouldn't be treated as
>    such.
> 
>    *  The Salt field is represented as a sequence of pairs of
>       case-insensitive hexadecimal digits.  Leading zeros are 
significant.
>       Whitespace is not allowed within the sequence.  The Salt Field
>       is represented as "-" (without the quotes) when the Salt
>       Length field has value 0.
> 
>    e.g. 00ff indicates a salt of length 2 with the first 8 bits set
>    to zero and the second 8 bits set to 1.

I agree. I'll add it to the draft.

Roy

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Mike StJohns | 6 Sep 2006 18:58

Re: draft-ietf-dnsext-trustupdate-timers-03 - Last Pass

Sorry - I finished the edits on this a while ago and it sat for two 
weeks.  It has now been submitted.  I'm going to ask the WG chairs to 
schedule a WG last call to begin 1 week after publication (e.g. call 
it a week from Friday) for 2 weeks (end of September).

Mike

At 12:55 PM 8/14/2006, Mike StJohns wrote:
>OK -
>
>Speak now or forever hold your peace.  Last date for comments is Wed 
>1700 EDT this week.
>
>I'll be putting out a final version of this by the end of the week 
>with the following changes (Names in parens are the reviewers that 
>prompted the changes - thanks!).  I expect this one to go to WG last call:
>
>Adding "... - the new trust anchor will be populated at the 
>resolvers on the schedule described by the state table and update 
>algorithm - see section 2.3 above" to the end of 5.1 (Scott Rose)
>
>Pulling out the comment about whether or not to delete a trust 
>anchor after it disappears from the signed list, but wasn't actually 
>revoked - the list discussion resolved my discussion point. (Scott 
>Rose, Robert Story)
>
>Moving part of 4.3 to section 5 and labeling section 5 as 
>"Informative"  (Robert Story)

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
bert hubert | 6 Sep 2006 21:39
Picon
Favicon
Gravatar

Re: updated: Re: RFC proposal on DNS spoofing prevention

On Thu, Aug 31, 2006 at 04:39:31PM +0200, Stephane Bortzmeyer wrote:
> Good document, I've read it and I find it fine.

Thanks!

> But it should be submitted to the dnsop WG, no, since it does not
> change the protocol?

In some sense it does. You need source level changes to a nameserver to be
able to adhere to this draft. It is not an operational choice. RFC 1034
already contains language on verifying DNS question id's and addresses.

This draft actually changes DNS in that respect.

But I'm no expert on the finer points between dnsop/dnsext. Olafs?

	Bert

--

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 1 comment |
headers
bert hubert | 6 Sep 2006 21:45
Picon
Favicon
Gravatar

Re: RFC proposal on DNS spoofing prevention

On Thu, Aug 31, 2006 at 03:18:10PM +0300, Andreas Gustafsson wrote:
> >  * http://ds9a.nl/rfc/dns-anti-spoofing.html
> I read the above draft.  A few comments:

Thanks!

> The draft covers threat 2.2, "ID Guessing and Query Prediction", in
> excellent detail, but makes no mention of the others.  It would be
> helpful to note in the draft that the term "DNS spoofing" can also
> refer to threats other than those discussed in the draft.

Will do.

> "Name Chaining".  All caching server implementations in common use
> today already implement such countermeasures, typically based on
> discarding records whose owner name is outside the domain whose
> authoritative servers are being queried.  In practice, these
> countermeasures are no longer optional, but there is still no IETF
> document discussing them.

Do you think this might fit in our current draft? I personally think it
would.

> >   o  Use a new random source port from its available range for each
> >      outgoing query
> 
> I don't think this MUST is realistic for high-volume servers.  In

Some of the highest-volume resolvers (7kpqs) of the internet currently run
with a new random source port per outgoing query. All recent operating
(Continue reading)

Permalink | Reply | 1 comment |
headers
bert hubert | 6 Sep 2006 21:49
Picon
Favicon
Gravatar

Re: RFC proposal on DNS spoofing prevention

On Fri, Sep 01, 2006 at 12:00:31AM -0400, Kevin Darcy wrote:

> Thinking as an implementor, the term "random source port" to me means 
> invoking a randomization function every time a source port is chosen, 
> regardless of whether the term is preceded by the adjective "new" or 

How about changing the current rather specific instruction, which mandates a
"new random source port" for each outgoing query, to one that describes the
intended effect:

  Given the above, a resolver MUST:

    o Send outgoing queries from source ports which can not be predicted
      by observing previous queries

How the nameserver achieves this is up to the implementor to decide.

Thanks for your analysis, Kevin!

	Bert

--

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ólafur Guðmundsson /DNSEXT co-chair | 6 Sep 2006 22:29

Re: updated: Re: RFC proposal on DNS spoofing prevention

<chair-hat on>
The chairs of DNSEXT and DNSOP's are discussing which WG is more appropriate
for this work, please give us few days to figure that out.

The bigger issue right now is what Andreas raised: what is the
scope of this document see:
http://psg.com/lists/namedroppers/namedroppers.2006/msg01220.html

<chair-hat off>
My gut feeling is that it will be hard to write this or similar draft
without saying "Updates RFC1035".

         Olafur

At 15:39 06/09/2006, bert hubert wrote:

> > But it should be submitted to the dnsop WG, no, since it does not
> > change the protocol?
>
>In some sense it does. You need source level changes to a nameserver to be
>able to adhere to this draft. It is not an operational choice. RFC 1034
>already contains language on verifying DNS question id's and addresses.
>
>This draft actually changes DNS in that respect.
>
>But I'm no expert on the finer points between dnsop/dnsext. Olafs?
>
>         Bert

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olaf M. Kolkman | 6 Sep 2006 22:31
Picon
Favicon

Re: RFC proposal on DNS spoofing prevention

>
>   Given the above, a resolver MUST:
>
>     o Send outgoing queries from source ports which can not be  
> predicted
>       by observing previous queries
>

So I was doubting if that should be a MUST or a SHOULD.

RFC2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
    definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Further down in the same document:
    In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)

I think it is clear that MUST is not needed for interoperability (DNS  
has some interop trackrecord without this requirement). But it seems  
that the "limit behaviour which has potential for causing harm" does  
apply.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane