At 15:47 +0000 8/10/06, [EMAIL PROTECTED] wrote:
On Thu, Aug 10, 2006 at 10:21:45AM -0400, Steven Champeon wrote:
on Thu, Aug 10, 2006 at 01:11:50AM -0700, william(at)elan.net wrote:
> >>On Aug 9, 2006, at 1:06 PM, Matthew Sullivan wrote:
> >>>
<http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt>
>
> The reason I do not like RDNS naming scheme is because it forces
> one particular policy as part of the name.
Fair enough. FWIW, I've seen a wide variety of naming schemes (I've
got a project that collects these as an antispam/anti-botnet measure,
and so far we've got around 16K conventions documented for 11K domains).
first... as a draft, it carries ZERO weight. -IF- it becomes an
RFC, its targeted status in INFORMATIONAL, e.g no standard of any kind.
So no one is going to -force- you to implement it.
hum... why does this draft remind me of the (in)famous WKS RR?
what is WKS? you know, that RR type that specified the "well known
services" running on/at the particular lable.
WKS was depricated, in part due to the fact that "black hats" would
use WKS to groom thair attack profiles. Use of the conventions
outlined in this draft would be very useful in building targeted
attacks. To paraphrase Randy Bush, "I encourage all my competition to
implement these guidelines."
Piling on here ...
The effort is to infer the intent of a packet based on ancillary
data. The twin dangers here are inference of intent and exposure of
the ancillary data.
The first part is like asking "would I want to have security research
done by a company on Glenwood Road or on Shady Lane?" (Ya, know
"shady" in security.) Legend has it that one research company moved
it's location because of this, or maybe it was a joke that came
afterwards.
The second part is what ancillary data is exposed. You can require,
you can request, or you can assume you won't get the data you need.
Sometimes you won't get it because the giver doesn't want the
headache of providing it or because the giver is afraid of the
ancillary data going to nefarious uses.
My point is that inferring intent based on incomplete data is faulty,
but it seems to be useable in real life. However, once heuristics
get encoded in deterministic algorithms, the results generally are
not so good - mostly because the encoding of the heuristics fails.
The answer is to include things like RFC 3514, (Note the pub date.)
or ancillary data. But the solution of adding ancillary data maybe
worse than the disease. This is just one of the hard problems.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time
catching on in North America.