Subject: Re: [DNSOP] DNSOP Digest, Vol 22, Issue 16

From: "venkatesh.bs" <[email-masked]>
Date: Thu, 11 Sep 2008 00:32:15 +0530

Hi,
       what may be DNS behaviour if the DNS server address is 0.0.0.0

Regards,
venkatesh.

[email-masked] wrote:
> Send DNSOP mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/dnsop
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DNSOP digest..."
>
>
> Today's Topics:
>
>    1. Re:  I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
>       (Dean Anderson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Sep 2008 11:33:20 -0400 (EDT)
> From: Dean Anderson <[email-masked]>
> Subject: Re: [DNSOP] I-D
> 	Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
> To: Kevin Darcy <[email-masked]>
> Cc: DNSOP WG <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Tue, 9 Sep 2008, Kevin Darcy wrote:
>
>   
>> First layer of defense: BCP 38
>>
>> Second layer of defense (because there are those who cannot or will not 
>> implement the firsFrom [email-masked]  Wed Sep 10 12:03:15 2008
Date: Thu, 11 Sep 2008 00:32:15 +0530
From: "venkatesh.bs" <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] DNSOP Digest, Vol 22, Issue 16
Sender: [email-masked]

This is a multi-part message in MIME format.

Hi,
       what may be DNS behaviour if the DNS server address is 0.0.0.0

Regards,
venkatesh.

[email-masked] wrote:
> Send DNSOP mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/dnsop
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DNSOP digest..."
>
>
> Today's Topics:
>
>    1. Re:  I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
>       (Dean Anderson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Sep 2008 11:33:20 -0400 (EDT)
> From: Dean Anderson <[email-masked]>
> Subject: Re: [DNSOP] I-D
> 	Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
> To: Kevin Darcy <[email-masked]>
> Cc: DNSOP WG <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Tue, 9 Sep 2008, Kevin Darcy wrote:
>
>   
>> First layer of defense: BCP 38
>>
>> Second layer of defense (because there are those who cannot or will not 
>> implement the fit 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).
>>     
>
> 		--Dean
>
> --
> 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-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> End of DNSOP Digest, Vol 22, Issue 16
> *************************************
>
>   

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ron Bonica <[email-masked]>
Date: Wed, 10 Sep 2008 15:17:51 -0400

>> implement the first layer): Restrict recursive service by default
> 

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.

             From [email-masked]  Wed Sep 10 12:18:48 2008
Date: Wed, 10 Sep 2008 15:17:51 -0400
From: Ron Bonica <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Sender: [email-masked]

>> implement the first layer): Restrict recursive service by default
> 

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

                       Ron

---

From: Dean Anderson <[email-masked]>
Date: Wed, 10 Sep 2008 16:43:16 -0400 (EDT)

The address 0.0.0.0 as usually an alias for self, so packets to 0.0.0.0
will be locally delivered.  So for recursive DNS servers, this would
result in a recursion-to-self error on most DNS servers.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 10 Sep 2008 16:43:16 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 10 Sep 2008 17:38:05 -0400 (EDT)

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 toFrom [email-masked]  Wed Sep 10 14:39:14 2008
Date: Wed, 10 Sep 2008 17:38:05 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Ron Bonica <[email-masked]>
Cc: Peter Koch <[email-masked]>, [email-masked], "Contreras,
	Jorge" <[email-masked]>,
	[email-masked], [email-masked]
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Sender: [email-masked]

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  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
> 
> 

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
> 
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Sep 2008 18:12:13 -0400

> at Afilias, and doesn't assert having personal knowledge.

I'm not sure how you conclude I have no personal knowledge, or how you
make any inferences about appearances in this matter.  But for the
record, I do in fact have such personal knowledge, so I hereby assert
it.  

Because when I left Afilias I (naturally) left behind any documents or
other evidence to which I might have had access as part of my
employment, I'm not actually in a position to deliver any evidence to
prove to anyone what I have observed.  Since you have responded to
everyone who has said, "I have observed these attacks," with a demand
that they produce evidence that will convince you, it seemed to me to
be futile to claim I've such personal knowledge.  It will only result
in another round of shrill accusations of fraud, long quotations from
(in my opinion completely irrelevant) law dictionaries, &c.  I am
willing to take it as stipulated that I am yet another member of the
giant global conspiracy to suppress the right-thinking way of running
DNS, which is obviously your way; so you may skip listing the many
evils I have committed in the course of my miserable life.  I still
support the document, on the basis of my experience.  I leave it to
others to evaluate whether my experience is of any worth whatsoever.

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 10 Sep 2008 18:12:13 -0400

A

---

From: Joe Abley <[email-masked]>
Date: Wed, 10 Sep 2008 22:16:49 -0400

> draft-ietf-dnsop-reflectors-are-evil-06

This question needs clarification. I say this because this is an  
operations group, not a protocol group; what is dealt with here is  
practice, not theory.

BCP38, if deployed universally, would eliminate the possibility of the  
DNS reflection attacks I have seen, since all those involved the use  
of open recursive nameservers as amplifiers whose input consisted of  
packets with spoofed source addresses.

However, I can see that BCP38 is not universally deployed today, and I  
have no confidence that it will ever be deployed universally.

So I think your question would be better phrased as "can BCP38  
deployment be relied upon to mitigate the attack vectors..." and my  
answer to that question would be "no".

> - is filtering after the attack has begun good enough

If the presence of open resolvers became the exception rather than the  
rule then those few open resolvers could be filtered before attacks  
have begun, perhaps using something akin to a blacklist (which might  
induce them to stop being open). This would be a better situation From [email-masked]  Wed Sep 10 19:18:07 2008
From: Joe Abley <[email-masked]>
To: Ron Bonica <[email-masked]>
Date: Wed, 10 Sep 2008 22:16:49 -0400
Cc: [email-masked]
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Sender: [email-masked]

> draft-ietf-dnsop-reflectors-are-evil-06

This question needs clarification. I say this because this is an  
operations group, not a protocol group; what is dealt with here is  
practice, not theory.

BCP38, if deployed universally, would eliminate the possibility of the  
DNS reflection attacks I have seen, since all those involved the use  
of open recursive nameservers as amplifiers whose input consisted of  
packets with spoofed source addresses.

However, I can see that BCP38 is not universally deployed today, and I  
have no confidence that it will ever be deployed universally.

So I think your question would be better phrased as "can BCP38  
deployment be relied upon to mitigate the attack vectors..." and my  
answer to that question would be "no".

> - is filtering after the attack has begun good enough

If the presence of open resolvers became the exception rather than the  
rule then those few open resolvers could be filtered before attacks  
have begun, perhaps using something akin to a blacklist (which might  
induce them to stop being open). This would be a better situatiothan  
one in which victims have to wait for attacks to start before they  
start working to filter.

So I think I would answer this question "no".

> If the answer to both of these questions is "no", the document can go

Joe

n than  
one in which victims have to wait for attacks to start before they  
start working to filter.

So I think I would answer this question "no".

> If the answer to both of these questions is "no", the document can go

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Sep 2008 08:56:41 +0200

On Thu, Sep 11, 2008 at 12:32:15AM +0530,
 venkatesh.bs <[email-masked]> wrote 

>       what may be DNS behaviour if the DNS server address is 0.0.0.0

Why don't you test? :-)

% dig @0.0.0.0 SOA .
...
;; ANSWER SECTION:
.                       86400   IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2008091001 1800 900 604800 86400
...

0.0.0.0 means historically "this machine" (this behaviour does not
seem properly standardized in a RFC, by the way, and it certainly
would be dangerous to rely on it), so, in practice, it is not much
different from 127.0.0.1.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Sep 2008 08:56:41 +0200

