Fwd: [sig-policy] Report on traffic directed to 1.0.0.0/8
-------- Original Message --------
Subject: [sig-policy] Report on traffic directed to 1.0.0.0/8
Date: Thu, 8 Apr 2010 11:18:31 +1000
From: Geoff Huston
On Mon, Apr 12, 2010 at 11:28, Andy Linton
In particular, is there a significant level of "leakage" of supposedly private use traffic directed to addresses in 1.0.0.0/8 that leak into the public Internet?
The report on this study is now available at http://www.potaroo.net/studies/1slash8/1slash8.html, and two recommendations are included in this report regarding reservations of particular address blocks and further followup studies.
Interesting, but is there no investigation on the origins of the leakage? Hamish. -- http://tr.im/HKM
On 2010-04-13 13:21, Hamish MacEwan wrote:
On Mon, Apr 12, 2010 at 11:28, Andy Linton
wrote: In particular, is there a significant level of "leakage" of supposedly private use traffic directed to addresses in 1.0.0.0/8 that leak into the public Internet?
The report on this study is now available at http://www.potaroo.net/studies/1slash8/1slash8.html, and two recommendations are included in this report regarding reservations of particular address blocks and further followup studies.
Interesting, but is there no investigation on the origins of the leakage?
Well, we know that some sites run Net 1 behind a NAT when they should be running an RFC 1918 prefix. We also know that pretty much everbody is configured to drop RFC 1918 destination packets, but since Net 1 is a valid prefix there is no reason to drop it. So the real question is probably: why are packets being sent to addresses that are behind NATs? Shooting from the hip, I would suspect some sort of peer to peer protocol (in the generic sense of peer to peer), where a peer outside the NAT has been given the address of a peer inside the NAT. It would be interesting to know something about the UDP and TCP port numbers involved. Brian
Well, we know that some sites run Net 1 behind a NAT when they should be running an RFC 1918 prefix. We also know that pretty much everbody is configured to drop RFC 1918 destination packets, but since Net 1 is a valid prefix there is no reason to drop it.
So the real question is probably: why are packets being sent to addresses that are behind NATs?
Put it this way, if a device that implement NAT, translates the 1/8 IP address to the real IPs the customer owns and has a subnet within 1/8 directly attached, but also participates in dynamic routing with border routers or ISP routers, whether you use NAT or not, the 1/8 network will be injected into the ISP's routing tables ...
On 13/04/2010, at 2:37 PM, Florent Bouron wrote:
Well, we know that some sites run Net 1 behind a NAT when they should be running an RFC 1918 prefix. We also know that pretty much everbody is configured to drop RFC 1918 destination packets, but since Net 1 is a valid prefix there is no reason to drop it.
So the real question is probably: why are packets being sent to addresses that are behind NATs?
Put it this way, if a device that implement NAT, translates the 1/8 IP address to the real IPs the customer owns and has a subnet within 1/8 directly attached, but also participates in dynamic routing with border routers or ISP routers, whether you use NAT or not, the 1/8 network will be injected into the ISP's routing tables ...
With a poorly configured router at the ISP and the user's site, sure. However that doesn't explain why there are packets on the wider Internet that are destined to 1/8 addresses. I think Brian is right in suggesting peer to peer, and I imagine there are other things as well. For example, responses to packets sourced from 1/8 addresses. Perhaps there is a NAT somewhere that only NATs TCP, UDP and ICMP, and doesn't drop other protocols. Perhaps there is a botnet sending packets from 1/8 addresses, because that was a random address that the script kiddie that put it together came up with. There are any number of scenarios that could be causing traffic to 1/8. I'm not convinced it is operationally useful for us to know why this is happening, just that it is, and how to avoid it impacting us. If it's being caused by people using 1/8 when they shouldn't have, they'll have to fix it soon enough. It occurs to me that 1/8 could perhaps be primarily given to APNIC members who are asking for IPv4 space for dynamic end users. If the assumption that most 1/8 users are end users behind bad NATs is correct then impact is limited to preventing peer to peer between the two hosts, and most peer to peer systems have ways to minimise the negative impact of these situations, either with help from other hosts or alternative peers. If, however, someone got a 1/8 address for a web server or similar, then impact would be quite a bit worse. -- Nathan Ward
i can't imagine a user being allocated ip space in that block would be to happy paying for traffic they were not requesting in the first place. (not that it's any different from most current practices). On 13/04/10 15:02, Nathan Ward wrote:
On 13/04/2010, at 2:37 PM, Florent Bouron wrote:
Well, we know that some sites run Net 1 behind a NAT when they should be running an RFC 1918 prefix. We also know that pretty much everbody is configured to drop RFC 1918 destination packets, but since Net 1 is a valid prefix there is no reason to drop it.
So the real question is probably: why are packets being sent to addresses that are behind NATs?
Put it this way, if a device that implement NAT, translates the 1/8 IP address to the real IPs the customer owns and has a subnet within 1/8 directly attached, but also participates in dynamic routing with border routers or ISP routers, whether you use NAT or not, the 1/8 network will be injected into the ISP's routing tables ...
With a poorly configured router at the ISP and the user's site, sure. However that doesn't explain why there are packets on the wider Internet that are destined to 1/8 addresses.
I think Brian is right in suggesting peer to peer, and I imagine there are other things as well. For example, responses to packets sourced from 1/8 addresses. Perhaps there is a NAT somewhere that only NATs TCP, UDP and ICMP, and doesn't drop other protocols. Perhaps there is a botnet sending packets from 1/8 addresses, because that was a random address that the script kiddie that put it together came up with. There are any number of scenarios that could be causing traffic to 1/8.
I'm not convinced it is operationally useful for us to know why this is happening, just that it is, and how to avoid it impacting us. If it's being caused by people using 1/8 when they shouldn't have, they'll have to fix it soon enough.
It occurs to me that 1/8 could perhaps be primarily given to APNIC members who are asking for IPv4 space for dynamic end users. If the assumption that most 1/8 users are end users behind bad NATs is correct then impact is limited to preventing peer to peer between the two hosts, and most peer to peer systems have ways to minimise the negative impact of these situations, either with help from other hosts or alternative peers. If, however, someone got a 1/8 address for a web server or similar, then impact would be quite a bit worse.
-- Nathan Ward _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- *Leon Strong *| Technical Engineer *DDI:* +64 9 950 2203 *Fax:* +64 9 302 0518 *Mobile:* +64 21 0202 8870 *Freephone:* 0800 SMX SMX (769 769) Level 15, 19 Victoria Street, Auckland, New Zealand | SMX Ltd | smx.co.nz http://smx.co.nz SMX | Business Email Specialists The information contained in this email and any attachments is confidential. If you are not the intended recipient then you must not use, disseminate, distribute or copy any information contained in this email or any attachments. If you have received this email in error or you are not the originally intended recipient please contact SMX immediately and destroy this email. ______________________________________________________________________________ This email has been scrubbed for your protection by SMX. For more information visit http://smxemail.com ______________________________________________________________________________
I believe APNIC is going to reserve the spaces in question as "APNIC R&D" or something similar. Someone correct me if i'm wrong. On 13/04/2010 5:09 p.m., Leon Strong wrote:
i can't imagine a user being allocated ip space in that block would be to happy paying for traffic they were not requesting in the first place. (not that it's any different from most current practices).
On 13/04/10 15:02, Nathan Ward wrote:
On 13/04/2010, at 2:37 PM, Florent Bouron wrote:
Well, we know that some sites run Net 1 behind a NAT when they should be running an RFC 1918 prefix. We also know that pretty much everbody is configured to drop RFC 1918 destination packets, but since Net 1 is a valid prefix there is no reason to drop it.
So the real question is probably: why are packets being sent to addresses that are behind NATs?
Put it this way, if a device that implement NAT, translates the 1/8 IP address to the real IPs the customer owns and has a subnet within 1/8 directly attached, but also participates in dynamic routing with border routers or ISP routers, whether you use NAT or not, the 1/8 network will be injected into the ISP's routing tables ...
With a poorly configured router at the ISP and the user's site, sure. However that doesn't explain why there are packets on the wider Internet that are destined to 1/8 addresses.
I think Brian is right in suggesting peer to peer, and I imagine there are other things as well. For example, responses to packets sourced from 1/8 addresses. Perhaps there is a NAT somewhere that only NATs TCP, UDP and ICMP, and doesn't drop other protocols. Perhaps there is a botnet sending packets from 1/8 addresses, because that was a random address that the script kiddie that put it together came up with. There are any number of scenarios that could be causing traffic to 1/8.
I'm not convinced it is operationally useful for us to know why this is happening, just that it is, and how to avoid it impacting us. If it's being caused by people using 1/8 when they shouldn't have, they'll have to fix it soon enough.
It occurs to me that 1/8 could perhaps be primarily given to APNIC members who are asking for IPv4 space for dynamic end users. If the assumption that most 1/8 users are end users behind bad NATs is correct then impact is limited to preventing peer to peer between the two hosts, and most peer to peer systems have ways to minimise the negative impact of these situations, either with help from other hosts or alternative peers. If, however, someone got a 1/8 address for a web server or similar, then impact would be quite a bit worse.
-- Nathan Ward _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 13/04/2010, at 3:58 PM, Daniel Richards wrote:
I believe APNIC is going to reserve the spaces in question as "APNIC R&D" or something similar.
Someone correct me if i'm wrong.
You are right The recommendations at the end of the report are being implemented. Five /24s where the traffic is exceptionally high are being withheld from general allocation to allow further experimentation. If things change with these "toxic" /24s we'll release them for allocation, but that's not something that will be done in the near future. A larger set of /16s listed in the report's recommendations are to be marked as allocated to APNIC R&D to allow further short term experimentation in the distribution of unsolicited background traffic to these addresses to be conducted by APNIC in collaboration with interested researchers and the operational community. The experimentation would be conducted in the period April – October 2010, and a followup report on recommended longer term reservations from this set of addresses be provided at the end of this period. thanks, Geoff Huston APNIC
On 13/04/2010, at 3:09 PM, Leon Strong wrote:
i can't imagine a user being allocated ip space in that block would be to happy paying for traffic they were not requesting in the first place. (not that it's any different from most current practices).
We are happy with the report's conclusions that, aside from the listed /16s, network 1 does not appear to be overly "worse" than other parts of the IPv4 address space. There is a certain amount of value judgement in that sentence, but the report attempts to provide a more detailed measurement of what would be "normal" for an address block from another part of the address space (network 27) and equate that to what we observed across network 1. Most of network 1 receives incoming traffic at a rate which is less than one small incoming packet per second, which is comparable to what we observed in a similar experiment conducted in network 27. regards, Geoff Huston APNIC
On Mon, Apr 12, 2010 at 7:31 PM, Brian E Carpenter < brian.e.carpenter(a)gmail.com> wrote:
Interesting, but is there no investigation on the origins of the leakage?
Well, we know that some sites run Net 1 behind a NAT when they should be running an RFC 1918 prefix. We also know that pretty much everbody
"Secondary DNS server? What the hell is that? OK.. 0.0.0.0. What do you mean Invalid IP? OK.. 1.1.1.1. There - that fixed it!" Repeat for STUN servers, hosts entries for the Google Ads servers and the Microsoft activation servers, DHCP agent forwarding, highest (or lowest) priority MX records for the server you try and use to avoid botnet spam, etc, etc, etc. It's a pretty much endless list. APNIC has said that they will be doing further analysis on the captured data and releasing it in the next few months. Scott.
On 13/04/2010, at 11:21 AM, Hamish MacEwan wrote:
On Mon, Apr 12, 2010 at 11:28, Andy Linton
wrote: In particular, is there a significant level of "leakage" of supposedly private use traffic directed to addresses in 1.0.0.0/8 that leak into the public Internet?
The report on this study is now available at http://www.potaroo.net/studies/1slash8/1slash8.html, and two recommendations are included in this report regarding reservations of particular address blocks and further followup studies.
Interesting, but is there no investigation on the origins of the leakage?
yes there has been, but the report on this, and some other potentially interesting aspects of the data that was captured in these experiments, will be published in reports currently being prepared. regards, Geoff Huston APNIC
participants (9)
-
Andy Linton
-
Brian E Carpenter
-
Daniel Richards
-
Florent Bouron
-
Geoff Huston
-
Hamish MacEwan
-
Leon Strong
-
Nathan Ward
-
Scott Howard