Forgery Resistance phase #2

[Ólafur Guðmundsson /DNSEXT chair <[e-mail]>]

This message is sent in my role as chair with consent of my co-chair 
but without
his editing help, thus any mistakes in this message are mine and only mine.

The large volume of message over the last 2 weeks related to how to make DNS
safer made me think about "what are all the different possible approaches?"
Below is a list of ideas I have heard mentioned or thought off.

The list is supposed to be as complete as possible, if there is anything
missing feel free to bring it up.
Some of the ideas are stupid or do not make sense but are documented here
for sake of completeness.
Deployment of some of these ideas can be done real soon, others require
extensive software upgrades. The final solution selection may include more than
one ideas below as there is frequently not just one solution.

The goal of this email is that the WG is in a position to know that it is
selecting from a "complete set" of solutions When/IF the WG (or DNSOP WG)
decides that it should attempt to document/recommend more approaches than
what was covered in the FR-draft.

Covered in FR draft:
	Query ID
	Source Port
	Source Address

Randomness possibilities that originators have:
	Destination Address [1]
	Case games (like x20)
	Multiple identical questions [5]
	Repeat question [6]
	Spread question to number of nameservers. [7]
	Delay question [8]
	Time spaced repeated questions [9]
	"random" TCP query [11]


What Destinations can do to increase protection:
	More addresses: [10]
	DNSSEC

Protections that require both parties collaboration:
	TSIG
	DNS cookies
	TKEY + TSIG/SIG(0)
	SIG(0) 	Destination Protocol/port [2]
	Query name hacks (pre and post fixes) [3]
	EDNS ECHO [4]
	QCount > 1  [14]
	QClass top bit 8 redefinition [13]
	IPsec tunnels [12]
	IPv6 preference [15]

Steps that resolvers can take to protect them self:
	Forgery Detection
	and react to forgery attempts.

Steps that Operators of Authorative servers/zone owners can take:
	Deploy only current software
	Deploy DNSSEC
	Update ACL rules to reflect current recommended DNS port usage.

Comments:
[1] Destination Address: Many implementations go to first name server in an
	NS set all the time, some go to the one they know is closest or go
	to the one that they know has answered a query in the past, one they
	have an A record for, etc.
	From security point of view always selecting a random server is the
	best one. From an operating point of view this may/will cause more
	delays/errors. For high availability zones with short names having
	large NS sets is an possible source of randomness for example "." has
	13 A address this adds 3.5 bits of randomness for resolvers that use
	random selection. By expanding this to randomly select IPv4 and IPv6
	as transport for query another bit can be added.

[2] Destination Port: Another potential source for randomness is to reserve
	4 - 16 ports that DNS servers MUST listen on. 16 ports add 4 bits of
	randomness.

[3]  This relates to adding <foo.bar>.QNAME in query section or
	QNAME.<foo-bar> or even if QNAME is a.b.c to do
	a.<foo-bar>.b.c or a.b.<foo-bar>.c
	<foo.bar> is in this case has a known prefix in the first label
	that is registered with IANA so people can avoid it,
	if <foo-bar> is multiple labels the first label should encode
	how many bytes or labels to strip.

[4] EDNS Echo: A simple option to EDNS that instructs a server to copy back
	this option in the answer or the answer is not to be trusted.
	The contents of the option is random data unique to the query.

[5] In this case a resolver fires a number of identical questions off and
	expects to get the same number of identical answers.

[6] In this case the resolver repeats the question after getting an answer,
	it expects an identical answer.

[7] Spread question to a number of nameservers/recursive resolvers,
	expects to get back identical answers from all.

[8] Here the resolver waits for a short random time before sending the
	question but it is listening for answers from the time it forms
	the question.
	This is to detect forgery attack before sending the question.

[9] In this case the resolver sends queries that are spaced in time
	and it expects the answers to come back in the same order as sent the
	time between second and subsequent answers should approximate
	the transmission time.

[10] More designation addresses, larger NS sets potentially offer more
	protection as the client has more addresses to choose from.

[11] TCP queries are controversial as they require more state and overhead.
	Over the last few years we have seen TCP stacks optimized for handling
	large number of TCP connections thus the assumptions for not using TCP
	for DNS should be reexamined and requiring TCP port to be available on
	authorative servers will allow clients to fall back on TCP in
	specified situations.

[12] IPSEC: this is an option when there is strong relationship between two
	DNS entities, it is not clear how applicable this it is in the random
	resolver talking to random server.

[13] Right now about 4 classes are defined in the IANA registry. Use 
and deployment
	of new classes is difficult to say the least. For this reason it is tempting
	to steal some of these unusable bits into help protect the protocol.
	The proposal is to redefine the top 8 bits into a QID and servers would
	ignore these bits when checking class answer but echo them back in the
	answer's QCLASS.

[14] QCOUNT > 1 is currently not allowed but could be used to add 
randomness to
	the query if the second query is ignored in the answer processing
	but is copied into the answer.  There are number of different possibilities
	in how the randomness is expressed in the: label, QCLASS, QTYPE or all.

[15] IPv6 preference for queries, A resolver can cycle through many
	privacy address to increase source address randomization.


Sorry for the lack of attributions in this posting, if/when this becomes an
an ID that will be fixed.

	Olafur 


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