Why don't you test? :-)

% dig @0.0.0.0 SOA .
...
;; ANSWER SECTION:

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Sep 2008 09:01:01 +0200

On Wed, Sep 10, 2008 at 03:17:51PM -0400,
 Ron Bonica <[email-masked]> wrote 
 a message of 39 lines which said:

> 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.

It is certain that any message by <unnamed troll that everyone will
recognize> is not sufficient ground for any action or inaction. I
strongly suggest to completely ignore what he writes.

> draft-ietf-dnsop-reflectors-are-evil-06

Yes. But I agree with Joe Abley rewriting and I regret that the
current draft still continues to pretend that BCP38 is the right
solution to the problem; it is not a realistic solution.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 11 Sep 2008 09:01:01 +0200

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 11 Sep 2008 09:08:50 +0200

Dear Dean,

[Removing Jorge from the CC-list, this reply is supposed to be  
technical in nature. Also removing the IESG since this appears to be a  
WG issue, they can go back to the archives if and when relevant]

> -AndrewsFrom [email-masked]  Thu Sep 11 00:09:30 2008
From: Olaf Kolkman <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Thu, 11 Sep 2008 09:08:50 +0200
Cc: Ron Bonica <[email-masked]>, Peter Koch <[email-masked]>, [email-masked],
	Bill Manning <[email-masked]>
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

Dear Dean,

[Removing Jorge from the CC-list, this reply is supposed to be  
technical in nature. Also removing the IESG since this appears to be a  
WG issue, they can go back to the archives if and when relevant]

> -Andre works for ISC, the document author's employer. Appears to  
> have

I do not have first hand experience from being under attack but I have  
seen enough arguments that reflector attacks are not only  
hypothetically possible but they also happen in real life. Not only  
from private conversations but also from, for instance, http://staff.washington.edu/dittrich/misc/ddos/grc-syn.txt 
  and http://www.isotf.org/news/DNS-Amplification-Attacks.pdf and  
references therein.

The fact that folk do not have first hand experience in being attacked  
does not dismis them from making an informed trade-off.  For example.  
Fortunately, nobody in my circle of friends or family has ever been in  
a serious car crash. But that does not dismiss me from telling my kids  
that they SHOULD wear their seat belts (actually in my household it is  
a MUST).

An informed trade-off is what I made when reviewing the document.

> can't control.

Although I agree that universal BCP38 deployment would mitigate  
reflector type DDOS attacks and the Kaminsky style cache poison  
attacks. I also know that BCP38 is far from universally deployed.

Because I think that BCP38 deployment is not yet sufficient I support  
draft-ietf-dnsop-reflectors-are-evil-06. The draft as is does explain  
in detail what the problem is with DDOS caused by reflection and  
argues that "By default, nameservers SHOULD NOT offer recursive  
service to external networks.".

That is an instruction to us (I am wearing my NLnet Labs Hat) as  
software developers who ship software to be very careful in what sort  
of settings I present to whoever installs our software.

The document does not prevent an operator to change to a non-default  
setting and offer recursion to the world but allows them to make an  
informed decision.

> DNSSEC advocates sell DNSSEC as a solution to cache
> and profit.

