Subject: I-D ACTION:draft-ietf-dnsext-forgery-resilience-01.txt

From: [email-masked]
Date: Tue, 07 Aug 2007 10:15:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Measures for making DNS more resilient against forged answers
	Author(s)	: R. van Mook, B. Hubert
	Filename	: draft-ietf-dnsext-forgery-resilience-01.txt
	Pages		: 22
	Date		: 2007-8-7
	
The current internet climate poses serious threats to the Domain Name
   System.  In the interim period before the DNS protocol can be secured
   more fully, measures can already be taken to make 'spoofing' a
   recursing nameserver many orders of magnitude harder.

   Even a cryptographically secured DNS benefits from having the ability
   to discard bogus answers quickly, as this potentially saves large
   amounts of computation.

   By describing certain behaviour that has previously not been
   standardised, this document sets out how to make the DNS more
   resilient against accepting incorrect answers.  This document updates
   RFC1034.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dnsext-forgery-resilience-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-forgery-resilience-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: bert hubert <[email-masked]>
Date: Tue, 7 Aug 2007 21:59:14 +0200

And as a reminder, changes can be observed on our wiki. Additionally, the
wiki is also the place to file defects - which we will also gladly discuss
or consider reported on this list.

The wiki & issue tracker are on: 

http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/wiki/

Thanks!

On Tue, Aug 07, 2007 at 10:15:02AM -0400, [email-masked] wrote:
> !DSPAM:46b88344184348139311174!

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Shane Kerr <[email-masked]>
Date: Mon, 13 Aug 2007 12:20:32 +0200

> 	Author(s)	: R. van Mook, B. Hubert

Hello,

Regarding the "Countermeasures" section:

   Implementations SHOULD NOT use UDP source ports <1024 for sending
   queries

Why? I mean, firewalls often block these, but any special reason other than that?

   Implementations MUST use an as large as possible pool of UDP source
   ports for sending queries

Perhaps SHOULD? Because this basically means that implementations have to use
1024 to 65535 doesn't it?

- --
Shane

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Aug 2007 11:59:59 +0100

--On 13 August 2007 12:20 +0200 Shane Kerr <[email-masked]> wrote:

> Perhaps SHOULD? Because this basically means that implementations have to
> use 1024 to 65535 doesn't it?

Actually the two requirements conflict. It is *possible* to use ports below
1024. I believe the latter requirement should (in addition to being subject
to the first requirement) be a "SHOULD", else a device that for good reason
(e.g. broken middleboxen) avoids a single UDP port above 1024 (e.g. say
5060) becomes in technical breach.

Alex

---

From: bert hubert <[email-masked]>
Date: Mon, 13 Aug 2007 13:06:43 +0200

> Why? I mean, firewalls often block these, but any special reason other than that?

No, I think Peter Koch suggested it for this reason. No other special
reason, we just wanted to include the things suggested over at IETF 68.

> 1024 to 65535 doesn't it?

This is basically a knob you can turn. If you turn it to '1 source port',
you get the current situation as with BIND and Nominum CNS, Windows DNS etc.
If you turn it to 64511 you get DJBDNS or PowerDNS, and the highest
possible protection against spoofing.

Paul has an implementation that has the knob set to 16.

Our feelings are that the draft should strongly state that all available
ports should be used, but we also understand not every OS and platform can
meet this requirement.

Hence 'as large as *possible*'. So you can get out of it if your platform
does not support it.

It is expected that this 'MUST' or 'SHOULD' will be something that needs
further discussion here.

	Bert

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 13 Aug 2007 14:09:56 +0200

> It is expected that this 'MUST' or 'SHOULD' will be something that needs

It think MUST and 'as large as possible' don't combine very well;
together they still leave it open for the implementor or deployer.

In theory you could have a design or setup so that that 'as large as
possible' amounts to exactly 1...

In such cases the MUST devaluates to SHOULD anyway. While i strongly
support using as large a pool as possible, i think this should be a SHOULD.

I think i wouldn't even mind 'should' by the way; the explanation as to
why seems much more important.

Jelte

---

From: John Kristoff <[email-masked]>
Date: Mon, 13 Aug 2007 07:52:54 -0500

On Mon, 13 Aug 2007 13:06:43 +0200

> reason, we just wanted to include the things suggested over at IETF 68.

As a practical matter, there are common configurations (more so than
as an implementation pecularity it seems to me) that send queries with
source ports < 1024.  Many sites in fact statically lock in source port
53 often precisely for the same sort of reason, to get around firewalls
as unwise as that may be.  In addition, based on what I've seen, NATs
seem to sometimes map the "internally" used source port to something
less than 1024 on the outside.  Although this seems to be relatively
uncommon, it does appear to happen on occasion.

Perhaps the wording should be altered slightly to reflect that it is
a recommendation for more than just resolver implementations?

John

---

From: bert hubert <[email-masked]>
Date: Mon, 13 Aug 2007 15:03:33 +0200

> possible' amounts to exactly 1...

(...)

> why seems much more important.

The aim is to get the wording such that anybody still using 1 port will feel
bad.

There are already lots of RFCs that explain things, it would be nice to have
one with (small) teeth.

That doesn't mean we must end up with MUST, but it would be very good to
have something we can throw at people - until something comes along that
truly fixes the issue (like perhaps DNSSEC).

	Bert

---

From: Robert Story <[email-masked]>
Date: Mon, 13 Aug 2007 09:56:32 -0400

On Mon, 13 Aug 2007 15:03:33 +0200 bert wrote:
BH> The aim is to get the wording such that anybody still using 1 port will feel
BH> bad.
BH> 
BH> There are already lots of RFCs that explain things, it would be nice to have
BH> one with (small) teeth.

The only way to give it some teeth is to put in real numbers. Given
that many OSes have limits on the number of open file descriptors, I'd
say somewhere between 128-256 would be a good starting place for a
MUST.

-- 
Robert Story
SPARTA

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Aug 2007 00:27:03 +1000

