Re: Protocol Policy Publication Was: DNSEXT future

[Douglas Otis <dotis@mail-abuse.org>]

On Mar 27, 2007, at 9:40 AM, Hallam-Baker, Phillip wrote:

> One issue that keeps coming up is the desire to publish some form  
> of policy indication through the DNS.
>
> I don't think that the IETF can or should ignore this. If we do we  
> will end up with the situation that most of us like least and is  
> the reason that people tend to try to suppress such proposals -  
> without success. In particular we end up with:
>
>   * Protocols that perform 'tree walking' and other forms of  
> heuristic policy discovery
>
>   * DNS RRs being hijacked for other purposes (e.g. SPF use of the  
> unprefixed TXT record)
>
>   * A proliferation of unregistered, untracked TXT and SRV prefixes.
>
>   * People sticking large chunks of XML text into the DNS  
> infrastructure itself
>
>   * People propose rival infrastructures (e.g. UDDI, XRI) that  
> attempt to superceed the DNS.
>
>   * It is not yet happening but if we make DNS RR assignments into  
> the equivalent of IP port numbers we should expect to see  
> unauthorized and uncontrolled RR assignments becoming common.

These contortions of DNS overcome impediments imposed by messaging  
protocols that fail to offer client identification and a corporate  
environment lacking provisions for DNS.  What new DNS feature will  
allow DNS to evolve when DNS development appears stagnant within the  
corporate environment?  PRNP and Teredo is the change being offered,  
for good or bad.

> I don't like any of the above. But from an architecture perspective  
> I fully expect that in the future we will see most new protocols  
> specify some form of policy layer. And expect the number of  
> protocols to start to proliferate very quickly as Web Services /  
> Mashups / Semantic web take hold over the next ten years.

While true, motivation appears related to messaging providers wishing  
to remain nameless.  After being affected by various DoS attacks, one  
grows wary of a plan that has DNS servers synthesize large answers  
for a label anywhere within their bailiwick.  Initiatives such as  
OpenID could be a cue HTTP is an appropriate repository for such  
extensions.

> I fully expect that the number of protocols that define policy will  
> be of the order of hundreds a year. I don't believe that this is  
> compatible with the idea that each policy record should have its  
> own RR. If we go that route we are committing to burn several  
> hundred, possibly thousand RRs per year to keep up with something  
> that is not core to the DNS protocol. That is something that we  
> must also avoid.

HTTP is shifted to the edge of the network by various strategies  
which also makes it a compelling alternative.  Efficiencies found in  
simple messaging protocols have been countered by abuse permitted  
through a lack of name based identifications.  It is hard to know  
whether an IP address normally carries messages for some named  
entity.  When such message traffic is amassed behind address  
translation gateways, such will become increasingly difficult.  HTTP  
OpenID solves client identification issues in a manner independent of  
the IP address.

> Rather than wait for the problem to become serious I would prefer  
> to solve the problem now, once by anticipating it.

An attempt to repair a deficient messaging protocol with DNS  
wildcards can produce even greater harm.  Can client identification  
be established without scanning domain hierarchies?  Yes, especially  
when authentication and authorization is a component of the  
protocol.  A scheme of synthesizing a DNS answer facilitates  
publishing information regarding protocol repairs, but over a vast  
name space.  Often what is often needed is a means to associating one  
name with another.  Name associations can be done without use of  
wildcards.  Much of the authorization quandary can be resolved by  
associating two disparate names.  Publishing a name as a base32 hash  
below the authorizing name allows a large array of associations using  
small DNS answers.  DNS supports this today without searches or use  
of wildcards.  Rate limits offer a solution for all unauthorized  
messages within an adoption phase.

> The solution I want to propose makes use of either one new RR or  
> possibly two new RRs. The objective here is to get ahead of the  
> curve by anticipating a very large number of needs while sticking  
> to the core principles of DNS. In particular:
>
> AXIOM1     : The DNS infrastructure is the sole authortitative  
> lookup scheme for DNS names
>
> COROLARY1  : If a protocol policy is bound to a DNS name the  
> mechanism for discovery of that policy must be mediated by the DNS.

The relationship between names can be established as a component of  
the protocol without requiring a modification to DNS.

> AXIOM2     : The DNS supports lightweight queries and responses
>
> COROLARY2  : If the policy does not fit onto a few lines of text  
> the DNS should return a pointer (i.e. URI) to the results.

Cue HTTP.

> COROLARY3  : If the form of the query requires any parameters other  
> than a DNS name the DNS result must be a pointer to a service that  
> can handle the extended query (e.g. SIP, LDAP, etc.)

It would be better to have this pushed to the edge of the network  
when possible.  There is a fair amount of infrastructure in place to  
do this with HTTP as well.

> AXIOM3     : Adding a new protocol to the Internet should not  
> require any change to the core Internet infrastructure, including  
> the DNS, nor should this require consumption of any finite resource  
> (IP ports, DNS RRs).

It would be better to design authorization and authentication within  
the protocol initially, rather than adding these feature later.  You  
describe a mechanism to publish SPF record sets across a vast name  
space.  Whatever problem you see this as resolving creates a hazard  
many orders of magnitude worse.  You are in a good position to know  
controlling a domain or even millions of domains means very little.   
When a domain wishes to be white listed, they will ensure all the  
pieces needed in this new puzzle are in the right place.

Much is still possible by defining new RRs without changing how they  
operate.  Security demands simplicity.

-Doug





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