I have not seen your argument (maybe I've overlooked it) why DNSSEC  
advocates benefit from this draft being published. I think BCP38 has  
to do with it.

For what its worth if your argument is (I am guessing): BCP38 would,  
if it were to be universally deployed, mitigate Kaminsky style  
attacks.  If that is the argument I would actually agree. And even  
though DNSSEC protects against other types of attacks as well full  
deployment of BCP38 might change the cost/benefit ratio for the  
deployment of DNSSEC. Even as a DNSSEC advocate I might be starting to  
sing a different tune then, but not now.

--Olaf Kolkman (NLnet Labs)

---

From: "Ondřej Surý" <[email-masked]>
Date: Thu, 11 Sep 2008 11:34:05 +0200

> draft-ietf-dnsop-reflectors-are-evil-06

this is like asking: "Will safe driving prevent car accidents?"  Exact
answer to your question is "xZ��좖�w�'�~��N�z�u�m��m���^���=�av{(��.�Ǭ��_��:���v�N�g��Z��b��)�)��'�~��
�b���u:"z�ڭ�]��)j�!������jk%r��yǢ��_���۽4�ZjXh��v�M5o'(��ښ�\�c������D�L���:�p:��ӆ�uI�v�O4�~u�N����\��)ڕ:��)r��ݩ���&
�b���u:��)r��ݩ���&E����~�&���,�ZjXh��v�M5o'(��ښ�\�c������D�L���^A�p:���g��\���jk%r����uI�v�O4�~u�N����]X��Ĝjy�u���+�������&]*Z�YZ�ӗJ��I�+{];�t�jb޽�WJ��J֭��h��+{];�֠��Zn����kz����y��-�-4۟}�NDa�/N�ؐ� "�4��}:0��@7E����~�&�����_��:�^����o)hq�a��\���jk%r��۽4թ��+��)��u�M��+a#>'E��<Έ��ߢ�g��\���jk%r����uI�v�O4�~t�N����E����~�&��.�Ou�
(�W��iߢ�t�] ��%y�&덷�_6��[��+{v��W(��,����+a#>'wN9��Ӈ��좘���+�8n�T��m4�M��N��M
4^q�y���.�Ou�
(�W��l"��L��o]l�^<��'~�~�ݞ�)��_����uI�v�O4�~4�N����E����o-t�]9�|"��L���y��Nu��m�<�m��nz���8n�T��m4�M��Nt�M
4^q�y���M�ӭ����t�=8n�T��m4�M��Nt�M
> draft-ietf-dnsop-reflectors-are-evil-06

this is like asking: "Will safe driving prevent car accidents?"  Exact
answer to your question is W2"�'WB&VƗG��2F�B$53��2��Bv���p�F�&RV�fW'6�ǒFW���VB6����6�ג�7vW"v�F�&VƗG�F�V6��2��ࠣ���2f��FW&��rgFW"F�RGF6��2&VwV�v��BV��Vv�������B�F��wBV�FW'7F�Bv��F�R'W&FV��b�V�&W6��fW'26��V�@�&RWB��6��V�FW'2�bGF6�VBD�2�W&F�'2ࠣ��bF�R�7vW"F�&�F��bF�W6RVW7F���2�2&��"�F�RF�7V�V�B6�v��f�'v&B2�2ࠤ��G&V�������LY�V�7W,;ТFV6��6�;�Y�VF�FV��6��VbFV6��6��ff�6W �����������������������������������������Т5���2���2�������7�F����&Vv�7G'���W&�6�:#2�#&�"�7�V6�&WV&Ɩ0����F���G&V��7W'��2�7��GG����2�7��6����G&V��7W'��2�7�FVâ�C#�###sCS���#��C#�s3�3c��f���C#�###sCS �����������������������������������������Х�����������������������������������������������D�4���Ɩ�rƗ7@�D�4��WFb��&p��GG3���wwr�WFb��&r�������Ɨ7F��f��F�6����̈����Ёɕ����䁥́ѡ�Ё	
@����́��Ё�����)Ѽ����չ�ٕ�ͅ��䁑����啐�ͽ����ͼ��䁅��ݕȁݥѠ�ɕ�����ѽՍ���́9<�((�����́���ѕɥ�����ѕȁѡ����х�����́���ո���������՝�()9�������$�����Ёչ����х���ݡ�ѡ����ɑ�����������ɕͽ�ٕ�́͡�ձ�)�����Ё���͡�ձ���́�����х�����9L����Ʌѽ�̸((��%��ѡ�����ݕȁѼ���Ѡ����ѡ�͔��Օ�ѥ��́�̀������ѡ�����յ��Ё������(�����݅ɐ��́�̸()=��ɕ��(���(�=��e���M���(�ѕ�������e���ѕ��
�����Q���������=������(������������������������������������������(�
h�9%���̹����������聑������ɕ������(���ɥ�����̰�������AɅ���ȱ
镍��I��Չ���(�����Ѽ齹�ɕ�����������聡���輽������(�ͥ�齹�ɕ������������ѕ���������������(�����������������䁙����������������(������������������������������������������)}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}|)9M=@�������������)9M=A��ј��ɜ)�����輽��ܹ��ј��ɜ������������ѥ������ͽ�(

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Sep 2008 15:16:56 -0400 (EDT)

On Thu, 11 Sep 2008, Olaf Kolkman wrote:

> from private conversations but also from, for instance, 
> http://staff.washington.edu/dittrich/misc/ddos/grc-syn.txt 

This is a report from 2002, describing a 4x amplification attack.

>   and http://www.isotf.org/news/DNS-Amplification-Attacks.pdf and  

The above is a document from Gadi Evron of Afilias, documenting the two
small motivating attacks. There is nothing new in that report.

> does not dismis them from making an informed trade-off.  

There is first-hand experience and hearsay.  What you have is hearsay
and rehashed old reports.  

	--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Sep 2008 15:16:56 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Sep 2008 15:34:36 -0400 (EDT)

Please tell about the experiences you personally had with open recursor
attacks at Afilias.

Afilias doesn't seem to run open recursors--is that correct?  Was
Afilias a target of an attack? If so, what did Afilias do to mitigate
the attack?  Why couldn't the attack be mitigated using ordinary
methods?  I don't seem to have any mention anywhere about Afilias being
down or harmed as a result of any attack.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Sep 2008 15:34:36 -0400 (EDT)

--Dean

---

From: Ron Bonica <[email-masked]>
Date: Thu, 11 Sep 2008 15:39:09 -0400

Folks,

This is a reminder that only two questions are on the table. These are:

Discussions of how many times this attack has been observed in the wild,
who has reported the attack, who that person works for, and whether that
person is credible are entirely out of bounds.

                               Ron

Dean Anderson wrote:
>> http://staff.washington.edu/dittrich/misc/ddos/grc-syn.txFrom [email-masked]  Thu Sep 11 12:39:31 2008
Date: Thu, 11 Sep 2008 15:39:09 -0400
From: Ron Bonica <[email-masked]>
To: Dean Anderson <[email-masked]>
Cc: Olaf Kolkman <[email-masked]>, Peter Koch <[email-masked]>, [email-masked],
	Bill Manning <[email-masked]>
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Sender: [email-masked]

Folks,

This is a reminder that only two questions are on the table. These are:

Discussions of how many times this attack has been observed in the wild,
who has reported the attack, who that person works for, and whether that
person is credible are entirely out of bounds.

                               Ron

Dean Anderson wrote:
>> http://staff.washington.edu/dittrich/misc/ddos/grc-syn.txt t 
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Sep 2008 15:48:42 -0400

> Please tell about the experiences you personally had with open recursor

I guess I wasn't clear enough in my message: I am not in a position to
tell you about that.  I am constrained by the non-disclosure terms of
my previous employment.  If Afilias believes that it can discuss those
attacks in a forum like this, I'm sure the management will send some
notices about them.  I have little confidence that they will send
those notices, for the same reasons everyone else in this thread has
mentioned.  

> down or harmed as a result of any attack.

I am not willing to speak about any specific case involving Afilias or
any machines that it operates.  I will note, however, that there is a
harm to any operator when it has to respond to attacks: they're
emergencies and have to be treated as such.  This entails use of staff
time, and often at inconvenient hours.  So even if all the services
stay up and nobody knows about an attack, that is nowise evidence that
no harm happens.  Therefore, since the document we're still discussing
offers (perhaps redundant) defence From [email-masked]  Thu Sep 11 12:49:00 2008
Date: Thu, 11 Sep 2008 15:48:42 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Sender: [email-masked]

> Please tell about the experiences you personally had with open recursor

I guess I wasn't clear enough in my message: I am not in a position to
tell you about that.  I am constrained by the non-disclosure terms of
my previous employment.  If Afilias believes that it can discuss those
attacks in a forum like this, I'm sure the management will send some
notices about them.  I have little confidence that they will send
those notices, for the same reasons everyone else in this thread has
mentioned.  

> down or harmed as a result of any attack.

I am not willing to speak about any specific case involving Afilias or
any machines that it operates.  I will note, however, that there is a
harm to any operator when it has to respond to attacks: they're
emergencies and have to be treated as such.  This entails use of staff
time, and often at inconvenient hours.  So even if all the services
stay up and nobody knows about an attack, that is nowise evidence that
no harm happens.  Therefore, since the document we're still discussing
offers (perhaps redundant) defence agagainst a line of attack, I support
it.

A

ainst a line of attack, I support
it.

A

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Sep 2008 16:00:05 -0400 (EDT)

On Thu, 11 Sep 2008, [UTF-8] OndÅ™ej SurÃ½ wrote:

> No.  And I don't understand why the burden of open resolvers should
> be put on shoulders of attacked DNS operators.

DNS operators aren't generally being attacked, and aren't generally
complaining of the burden.  Almost no one is complaining of an actual
burden. Indeed, the almost total lack of burden is what's most notable
for this extreme measure of closing all open recursors.

However, if there someday becomes a true burden, the first complaint
should go to the DNSSEC vendors/advocates such as Nominet and DNSSEC.NET
who are soliciting abuse of open recursors.

I don't understand why open recursors should be closed to increase the
sales of DNSSEC software---closed to increase the harm from cache
poisoning---closed for no reason.

The whole thing appears to be a scam to me.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 11 Sep 2008 16:00:05 -0400 (EDT)

--Dean

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 11 Sep 2008 21:55:46 +0200

> draft-ietf-dnsop-reflectors-are-evil-06

Were it universally deployed, yes. Will it be? No. Thus, no. 

> - is filtering after the attack has begun good enough

No. There might be sufficent harm caused by the transient damage before
responsive filtering (as opposed to measures already in place) takes
effect.

/Måns, borrowing the reminder to state his position. 
-- 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 11 Sep 2008 21:55:46 +0200

---

From: Roy Arends <[email-masked]>
Date: Fri, 12 Sep 2008 10:31:59 +0200

T24gU2VwIDEwLCAyMDA4LCBhdCA5OjE3IFBNLCBSb24gQm9uaWNhIHdyb3RlOgoKPiBGb2xrcywKPgo+IEJhc2VkIG9uIHRoZSByZXNwb25zZSB0aGF0IHdlIGhhdmUgc2VlbiBmcm9tIHRoZSBXRyBzbyBmYXIsIEkgZG9uJ3QgIAo+IHNlZQo+IGFueSByZWFzb24gdG8gYW1lbmQgdGhlIGRyYWZ0LiBCQ1AgMzggaXMgYWxyZWFkeSBwdWJsaXNoZWQuCgpJbiBkZWZlbnNlIG9mIHB1Ymxpc2hpbmcgZHJhZnQtaWV0Zi1kbnNvcC1yZWZsZWN0b3JzLWFyZS1ldmlsIEknZCBsaWtlICAKdG8gcHV0IGZvcndhcmQgdGhlIGZvbGxvd2luZyBhcnRpY2xlIHRoYXQgd2FzIHBhcnQgb2YgYSBwYXBlciBJIGNvLSAKYXV0aG9yZWQgaW4gMjAwNS4gSSBkbyB0aGlzIHRvIHNob3cgdGhhdCB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBkcmFmdCAgCmlzIGxvbmcgb3ZlcmR1ZSwgYW5kIHRoYXQgSSByYXRoZXIgaGF2ZSBpdCBwdWJsaXNoZWQgc29vbmVyIHRoYW4gIApsYXRlci4gRnVydGhlcm1vcmUsIHRvIGRlZmVuZCBhZ2FpbnN0IGFidXNlIHRoYXQgaW5jbHVkZXMgb3Blbi0gCnJlc29sdmVycyBJIHdvdWxkIHdlbGNvbWUgYW4gUkZDIGFzIHNvb24gYXMgcG9zc2libGUsIHRvIGhhdmUgYSAgCmJvaWxlcnBsYXRlIHRoYXQgSSBjYW4gc2hvdyBmb2xrcywgd2hvIHVua25vd2luZ2x5IHJ1biBvcGVuIHJlc29sdmVycywgIApidXQgbmVlZCBhIHBvaW50ZXIgdG8gZGVmZW5kIHRoZSBjb3N0IG9mIGNvbmZpZ3VyYXRpb24gY2hhbmdlIHRvIHRoZWlyICAKbWFuYWdlbWVudC4KClRoZSBhcnRpY2xlOgoKQWJvdXQgT3BlbiBSZWxheXMgYW5kIE9wZW4gUmVzb2x2ZXJzCgpJbiB0aGUgZWFybHkgZGF5cyBvZiB0aGUgSW50ZXJuZXQgaXQgd2FzIGNvbW1vbiB0byBvZmZlciBzZXJ2aWNlcyB0byAgCmV2ZXJ5b25lLCBlaXRoZXIgaW50ZW50aW9uYWxseSBvciBhcyBhIHNpZGUgZWZmZWN0LiAgVGhlIHJpc2Ugb2Ygc3BhbSAgCnRhdWdodCB1cyB0aGF0IHRoaXMgYXBwcm9hY2ggd2FzIG5vdCB3ZWxsIHN1aXRlZCBmb3IgdGhlIHJlYWwgd29ybGQsICAKc28gb3ZlciB0aW1lIG1vc3Qgb3BlbiByZWxheXMgd2VyZSBjbG9zZWQuICBTcGFtIGRpZCBub3QgY2Vhc2UgYnV0ICAKanVzdCBvbmUgYWJ1c2UgbWVjaGFuaXNtIGRpc2FwcGVhcmVkLiAgSW4gdGhlIEROUyB0aGVyZSBpcyBhIHNlcnZpY2UgIApzaW1pbGFyIHRvIG9wZW4gcmVsYXlzOiByZXNvbHZlcnMgb2ZmZXJpbmcgcmVjdXJzaXZlIHNlcnZpY2UgdG8gIAphbnlvbmUuICBXaGlsZSBsYXJnZSBJU1BzIG9yIG9yZ2FuaXNhdGlvbnMgbmVlZCBvbmUgb3IgbW9yZSByZWN1cnNpdmUgIApuYW1lIHNlcnZlcnMgKHJlc29sdmVycykgdG8gc2VydmUgdGhlaXIgb3duIGNsaWVudHMsIHRoZXJlIGlzIG5vIG5lZWQgIAp0byBzZXJ2ZSB0aGUgd29ybGQuICBFdmVuIHdvcnNlLCBkdWUgdG8gdGhlIGV4aXN0ZW5jZSBvZiBjYWNoZSAgCnBvaXNvbmluZywgdGhpcyBraW5kIG9mIG11bmlmaWNlbmNlIG1heSBleHBvc2UgdGhlIHN5c3RlbSB0byBjZXJ0YWluICAKYXR0YWNrcy4gIFdoaWxlIHRoaXMgaGFzIGJlZW4ga25vd24gZm9yIHF1aXRlIHNvbWUgdGltZSwgd2Ugd2lsbCBzaG93ICAKaG93IHRoaXJkIHBhcnRpZXMgY2FuIGNvbW11bmljYXRlIHRocm91Z2ggb3BlbiByZXNvbHZlcnMsIHVzaW5nICAKbm90aGluZyBlbHNlIGJ1dCBETlMgcHJvdG9jb2wgY29uZm9ybWFudCBwYWNrZXRzLgoKQ2FjaGUgcG9pc29uaW5nIGlzIGRvbmUgaW4gc2V2ZXJhbCB3YXlzLCBlYWNoIHBhcnQgb2YgYSBkaWZmZXJlbnQgIApjbGFzcyBvZiBhdHRhY2tzLiAgVGhlcmUgaXMgdGhlIGludHJ1c2l2ZSBhdHRhY2ssIHdoZXJlIGEgcGljYXJvIGNhbiAgCnNpdCBvbiB0aGUgd2lyZSBhbmQgYWx0ZXJzIGhvc3QgYWRkcmVzc2VzIGluIHJlc3BvbnNlIHBhY2tldHMsIHdoaWNoICAKd2lsbCBzdWJzZXF1ZW50bHkgYmUgY2FjaGVkIGZvciBhIGNlcnRhaW4gdGltZSBieSBhIHJlc29sdmVyLiAgQW5vdGhlciAgCmNsYXNzIGlzIHRoZSB0cmlhbCBhbmQgZXJyb3IgYXR0YWNrLCB3aGVyZSBhIHJlc29sdmVyIGlzIGhvc2VkIHdpdGggYSAgCmJ1bGsgb2YgaWRlbnRpY2FsIHJlc3BvbnNlcywgd2hpbGUgdGhlIGlkZW50ae+sgWVycyBhcmUgZGlmZmVyZW50LiAgVG8gIAppbmNyZWFzZSB0aGUgc3VjY2VzcyBvZiBzdWNoIGFuIGF0dGFjaywgdGhlIGV4cGlyeSB0aW1lIG9mIHRoZSBjdXJyZW50ICAKY2FjaGVkIGRhdGEgZm9yIGEgY2hvc2VuIGNhbmRpZGF0ZSBjYW4gZWFzaWx5IGJlIG1lYXN1cmVkLiAgQW4gb3BlbiAgCnJlc29sdmVyIHdpbGwgcHJvbXB0bHkgcmVzcG9uZCB0byBwcm9iZXMgZm9yIHRoZSBleHBpcnkgdGltZSBvZiB0aGUgIApjdXJyZW50IGNhY2hlZCBkYXRhLgoKQW5vdGhlciB0eXBlIG9mIGF0dGFjayBpcyBhIHNpbXBsZSBEZW5pYWwgb2YgU2VydmljZSBhdHRhY2sgYWdhaW5zdCBhICAKcmVzb2x2ZXIuICBUaGUgQklORCA4IG5hbWVzZXJ2ZXIgZG9lcyBub3QgaW1wbGVtZW50IGEgbWVtb3J5LXVzYWdlICAKbWF4aW11bS4gIEl0IGlzIHRyaXZpYWwgdG8gYnVyc3QgYSBzZXQgb2YgcXVhbGnvrIFlZCBxdWVyaWVzIHRvIGEgIApyZXNvbHZlciwgd2hlcmUgdGhlIHJlc3BvbnNlcyB3aWxsIGNvbnRhaW4gcmVjb3JkcyB3aXRoIGhpZ2ggVFRMICAKdmFsdWVzLCBpbiBvcmRlciB0byBpbmNyZWFzZSB0aGUgbWVtb3J5IGZvb3RwcmludCBvZiBhIGNhY2hlLiAgT25jZSAgCnRoZSBzaXplIHdpbGwgbmVhciBwaHlzaWNhbCBsaW1pdGF0aW9ucyBvZiBzb21lIGZvcm0sIHRoZSBzZXJ2ZXIgd2lsbCAgCnN0YWxsIG9yIHdvcnNlLCBzdG9wIHByb2Nlc3NpbmcgcXVlcmllcy4KClVzaW5nIG9wZW4gcmVzb2x2ZXJzIGFzIGEgRG9TIGFtcGxp76yBZXIgaXMgYW5vdGhlciBhdHRhY2sgdmVjdG9yLiAgSXQgIAppcyB0cml2aWFsIHRvIHNlbmQgYSBzaW5nbGUgcXVlcnkgdG8gYSByZXNvbHZlci4gIEl0IGlzIHRyaXZpYWwgdG8gIApzZW5kIGEgYnVsayBvZiBpZGVudGljYWwgcXVlcmllcyB0byBhIGJ1bGsgb2Ygb3BlbiByZXNvbHZlcnMuICAgIApBY3F1aXJpbmcgYSBzZXQgb2YgSVAgYWRkcmVzc2VzIHdoaWNoIGhvc3Qgb3BlbiByZXNvbHZlcnMgaXMgdHJpdmlhbCAgCmFzIHdlbGwuICBTaW5jZSBETlMgaXMgVURQIGJhc2VkLCBhIHNjYW4gb2YgYSBzaW5nbGUgLzE2ICjigJljbGFzcyAgCkLigJkpIG5ldHdvcmsgdGFrZXMgb25seSBtaW51dGVzLiAgVXNpbmcgYSBsYXJnZSBlbm91Z2ggYnVsayBvZiAgCnJlc29sdmVycyB0byBxdWVyeSByb290IG9yIFRMRCBzZXJ2ZXJzIGZvciBhIHNpbmdsZSBuYW1lIGNhbiBjYXVzZSB0aGUgIApyZXNwZWN0aXZlIGRvbWFpbiB0byBleHBlcmllbmNlIGEgc2lnbmnvrIFjYW50IHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLgoKQSBuZXcgc2V0IG9mIGFidXNpdmVuZXNzIGlzIGN1cnJlbnRseSBiZWluZyBkZXZlbG9wZWQgdGhhdCBpbnZvbHZlcyAgCnVzaW5nIGEgYnVsayBvZiBvcGVuIHJlc29sdmVycyBhbmQgdGhlaXIgY2FjaGUgYXMgYSB3YXkgdG8gc3RvcmUgYW5kICAKdHJhbnNmZXIgZGF0YSwgZGlzZ3Vpc2VkIGFzIEROUyBkYXRhLiAgVGhlIGRhdGEgY2FuIHRha2UgYW55IGZvcm0sICAKZnJvbSBzdHJlYW1pbmcgbWVkaWEgdG8gYml0LXRvcnJlbnQgc2VlZHMgW0thbWkwNF0uCgpOb3RlIHRoYXQgdGhlc2Ugb3BlbiByZXNvbHZlcnMgZG8gbm90IGhhdmUgdG8gYmUgcmVjcnVpdGVkIHRvIGJlICAKdmljdGltaXNlZC4gIFRoZXkgYXJlIHRoZXJlIGZvciB0aGUgdGFraW5nLCB0aGV5IHNpbXBseSBuZWVkIHRvIGJlICAKZm91bmQuICBBbGwgdGhpcyBjYW4gYmUgZG9uZSB3aXRoaW4gdGhlIGJvdW5kYXJpZXMgb2YgdGhlCkROUy1wcm90b2NvbC4gIFRoZSBwYWNrZXRzIG9uIHRoZSB3aXJlIGFyZSBzb2xlbHkgRE5TIG1lc3NhZ2VzLgoKW0thbWkwNF0gRC4gS2FtaW5za3kgQmxhY2sgT3BzIG9mIEROUyBUb29yY29uIDIwMDQsIGh0dHA6Ly93d3cuZG94cGFyYS5jb20vZG5zX3RjL0JsYWNrX09wc19ETlNfVENfZmlsZXMvdjNfZG9jdW1lbnQuaHRtIAogIDIwMDQKClJveQoKCihwYXBlcikKaHR0cDovL3d3dy5kZm4tY2VydC5kZS92ZXJhbnN0YWx0dW5nZW4vd29ya3Nob3Avdm9ydHJhZ2UtdmVyZ2FuZ2VuZXItd29ya3Nob3BzLzEyLi13b3Jrc2hvcC0yMDA1L2RmbFrom [email-masked]  Fri Sep 12 01:31:59 2008Return-Path: <[email-masked]>X-Original-To: [email-masked]: [email-masked]: from [127.0.0.1] (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id 1029D3A6BEF;	Fri, 12 Sep 2008 01:31:59 -0700 (PDT)X-Original-To: [email-masked]: [email-masked]: from localhost (localhost [127.0.0.1])	by core3.amsl.com (Postfix) with ESMTP id F406F3A6BEF	for <[email-masked]>; Fri, 12 Sep 2008 01:31:57 -0700 (PDT)X-Virus-Scanned: amavisd-new at amsl.comX-Spam-Flag: NOX-Spam-Score: -0.949X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, 	BAYES_00=-2.599, HELO_EQ_SE=0.35]Received: from mail.ietf.org ([64.170.98.32])	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id osWbZlU9z9hr for <[email-masked]>;	Fri, 12 Sep 2008 01:31:56 -0700 (PDT)Received: from mail.schlyter.se (trinitario.schlyter.se [195.47.254.10])	by core3.amsl.com (Postfix) with ESMTP id 373743A6B7C	for <[email-masked]>; Fri, 12 Sep 2008 01:31:55 -0700 (PDT)Received: from [127.0.0.1] (core.dnss.ec [82.94.105.50])	(using TLSv1 with cipher AES128-SHA (128/128 bits))	(No client certificate requested) (Authenticated sender: roy)	by mail.schlyter.se (Postfix) with ESMTPSA id 35DA52D498;	Fri, 12 Sep 2008 10:32:00 +0200 (MEST)Message-Id: <[email-masked]>From: Roy Arends <[email-masked]>To: Ron Bonica <[email-masked]>In-Reply-To: <[email-masked]>Mime-Version: 1.0 (Apple Message framework v928.1)Date: Fri, 12 Sep 2008 10:31:59 +0200References: <[email-masked]>	<[email-masked]>X-Mailer: Apple Mail (2.928.1)Cc: [email-masked]: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txtX-BeenThere: [email-masked]: 2.1.9Precedence: listList-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,	<mailto:[email-masked]?subject=unsubscribe>List-Archive: <http://www.ietf.org/pipermail/dnsop>List-Post: <mailto:[email-masked]>List-Help: <mailto:[email-masked]?subject=help>List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,	<mailto:[email-masked]?subject=subscribe>Content-Type: text/plain; charset="utf-8"Content-Transfer-Encoding: base64Sender: [email-masked]: [email-masked]OgoKPiBGb2xrcywKPgo+IEJhc2VkIG9uIHRoZSByZXNwb25zZSB0aGF0IHdlIGhhdmUgc2VlbiBmcm9tIHRoZSBXRyBzbyBmYXIsIEkgZG9uJ3QgIAo+IHNlZQo+IGFueSByZWFzb24gdG8gYW1lbmQgdGhlIGRyYWZ0LiBCQ1AgMzggaXMgYWxyZWFkeSBwdWJsaXNoZWQuCgpJbiBkZWZlbnNlIG9mIHB1Ymxpc2hpbmcgZHJhZnQtaWV0Zi1kbnNvcC1yZWZsZWN0b3JzLWFyZS1ldmlsIEknZCBsaWtlICAKdG8gcHV0IGZvcndhcmQgdGhlIGZvbGxvd2luZyBhcnRpY2xlIHRoYXQgd2FzIHBhcnQgb2YgYSBwYXBlciBJIGNvLSAKYXV0aG9yZWQgaW4gMjAwNS4gSSBkbyB0aGlzIHRvIHNob3cgdGhhdCB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBkcmFmdCAgCmlzIGxvbmcgb3ZlcmR1ZSwgYW5kIHRoYXQgSSByYXRoZXIgaGF2ZSBpdCBwdWJsaXNoZWQgc29vbmVyIHRoYW4gIApsYXRlci4gRnVydGhlcm1vcmUsIHRvIGRlZmVuZCBhZ2FpbnN0IGFidXNlIHRoYXQgaW5jbHVkZXMgb3Blbi0gCnJlc29sdmVycyBJIHdvdWxkIHdlbGNvbWUgYW4gUkZDIGFzIHNvb24gYXMgcG9zc2libGUsIHRvIGhhdmUgYSAgCmJvaWxlcnBsYXRlIHRoYXQgSSBjYW4gc2hvdyBmb2xrcywgd2hvIHVua25vd2luZ2x5IHJ1biBvcGVuIHJlc29sdmVycywgIApidXQgbmVlZCBhIHBvaW50ZXIgdG8gZGVmZW5kIHRoZSBjb3N0IG9mIGNvbmZpZ3VyYXRpb24gY2hhbmdlIHRvIHRoZWlyICAKbWFuYWdlbWVudC4KClRoZSBhcnRpY2xlOgoKQWJvdXQgT3BlbiBSZWxheXMgYW5kIE9wZW4gUmVzb2x2ZXJzCgpJbiB0aGUgZWFybHkgZGF5cyBvZiB0aGUgSW50ZXJuZXQgaXQgd2FzIGNvbW1vbiB0byBvZmZlciBzZXJ2aWNlcyB0byAgCmV2ZXJ5b25lLCBlaXRoZXIgaW50ZW50aW9uYWxseSBvciBhcyBhIHNpZGUgZWZmZWN0LiAgVGhlIHJpc2Ugb2Ygc3BhbSAgCnRhdWdodCB1cyB0aGF0IHRoaXMgYXBwcm9hY2ggd2FzIG5vdCB3ZWxsIHN1aXRlZCBmb3IgdGhlIHJlYWwgd29ybGQsICAKc28gb3ZlciB0aW1lIG1vc3Qgb3BlbiByZWxheXMgd2VyZSBjbG9zZWQuICBTcGFtIGRpZCBub3QgY2Vhc2UgYnV0ICAKanVzdCBvbmUgYWJ1c2UgbWVjaGFuamNlcnQtd3MyMDA1LWY3cGFwZXIucGRmCgooc2xpZGVzKQpodHRwOi8vd3d3LmRmbi1jZXJ0LmRlL3ZlcmFuc3RhbHR1bmdlbi93b3Jrc2hvcC92b3J0cmFnZS12ZXJnYW5nZW5lci13b3Jrc2hvcHMvMTIuLXdvcmtzaG9wLTIwMDUvZGZuY2VydC13czIwMDUtZjcucGRmCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFpbGluZyBsaXN0CkROU09QQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zb3AKXNtIGRpc2FwcGVhcmVkLiAgSW4gdGhlIEROUyB0aGVyZSBpcyBhIHNlcnZpY2UgIApzaW1pbGFyIHRvIG9wZW4gcmVsYXlzOiByZXNvbHZlcnMgb2ZmZXJpbmcgcmVjdXJzaXZlIHNlcnZpY2UgdG8gIAphbnlvbmUuICBXaGlsZSBsYXJnZSBJU1BzIG9yIG9yZ2FuaXNhdGlvbnMgbmVlZCBvbmUgb3IgbW9yZSByZWN1cnNpdmUgIApuYW1lIHNlcnZlcnMgKHJlc29sdmVycykgdG8gc2VydmUgdGhlaXIgb3duIGNsaWVudHMsIHRoZXJlIGlzIG5vIG5lZWQgIAp0byBzZXJ2ZSB0aGUgd29ybGQuICBFdmVuIHdvcnNlLCBkdWUgdG8gdGhlIGV4aXN0ZW5jZSBvZiBjYWNoZSAgCnBvaXNvbmluZywgdGhpcyBraW5kIG9mIG11bmlmaWNlbmNlIG1heSBleHBvc2UgdGhlIHN5c3RlbSB0byBjZXJ0YWluICAKYXR0YWNrcy4gIFdoaWxlIHRoaXMgaGFzIGJlZW4ga25vd24gZm9yIHF1aXRlIHNvbWUgdGltZSwgd2Ugd2lsbCBzaG93ICAKaG93IHRoaXJkIHBhcnRpZXMgY2FuIGNvbW11bmljYXRlIHRocm91Z2ggb3BlbiByZXNvbHZlcnMsIHVzaW5nICAKbm90aGluZyBlbHNlIGJ1dCBETlMgcHJvdG9jb2wgY29uZm9ybWFudCBwYWNrZXRzLgoKQ2FjaGUgcG9pc29uaW5nIGlzIGRvbmUgaW4gc2V2ZXJhbCB3YXlzLCBlYWNoIHBhcnQgb2YgYSBkaWZmZXJlbnQgIApjbGFzcyBvZiBhdHRhY2tzLiAgVGhlcmUgaXMgdGhlIGludHJ1c2l2ZSBhdHRhY2ssIHdoZXJlIGEgcGljYXJvIGNhbiAgCnNpdCBvbiB0aGUgd2lyZSBhbmQgYWx0ZXJzIGhvc3QgYWRkcmVzc2VzIGluIHJlc3BvbnNlIHBhY2tldHMsIHdoaWNoICAKd2lsbCBzdWJzZXF1ZW50bHkgYmUgY2FjaGVkIGZvciBhIGNlcnRhaW4gdGltZSBieSBhIHJlc29sdmVyLiAgQW5vdGhlciAgCmNsYXNzIGlzIHRoZSB0cmlhbCBhbmQgZXJyb3IgYXR0YWNrLCB3aGVyZSBhIHJlc29sdmVyIGlzIGhvc2VkIHdpdGggYSAgCmJ1bGsgb2YgaWRlbnRpY2FsIHJlc3BvbnNlcywgd2hpbGUgdGhlIGlkZW50ae+sgWVycyBhcmUgZGlmZmVyZW50LiAgVG8gIAppbmNyZWFzZSB0aGUgc3VjY2VzcyBvZiBzdWNoIGFuIGF0dGFjaywgdGhlIGV4cGlyeSB0aW1lIG9mIHRoZSBjdXJyZW50ICAKY2FjaGVkIGRhdGEgZm9yIGEgY2hvc2VuIGNhbmRpZGF0ZSBjYW4gZWFzaWx5IGJlIG1lYXN1cmVkLiAgQW4gb3BlbiAgCnJlc29sdmVyIHdpbGwgcHJvbXB0bHkgcmVzcG9uZCB0byBwcm9iZXMgZm9yIHRoZSBleHBpcnkgdGltZSBvZiB0aGUgIApjdXJyZW50IGNhY2hlZCBkYXRhLgoKQW5vdGhlciB0eXBlIG9mIGF0dGFjayBpcyBhIHNpbXBsZSBEZW5pYWwgb2YgU2VydmljZSBhdHRhY2sgYWdhaW5zdCBhICAKcmVzb2x2ZXIuICBUaGUgQklORCA4IG5hbWVzZXJ2ZXIgZG9lcyBub3QgaW1wbGVtZW50IGEgbWVtb3J5LXVzYWdlICAKbWF4aW11bS4gIEl0IGlzIHRyaXZpYWwgdG8gYnVyc3QgYSBzZXQgb2YgcXVhbGnvrIFlZCBxdWVyaWVzIHRvIGEgIApyZXNvbHZlciwgd2hlcmUgdGhlIHJlc3BvbnNlcyB3aWxsIGNvbnRhaW4gcmVjb3JkcyB3aXRoIGhpZ2ggVFRMICAKdmFsdWVzLCBpbiBvcmRlciB0byBpbmNyZWFzZSB0aGUgbWVtb3J5IGZvb3RwcmludCBvZiBhIGNhY2hlLiAgT25jZSAgCnRoZSBzaXplIHdpbGwgbmVhciBwaHlzaWNhbCBsaW1pdGF0aW9ucyBvZiBzb21lIGZvcm0sIHRoZSBzZXJ2ZXIgd2lsbCAgCnN0YWxsIG9yIHdvcnNlLCBzdG9wIHByb2Nlc3NpbmcgcXVlcmllcy4KClVzaW5nIG9wZW4gcmVzb2x2ZXJzIGFzIGEgRG9TIGFtcGxp76yBZXIgaXMgYW5vdGhlciBhdHRhY2sgdmVjdG9yLiAgSXQgIAppcyB0cml2aWFsIHRvIHNlbmQgYSBzaW5nbGUgcXVlcnkgdG8gYSByZXNvbHZlci4gIEl0IGlzIHRyaXZpYWwgdG8gIApzZW5kIGEgYnVsayBvZiBpZGVudGljYWwgcXVlcmllcyB0byBhIGJ1bGsgb2Ygb3BlbiByZXNvbHZlcnMuICAgIApBY3F1aXJpbmcgYSBzZXQgb2YgSVAgYWRkcmVzc2VzIHdoaWNoIGhvc3Qgb3BlbiByZXNvbHZlcnMgaXMgdHJpdmlhbCAgCmFzIHdlbGwuICBTaW5jZSBETlMgaXMgVURQIGJhc2VkLCBhIHNjYW4gb2YgYSBzaW5nbGUgLzE2ICjigJljbGFzcyAgCkLigJkpIG5ldHdvcmsgdGFrZXMgb25seSBtaW51dGVzLiAgVXNpbmcgYSBsYXJnZSBlbm91Z2ggYnVsayBvZiAgCnJlc29sdmVycyB0byBxdWVyeSByb290IG9yIFRMRCBzZXJ2ZXJzIGZvciBhIHNpbmdsZSBuYW1lIGNhbiBjYXVzZSB0aGUgIApyZXNwZWN0aXZlIGRvbWFpbiB0byBleHBlcmllbmNlIGEgc2lnbmnvrIFjYW50IHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLgoKQSBuZXcgc2V0IG9mIGFidXNpdmVuZXNzIGlzIGN1cnJlbnRseSBiZWluZyBkZXZlbG9wZWQgdGhhdCBpbnZvbHZlcyAgCnVzaW5nIGEgYnVsayBvZiBvcGVuIHJlc29sdmVycyBhbmQgdGhlaXIgY2FjaGUgYXMgYSB3YXkgdG8gc3RvcmUgYW5kICAKdHJhbnNmZXIgZGF0YSwgZGlzZ3Vpc2VkIGFzIEROUyBkYXRhLiAgVGhlIGRhdGEgY2FuIHRha2UgYW55IGZvcm0sICAKZnJvbSBzdHJlYW1pbmcgbWVkaWEgdG8gYml0LXRvcnJlbnQgc2VlZHMgW0thbWkwNF0uCgpOb3RlIHRoYXQgdGhlc2Ugb3BlbiByZXNvbHZlcnMgZG8gbm90IGhhdmUgdG8gYmUgcmVjcnVpdGVkIHRvIGJlICAKdmljdGltaXNlZC4gIFRoZXkgYXJlIHRoZXJlIGZvciB0aGUgdGFraW5nLCB0aGV5IHNpbXBseSBuZWVkIHRvIGJlICAKZm91bmQuICBBbGwgdGhpcyBjYW4gYmUgZG9uZSB3aXRoaW4gdGhlIGJvdW5kYXJpZXMgb2YgdGhlCkROUy1wcm90b2NvbC4gIFRoZSBwYWNrZXRzIG9uIHRoZSB3aXJlIGFyZSBzb2xlbHkgRE5TIG1lc3NhZ2VzLgoKW0thbWkwNF0gRC4gS2FtaW5za3kgQmxhY2sgT3BzIG9mIEROUyBUb29yY29uIDIwMDQsIGh0dHA6Ly93d3cuZG94cGFyYS5jb20vZG5zX3RjL0JsYWNrX09wc19ETlNfVENfZmlsZXMvdjNfZG9jdW1lbnQuaHRtIAogIDIwMDQKClJveQoKCihwYXBlcikKaHR0cDovL3d3dy5kZm4tY2VydC5kZS92ZXJhbnN0YWx0dW5nZW4vd29ya3Nob3Avdm9ydHJhZ2UtdmVyZ2FuZ2VuZXItd29ya3Nob3BzLzEyLi13b3Jrc2hvcC0yMDA1L2RmbmNlcnQtd3MyMDA1LWY3cGFwZXIucGRmCgooc2xpZGVzKQpodHRwOi8vd3d3LmRmbi1jZXJ0LmRlL3ZlcmFuc3RhbHR1bmdlbi93b3Jrc2hvcC92b3J0cmFnZS12ZXJnYW5nZW5lci13b3Jrc2hvcHMvMTIuLXdvcmtzaG9wLTIwMDUvZGZuY2VydC13czIwMDUtZjcucGRmCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFpbGluZyBsaXN0CkROU09QQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zb3AK

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Sep 2008 13:44:40 -0400 (EDT)

On Fri, 12 Sep 2008, Roy Arends wrote:

> On Sep 10, 2008, at 9:17 PM, Ron Bonica wrote:

> In defense of publishing draft-ietf-dnsop-reflectors-are-evil I'd like  
> to put forward the following article that was part of a paper I co- 
> authored in 2005. I do this to show that the publication of this draft  
> is long overdue, and that I rather have it published sooner than  
> later. Furthermore, to defend against abuse that includes open- 
> resolvers I would welcome an RFC as soon as possible, to have a  
> boilerplate that I can show folks, who unknowingly run open resolvers,  
> but need a pointer to defend the cost of configuration change to their  
> management.
> 
> The article:
> 
> About Open Relays and Open Resolvers
> 
> In the early days of the Internet it was common to offer services to  
> everyone, either intentionally or as a side effect.  The rise of spam  
> taught us that this approach was not well suited for the real world,  
> so over time most open relays were closed.  

The assertion that most open relays were closed is false. In 2003, just
before most of the open relay blacklists closed, it was reported to the
FTC that there were 400,000 open relays and that the number continued to
rise.  I am aware of no reports on numbers of open relays after 2003.  
I was an early advocate of open relays because they had legitimate uses
for traveling consultants and because the arguments against them had no
substance. AV8 is still an open relay operator today. There are some
aspects in common with open relays and open recursors:

	In both cases, there are legitimate uses for open relays and
open recursors.  Open relays are useful for people who use outside IP
addresses but need common processing (eg logs or copies of email sent)  
or just don't trust the email servers provided for the outside IP
addresses.  Open recursors also have legitimate uses from outside IP
addresses that were emphasized with the cache poisoning attacks.

	In both cases, there was no non-mitigatable harm. Open relay 
abuse was detected and stopped by open relay operators.  Open recursors 
are run by businesses and ISPs that detect and mitigate abuse.

	In both cases, advocates of closing them solicited abuse of
them, and did this for their own profit.  For example, In two open relay
cases, I tracked open relay abuse to Osirusoft and ORBS by setting up
non-production servers, logging (via cisco acls) activity, and
submitting them one at a time for scanning. ORBS was subsequently found
in court, 3 times, of using false statements about open relays for its
profit, and was forced out of business to pay for damages. John Levine,
Paul Vixie, with NANOG senior members misled operators about the laws
that apply to ISPs. See
http://www.av8.net/IETF-watch/People/JohnLevine/index.html
http://www.av8.net/IETF-watch/People/StevenBellovin/index.html

In the case of open recursors, the opponents of open recursors are
advocates of DNSSEC software, and closing open recursors will mean that
more closed recursors will be needed, creating sales opportunities for
their software.  Closing open recursors makes the cache poisoning
problem worse, and offer to sell a solution for cache poisoning.

In the case of open relays, opponents supported assertions to NANOG
members that it was OK to abuse open relays and that the Computer Fraud
and Abuse Act didn't apply to ISPs. I was silenced on NANOG in 2000
before I could gloat about proof that these laws do apply after the FBI
arrested foreign hackers who stole credit cards. See
http://www.iadl.org/nanog/nanog-story.html
http://www.iadl.org/ks/kai-schlicting-story.html
http://www.iadl.org/cn/cn-story.html

In fact, open relays did not offer any of the harms that opponents
claimed. The claims of harm were deceptive.  See
http://www.av8.net/FTC.pdf The claims of harm were also intentionally
misleading. I added the fact that open relays were not anonymous, and
explained the header issue to the wikipedia page on open relays, and
this information was deleted, and replaced with innuendo implying that
open relays enable anonymous email. Deleting these facts are intentional
deceptions.  See also
http://www.iadl.org/JATerranson/JATerranson-story.html for an account of
false claims of open relay harms.

> Spam did not cease but just one abuse mechanism disappeared.  

The above is a false assertion. Genuine bulk emailers had no interest in
open relays. After Sanford Wallace's fixed IP address was blocked by
MAPS in 1997, Wallace tried to abuse open relays, and discovered that
open relays don't offer anonymity.  In fall of 1997, most bulk emailers
including Wallace turned to disposable dialups, and thereafter didn't
abuse open relays. The Vixie/Levine/Joffe bulk email company,
Whitehat.com was apparently kept off of spam-traps by inside information
and to my knowledge, Whitehat didn't ever use disposable dialups to
circumvent blacklists.  Vixie was a cofounder of MAPS; John Levine is
chair of the IRTF Anti-spam Research Group; Rodney Joffe is founder of
UltraDNS, Centergate Research, Whitehat. Bill Manning is Chief
Scientist; Vixie was board member on Nominum, David Conrad was CTO at
Nominum.  (See http://www.iadl.org/maps/maps-story.html,
http://www.av8.net/IETF-watch/People/JohnLevine/index.html) Open relays
offered no advantage to genuine commercial bulk emailers.  This is shown
most evidently in the abuse by Sanford Wallace in 1997.  Wallace was
detected and stopped. Protecting an open relay from abuse is no
different than protecting a closed relay from abuse, and one doesn't
need to close the open relay to add such protection.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Sep 2008 13:44:40 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Sep 2008 14:08:37 -0400 (EDT)

> Were it universally deployed, yes. Will it be? No. Thus, no. 

What do you want to spend your time doing: Getting people to implement
BCP38 or getting people to close open recursors?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Sep 2008 14:08:37 -0400 (EDT)

--Dean

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 12 Sep 2008 22:44:47 +0200

> BCP38 or getting people to close open recursors?

I _want_ to spend time with my family, and now and then have a beer
with my friends.

With the Internet being a network of networks, it will by virtue of
this fact be heterogenously built, maintained and configured. 

BCP38 is in place. It is a good cluebat, but won't  bite on all people.

For those situations where BCP38 is operationally (for some persons
definition of) impossible to deploy, or for when the cluebat does not
work, we need a cluestick. Perhaps, just perhaps, it will hurt enough.
Differently enough that we get to close another attack vector. (because
these attacks do happen. Surprise! ) 

I see a RFC about the disadvantages of running open recursors as this
clue stick. There is no need to oppose BCP38 with a !recurse RFC; they
will complement each other just nicely. Simply because the Internet is
a patchwork of different ways to run networks.

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 12 Sep 2008 22:44:47 +0200

---

From: Peter Koch <[email-masked]>
Date: Sat, 13 Sep 2008 10:46:53 +0200

Ron,

> If the answer to both of these questions is "no", the document can go

and in an earlier message

> consensus and I will take appropriate action.

Amongst those individuals who responded directly to the questions, there was
consensus that wide deployment of BCP38 would be sufficient but at the same time
that this state has not been reached today and is unlikely to be reached in
the forseeable future. This is consistent with the spirit of the draft under
consideration w.r.t. its relation to BCP38.
The WG's answer to the first question is "no".

There is also consensus that taking action after an attack has started is
not a sufficient defense mechanism and proactive measures are needed.
The WG's answer to the second question is "no".

Several other people have expressed their support for publishing the draft
"as is", nobody expressed opposition.

It is noted that Mr Anderson maintained his dissenting view.

I therefore declare WG consensus on the publication of
draft-ietf-dnsop-reflectors-are-evil-06.txt "as is"(*).

-Peter Koch [wg co-chair and document shepherd]

(*) Please see the the I-D tracker for an RFC Editor's note which adds
    three reFrom [email-masked]  Sat Sep 13 01:48:32 2008
Date: Sat, 13 Sep 2008 10:46:53 +0200
From: Peter Koch <[email-masked]>
To: Ron Bonica <[email-masked]>
Cc: Dan Romascanu <[email-masked]>, IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Sender: [email-masked]

Ron,

> If the answer to both of these questions is "no", the document can go

and in an earlier message

> consensus and I will take appropriate action.

Amongst those individuals who responded directly to the questions, there was
consensus that wide deployment of BCP38 would be sufficient but at the same time
that this state has not been reached today and is unlikely to be reached in
the forseeable future. This is consistent with the spirit of the draft under
consideration w.r.t. its relation to BCP38.
The WG's answer to the first question is "no".

There is also consensus that taking action after an attack has started is
not a sufficient defense mechanism and proactive measures are needed.
The WG's answer to the second question is "no".

Several other people have expressed their support for publishing the draft
"as is", nobody expressed opposition.

It is noted that Mr Anderson maintained his dissenting view.

I therefore declare WG consensus on the publication of
draft-ietf-dnsop-reflectors-are-evil-06.txt "as is"(*).

-Peter Koch [wg co-chair and document shepherd]

(*) Please see the the I-D tracker for an RFC Editor's note which adds
    three references.
    <https://datatracker.ietf.org/idtracker/ballot/2581/>
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

ferences.
    <https://datatracker.ietf.org/idtracker/ballot/2581/>
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop