Subject: RE: [Asrg] 6. Proposals - RMX I Never send mail

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 25 Sep 2003 10:19:19 -0700

> -----Original Message-----
> From: Raymond S Brand [mailto:[email-masked]]
> Sent: Thursday, September 25, 2003 12:51 PM
> To: [email-masked]
> Subject: Re: [Asrg] 6. Proposals - RMX I Never send mail
> 
> 
> Although I agree with the motivation and sentiments expressed 
> in this idea,
> it suffers from the same set problems that _ALL_ of the TXT 
> RR ideas suffer
> from:
> 
> 1) Large responses to the query. Potentially very large when 
> you include
> 	some other TXT RRs people have suggested.

I don't think this is a major problem. The amount of text sent in a UDP
packet is effectively limited to 500 bytes and the cost is almost entirely
routing.

If the UDP response is too large the client does not need to followup with
TCP.

> 2) Multiple responses to search through to find the 
> specifically formatted
> 	TXT RR the application is looking for.

Here an SRV like selector mechanism of the sort you propose would work well.
I would suggest however that any selector use the numeric port address
rather than a protocol name. Here we are really giving a line
characteristic.

That said it is useful to distinguish addresses that do not initiate any
connections (i.e. they only act as servers) and those that never respond,
this might merit a case by case consideration.

> 3) Parsing the formatted TXT RR to find the data that the 
> application is
> 	interested in.

I am unconvinced on that point. All a network protocol consists of is
parsing and more parsing. 

> If instead you use the name from the the rDNS query result to 
> do an A RR
> query of the following (DRIPish) form:
> 
> 	addrtype._email_.${PTR_VALUE}
> 
> This way you get 24 bits to assign meaning to (if results 
> must be part of
> 127.0.0.0/8). The query response will be small. Multiple A RRs in the
> response mean the test failed. No parsing needed.
> 
> You should also do an A RR query on ${PTR_VALUE} to verify 
> that the PTR RR
> record isn't bogus.
> 
> 
> Raymond S Brand
> 
> 
> "Hallam-Baker, Phillip" wrote:
> > 
> > All,
> > 
> >         There seems to be an issue with current blacklist 
> implementations.
> > The DNS server approach works fine functionally but the 
> blacklist server
> > becomes a target for a DoS attack. While it is possible to run DNS
> > configurations hardened against DNS attack this costs a 
> collosal amount. The
> > cost of the necessary bandwidth, hardware, support of doing 
> it right is
> > huge.
> > 
> >         I would like to suggest therefore that we look for 
> ways that we can
> > distribute certain information that is currently distributed via DNS
> > blacklists in a more distributed fashion. This will not be 
> possible for all
> > information of course but is possible for certain subsets.
> > 
> >         In particular dial up modem pools, residential 
> broadband links,
> > services that never send mail can be blacklisted through 
> the rDNS. This has
> > a second advantage, the responsibility for maintenance is 
> brought back to
> > the owner of the IP address. This would address current 
> problems with large
> > IP address blocks being contaminated by prior spammer 
> hijacking, listing by
> > an ISP etc.
> > 
> >         For example 18.2.1.xx might have a DNS record of one of the
> > following forms
> > 
> >                 TXT             <ASRG><TYPE>DIALUP</TYPE></ASRG>
> >                 POLICY  DIALUP
> > 
> >         Where POLICY would be a new record written for the 
> purpose (usual
> > caveats apply). The usual caveats about using the DNS would 
> also apply, risk
> > of spoofing etc. However I think that if those are really 
> an issue we just
> > go fix DNS.
> > 
> >         I would see the following as useful identifiers:
> > 
> >                 SERVER          A full service IP address
> >                 DIALUP          The address is allocated to 
> a dialup modem
> > pool
> >                 RESIDENTIAL             The address is allocated to
> > residential broadband
> >                 BLOCKED         The address is blocked, you 
> should never
> > connect
> >                 UNALLOCATED             The address has not 
> been allocated
> > 
> >         It might be useful to make this a bit more complex 
> so as to allow
> > specific protocols to be identified, but I think that is 
> best done through
> > the forward DNS.
> > 
> >         This might be interpreted as breaking the end to 
> end religion, but
> > people are already doing that of their own accord. I would 
> rather have ISPs
> > open port 25 outgoing and label the connection honestly as 
> residential than
> > have then block the port entirely to stop attacks from 
> anti-spam vigilantes.
> 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 25 Sep 2003 16:47:53 -0400

I would like to make some comments in the RMX and DNSRBL areas in general.

First of all, as someone else pointed out two days ago in the list, 
there are several competing proposals for DNS-based verification (RMX, 
DRIP, etc.). We need someone who has knowledge in this area to figure 
out how to reconcile these proposals.

Second, we also need to sit down and evaluate how RMX and DNSRBLS affect 
existing systems, and how viable are they. The tech consideridations 
document and requirements document would help here, and the tech 
considerations document actually has a checklist. We also need to figure 
out how this fits in within the consent framework, if we are going with 
proceed with the notion of consent.

Third, the issue with DDOS and DNSRBLs has relevance in the BCP area 
from both the side of the operator of the blacklist and the customers of 
the blacklist. For example, we need guidelines on how an anti-spam 
system should deal with a DNSRBL that has been DDOSed or has gone beserk 
(like Osirusoft has down recently). While technical issues are 
important, we also need to deal with some policy issues. I think that 
some of the folks involved with both DNSRBLs and DNS can give invaluable 
input on the policy side. BTW, Chris Lewis and Matt Sergeant have been 
doing some work on the BCP area, and a draft should be forthcoming soon.

Yakov

---

From: Raymond S Brand <[email-masked]>
Date: Thu, 25 Sep 2003 19:06:59 -0400

Please DO NOT cc me the message is also sent to the list.

Raymond S Brand

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 26 Sep 2003 01:53:34 +0200

> Please DO NOT cc me the message is also sent to the list.

Yeah!
And this is so important, that you have so send it to the whole list
with the fully quoted original mail attached.
Use  Mail-Followup-To  if you don't want copies.

And stop top posting.
   | Posting at the top because that's where the cursor happened to be
   | is like shitting in your pants because that's where your asshole
   | happened to be.  

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"