Subject: RE: [Asrg] Re: 6. Proposals - rDNS / MTA MARK - DESCRIPtion not P ERMission

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Dec 2003 08:10:23 -0800

> There are people (even in IETF DNSOP) that think revDNS is obsolete
> and if not for IPv4 it will be at least for IPv6 ;-)

If there is a value it can be implemented. Given the rate of IPv6 progress I
would not worry overmuch about it at this point, the principal of mapping
addresses still holds, the difference is that you probably use a lot of
wildcards and possibly even synthesized responses.

> Currently we tend to a more structured approach like
> 
>   _perm._smtp._tcp.8.0.30.195.in-addr.arpa	IN	TXT	"1"
>   _perm._smtp._tcp.1.0.30.195.in-addr.arpa	IN	TXT	"0"
> 
> or like
> 
>   _smtp._tcp.8.0.30.195.in-addr.arpa		IN	PERM	1
>   _smtp._tcp.1.0.30.195.in-addr.arpa		IN	PERM	0

I would suggest that what is going on here is that you have a lookup
application and that should be your primary key. Within the lookup
application you have a specific protocol, transport and port. Then there is
information about the lookup.

This suggests to me that the ordering should be something like 

	_perm.8.0.30.195.in-addr.arp			The permission
application
	_xxx.8.0.30.195.in-addr.arp			Some other
application
	_smtp._tcp._perm.8.0.30.195.in-addr.arp	Permission data relating to
smtp

Now one issue to consider here is that we are talking about a reverse
lookup. I do not think that the _smtp._tcp labelling is necessarily the
right one. It is right for SRV which goes in the forward direction and could
involve port swapping. 

I think that our application is the reverse, we receive a stimulus on an IP
address, Port, Protocol tuple and want to look it up

	_80._tcp._perm.8.0.30.195.in-addr.arp	Permission data for TCP port
80
	*._perm.8.0.30.195.in-addr.arp		Permission data for all
protocols

OK that is the search term, lets look at the right hand side.

I dislike the binary approach suggested. The types of applications I am
concerned about go beyond spam, I am also concerned about attacks on my root
servers.

I would want to be able to include contact information into the reverse DNS
to be able to perform remediation. So an ISP can add into the rDNS a NAPTR
pointer to its contact desk. That looks like a different application.

From the spam side I would like to be able to broaden the problem. I do not
want to express permission, I want to describe the port and address. If it
is a question of Permission it should be enforced at the router. What we are
talking about here is DESCRIPtion.

	_80._tcp._descrip.8.0.30.195.in-addr.arp	? "TBS"

My discussion with Mark Kosters on TXT versus new record type was somewhat
surprising. I mentioned TXT and got back the response, Oh thats OK that will
work. 

This begs the question of the advantage of a new record type. The only
advantage in the DNS protocol is that a record type is a search term. But it
is already clear that we need additional search terms to be included here
and from a management point of view the _descrip term is pretty nice to
have. Go back to my hypothetical contact desk application. It is quite
likely I would want to be able to separate management of the two data sets
for the different applications by delegating to different resolvers. The
DESCRIPtion resolver might well be some synthetic resolver working on the
DHCP box. I can imaging my contact resolver being very different.

I would like to have more description terms and to be able to impose some
sort of taxonomy on them. It should be possible to combine search terms and
for new terms to be defined independently of the specification.

I see the search terms being expressed syntactically as a TXT record with a
string of XML QName like terms:

   One A:Two B:Three 

If a prefix is specified it is defined by means of a URI in the same manner
as XML namespaces. This may seem overly complex but DO NOT DISCOUNT
EXTENSIBILITY, my experience is that if a protocol is to remain simple and
relevant it should have the extension mechanism designed in. People always
attack the extension mechanisms, particularly if they are unconstrained and
do not involve a council of the great and the good handing out numbers like
IANA does.

The basic terms I think we need are:

    NotAllocated		The address has not been allocated by a
local registry
    NotInService		The address has been allocated but is not in
service
    Prohibited		The address is prohibited from using the speicifed
port
    Restricted		The address is associated with a restricted service
    Annonymous		The address is associated with annoynmous service,
beware.

Annonymous service is what I might provide to people who happened to be
passing by and needed some 802.11b service ex gracia.

Within Restricted and Annonymous I think there are some sub terms
    Pooled			The address is allocated on a pooled basis,
this would
				usually correspond to a dial up modem
    Fixed			The address is allocated on a long term
basis so that
				a single user is associated with the
connection

The point here is that there is no need to prohibit the use of Pooled or
Fixed restricted connections to send mail provided that the receiver is
warned and can take appropriate spam control measures.

Since these are mutually exclusive they can be tied to the master term,
something like Restricted.Pooled

> A solution to that would be to make the RHS not a boolean but e.g.
> a 64 bit integer and give it a meaning:
>    0    dont allow connections
>    1	allow unauthenticated connections (aka outgoing MTA)
>    2	allow only authenticated connections
>    3	allow only authenticated connections with ciphered passwords
> The same could of course also be achieved with TXT records.

TXT is much more extensible. Even if we do not have namespaces.

> One question raised today was:
>   Why is this useful at all? MTA MARK could also be accomplished much
>   more effective by a firewall rule.
> This is IMHO a good and valid question ;-)

I would like to avoid closing down port 25 just because someone is working
from a mass market connection. What do we do when it is no longer possible
to get T1 connections to a house because the cable company has driven the
competition out? If a service 

> An answer might be that firewalls rules are expensive, the more rules
> a firewall has to check the more expensive they get. So with large
> networks MTA MARK (or a more generalized form) could be a alternative.

Firewall rules are a blunt instrument and encourage people to work arround.
If port 25 starts being shut down everywhere there are going to be a lot of
people setting up servers that accept email under submit - and many will end
up being open.

		Phill

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg