Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
Dear colleagues
Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did not reach consensus at the APNIC 37 Member Meeting.
Therefore, this proposal is being returned to the authors and the Policy SIG mailing list for further consideration.
Proposal details ----------------
The objective of this proposal is to permit the use 1.2.3.0/24 as anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers.
Proposal details including the full text of the proposal, history, and links to mailing list discussions are available at:
http://www.apnic.net/policy/proposals/prop-110
Regards
Masato
------------------------------------------------------------------------ prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure ------------------------------------------------------------------------
Proposers: Dean Pemberton, dean@internetnz.net.nz Geoff Huston, gih@apnic.net
1. Problem statement --------------------
Network 1 (1.0.0.0/8) was allocated to APNIC by the IANA on 19 January 2010. In line with standard practice APNIC's Resource Quality Assurance activities determined that 95% of the address space would be suitable for delegation as it was found to be relatively free of unwanted traffic [1].
Testing, conducted by APNIC R&D found that certain blocks within Network 1 attract significant amounts of unwanted traffic, primarily due to its unauthorised use as private address space [2].
Analysis revealed that, prior to any delegations being made from the block, 1.0.0.0/8 attracted an average of 140Mbps - 160Mbps of unsolicited incoming traffic as a continuous sustained traffic level, with peak bursts of over 800Mbps.
The analysis highlighted individual addresses such as 1.2.3.4 with its covering /24 (identified as 1.2.3.0/24) remain in APNIC quarantine and it is believed they will not be suitable for normal address distribution.
The proposal proposes the use of 1.2.3.0/24 in a context of locally scoped infrastructure support for DNS resolvers.
2. Objective of policy change -----------------------------
As the addresses attract extremely high levels of unsolicited incoming traffic, the block has been withheld from allocation and periodically checked to determine if the incoming traffic profile has altered. None has been observed to date. After four years, it now seems unlikely there will ever be any change in the incoming traffic profile.
The objective of this proposal is to permit the use 1.2.3.0/24 as a anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers. It is noted that as long as providers who use this address use basic route scope limitations, the side effect of large volumes of unsolicited incoming traffic would be, to some extent mitigated down to manageable levels.
3. Situation in other regions -----------------------------
Improper use of this address space is a globally common issue. However the block is delegated only APNIC and so therefor, no other RIR has equivalent policy to deal with the situation.
4. Proposed policy solution ---------------------------
This proposal recommends that the APNIC community agree to assign 1.2.3.0/24 to the APNIC Secretariat for use in the context of locally scoped infrastructure support for DNS resolvers.
At some future point there is nothing restricting an RFC being written to include this prefix into the special-purpose IPv4 registry. However, at this time it is considered sufficient for the APNIC community to designate this prefix to be managed as a common anycast address for locally scoped infrastructure support for DNS resolvers.
5. Advantages / Disadvantages -----------------------------
Advantages
- It will make use of this otherwise unusable address space. - DNS operators will have an easy-to-remember address they can use to communicate with their users (e.g. configure "1.2.3.4" as your DNS resolver")
Disadvantages
- The address attracts a large volume of unsolicited incoming traffic, and leakage of an anycast advertisement outside of a limited local scope may impact on the integrity of the DNS service located at the point associated with the scope leakage. Some operators with high capacity infrastructure may see this as a negligible issue.
6. Impact on APNIC ------------------
Although this space will no longer be available for use by a single APNIC/NIR account holder, the proposal would result in benefit for all APNIC community members, as well as the communities in other regions.
References ----------
[1] Resource Quality Good for Most of IPv4 Network "1" http://www.apnic.net/publications/press/releases/2010/network-1.pdf
[2] Traffic in Network 1.0.0.0/8 http://www.potaroo.net/ispcol/2010-03/net1.html
Geoff and Dean,
As next step, can you share your thought as the authors whether continue the discussion or withdraw this proposal?
Rgs, Masato
2014-03-03 5:27 GMT-08:00 Masato Yamanishi myamanis@japan-telecom.com:
Dear colleagues
Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did not reach consensus at the APNIC 37 Member Meeting.
Therefore, this proposal is being returned to the authors and the Policy SIG mailing list for further consideration.
Proposal details
The objective of this proposal is to permit the use 1.2.3.0/24 as anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers.
Proposal details including the full text of the proposal, history, and links to mailing list discussions are available at:
http://www.apnic.net/policy/proposals/prop-110Regards
Masato
prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Proposers: Dean Pemberton, dean@internetnz.net.nz Geoff Huston, gih@apnic.net
- Problem statement
Network 1 (1.0.0.0/8) was allocated to APNIC by the IANA on 19 January 2010. In line with standard practice APNIC's Resource Quality Assurance activities determined that 95% of the address space would be suitable for delegation as it was found to be relatively free of unwanted traffic [1].
Testing, conducted by APNIC R&D found that certain blocks within Network 1 attract significant amounts of unwanted traffic, primarily due to its unauthorised use as private address space [2].
Analysis revealed that, prior to any delegations being made from the block, 1.0.0.0/8 attracted an average of 140Mbps - 160Mbps of unsolicited incoming traffic as a continuous sustained traffic level, with peak bursts of over 800Mbps.
The analysis highlighted individual addresses such as 1.2.3.4 with its covering /24 (identified as 1.2.3.0/24) remain in APNIC quarantine and it is believed they will not be suitable for normal address distribution.
The proposal proposes the use of 1.2.3.0/24 in a context of locally scoped infrastructure support for DNS resolvers.
- Objective of policy change
As the addresses attract extremely high levels of unsolicited incoming traffic, the block has been withheld from allocation and periodically checked to determine if the incoming traffic profile has altered. None has been observed to date. After four years, it now seems unlikely there will ever be any change in the incoming traffic profile.
The objective of this proposal is to permit the use 1.2.3.0/24 as a anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers. It is noted that as long as providers who use this address use basic route scope limitations, the side effect of large volumes of unsolicited incoming traffic would be, to some extent mitigated down to manageable levels.
- Situation in other regions
Improper use of this address space is a globally common issue. However the block is delegated only APNIC and so therefor, no other RIR has equivalent policy to deal with the situation.
- Proposed policy solution
This proposal recommends that the APNIC community agree to assign 1.2.3.0/24 to the APNIC Secretariat for use in the context of locally scoped infrastructure support for DNS resolvers.
At some future point there is nothing restricting an RFC being written to include this prefix into the special-purpose IPv4 registry. However, at this time it is considered sufficient for the APNIC community to designate this prefix to be managed as a common anycast address for locally scoped infrastructure support for DNS resolvers.
- Advantages / Disadvantages
Advantages
- It will make use of this otherwise unusable address space.
- DNS operators will have an easy-to-remember address they can use to communicate with their users (e.g. configure "1.2.3.4" as your DNS resolver")
Disadvantages
- The address attracts a large volume of unsolicited incoming traffic, and leakage of an anycast advertisement outside of a limited local scope may impact on the integrity of the DNS service located at the point associated with the scope leakage. Some operators with high capacity infrastructure may see this as a negligible issue.
- Impact on APNIC
Although this space will no longer be available for use by a single APNIC/NIR account holder, the proposal would result in benefit for all APNIC community members, as well as the communities in other regions.
References
[1] Resource Quality Good for Most of IPv4 Network "1" http://www.apnic.net/publications/press/releases/2010/network-1.pdf
[2] Traffic in Network 1.0.0.0/8 http://www.potaroo.net/ispcol/2010-03/net1.html
wlan0 Link encap:Ethernet HWaddr 84:3a:4b:0b:e1:30 inet addr:100.64.210.21 Bcast:100.64.223.255 Mask:255.255.240.0 inet6 addr: fe80::863a:4bff:fe0b:e130/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4141929 errors:0 dropped:0 overruns:0 frame:0 TX packets:2440540 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5017566130 (5.0 GB) TX bytes:500882587 (500.8 MB)
coffee shop near reston virginia
After consideration of all the factors highlighted on the mailing list and in person at both the OPM and AMM, the authors do not wish to proceed with this proposal.
Regards, Dean
On Tuesday, March 4, 2014, Masato Yamanishi myamanis@japan-telecom.com wrote:
Geoff and Dean,
As next step, can you share your thought as the authors whether continue the discussion or withdraw this proposal?
Rgs, Masato
2014-03-03 5:27 GMT-08:00 Masato Yamanishi <myamanis@japan-telecom.comjavascript:_e(%7B%7D,'cvml','myamanis@japan-telecom.com');
:
Dear colleagues
Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did not reach consensus at the APNIC 37 Member Meeting.
Therefore, this proposal is being returned to the authors and the Policy SIG mailing list for further consideration.
Proposal details
The objective of this proposal is to permit the use 1.2.3.0/24 as anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers.
Proposal details including the full text of the proposal, history, and links to mailing list discussions are available at:
http://www.apnic.net/policy/proposals/prop-110Regards
Masato
prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Proposers: Dean Pemberton, dean@internetnz.net.nz Geoff Huston, gih@apnic.net
- Problem statement
Network 1 (1.0.0.0/8) was allocated to APNIC by the IANA on 19 January 2010. In line with standard practice APNIC's Resource Quality Assurance activities determined that 95% of the address space would be suitable for delegation as it was found to be relatively free of unwanted traffic [1].
Testing, conducted by APNIC R&D found that certain blocks within Network 1 attract significant amounts of unwanted traffic, primarily due to its unauthorised use as private address space [2].
Analysis revealed that, prior to any delegations being made from the block, 1.0.0.0/8 attracted an average of 140Mbps - 160Mbps of unsolicited incoming traffic as a continuous sustained traffic level, with peak bursts of over 800Mbps.
The analysis highlighted individual addresses such as 1.2.3.4 with its covering /24 (identified as 1.2.3.0/24) remain in APNIC quarantine and it is believed they will not be suitable for normal address distribution.
The proposal proposes the use of 1.2.3.0/24 in a context of locally scoped infrastructure support for DNS resolvers.
- Objective of policy change
As the addresses attract extremely high levels of unsolicited incoming traffic, the block has been withheld from allocation and periodically checked to determine if the incoming traffic profile has altered. None has been observed to date. After four years, it now seems unlikely there will ever be any change in the incoming traffic profile.
The objective of this proposal is to permit the use 1.2.3.0/24 as a anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers. It is
-- Masato Yamanishi SVP, Network Engineering Japan Telecom America Tel: +1-213-623-0797 ext.106
Thx, Dean.
Is there anyone who want to continue this proposal?
Rgs, Masato
On 14/03/03 9:59, "Dean Pemberton" dean@internetnz.net.nz wrote:
After consideration of all the factors highlighted on the mailing list and in person at both the OPM and AMM, the authors do not wish to proceed with this proposal.
Regards, Dean
On Tuesday, March 4, 2014, Masato Yamanishi myamanis@japan-telecom.com wrote:
Geoff and Dean,
As next step, can you share your thought as the authors whether continue the discussion or withdraw this proposal?
Rgs, Masato
2014-03-03 5:27 GMT-08:00 Masato Yamanishi <myamanis@japan-telecom.com javascript:_e(%7B%7D,'cvml','myamanis@japan-telecom.com'); >:
Dear colleagues
Version 2 of prop-110: Designate 1.2.3.0/24 http://1.2.3.0/24 as Anycast to support DNS Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did not reach consensus at the APNIC 37 Member Meeting.
Therefore, this proposal is being returned to the authors and the Policy SIG mailing list for further consideration.
Proposal details
The objective of this proposal is to permit the use 1.2.3.0/24 http://1.2.3.0/24 as anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers.
Proposal details including the full text of the proposal, history, and links to mailing list discussions are available at:
http://www.apnic.net/policy/proposals/prop-110http://www.apnic.net/policy/proposals/prop-110
Regards
Masato
prop-110v002: Designate 1.2.3.0/24 http://1.2.3.0/24 as Anycast to support DNS Infrastructure
Proposers: Dean Pemberton, dean@internetnz.net.nz Geoff Huston, gih@apnic.net
- Problem statement
Network 1 (1.0.0.0/8 http://1.0.0.0/8 ) was allocated to APNIC by the IANA on 19 January 2010. In line with standard practice APNIC's Resource Quality Assurance activities determined that 95% of the address space would be suitable for delegation as it was found to be relatively free of unwanted traffic [1].
Testing, conducted by APNIC R&D found that certain blocks within Network 1 attract significant amounts of unwanted traffic, primarily due to its unauthorised use as private address space [2].
Analysis revealed that, prior to any delegations being made from the block, 1.0.0.0/8 http://1.0.0.0/8 attracted an average of 140Mbps - 160Mbps of unsolicited incoming traffic as a continuous sustained traffic level, with peak bursts of over 800Mbps.
The analysis highlighted individual addresses such as 1.2.3.4 with its covering /24 (identified as 1.2.3.0/24 http://1.2.3.0/24 ) remain in APNIC quarantine and it is believed they will not be suitable for normal address distribution.
The proposal proposes the use of 1.2.3.0/24 http://1.2.3.0/24 in a context of locally scoped infrastructure support for DNS resolvers.
- Objective of policy change
As the addresses attract extremely high levels of unsolicited incoming traffic, the block has been withheld from allocation and periodically checked to determine if the incoming traffic profile has altered. None has been observed to date. After four years, it now seems unlikely there will ever be any change in the incoming traffic profile.
The objective of this proposal is to permit the use 1.2.3.0/24 http://1.2.3.0/24 as a anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers. It is
-- Masato Yamanishi SVP, Network Engineering Japan Telecom America Tel: +1-213-623-0797 ext.106
--
Dean Pemberton
Technical Policy Advisor InternetNZ +64 21 920 363 (mob) dean@internetnz.net.nz
To promote the Internet's benefits and uses, and protect its potential.
On Wed, Mar 5, 2014 at 5:33 AM, Masato Yamanishi <myamanis@japan-telecom.com
wrote:
Is there anyone who want to continue this proposal?
I read the Transcript, and saw the comment made on the inadvisability of 1.2.3.4/24 being used as a DNS resolver. I am not sure that this concern is either new enough, or severe enough, to substantially cause the proposal to be dropped.
To quote the Transcript:
Yoshinobu Matsuzaki (IIJ): Let me clarify
why I oppose to the prop-110, because
it's creating a new security risk. Once
the broadband router is set with default
setting, that DNS reserve the 1.2.3.4, if
there's no DNS server maintained by ISP,
probably it's query to the DNS server in
the Internet, and sometimes it's
maintained by good guy, but sometimes it
could be maintained by bad boy. Right?
I see two scenarios which might lead to to this objection: (Yamanishi-san, please forward this email to mazz if he is not on this list. I hope I am not misunderstanding his objections.)
1. Consumer Router manufacturers might start hardcode-ing 1.2.3.4 as the default DNS resolver, and this may be someone outside the ISP's network. I appreciate that this may happen, and I have seen similar things happen re: NTP servers. I do not, however, think this is either going to be likely, or widespread. At least in S E Asia, I have not seen any Home Routers with even Google's PDNS hardcoded into them. As such, I do not think D-Link or Linksys (as an example) is likely to ship devices with 1.2.3.4 as the default. The support costs for D-Link if this does not work would be prohibitive. 2. Second, the Home Device could be re-sold, with 1.2.3.4 as the DNS setup, and the new owner would be unknowingly be using it. I consider this extremely unlikely to happen accidentally. The new owner would (unless he had exactly the same ISP and setup) need to review settings, perhaps a factory default. And if he had the same ISP and setup as the previous owner, then there would be no additional danger anyway.
As such, I am not saying that a bad network operator could not announce 1.2.3.4, and wait for people to use him. I am saying that this is not an additional danger, many people already use 8.8.8.8. and 4.4.2.2, for example, or OpenDNS.
And any person deciding to announce 1.2.3.0/24 to the open network, would have to face a massive traffic storm anyway. prop-109 by Geoff Huston mentions the traffic flowing to certain easily-remembered ranges. Assuming that 1.2.3.0/24 gets even 50Mbps of traffic if I announce it to the Internet, that is till still an expensive pipe, and probably not worth it on the off-chance that a random user will use it and allow "evil me" to redirect him to the particular bank that he is a member of, and which I am forging a website for. To summarize, there is no ADDITIONAL danger, and there are some advantages to this proposal. I would like work on this proposal to continue, and see if we can address the concerns raised at the APNIC Meeting.
(BTW, I see that AS15169, Google, is still advertising 1.2.3.0/24. This may be due to the APNIC-YouTube experiment).
On Mar 5, 2014, at 00:09 , Sanjeev Gupta sanjeev@dcs1.biz wrote:
On Wed, Mar 5, 2014 at 5:33 AM, Masato Yamanishi myamanis@japan-telecom.com wrote: Is there anyone who want to continue this proposal?
I read the Transcript, and saw the comment made on the inadvisability of 1.2.3.4/24 being used as a DNS resolver. I am not sure that this concern is either new enough, or severe enough, to substantially cause the proposal to be dropped.
To quote the Transcript:
Yoshinobu Matsuzaki (IIJ): Let me clarify
why I oppose to the prop-110, because it's creating a new security risk. Once the broadband router is set with default setting, that DNS reserve the 1.2.3.4, if there's no DNS server maintained by ISP, probably it's query to the DNS server in the Internet, and sometimes it's maintained by good guy, but sometimes it could be maintained by bad boy. Right?I see two scenarios which might lead to to this objection: (Yamanishi-san, please forward this email to mazz if he is not on this list. I hope I am not misunderstanding his objections.) Consumer Router manufacturers might start hardcode-ing 1.2.3.4 as the default DNS resolver, and this may be someone outside the ISP's network. I appreciate that this may happen, and I have seen similar things happen re: NTP servers. I do not, however, think this is either going to be likely, or widespread. At least in S E Asia, I have not seen any Home Routers with even Google's PDNS hardcoded into them. As such, I do not think D-Link or Linksys (as an example) is likely to ship devices with 1.2.3.4 as the default. The support costs for D-Link if this does not work would be prohibitive. Second, the Home Device could be re-sold, with 1.2.3.4 as the DNS setup, and the new owner would be unknowingly be using it. I consider this extremely unlikely to happen accidentally. The new owner would (unless he had exactly the same ISP and setup) need to review settings, perhaps a factory default. And if he had the same ISP and setup as the previous owner, then there would be no additional danger anyway. As such, I am not saying that a bad network operator could not announce 1.2.3.4, and wait for people to use him. I am saying that this is not an additional danger, many people already use 8.8.8.8. and 4.4.2.2, for example, or OpenDNS.
1.2.3.4 is very different from 8.8.8.8 and 4.4.2.2, etc. In the case of the former, random advertisements leaking from whoever are expected and normal. They should be blocked, but the concept of should in the global routing table is an amusing one at best. In the latter case, the routes are expected to come from known origin ASNs and a misalignment would be rapidly and easily detected, especially one for malicious intent or fraudulent purposes.
And any person deciding to announce 1.2.3.0/24 to the open network, would have to face a massive traffic storm anyway. prop-109 by Geoff Huston mentions the traffic flowing to certain easily-remembered ranges. Assuming that 1.2.3.0/24 gets even 50Mbps of traffic if I announce it to the Internet, that is till still an expensive pipe, and probably not worth it on the off-chance that a random user will use it and allow "evil me" to redirect him to the particular bank that he is a member of, and which I am forging a website for.
Never underestimate the willingness of a malefactor to subject hosts he controls (but probably doesn't own) or even hosts he doesn't necessarily control to vast quantities of traffic.
To summarize, there is no ADDITIONAL danger, and there are some advantages to this proposal. I would like work on this proposal to continue, and see if we can address the concerns raised at the APNIC Meeting.
There are no advantages to this proposal and substantial danger, actually. I support dropping it.
Owen
On Wed, Mar 5, 2014 at 5:19 PM, Owen DeLong owen@delong.com wrote:
And any person deciding to announce 1.2.3.0/24 to the open network, would have to face a massive traffic storm anyway. prop-109 by Geoff Huston mentions the traffic flowing to certain easily-remembered ranges. Assuming that 1.2.3.0/24 gets even 50Mbps of traffic if I announce it to the Internet, that is till still an expensive pipe, and probably not worth it on the off-chance that a random user will use it and allow "evil me" to redirect him to the particular bank that he is a member of, and which I am forging a website for.
Never underestimate the willingness of a malefactor to subject hosts he controls (but probably doesn't own) or even hosts he doesn't necessarily control to vast quantities of traffic.
Owen,
Can you give me an example of what would be the scenario here? Assuming I am the upstream ISP of the "hosts I control, willing to subject them to vast quantities of traffic". Would I announce 1.2.3.0/24 upstream, and point it to my customer's link?
Or would I announce 1.2.3.0/24 from another ISP's origin AS?
How would (evil me) be able to hurt hosts other than on _my_ network?
I am not doubting that people would not want to misuse this, but how would this work in the case you have outlined?
On Mar 9, 2014, at 23:52 , Sanjeev Gupta sanjeev@dcs1.biz wrote:
On Wed, Mar 5, 2014 at 5:19 PM, Owen DeLong owen@delong.com wrote:
And any person deciding to announce 1.2.3.0/24 to the open network, would have to face a massive traffic storm anyway. prop-109 by Geoff Huston mentions the traffic flowing to certain easily-remembered ranges. Assuming that 1.2.3.0/24 gets even 50Mbps of traffic if I announce it to the Internet, that is till still an expensive pipe, and probably not worth it on the off-chance that a random user will use it and allow "evil me" to redirect him to the particular bank that he is a member of, and which I am forging a website for.
Never underestimate the willingness of a malefactor to subject hosts he controls (but probably doesn't own) or even hosts he doesn't necessarily control to vast quantities of traffic.
Owen,
Can you give me an example of what would be the scenario here? Assuming I am the upstream ISP of the "hosts I control, willing to subject them to vast quantities of traffic". Would I announce 1.2.3.0/24 upstream, and point it to my customer's link?
I'm not assuming that the upstream ISP would be the malefactor. That is, in fact, a rather odd assumption, is it not?
OTOH, if you are a malefactor that wants to turn your botnet into anycasted DNS servers to issue incorrect redirections to others, getting said botnet (or its upstream routers if you are able to control them somehow) to announce 1.2.3.0/24 really doesn't pose any problem to you as a result of the traffic it generates.
Or would I announce 1.2.3.0/24 from another ISP's origin AS?
Not sure how that would work or help other than in an attempt to cover your tracks.
How would (evil me) be able to hurt hosts other than on _my_ network?
You are assuming that you are doing this with routers you own (in the commercial sense of the word). I am assuming someone doing this with routers that they control (in the enable access sense of the word) but do not own (in the commercial sense of the word).
Malefactors these days are rather well known for using other people's equipment to carry out their misdeeds, or are you unfamiliar with the term "botnet"?
I am not doubting that people would not want to misuse this, but how would this work in the case you have outlined?
I hope I have adequately clarified.
Owen
On Mon, Mar 10, 2014 at 3:43 PM, Owen DeLong owen@delong.com wrote:
Can you give me an example of what would be the scenario here? Assuming I am the upstream ISP of the "hosts I control, willing to subject them to vast quantities of traffic". Would I announce 1.2.3.0/24 upstream, and point it to my customer's link?
I'm not assuming that the upstream ISP would be the malefactor. That is, in fact, a rather odd assumption, is it not?
Very odd, but I was trying to think of ways to force someone to use my servers.
OTOH, if you are a malefactor that wants to turn your botnet into anycasted DNS servers to issue incorrect redirections to others, getting said botnet (or its upstream routers if you are able to control them somehow) to announce 1.2.3.0/24 really doesn't pose any problem to you as a result of the traffic it generates.
This is the part that I really do not understand. Suppose I control a significant number of Windows7 PCs, and a few Cisco Routers, in your network, through a C&C botnet. How would I get them (the PCs) to make announcements for 1.2.3.0/24? I could install quagga (after porting it) quietly on them, but who would the Windows 7 PCs peer with? Only the routers under my control? In which case, what would be the point?
I could get the Ciscos to startup BGP, and start announcing 1.2.3.0/24 , but to whom? Again, I can only peer if I control both sides of the link, and if I control both sides, why do anycast anywhay? I have control on the RIB.
If I controlled the Routers at the edge of your network, I could redirect traffic from your nodes to any address I wished. This requires no new DNS, or 1.2.3.0/24 routing.
There is one other case I can think of. Start DNS servers on the zombie PCs, assign them 1.2.3.4, and use them as a DNS server farm. But who would come to them? If this was a home network (or any kind of leaf network), assigning 8.8.8.8 to my interface does not make you next to me send your DNS query to me.
Or would I announce 1.2.3.0/24 from another ISP's origin AS?
Not sure how that would work or help other than in an attempt to cover your tracks.
Thank you, so we can close that scenario I postulated as invalid.
How would (evil me) be able to hurt hosts other than on _my_ network?
You are assuming that you are doing this with routers you own (in the commercial sense of the word). I am assuming someone doing this with routers that they control (in the enable access sense of the word) but do not own (in the commercial sense of the word).
Malefactors these days are rather well known for using other people's equipment to carry out their misdeeds, or are you unfamiliar with the term "botnet"?
I am aware of the concept, and some implementations. And I appreciate your distinction between the the "own" and "control" part, it helps bisect the problem.
Suppose I subvert a router in your network (might be your edge router, might be an internal). Now what? Where does 1.2.3.0/24 come into the picture?
I am not doubting that people would not want to misuse this, but how would this work in the case you have outlined?
I hope I have adequately clarified.
I can understand if I am being too slow in picking up something obvious. I am still nt seeing a _new_ attack vector _due_ to 1.2.3.0/24 being allowed to be used internally (and even leaking externally).
Hi,
As such, I am not saying that a bad network operator could not announce 1.2.3.4, and wait for people to use him. I am saying that this is not an additional danger, many people already use 8.8.8.8. and 4.4.2.2, for example, or OpenDNS.
These are different. As the Google Public DNS and OpenDNS are maintained by the service operators, and they are responsible to fix the services if there are any issues. However regarding the prop-110 (1.2.3.0/24), anyone can operate the network as they like - nicely, badly and even for malicious purpuse.
And any person deciding to announce 1.2.3.0/24 to the open network, would have to face a massive traffic storm anyway. prop-109 by Geoff Huston mentions the traffic flowing to certain easily-remembered ranges. Assuming that 1.2.3.0/24 gets even 50Mbps of traffic if I announce it to the Internet, that is till still an expensive pipe, and probably not worth it on the off-chance that a random user will use it and allow "evil me" to redirect him to the particular bank that he is a member of, and which I am forging a website for.
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.
To summarize, there is no ADDITIONAL danger, and there are some advantages to this proposal. I would like work on this proposal to continue, and see if we can address the concerns raised at the APNIC Meeting.
This is not reliable from user's point of view, and is even danger, I support dropping the proposal.
Regards, ----- Matsuzaki Yoshinobu maz@iij.ad.jp - IIJ/AS2497 INOC-DBA: 2497*629
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
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?
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
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 sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
On Mon, Mar 10, 2014 at 3:49 PM, Kenny Huang, Ph.D. huangk@alum.sinica.eduwrote:
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.
Thank you, this is a well-defined scenario to discuss.
If the ISP is not checking RPKI, how would this be different from (evil me) announcing 208.67.222.0/24https://ri.renesys.com/ri/grad?fn=prefixtool&prefix=208.67.222.0/24&t0=1394433679&t1=1394448079, which is the range used by OpenDNS?
(And if the ISP uses RPKI, and bogon filters, then my announcement will never affect him anyway)
Again, I am not saying that I am not evil, I am trying to understand how prop-110 makes things worse.
On 10 March 2014 18:44, Sanjeev Gupta sanjeev@dcs1.biz wrote:
On Mon, Mar 10, 2014 at 3:49 PM, Kenny Huang, Ph.D. < huangk@alum.sinica.edu> wrote:
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.
Thank you, this is a well-defined scenario to discuss.
If the ISP is not checking RPKI, how would this be different from (evil me) announcing 208.67.222.0/24https://ri.renesys.com/ri/grad?fn=prefixtool&prefix=208.67.222.0/24&t0=1394433679&t1=1394448079, which is the range used by OpenDNS?
(And if the ISP uses RPKI, and bogon filters, then my announcement will never affect him anyway)
Two things, First, Policy SIG is not the right place to define protocol
specific address block.
Second, the service that public DNS providers provided and ISPs' routing strategy has
nothing to do with RIR address policy. Any protocol/application utilize allocated address
block has nothing to do with RIR address policy neither. But if an existence of the undesirable
scenario expanded due to official encouragement/endorsement of address policy, then RIR
will be liable for the outcome.
Regards
Kenny Huang
Masato,
Can it be explained how this occurred. Did something change between the two?
I thought it was practice that the AMM essentially confirmed the proceedings on the Policy SIG - to avoid these kinds of events, especially at APRICOT meetings where support/non-support may not be able to make both events.
I find it extraordinarily a waste of time if all the effort of the Policy SIG is undone on an individual policy basis. The AMM should be confirming the whole Policy SIG event, not individual policies.. or you might as well not call for consensus during Policy SIG and just save time and do it once at the AMM, or the other way around.
I've seen this happen a number of times at combined Apricot events with a lot of other parties present. One might say that it would be wiser to propose policies only at the mid-year events.
...Skeeve
*Skeeve Stevens - *eintellego Networks Pty Ltd skeeve@eintellegonetworks.com ; www.eintellegonetworks.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
On Tue, Mar 4, 2014 at 12:27 AM, Masato Yamanishi < myamanis@japan-telecom.com> wrote:
Dear colleagues
Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did not reach consensus at the APNIC 37 Member Meeting.
Therefore, this proposal is being returned to the authors and the Policy SIG mailing list for further consideration.
Proposal details
The objective of this proposal is to permit the use 1.2.3.0/24 as anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers.
Proposal details including the full text of the proposal, history, and links to mailing list discussions are available at:
http://www.apnic.net/policy/proposals/prop-110Regards
Masato
prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Proposers: Dean Pemberton, dean@internetnz.net.nz Geoff Huston, gih@apnic.net
- Problem statement
Network 1 (1.0.0.0/8) was allocated to APNIC by the IANA on 19 January 2010. In line with standard practice APNIC's Resource Quality Assurance activities determined that 95% of the address space would be suitable for delegation as it was found to be relatively free of unwanted traffic [1].
Testing, conducted by APNIC R&D found that certain blocks within Network 1 attract significant amounts of unwanted traffic, primarily due to its unauthorised use as private address space [2].
Analysis revealed that, prior to any delegations being made from the block, 1.0.0.0/8 attracted an average of 140Mbps - 160Mbps of unsolicited incoming traffic as a continuous sustained traffic level, with peak bursts of over 800Mbps.
The analysis highlighted individual addresses such as 1.2.3.4 with its covering /24 (identified as 1.2.3.0/24) remain in APNIC quarantine and it is believed they will not be suitable for normal address distribution.
The proposal proposes the use of 1.2.3.0/24 in a context of locally scoped infrastructure support for DNS resolvers.
- Objective of policy change
As the addresses attract extremely high levels of unsolicited incoming traffic, the block has been withheld from allocation and periodically checked to determine if the incoming traffic profile has altered. None has been observed to date. After four years, it now seems unlikely there will ever be any change in the incoming traffic profile.
The objective of this proposal is to permit the use 1.2.3.0/24 as a anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers. It is noted that as long as providers who use this address use basic route scope limitations, the side effect of large volumes of unsolicited incoming traffic would be, to some extent mitigated down to manageable levels.
- Situation in other regions
Improper use of this address space is a globally common issue. However the block is delegated only APNIC and so therefor, no other RIR has equivalent policy to deal with the situation.
- Proposed policy solution
This proposal recommends that the APNIC community agree to assign 1.2.3.0/24 to the APNIC Secretariat for use in the context of locally scoped infrastructure support for DNS resolvers.
At some future point there is nothing restricting an RFC being written to include this prefix into the special-purpose IPv4 registry. However, at this time it is considered sufficient for the APNIC community to designate this prefix to be managed as a common anycast address for locally scoped infrastructure support for DNS resolvers.
- Advantages / Disadvantages
Advantages
- It will make use of this otherwise unusable address space.
- DNS operators will have an easy-to-remember address they can use to communicate with their users (e.g. configure "1.2.3.4" as your DNS resolver")
Disadvantages
- The address attracts a large volume of unsolicited incoming traffic, and leakage of an anycast advertisement outside of a limited local scope may impact on the integrity of the DNS service located at the point associated with the scope leakage. Some operators with high capacity infrastructure may see this as a negligible issue.
- Impact on APNIC
Although this space will no longer be available for use by a single APNIC/NIR account holder, the proposal would result in benefit for all APNIC community members, as well as the communities in other regions.
References
[1] Resource Quality Good for Most of IPv4 Network "1" http://www.apnic.net/publications/press/releases/2010/network-1.pdf
[2] Traffic in Network 1.0.0.0/8 http://www.potaroo.net/ispcol/2010-03/net1.html
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
Skeeve,
Rather, I think it is good example which shows why we need to ask consensus in both SIG and AMM.
In SIG, while there were some opponents and a couple of strong opponents, I decided it reached consensus since what I have caught from the discussion was that two raised issues (noise and leakage to the Internet) are manageable by ISPs who want to use this address space and these are not a risk for other ISPs and users.
However, after SIG, mazz, who could not attend SIG since he was very working hard in APRICOT NOC, raised another risk for users even if they are not direct users. And in AMM, more opponents were seen. So, even though it is EC chair's responsibility to decide consensus in AMM, I have no complain for his decision.
That is a situation and I think it is not related with the difference of APRICOT and APNIC meeting in participation level as you thought.
Rgs, Masato
2014-03-03 5:45 GMT-08:00 Skeeve Stevens skeeve@eintellegonetworks.com:
Masato,
Can it be explained how this occurred. Did something change between the two?
I thought it was practice that the AMM essentially confirmed the proceedings on the Policy SIG - to avoid these kinds of events, especially at APRICOT meetings where support/non-support may not be able to make both events.
I find it extraordinarily a waste of time if all the effort of the Policy SIG is undone on an individual policy basis. The AMM should be confirming the whole Policy SIG event, not individual policies.. or you might as well not call for consensus during Policy SIG and just save time and do it once at the AMM, or the other way around.
I've seen this happen a number of times at combined Apricot events with a lot of other parties present. One might say that it would be wiser to propose policies only at the mid-year events.
...Skeeve
*Skeeve Stevens - *eintellego Networks Pty Ltd skeeve@eintellegonetworks.com ; www.eintellegonetworks.com
Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve
twitter.com/theispguy ; blog: www.theispguy.com
The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
On Tue, Mar 4, 2014 at 12:27 AM, Masato Yamanishi < myamanis@japan-telecom.com> wrote:
Dear colleagues
Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did not reach consensus at the APNIC 37 Member Meeting.
Therefore, this proposal is being returned to the authors and the Policy SIG mailing list for further consideration.
Proposal details
The objective of this proposal is to permit the use 1.2.3.0/24 as anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers.
Proposal details including the full text of the proposal, history, and links to mailing list discussions are available at:
http://www.apnic.net/policy/proposals/prop-110Regards
Masato
prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Proposers: Dean Pemberton, dean@internetnz.net.nz Geoff Huston, gih@apnic.net
- Problem statement
Network 1 (1.0.0.0/8) was allocated to APNIC by the IANA on 19 January 2010. In line with standard practice APNIC's Resource Quality Assurance activities determined that 95% of the address space would be suitable for delegation as it was found to be relatively free of unwanted traffic [1].
Testing, conducted by APNIC R&D found that certain blocks within Network 1 attract significant amounts of unwanted traffic, primarily due to its unauthorised use as private address space [2].
Analysis revealed that, prior to any delegations being made from the block, 1.0.0.0/8 attracted an average of 140Mbps - 160Mbps of unsolicited incoming traffic as a continuous sustained traffic level, with peak bursts of over 800Mbps.
The analysis highlighted individual addresses such as 1.2.3.4 with its covering /24 (identified as 1.2.3.0/24) remain in APNIC quarantine and it is believed they will not be suitable for normal address distribution.
The proposal proposes the use of 1.2.3.0/24 in a context of locally scoped infrastructure support for DNS resolvers.
- Objective of policy change
As the addresses attract extremely high levels of unsolicited incoming traffic, the block has been withheld from allocation and periodically checked to determine if the incoming traffic profile has altered. None has been observed to date. After four years, it now seems unlikely there will ever be any change in the incoming traffic profile.
The objective of this proposal is to permit the use 1.2.3.0/24 as a anycast addresses to be used in context of scoped routing to support the deployment of DNS resolvers. It is noted that as long as providers who use this address use basic route scope limitations, the side effect of large volumes of unsolicited incoming traffic would be, to some extent mitigated down to manageable levels.
- Situation in other regions
Improper use of this address space is a globally common issue. However the block is delegated only APNIC and so therefor, no other RIR has equivalent policy to deal with the situation.
- Proposed policy solution
This proposal recommends that the APNIC community agree to assign 1.2.3.0/24 to the APNIC Secretariat for use in the context of locally scoped infrastructure support for DNS resolvers.
At some future point there is nothing restricting an RFC being written to include this prefix into the special-purpose IPv4 registry. However, at this time it is considered sufficient for the APNIC community to designate this prefix to be managed as a common anycast address for locally scoped infrastructure support for DNS resolvers.
- Advantages / Disadvantages
Advantages
- It will make use of this otherwise unusable address space.
- DNS operators will have an easy-to-remember address they can use to communicate with their users (e.g. configure "1.2.3.4" as your DNS resolver")
Disadvantages
- The address attracts a large volume of unsolicited incoming traffic, and leakage of an anycast advertisement outside of a limited local scope may impact on the integrity of the DNS service located at the point associated with the scope leakage. Some operators with high capacity infrastructure may see this as a negligible issue.
- Impact on APNIC
Although this space will no longer be available for use by a single APNIC/NIR account holder, the proposal would result in benefit for all APNIC community members, as well as the communities in other regions.
References
[1] Resource Quality Good for Most of IPv4 Network "1" http://www.apnic.net/publications/press/releases/2010/network-1.pdf
[2] Traffic in Network 1.0.0.0/8 http://www.potaroo.net/ispcol/2010-03/net1.html
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
Activity Summary
- 3487 days inactive
- 3487 days old
- sig-policy@lists.apnic.net
- 8 participants
- 16 comments