On 10 March 2014 14:59, Sanjeev Gupta <sanjeev@dcs1.biz> wrote:

On Thu, Mar 6, 2014 at 5:41 PM, Matsuzaki Yoshinobu <maz@iij.ad.jp> wrote:
OK, here is an example.  The following report is published by the
cert.br, and regarding their analysis, attackers were serving cache
DNS for 4.5 milion users just to steal bank accounts from the users.

 *1) Phishing and Banking Trojan Cases Affecting Brazil, From P.17
 - http://www.cert.br/docs/palestras/certbr-firstsymposium2012.pdf

Attackers are patient, know your network, compromise your equipments,
and can use them for evil purposes.  We should not create a new
security risk.

Matsuzaki-san,

I read the link you forwarded.  Thank you.

I am sorry to see how this would be anyway affected by my announcing 1.2.3.0/24 on my ISP network.  The attack you cite changed the DNS resolver addresses on CPE.  If they had changed it to 1.2.3.4 , not only would it have been to a resolver I supply to my clients (and no one else), but since 1.2.3.0/24 would be filtered by me upstream, there is no way that 1.2.3.4 queries would go to them.  This seems to strengthen Dean and Geoff's proposal.

If I misunderstanding this, I would appreciate correction from the list.  Could someone give me a use case where I could make life worse, using this, for InternetNZ's customers?

Prop110 stated this prefix to be managed as a common anycast address for locally scoped infrastructure
support for DNS resolvers. Service providers, or software developers,  or CPE makers has no obligation
to support special control over 1.2.3.0/24 traffic as it was not mandated by engineering community (e.g. IETF).
Allocating address blocks for specific protocol/application is not the job of RIR address policy.

One scenario can be : ISPs without 1.2.3.0/24 control, receiving anycast announced by various sources
to redirect 1.2.3.0/24 traffic. This scenario causes additional concern in name resolution.

Kenny Huang

 

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy