Hmm. just about 23 hours. So much for sitting quietly while the working
group discusses matters.
The answer to both the questions is "yes". There is still no evidence
for "no", and _still_ no one has come forward with personal knowledge of
any attacks:
-Sullivan appears to have no personal knowledge of any attacks working
at Afilias, and doesn't assert having personal knowledge.
-Conrad says BCP38 hasn't worked (it has indeed worked--imagine if no
one implemented BCP38), worked for Nomimum, and ICANN, and appears to
have no personal knowledge of any attacks and does not assert personal
knowledge.
-Andrews works for ISC, the document author's employer. Appears to have
no personal knowledge of any attacks, and doesn't assert having any.
-Maton Sotomayer works for the Canada National Research Council, and
also appears to have no direct knowledge of any attacks, and doesn't
assert having any.
-Darcy works for Chrysler, appears to oppose the document, I think.
Not one single attack has been cited where the two measures cited were
actually insufficient.
To recap:
For some reason that promotors can't or won't explain, they want
everyone take the extreme measure to close open recursors, even though
this causes harm to many users through cache poisoning of recursors they
can't control. DNSSEC advocates sell DNSSEC as a solution to cache
poisoning. So they are making a situation worse for their own benefit
and profit. DNSSEC advocates are also SOLICITING abuse of open
recursors. Some of the above people are known to be DNSSEC advocates.
DNSSEC software promoters stand to sell more software if open recursors
are widely closed. I've already given a definition of Actionable Fraud.
Strangely, the Area Director Ron Bonica thinks (onlist and offlist
email) that honesty, reputation, and evidence of harm, are of no
consequence to the IETF when considering extreme measures such as this
document, and that objections based on the a reputation for previous
deceptions, lack of evidence and justification for the extreme action in
this document are for some reason (also unexplained) irrelevant. Kind
of like a kangaroo court for IETF documents: Evidence for the document
is unnecessary; evidence against the document is irrelevant. How is
that an honest and open process?
Of course, an Area Director has a lot of ability to force a document
through the process---violating a lot of rules and violating IETF
principles along the way as previous experience shows with RFC4786 and
TLS-AUTHZ (one succeeded, on failed; ISC et al benefited from RFC4786).
The Area Director can do this because its up to the Area Director to
enforce the process rules, so if the Area Director disregards the rules,
they can do anything--for a while, anyway. If this document is forced
through 'by hook or by crook', it may just wind up another in a pattern
of discredited IETF documents.
Fortunately, not everyone believes there should not be any personal
accountability for past actions. Sometimes all that is needed is an
account of past actions.
--Dean
On Tue, 9 Sep 2008, Ron Bonica wrote:
> Dean,
>
> Thanks for this proposal. At his point, I will sit quietly for a while
> and let the WG comment on whether they think that your proposed
> alternative mitigation is adequate. On Friday, the WG chairs will gauge
> consensus and I will take appropriate action.
>
> Ron
>
>
> Dean Anderson wrote:
>
> >
> > Mitigation of open resolver attacks is well described, both by BCP38 and
> > by the previous comparision with the more damaging DNS attack.
> >
> > If one is attacked by open recursors, the mitigation during the attack
> > is to filter the packets from the open recursors during the attack.
> > Filtering open recursors usually has little or no damage to either the
> > recursor operator or the target of the attack. This is the typical
> > response by ISPs to all kinds of packet flooding attacks. There is
> > nothing special about open recursor attacks that requires any kind of
> > special handling.
> >
> > --Dean
>
>
On Wed, 10 Sep 2008, Ron Bonica wrote:
>
> >
> >> First layer of defense: BCP 38
> >>
> >> Second layer of defense (because there are those who cannot or will not
> >> implement the first layer): Restrict recursive service by default
> >
> > If you mean 'restrict software configuration defaults', I'm OK with
> > that.
> >
> > If the draft is amended to only recommend that vendors should alter
> > their _default_ software configuration, then I will not object to the
> > draft.
> >
> >> Third layer of defense (because there are those who cannot or will not
> >> implement the first or second layers): Reactively filter abusive
> >> recursors (as Dean suggested).
> >
> >
>
> Folks,
>
> Based on the response that we have seen from the WG so far, I don't see
> any reason to amend the draft. BCP 38 is already published.
>
> The questions before the WG are:
>
> - is BCP38 enough to mitigate the attack vectors described in
> draft-ietf-dnsop-reflectors-are-evil-06
> - is filtering after the attack has begun good enough
>
> If the answer to both of these questions is "no", the document can go
> forward as is.
>
> Ron
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
