On 10 March 2014 14:59, Sanjeev Gupta <[email protected]> wrote: > > On Thu, Mar 6, 2014 at 5:41 PM, Matsuzaki Yoshinobu <[email protected]> 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 > > -- > Sanjeev Gupta > +65 98551208 http://sg.linkedin.com/in/ghane > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > [email protected] > http://mailman.apnic.net/mailman/listinfo/sig-policy > >
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