> --Sig_WvFiL6hUNIVSnzzpU02.psL
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: quoted-printable
> 
> BH> The aim is to get the wording such that anybody still using 1 port will=
>  feel
> BH> bad.
> BH>=20
> BH> There are already lots of RFCs that explain things, it would be nice to=
>  have

	Let's not specify a number.  Given the limitations of OS's and
	the number of interfaces it hard sometimes to get even 1 spare
	descriptor.
 
> --=20
> Robert Story
> SPARTA
> 
> --Sig_WvFiL6hUNIVSnzzpU02.psL
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Disposition: attachment; filename=signature.asc
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> 
> iD8DBQFGwGMQ7/fVLLY1mngRAuIBAJ0UOeoaouJT/2Flcbgj1REDstEYHQCfd4c8
> iQZ6qpKB2EO4++A+t1lpQoQ=
> =oEPV
> -----END PGP SIGNATURE-----
> 
> --Sig_WvFiL6hUNIVSnzzpU02.psL--
> 
> --
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Peter Koch <[email-masked]>
Date: Mon, 13 Aug 2007 16:42:33 +0200

> No, I think Peter Koch suggested it for this reason. No other special

this was one of the operational issues I had (review of -01 still pending).
There are still many people out there with stateless packet filters and
recommending a default behaviour should take into account the consequences
for the operator.

> possible protection against spoofing.

Yes, but at what cost and operational complexity? Many sites completely block
UDP ports 2049, 135-139 and others at their perimeter.  "Chargen" is a very
nice source port for DNS queries as well, so there's a lot to avoid.
A name server that is just "as open as possible" may not see the responses
to some of the queries it sends.

1024 is not magic, but it's often enough the threshold value chosen for inbound
packets. Also, a couple of years ago CAIDA, I think, did some research on source
port distribution.  We've done some stats on our AS112 system and see similar
results (see also John K's posting):  53 is the only "low" port with noteworthy
use with huge numbers strating at 1024 and again at 32768.
Even though it would cut the space to 25%, recommending ports in the "dynamic"
port range (49152-65535), might be a better approach.

-Peter

---

From: [email-masked] (Andreas Gustafsson
Date: Mon, 13 Aug 2007 18:01:06 +0300

> you get the current situation as with BIND and Nominum CNS, Windows DNS etc.

That's not what the draft actually says.  If you "MUST use an as large
as possible pool of source ports", turning the knob to anything other
than the maximum would violate the MUST.

Let me once again voice my strong objection to this requirement.  For
one thing, it means that on any host running a DNS resolver, it would
be impossible to later add any other UDP-based services, because all
the UDP ports would already be taken.  The ability to provide multiple
services on a single host is one of the fundamental properties of the
IP protocol suite that make it useful.  Even saying that a single
protocol MAY or SHOULD monopolize all UDP ports would be antisocial
towards other protocols; saying that it MUST do so is just ridiculous.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Aug 2007 15:03:03 +0000

> It is expected that this 'MUST' or 'SHOULD' will be something that needs

"possible" is still the wrong word.  i may have other UDP apps using the
same IP address.  it's "possible" to renumber those other apps and give
DNS more ports.  it's not "reasonable" or "feasible" however.

also, i havn't read the draft, but if it doesn't separately mention stub
resolvers, it should.  a stub resolver should ideally not be required to
keep any ports open across transactions, but it can be asked to choose
port numbers that are more random than what the IP stack would assign, and
it can be asked to NOT keep this port open across multiple transactions.

---

From: John Kristoff <[email-masked]>
Date: Mon, 13 Aug 2007 10:45:25 -0500

On Mon, 13 Aug 2007 16:42:33 +0200

> use with huge numbers strating at 1024 and again at 32768.

139 is frequently seen too, but in my experience they are practially
all "bogus", at least outside the Microsoft networking world.

1024 also tends to be slightly less common than others immediately
above it, because the OS that tends to start with source ports there
often has some app listener already locked on to that port making it
unavailable for query source port selection.

I don't recall a CAIDA paper that focused on source port distribution,
and I think I've seen all their work, so I'd be interested in a pointer
if someone has one.  I did some rudimentary source port usage analysis
and presented a summary at a NANOG lightning talk a short awhile back.
Perhaps that is what you're referring to?   You probably need to watch
the video that goes along with the slides since they probably do not
stand that well on their own:

  <http://www.nanog.org/mtg-0602/lightning.html>

> port range (49152-65535), might be a better approach.

Microsoft apparently moved in this direction with their source port
selection strategy, because they were interfering with other apps
that wanted one of the registered ports.

I'm not sure that it would be necessary to recommend that change for
all resolvers however.  Perhaps it makes more sense for a stub rather
than a full, dedicated resolver?  Maybe some wording to suggest that
an implementation MAY use only those dynamic ports for the reasons
discussed?

John

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Mon, 13 Aug 2007 12:08:14 -0400

<chair-hat=on>

Section #9 of the draft contains number of recommendations on what to do,
many of these are intertwined and some can be contradictorily.

WG please take a look that section, check which RFC2119 words you would use
in each recommendation.

If you agree with the recommendations please say so, if you want discussion or
changes please post your recommendations/issues.

Editors will open an discussion item for any recommendation that 
needs discussion
and/or consensus building.

draft time line for this draft is:
         work out the issues by the end of September
         do a LC in October and advance it by November.

Remember this is a document that makes recommendations for implementations,
based on what is technically best for DNS.
Operational issues/difficulties/practices are welcome as information 
but discussion
on these is not in-scope.

The recommendations this document provides MUST allow sites to configure their
setup to adhere to site policy.

Should the document will make recommendations on default configuration and
behavior of implementations?

Should there be different recommendation sections for stub resolvers
and recursive resolvers?

         Olafur

---

From: Robert Story <[email-masked]>
Date: Mon, 13 Aug 2007 12:44:25 -0400

On Mon, 13 Aug 2007 18:01:06 +0300 Andreas wrote:
AG> That's not what the draft actually says.  If you "MUST use an as large
AG> as possible pool of source ports", turning the knob to anything other
AG> than the maximum would violate the MUST.

No, the application developer is the one following this RFC, not the
operator. If the local configure says the max is 5 ports, then using 4
or less would violate the MUST. Hopefully the operator will be familiar
with the draft, and will recognize the need set the knob as high as
possible.

AG> Let me once again voice my strong objection to this requirement.  For
AG> one thing, it means that on any host running a DNS resolver, it would
AG> be impossible to later add any other UDP-based services, because all
AG> the UDP ports would already be taken.

Any implementation that opened every available port would be a very
silly one. The draft says that 'Implementations MUST be able to send
queries from ANY UDP port available to it', so any ports in use by another application would, by definition, be unavailable. There is no conflict here.

-- 
Robert Story
SPARTA

---

From: Robert Story <[email-masked]>
Date: Mon, 13 Aug 2007 12:47:39 -0400

On Mon, 13 Aug 2007 15:03:03 +0000 Paul wrote:
PV> "possible" is still the wrong word.  i may have other UDP apps using the
PV> same IP address.  it's "possible" to renumber those other apps and give
PV> DNS more ports.  it's not "reasonable" or "feasible" however.

As I just said in another message, the application developer is the one
following this RFC, not the operator. It's not possible for an
application to renumber ports used by other applications. (well, I
suppose it could start killing other processes and messing
with /etc/services, but I think any reasonable person would know that
that's not the intent.)

-- 
Robert Story
SPARTA

---

From: bert hubert <[email-masked]>
Date: Mon, 13 Aug 2007 19:10:47 +0200

> packets. Also, a couple of years ago CAIDA, I think, did some research on source

1024 is the limit all current implementations use anyhow. It is worth
nothing that even static implementations just pick *any* port above 1024 at
startup, so they might also end up with a 'bad' one.

In practice, >1024 is not seen to be causing problems.

I don't see any reasons to advocate <=1024.

> port range (49152-65535), might be a better approach.

That is also a possible position of the knob, indeed, although it should be
said that the current servers that use 1024-65535 don't see any notable
problems.

At least none that I've ever heard reported.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Aug 2007 17:09:32 +0000

> following this RFC, not the operator. It's not possible for an application
> to renumber ports used by other applications. (well, I suppose it could
> start killing other processes and messing with /etc/services, but I think
> any reasonable person would know that that's not the intent.)

"all possible" means, to an application developer, "use all the file 
descriptors you can, up to a maximum of the number of theoretical ports
that can be open in a 16-bit UDP port number".  that's what's possible.
but it is not reasonable or feasible.  if the document wants application
developers to be reasonable, then it should say so.

---

From: bert hubert <[email-masked]>
Date: Mon, 13 Aug 2007 20:17:30 +0200

> developers to be reasonable, then it should say so.

I'm an implementor, not a theorist, so yes I love to write reasonable
documents. 

It is not necessary to use all file descriptors.

It is necessary to have unpredictable source ports on subsequent queries.

In practice, some implementations will want have multiple transactions share
a single source port, to prevent the need to open as many sockets as there
are outgoing queries in flight.

What we need to do is find language that encodes the unpredictability
without requiring the use of all file descriptors.

Suggestions are welcome, we're working on it as well.

	Bert

---

From: Florian Weimer <[email-masked]>
Date: Tue, 14 Aug 2007 09:41:03 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> with /etc/services, but I think any reasonable person would know that

I think those systems with /etc/services should be on the safe side
because the dynamic port range used by the kernel is outside the usual
application range.  If you stick to ports in that range, you should be
safe.  This is different from the old RPC-vs-service problem, where
some RPC service gets dynamically assigned a well-known port which is
needed later in the boot process by some other daemon.

Windows is a different matter because the dynamic port range begins
just above 1024. 8-(

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Aug 2007 12:09:24 -0400

Referring to:

I've read the document before (-00) and still don't understand this:

#   5.  It is the first answer to match the previous four conditions.
#
#   Note that the fifth condition can strictly speaking be derived from
#   the first.  It is included for clarity reasons only.

In the reading it seems that the text is from RFC 1034/5.3.3 (which 
refers only to earlier lines apparently).  I went back and forth 
trying to find the source of this until I realized it is probably an 
interpretation and not the source.

Given that most sniffer based attacks are based on being closer to 
the querier than the proper responder, I would look for the last 
answer to match.  Of course, that is only theoretically possible as 
you will never know if any event is the last time it happens.  Like 
Elvis sightings.

The Note also is confusing. I don't see how you derive #5 from #1.

#4.5.  Have the answer arrive before the authentic answer
#
#   Once any packet has matched the previous four conditions, no further
#   answers should be accepted.

This is a strategy I disagree with, kinda.  If TSIG or DNSSEC is 
used, responses matching the first four conditions ought to be queued 
up until the answer has passed TSIG or DNSSEC checking.  This allows 
these techniques to not just detect errors but detect and deflect 
until the right answer comes (within the timeout).

#before applying DNS credibility rules.

RFC 2181 has trustworthiness rules, the are TSIG and DNSSEC rules.  I 
don't know of other "DNS credibility rule" sets.  You probably at 
least need a reference there.

#   The document can not require the use of either multiple ports or
#   addresses as that is an operational issue and should be addressed in
#   a separate document in DNSOP.

Don't let IETF document bureaucracy get in the way of a good story!

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

Think glocally.  Act confused.

---

From: bert hubert <[email-masked]>
Date: Wed, 15 Aug 2007 08:52:46 +0200

> interpretation and not the source.

We do quote a bit from section 5.3.3 of RFC 1035, and this bit is indented.
The other lines, 1. through 5., are our own invention.

I've updated the xml a bit to clarify where the quote from RFC 1035 ends:

-           Section 5.3.3 of <xref target="RFC1034"/> presaged the present problem:
+           The following sentence in section 5.3.3 of <xref

> you will never know if any event is the last time it happens.  Like 

That would be a good suggestion except in real life :-)

> The Note also is confusing. I don't see how you derive #5 from #1.

Indeed. It originally stated you could derive the fifth condition from the
first, where first was intended to be plural, and denote 1-4. But even that
is not true. Removed the note.

> until the right answer comes (within the timeout).

Well, I'd hate to sprinkle TSIG and DNSSEC exceptions all over the document.
I'd rather have that this document updates RFC 1035, and tries not to
engtangle itself with other developments.

> least need a reference there.

Well spotted - I copy pasted this section from elsewhere, and didn't fully
verify it.

> Don't let IETF document bureaucracy get in the way of a good story!

Thanks - I agree fully. Unsure what to do about it though..

	Bert

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Aug 2007 10:28:32 -0400

Referring to:

>changes please post your recommendations/issues.

There has never been a solid prescribed algorithm 
for resolving queries in DNS, so I don't know 
that RFC 2119 terminology will apply to this. 
Besides, it is questionable whether any 
recommendations to countermand simple spoofing 
represent an interoperability issue or whether 
this is just plain good practice to follow in 
operations.

Having read an earlier thread on this, I might 
suggest the following regarding port management:

A DNS client (stub or full) would be wise to 
select a handful of ports from which to source 
queries and would be even wiser to change these 
ports over time.  For example, at start up, 
request 16 or so unused ports from the operating 
system and arbitrarily spread the load of queries 
amongst the ports.  (A caveat here - asking for 
16 port #0's might get 16 consecutive ports which 
is not desired.  Perhaps we ought to recommend 
generating 16 randomly chosen numbers and 
requesting those ports, reselecting a number of 
the port is in use.)  Strict rotation is 
discouraged as this does not add to the security 
desired, however true randomness is not necessary 
as the set is small.  At some point during the 
operation of the querying process ports should be 
closed and replaced with new ones from the 
operating system.  It is not necessary to retire 
all ports at the same time.

# Having thought about that recommendation, I 
think it doesn't apply to stubs.  A stub instance 
ought to ask the OS for a port at each 
invocation.  I would say random, but OS's don't 
(at least back in the day when I wrote code) 
randomize port allocations.  As in, if you ask 
for a random port you get port # n+1 from the 
previously allocated port.  Of course, that 
applies if you ask for port 0, not a specific 
port.  Perhaps this is an issue for OS vendors to 
think about too.

Regarding message acceptance, if it needs to be 
made explicit then I'd agree to list all of the 
fields that ought to be identical.  I would go 
further and add that the answer has to be related 
to the question - I don't see a problem with out 
of zone CNAME'd records as you don't know "what 
zone" an answer is coming from but you do know 
"what server" an answer is coming from.  If a 
server is authoritative for both of the involved 
zones, then by RFC 2181 trustworthiness rules, 
the answers are all of the same ranking.

The strategy I mentioned in another set of 
comments, of waiting for the "last" and not the 
"first" response is something that could be 
worked in.  However, I don't think I would 
recommend the strategy unless the software is 
being written for a paranoid environment.  Absent 
DNSSEC and TSIG, the recommendation would include 
queuing all candidate responses to the query 
until the time-out or until an previous response 
is deemed trustworthy.  Of course, all of this is 
a great big pain in the neck to manage.  (OTOH, 
the Achilles Heel of most networking software is 
poor session management and deficient socket 
error handling elements, so this is par for the 
course.)

>behavior of implementations?

Only if it impacts interoperability of a stable protocol.

>Should there be different recommendation sections for stub resolvers

I think so, given the management of open sockets.

PS - By "socket" I mean a virtual device used to 
interact with TCP and UDP ports.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 15 Aug 2007 19:30:45 +0300

> all ports at the same time.

Although opening a handful of ports and choosing one of them at random
for each query does make spoofing harder, making those ports
non-consecutive and/or changing them periodically does not really
offer any additional security.

In the case of a server using a single port, we already assume that
the attacker has a way of determining which port is in use.  The
methods the attacker may use for doing that easily extend to multiple
ports, so we must also assume that the attacker now has a way of
determining the _set_ of ports currently in use.  If he does that
determination immediately before the attack, and repeats it frequently
enough during an extended attack, he will be able to track any changes
in the set.
--
Andreas Gustafsson, [email-masked]

---

From: Michael Graff <[email-masked]>
Date: Wed, 15 Aug 2007 12:00:49 -0500

> enough during an extended attack, he will be able to track any changes

That would almost imply that using one port for a server would actually
limit the ability to attack other servers if they have a chance to use a
different port.

That is, if an attacker could only detect a limited number of ports a
server uses (say, out of 16), the others would still be unknown
quantities from the attacker's point of view.

If, on the other hand, a random port were used, it's only a matter of
time before all ports were detected.

- --Michael

---

From: Shane Kerr <[email-masked]>
Date: Wed, 15 Aug 2007 19:30:47 +0200

> enough during an extended attack, he will be able to track any changes

In a sense you are right. If I have a set of 2^N ports and pick one at random,
then I've added N bits of entropy that the attacker must guess. It doesn't
matter whether what ports these are, as long as we pick one at random.

Changing the ports does not really limit the time the attacker has to guess
those bits, because *that* is already limited by time that it takes for the
"real" server to answer the query.

But...

We should not assume that the attacker can snoop the traffic from the server.
(In this case no prediction is necessary: the attacker can simply read the
outbound queries and send a spoofed answer.)

The method that I think we are talking about it getting the server to send
queries to a known location. When that happens, an attacker can get some idea of
the internal state of the server - the query port in this case.

If I can get a server to make a single query to a server that I want, then I can
determine the single port it is using. But that does not necessarily mean I can
get the server to make *any* number of queries!

Plus, if I have a set of query ports, an attacker can get a portion of those
through repeated queries, but it gets harder to find them all as the size of the
set increases.

So, I think we should not throw out the idea of "reseeding" our pool.

- --
Shane

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 15 Aug 2007 20:54:03 +0300

> outbound queries and send a spoofed answer.)

Correct.

> the internal state of the server - the query port in this case.

Yes.

> get the server to make *any* number of queries!

Usually you can, as many as bandwidth permits.

> through repeated queries, but it gets harder to find them all as the size of the

Yes, but Ed was talking about a "handful" of ports.  With a handful of
ports, or even a few dozen, finding them all is trivial.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Aug 2007 13:50:19 -0400

>offer any additional security.

My thought about that ...

If the problem is that we only have 16 (possible) bits of randomness 
in the transaction ID and we feel the need to add to it by using the 
bits in the source port, the more random the source port is the 
better.

If an attacker finds out that port Y is in use and it knows that 16 
consecutively-numbered ports are in use, then the attacker can hit on 
Y-16 to Y+16 (as it's not clear if Y is at the end of the run).

By changing the ports over time I see two advantages, one is that the 
attacker, once discovering a port, can only rely on that value for a 
short time.  The other is that the ports can go back into use in the 
OS for whatever other applications may want to use them.

Some time ago (like 4 years maybe) I wrote code where I wanted to 
have a lot of outstanding queries.  I recall using the query port's 
low order bits as part of the ID so I could tie the response to the 
request.  I didn't use threading for the code, off hand I forget the 
rest of the details.  But the strategy was to extend the ID field 
into the source port.  I wasn't concerned with spoofing though, my 
bigger concern was that many queries were going unanswered.  (It was 
a DNS test program.)

>enough during an extended attack, he will be able to track any changes

I'm under the assumption that we want to have like, say, 20 bits of 
randomness instead of just 16.  Four of those bits have to reside 
elsewhere/the source port/.  If they are sequential, we are using 16 
ports (2^4 if I am counting on my fingers correctly) and getting just 
the 20 bits of randomness as the upper bits of the port number are 
the same.  If not sequential, we are getting a bigger bang for 16 
ports as the upper bits of the port number aren't the same.

What's haunting me is an old TCP attack where the attacker could 
predict the next sequence number for a stream knowing that the 
sequence number was based on something regular and predictable like 
the system clock.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Aug 2007 14:28:15 -0400

>ports, or even a few dozen, finding them all is trivial.

Depends on how big your hands are.

The tradeoff is between using a lot of ports and hiding well because 
of it versus using too many resources on the client host.

One reason to choose new ports now and then is that it may make the 
pool seem larger - the attacker can't tell when you've closed a port 
unless the attacker knows the size of a "handful" in the system under 
attack.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 15 Aug 2007 22:38:19 +0300

> OS for whatever other applications may want to use them.

That's not necessarily a good thing.  For example, if you start your
DNS server before your SIP server in the boot sequence and the DNS
server chooses its ports randomly between 1024 and 65535, the SIP
server will randomly fail to start every once in a while because the
DNS server has happened to pick port 5060.  Now, if the ports are
fixed, you at least have a chance of figuring out what the problem is,
but if the DNS server has already changed to use another port by the
time you start debugging the problem, it's going to be harder.

> ports as the upper bits of the port number aren't the same.

We are still getting the same 20 bits of entropy.  Everything else is
just obfuscation.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Aug 2007 16:02:51 -0400

>time you start debugging the problem, it's going to be harder.

Yeah, race conditions, know all about them.  It's been a while for 
me, are there different port ranges nowadays where no "well-known" 
services set up shop?  (Is[n't] there a designated dynamically 
assignable range of ports?)

>We are still getting the same 20 bits of entropy.  Everything else is

Until there's DNSSEC or TSIG (or other $security-mechanism) in place, 
it's a gamble.

I should emphasize that it's not randomness that is really needed, 
just something "too hard to guess in the time you can abuse it."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: bert hubert <[email-masked]>
Date: Wed, 15 Aug 2007 22:54:18 +0200

Ok, recapping a bit.

Randomness is a confusing subject - a single number might be random, viz
http://imgs.xkcd.com/comics/random_number.png

We want port numbers that are hard to predict for outsiders, so any attacker
needs to scan a lot of port numbers before a fake DNS answers can be
injected.

A random, but static, port is only predictable for a complete outsider.

Anybody with access to the traffic to a big authoritative nameserver quickly
gains knowledge about this static port number a remote resolving nameserver
uses to query it.

There are at least two strategies to make sure the 'random source port
number secret' does not leak.

The first is to use a random source port for every query, which is not only
random but also unpredictable - unlike the random generator pictured above.

A second way is to reuse static ports, but make sure we have a specific and
secret port number for every authoritative server we talk to. This way, the
traffic of one authoritative nameserver does not give insight to port
numbers used for other queries.

I'd like to prevent the draft to proscribe details of how to keep the port
number secret - more ways might be found than the two listed above.

So it would be best if the draft merely states that the source port used
should not be predictable by attackers having access to previous queries to
different authoritative servers.

As a side note, I think that Paul's 16 port idea does not match the
criterium listed above. The 16 ports would quickly become known.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Aug 2007 21:03:46 +0000

> We are still getting the same 20 bits of entropy.  Everything else is

well, in one design i'm aware of (not bind and not published), it's slightly
more than 20 bits, since there are up to 16 pools of 65536 qid's, and each
pool gets its own udp socket and therefore its own port, but no pool's socket
remains open except when there are outstanding upstream transactions active.
so, a pool's udp port number will change every time it goes idle->nonidle,
and anyone trying to predict the next port number you'll use as more than 16
they have to worry about.  when combined with a firewall rule that prevents
nonclients from sending in queries, the only effective poisoning attack is one
that synchronizes the actions of a corrupted internal client and a corrupted
external server.  the synchronization between these corrupted devices is the
subject of IDS, and therefore, the attack overall has a Very High Cost even
if the random number generators aren't especially cryptographic.

---

From: Doug Barton <[email-masked]>
Date: Wed, 15 Aug 2007 14:44:16 -0700 (PDT)

On Wed, 15 Aug 2007, Andreas Gustafsson wrote:

>> short time.

I like this part of the proposal a lot. I think by "randomly" choosing N 
different ports to originate queries from, AND rotating those ports during 
the life of the process you gain at minimum obscurity, and a raised bar 
for the attacker. Ed's already said good things about why N static ports 
doesn't raise the bar high enough, so I'll just add my +1 to that.

>> The other is that the ports can go back into use in the

I'm not sure how relevant that bit is, since assuming a relatively 
constant load, the process is going to be consuming roughly the same N 
number of ports.

> DNS server has happened to pick port 5060.

Well, then don't do that. :) I think we should be talking about randomly 
choosing ports in the ephemeral port range (49152 through 65535) rather 
than starting from 0, or even 1024. I think 16k ports ought to be enough 
to rotate through no matter what N is. Logic already exists for all well 
behaved applications to pick an unused ephemeral port for their work, so 
we shouldn't be running afoul here.

> Now, if the ports are fixed, you at least have a chance of figuring out 
> what the problem is, but if the DNS server has already changed to use 
> another port by the time you start debugging the problem, it's going to 
> be harder.

Now I'd like to flip sides and agree with Andreas for a minute. Going down 
this road _will_ make DNS networking harder to debug. I used to work at a 
big company, with very experienced and capable network engineers, and even 
after we reached an agreement on a "standard" ephemeral port for BIND to 
use for its outgoing queries, making sure it was open and accessible 
through all the different firewalls, routers, etc. was sometimes (not 
usually, but sometimes) quite an exercise. Allowing the process to 
randomly shift through a range of thousands of ports will make this 
harder.

I think one way to help this situation would be a SHOULD to say that 
implementors provide a way to specify both the N number of outgoing ports, 
and the M range that they can cycle through. That will at least save 
_some_ hair being pulled out.

That said, I still think this is a good idea, and worth the extra 
complexity.

> We are still getting the same 20 bits of entropy.  Everything else is

I'm not sure I grasped the reasoning behind this conclusion, could you 
elaborate a bit?

Doug

-- 

 	If you're never wrong, you're not trying hard enough

---

From: John Kristoff <[email-masked]>
Date: Wed, 15 Aug 2007 16:45:32 -0500

On Wed, 15 Aug 2007 22:54:18 +0200

> needs to scan a lot of port numbers before a fake DNS answers can be

As operational information, scanning is often not necessary.  There
are millions of open resolvers today and even if a resolver is not
open, one that is may be trusted by one that isn't.  In either case,
an attacker need only send queries for name they can see the resolver
query to discover source port usage.  This type of reconnaissance can
be extremely difficult to detect.

My sense is most source port selection countermeasures will be at
best a weak countermeasure.  If kept at all, I suggest changing SHOULD
to MAY in this sentences:

   Implementations MUST use an as large as possible pool of UDP source   ports for sending queries

John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Aug 2007 16:11:17 -0700

On Aug 15, 2007, at 2:03 PM, Paul Vixie wrote:

> when combined with a firewall rule that prevents nonclients from  
> sending in queries, the only effective poisoning attack is one that  
> synchronizes the actions of a corrupted internal client and a  
> corrupted external server.  the synchronization between these  
> corrupted devices is the subject of IDS, and therefore, the attack  
> overall has a Very High Cost even if the random number generators  
> aren't especially cryptographic.

A firewall or intrusion detection system will not prevent SPF script  
parsers from rather vigorously exercising DNS resolvers ports.  SPF  
parsers are even in webmail browser plugins.  Each message validated  
may generate rather long sequences of transactions.  The malevolent  
SPF script created in the demonstration draft illustrates the DDoS  
potential.  This script could be changed to issue hundreds of  
transactions to a corrupt external server, and moments later issue  
queries for absolutely _any_ A, AAAA, or MX record of the bad actor's  
choice.  Timing, access, and ports are all exposed by this process,  
and can not be stopped by a firewall.  Of course similar SPF scripts  
can DDoS the authoritative servers at the same time without expending  
any of the bad actors resources as well.  A free and easy attack.

Handling SPF records often involves a stateful processing of a rather  
complex script that may encompass more than one hundred DNS  
transactions per message.  Another concern might be the port  
selection associated with a thread processing the script.  The thread  
may issue a long sequence of transactions fully controlled by SPF  
record parsing.  These records construct a script expected to  
validate the path for a message that could easily be sent by a bad  
actor.

As these SPF scripts can utilize the local-part of an email address,  
the same SPF record is able to generate _any_ number of new DNS  
transactions over the duration of a spam campaign.

-Doug

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 16 Aug 2007 09:50:11 +0300

> I'm not sure I grasped the reasoning behind this conclusion, could you 

Even if the ports are not sequential, the attacker can find out what
they are.  Once that is done, the amount of guesswork needed on part
of the attacker is exactly the same as if they were sequential:
guessing between 16 known ports and 65536 IDs.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 16 Aug 2007 09:40:23 -0400

>guessing between 16 known ports and 65536 IDs.

I think it is time to state some (ok, my) assumptions because maybe 
we are trying to solve different problems.

There are two attack scenarios.  One is when the attacker can see all 
or most of the traffic from the DNS client, as if it is on the same 
(broadcast) LAN segment.  The other is some remote attacker is 
somewhat blindly sending out answers.

If the attacker is monitoring the LAN, there's no way any amount of 
entropy in the bits is going to help.  A query can be copied into the 
ersatz response buffer, appended with the attack data and replied to. 
In this case it I doubt it makes sense to even worry about the number 
of ports used.

If the attacker is remote, not in the forwarding path of the query or 
response traffic, then I do think the less linking of bits (i.e., 
using scattered ports over sequential port for a given number of 
ports) is a help.

Let's say that the the DNS client uses one port per authoritative 
server and the attacker manages to discover the one port used for 
queries to the attacker's authoritative server.  In that case, the 
only data poisoned is that from the attacker.  However, one port per 
authority is a lot of overhead (probably), so the question is how 
does the client make it hard for a remote attacker to "guess" how to 
craft an attack response.

Am I missing a problem case?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Michael Graff <[email-masked]>
Date: Thu, 16 Aug 2007 09:18:09 -0500

Edward Lewis wrote:

> Let's say that the the DNS client uses one port per authoritative server
> and the attacker manages to discover the one port used for queries to
> the attacker's authoritative server.  In that case, the only data
> poisoned is that from the attacker.  However, one port per authority is
> a lot of overhead (probably), so the question is how does the client
> make it hard for a remote attacker to "guess" how to craft an attack
> response.

I would think that, at time T (when a certain set of ports are in use),
changing ports at time T+n (with a slightly different set of ports) adds
entropy.

That is, at any given time you have fixed additional bits that the
attacker must guess (the port number(s) in use add to these bits) and if
you change them, a new set must then be gathered.

I still like my idea of always using the same port for a given host, and
perhaps changing that port over time, but not using all available ports
for a given host.  That way, an attacker really has to work at getting
the port range, rather than just sending some number of queries and
getting most/all of them.  Sure, it's hiding data and doesn't guarantee
an advantage, but it does raise the bar.  With a mere 20 bits (16 ports
and 16 bit id) any bar-raising seems good.  It moves the needed probes
from number of queries before all ports are known to number of IP
addresses (under an attacker's control) needed before all ports are known.

As Ed suggests, if you can directly monitor the traffic, you lose.  No
need to worry about that case; it is not solvable using anything we've
suggested.  Other then DNSSEC, of course.

I think some people are having problems with the terms "local" and
"remote" here though.  To me, a "local" means "from within their
network" and remote is anything that is not local.  However, someone
pointed out to me offline that "local" could mean a virus-infested
machine which runs behind the IDS, firewall, or whatever; in that case,
many would consider that "local."  It's not on the same wire perhaps,
but the attacker might have enough ability to flood the client in any
way it desires.

- --Michael

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 16 Aug 2007 18:05:03 +0300

> In this case it I doubt it makes sense to even worry about the number 

Of course.  If the attacker is monitoring the LAN, you lose, and this
whole discussion is moot.

> only data poisoned is that from the attacker.

If you do use the "one port per authoritative server" approach, then
yes, I agree that scattering the ports is better.  But that is not the
case I'm talking about; I'm talking about the case of a server that
chooses the source port at random among its set of 16 (or whatever)
open ports, regardless of destination address.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Aug 2007 16:14:02 +0000

> addresses (under an attacker's control) needed before all ports are known.

since one of the purposes of the upstream socket pool is to add more QID's
and therefore add more potential outstanding upstream transactions, there's
some concern that flow-hashing the upstream server down to a 4-bit upstream
socket slot-number could lead to hot spots.  64K QID's sounds like a lot
but so did 640KB.

then there's the question of aliasing and antialiasing.  would we be hashing
the upstream server's address, in which case a multihomed upstream server
would learn more than one of our upstream port numbers?  or would we hash by
name, in which case a multinamed server could do likewise?  and in any case
couldn't an attacker just use a hundred or more upstream servers?  or a
thousand if that's what it takes?  if hiding these numbers is important, and
our defense depends on a sitting duck's location not being discovered, then
the whole scheme feels weak to me.

---

From: bert hubert <[email-masked]>
Date: Thu, 16 Aug 2007 21:55:42 +0200

> authority is a lot of overhead (probably), so the question is how 

The overhead appears to be around 20% on modern operating systems. I found
it hard to do the measurement for Windows XP as it was very slow no matter
how I measured it, so I don't think I can say anything useful about it. I
might have been using the wrong API.

Cleverly reusing per-remote connected sockets didn't really gain any
performance on Linux.

So it is not clear the overhead is 'a lot' or even 'substantial'.

	Bert

---

From: Edward Lewis <[email-masked]>
Date: Thu, 16 Aug 2007 16:18:27 -0400

>So it is not clear the overhead is 'a lot' or even 'substantial'.

20% seems like a lot, but of course, it depends on what is being measured.

To give some impression of what I meant by overhead...

Part of the question is - how many authoritative servers does a 
single recursive server contact?  Over any given period of time?  If 
a server contacts 1000 authoritative servers across a business day, 
does that mean 1000 ports are going to be held for DNS queries?  When 
is a port freed?  And what about any per-process limits on 
interprocess communications?  (Back in the day, UNIX-like systems 
were limited to like 32 or so.)

Of course, overhead could be the time used for a UDP connect() call, 
after that it's no more work to use the new port rather than a 
communal one. Is the 20% the related to the ratio of:

               use of a UDP port to send
               -------------------------
         use of a UDP port to send + connect()
?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Dean Anderson <[email-masked]>
Date: Thu, 16 Aug 2007 17:22:29 -0400 (EDT)

I'm not certain that this improves forgery resilience, since it makes it
harder to tell which packets are DNS, and therefore, harder to detect
hosts that are trying to spoof DNS responses.  Nothing is ever free.

However, the reason that Andreas gives against the proposal is wrong.  
Operating systems allow different processes to share the port space, so
a DNS resolver can share the range of ports with other services.  It is
not the case that all UDP port numbers must be reserved for DNS. It is
only the case that DNS can use any random port as given to it by the
operating system.

I think the standards should allow both behaviors, and I'd prefer
implmentations that had knobs to do either.  Which knob setting to use
depends on the situation, I think.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Aug 2007 11:36:50 +1000

> # Having thought about that recommendation, I=20
> think it doesn't apply to stubs.  A stub instance=20
> ought to ask the OS for a port at each=20
> invocation.  I would say random, but OS's don't=20
> (at least back in the day when I wrote code)=20
> randomize port allocations.  As in, if you ask=20
> for a random port you get port # n+1 from the=20
> previously allocated port.  Of course, that=20
> applies if you ask for port 0, not a specific=20
> port.  Perhaps this is an issue for OS vendors to=20
> think about too.

	Linux's port allocation gives you the same port unless the
	previous port is still open in which case you get n+1.  This
	really is sub-optimal for UDP as get all sorts of garbage
	destined for the previous user of the port.

	It also means that you can't do socket(), bind(), close(),
	socket(), and bind() and get a get a different port like
	with every other OS.  You have to do socket(), bind(),
	socket(), bind() then close() to ensure the OS gives you a
	new port.

	This wouldn't be a problem with real random ports as the
	probability of getting the same port on two consecutive
	bind()s is low.  You just try again.

	Please don't say the above procedure is what all applications
	should do as this is a cross process problem.  It's fine
	and reasonable for *a* process to do the above when it wants
	to reject specific system assigned ports.

	Having 30 dig proccess in a row get the same port leads to
	all sorts of responses to old queries being delivered.  It
	also leads to spurious bug reports about dig binding to
	specific ports when it was not told to.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Fri, 17 Aug 2007 00:06:24 -0400

>	Please don't say the above procedure is what all applications

I'll try to sum up my thoughts on this, not that I think I have 
answers but perhaps my input is reaching the point of diminishing 
returns.  But I won't promise to remain silent on this in the future. 
;)

It's an age-old problem, the interaction between OS related 
interprocess communications (such as BSD Sockets) and the network 
related (pseudo) devices (such as ports).  The OS is concerned about 
fair and efficient distribution of its resources (mbufs) among 
processes.  Protocols are concerned with transfer of information 
(entailing flow control, security, etc.).  These two goals are 
compatible even if orthogonal.  What's a problem, to the designer of 
a protocol, is that each OS solves the problems of resource 
allocation a bit differently.  (And we know that "a bit" can be very 
significant.)

The moral of this is it is impractical to proscribe a specific 
solution that works for the protocol and works on all OSs.  (To be 
cyber-culturally correct, not all OSs have processes, so read that as 
"threads of execution.")

If the situation is that we feel that we cannot make the 16 bit 
message ID unpredictable enough (I didn't say random on purpose), we 
ought to recommend the amount of needed degrees of freedom and where 
that might be found (port numbers).  It's not that I think it is a 
waste to dive into what each OS does, but well, it's a waste of time. 
No, seriously, I think that if the IETF document proscribes what we 
as a WG think is enough bits of unpredictability we should then just 
leave it to the implementers to deal.  After all, today's coders know 
the APIs and behaviors better than rusty old coots like me.

So, let me propose that we document that there is a need for more 
bits of unpredictability based on the calculations already in the 
draft.  An open question to me is to specify a number, I mean, others 
will have a far better idea than I so I won't suggest a number and 
will go along with any consensus.  As far as how the "extended 
unpredictability" is implemented is probably left best to the code 
writers with maybe some hints in the document - but let's avoid 
ratholing on anything that isn't needed for interoperability.

I should add that what we are talking about in this thread is just 
the equivalent of the session layer of the DNS protocol.  The 
"service" is that we can maintain a reliable enough communication 
between querier and respondent (avoiding the word "server" as both 
ends of the communication are likely servers), how this is jockeyed 
over the OS IPC and TCP/IP ports can be a hidden detail.  The 
document does cover other aspects of making sure the correct received 
answer is accepted, that is just not in this particular thread.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 18 Aug 2007 19:29:20 -0400 (EDT)

> 	destined for the previous user of the port.

This is a problem for linux kernel lists. Use the source, Luke. Fix it.

This is a good time to point out the 'random port selection' isn't often
really random, and can also be arbitrarilly reduced by getting 64K UDP
ports opened until the possible number of possible ports for the next
DNS request is narrowed to a small number of ports or even just one
port.

I'll leave it to you to think of a way to get all but one UDP port
opened so that you can just spoof the id in the DNS packet to one UDP
port.

Not that random port selection is a completely bad idea, but it isn't
the total panacea that it appears to be under the ideal conditions.

TCP is better because you have 64k ports as well as sequence numbers
that need to be right over several packets for a successful spoof. Plus, 
people have been working longer at making TCP harder to spoof (e.g. 
random initial sequence numbers)

		--Dean

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 21 Aug 2007 09:43:56 +0300

> you change them, a new set must then be gathered.

To recap, the case I'm talking about here is a recursive server
keeping (say) 16 open query source ports, randomly choosing one for
each outgoing query regardless of which authoritative server is being
queried, and changing the set of open ports from time to time.

The reason I wouldn't say that changing the set of open ports "adds
entropy" is that I think the term "entropy" should be reserved for
information that the attacker has no way of finding out short of
guessing.  The query ID and the random choice among the 16 open ports
both fall into that category, but the set of open ports doesn't,
because the attacker can trick the server into revealing it through
queries to an authoritative server under the attacker's control.

On a more practical level, whether you call it "entropy" or not, you
are of course correct that having to determine the set of open ports
adds to the total effort the attacker has to expend.  The question
then is, is this added effort significant?  At least in the case of a
small number of ports, I don't think it is.  For example, if I did the
math right, making 100 queries for names in a domain under the
attacker's control will fully reveal the set of 16 source ports with a
probability of 97.5%.  Compared to the amount of traffic needed to
successfully attack those 16 ports once they have been found out,
524,288 packets on average, those 100 queries are a drop in the
bucket.

> addresses (under an attacker's control) needed before all ports are known.

I think this is an interesting approach, and different enough that my
analysis above doesn't necessarily apply to it.  Though I'm not sure I
like the idea of a defense that protects against the little guy while
offering little protection against corporations and governments who
control large IP address spaces.

Anyway, don't get me wrong here: as far as the standards process goes,
I'm not trying to advocate or discourage any specific methods of
spoofing defense.  Quite the contrary - what I'm asking is for the
forgery-resilience draft to refrain from overly specific requirements
(such as "MUST use an as large as possible pool of source ports") that
limit the ability of implementers to explore different parts of the
solution space.
-- 
Andreas Gustafsson, [email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 21 Aug 2007 14:14:48 +0900

At Fri, 17 Aug 2007 00:06:24 -0400,

> ratholing on anything that isn't needed for interoperability.

I agree on this point.  It sounds too much to me for a protocol
specification to specify a countermeasure that is pretty
implementation-dependent, especially with an RFC2119 keyword,
such as this one:

   Implementations SHOULD be configurable to use one or multiple ports
   for queries.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]