Re: [sig-policy] Forwarded reply from Gordon Bader
ATT has been routing and utilizing dark address space for at least 3 years
that I can document, not mearly 3 weeks. Worldcom/con/MCI has been
doing so for longer than 4 years that I can document. AOL has been doing so
for longer than 6 years that I can document. And MSN has been doing so
for a little more than 4 years that I know of.
Hence I cannot in good faith, agree with your comment or opinion that
"Most if not all carriers, I believe attempt to perform a good job keeping
their tables current and clean."
I believe that Dr Batista, myself and others on other verious forums going
back at least 4 years have pointed this out to Worldcom/con/MCI as well
as ATT before.
GB wrote:
> Good Morning Jeff and all,
>
> For the most part I do agree that routing policies are implemented
> for the end customer's best interests. Most if not all carriers, I
> believe attempt to perform a good job keeping their tables current and
> clean. However, there are some that do route dark addresses either
> unknowingly or possibly just because there is too much to do and thus
> something needs to go undone. Therefor, it becomes a cost of doing
> business and it impacts all users on the Internet. It has been my
> experience that about 90% of the dark space email I receive (either
> originating or directing the reader to a dark address) uses an APNIC
> allocated address for some reason, thus my proposal to APNIC.
>
> Getting back to your statement that "If they (ISPs) do and it
> becomes known they will not be in business very long.", I will use the
> illustrative example I have used before.....
>
> =========
> 08/16/04 07:07:39 Fast traceroute 222.233.52.27
> Trace 222.233.52.27 ...
> 1 10.84.224.1 19ms 12ms 13ms TTL: 0 (No rDNS)
> 2 68.2.4.73 12ms 11ms 10ms TTL: 0
> (ip68-2-4-73.ph.ph.cox.net ok)
> 3 68.2.0.37 12ms 12ms 14ms TTL: 0
> (ip68-2-0-37.ph.ph.cox.net ok)
> 4 68.2.0.113 14ms 14ms 15ms TTL: 0
> (ip68-2-0-113.ph.ph.cox.net ok)
> 5 68.2.14.13 48ms 15ms 14ms TTL: 0
> (chnddsrc02-gew0303.rd.ph.cox.net ok)
> 6 68.1.0.168 17ms 28ms 16ms TTL: 0
> (chndbbrc02-pos0101.rd.ph.cox.net ok)
> 7 64.154.128.29 14ms 17ms 28ms TTL: 0
> (p1-0.hsa1.phx1.bbnplanet.net ok)
> 8 4.68.113.253 17ms 14ms 18ms TTL: 0
> (so-6-2-0.mp2.Phoenix1.Level3.net ok)
> 9 64.159.1.30 4ms 26ms 24ms TTL: 0
> (as-0-0.bbr1.LosAngeles1.Level3.net ok)
> 10 209.247.9.214 25ms 27ms 26ms TTL: 0
> (so-7-0-0.gar1.LosAngeles1.Level3.net ok)
> 11 4.68.127.138 26ms 23ms 25ms TTL: 0
> (att-level3-oc48.LosAngeles1.Level3.net ok)
> 12 12.123.29.6 24ms 27ms 27ms TTL: 0
> (tbr2-p012101.la2ca.ip.att.net probable bogus rDNS: No DNS)
> 13 12.123.199.229 26ms 25ms 22ms TTL: 0
> (gar1-p3100.lsnca.ip.att.net probable bogus rDNS: No DNS)
> 14 12.119.138.38 25ms 24ms 25ms TTL: 0 (No rDNS)
> 15 210.180.97.21 1091ms 1219ms 828ms TTL: 0 (No rDNS)
> 16 210.220.73.2 105ms 86ms 50ms TTL: 0 (No rDNS)
> 17 211.108.63.146 96ms 96ms 76ms TTL: 0 (No rDNS)
> 18 221.139.106.58 93ms 63ms 67ms TTL: 0 (No rDNS)
> 19 222.233.52.27 75ms 94ms 76ms TTL: 49 (No rDNS)
> ======
>
> Consider this traceroute that I took several minutes ago, Hop #14 is
> ATT, Hop #15 is dark space. Please check the date (against the date of
> the traceroute later in this email trail), ATT has been routing dark
> space for about 3 weeks now, and they have been notified. Is this an
> isolated instance? Maybe (hopefully). But they have not been very
> proactive on this one particular address.
>
> It is also interesting to note the infrastructure this has from hop
> #15 through hop #19. They are all dark address space, all APNIC IP
> addresses. I have published this before several weeks ago and nothing
> has happened.
>
> It has been estimated by various studies that dark space accounts
> for upwards of 15% of Internet traffic. Some one is routing this
> traffic - it has an Internet presence. 15% is not insignificant.
> Apparently people have found it useful to allocate to themselves
> whatever space they feel they need. In finding a way to have it routed,
> essentially provides them with a web presence that does not violate any
> ISP's APU, since they are not connected in the normal fashion.
>
> I submit that ATT is routing dark address space, nothing is being
> done about it, it is probably being treated as a cost of doing business,
> and ATT has been around for a very long time. I do not know the
> particulars in this specific instance, all I can do is look at the
> traceroute and the period of time this instance has been active and come
> to the obvious conclusions. What recourse does APNIC have in regaining
> control of their unallocated IP address that is currently being used?
> ATT is essentially providing value to the people using this dark address
> space, at the expense of everyone.
>
> It might be interesting to find out the following:
>
> - Through a random survey of unallocated APNIC addresses, how many
> are being used?
> - Who is routing them?
> - How did they become to be routed?
> - What process can be created to have the addresses returned to
> APNIC's control?
> - What can be done to prevent their routing in the first place?
>
> Regards,
> Gordon
>
> Jeff Williams wrote:
>
> >Phillip and all,
> >
> > I don't for a moment believe that many ISP's are going to implement
> >any routing policy they did not feel was in their customers best interests
> >as well as had a hand in determining. If they do and it becomes known
> >they will not be in business very long.
> >
> >Philip Smith wrote:
> >
> >
> >
> >>Hi Izumi,
> >>
> >>At 16:02 10/08/2004 +0900, Izumi Okutani wrote:
> >>
> >>
> >>
> >>>I have one additional question, which may be more appropriate to ask
> >>>APNIC Secretariat - would NIRs be expected to implement the same
> >>>policy once this reaches consensus? I am asking this since we have our
> >>>own policy making process within JP, and our process differs depending
> >>>on what is expected on NIRs.
> >>>
> >>>
> >>I think everyone has to implement this policy if it reaches consensus. It
> >>will only work if the RIRs & NIRs basically decide what the ISPs can and
> >>cannot route.
> >>
> >>And if it is approved in the AP region, it has to be approved in the other
> >>three RIR regions to have any impact at all; unless the proposed policy is
> >>intended to be binding on all routes the member ISPs provide transit to.
> >>Otherwise the miscreants which this policy proposal seeks to freeze out of
> >>the Internet will simply go outside of the region.
> >>
> >>As I see it, it will change the membership agreement each LIR has with
> >>APNIC, and the membership of the NIR have with the NIR. Basically giving
> >>the RIRs and NIRs internationally binding legal powers to influence their
> >>members' businesses. A pretty fundamental change in APNIC's existing
> >>address assignment policy, never mind uncharted waters for international
> >>law enforcement wrt the Internet. Which laws does APNIC as an Australian
> >>organisation use to stop an ISP in another country from "illegally
> >>announcing address space"? I'm no lawyer, but seeing the ICC being ignored
> >>by some countries doesn't give me much reason for optimism.
> >>
> >>philip
> >>--
> >>
> >>
> >>
> >>>Izumi
> >>>JPNIC
> >>>
> >>>From: APNIC Secretariat <secretariat at apnic dot net>
> >>>Subject: [sig-policy] Forwarded reply from Gordon Bader
> >>>Date: Mon, 09 Aug 2004 10:16:57 +1000
> >>>
> >>>
> >>>
> >>>>The email below is forwarded to the list on behalf of Gordon Bader. He is
> >>>>now subscribed to the list.
> >>>>
> >>>>regards,
> >>>>
> >>>>APNIC Secretariat.
> >>>>
> >>>>
> >>>>
> >>>>>Date: Fri, 06 Aug 2004 07:15:16 -0700
> >>>>>From: GB <gbader at cox dot net>
> >>>>>To: Izumi Okutani <izumi at nic dot ad dot jp>
> >>>>>CC: secretariat at apnic dot net, sig-policy at apnic dot net,
> >>>>>
> >>>>>
> >>>sig-policy-chair at apnic dot net
> >>>
> >>>
> >>>>>Subject: Re: [sig-policy] SIG Policy Proposal 'Preventing the routing of
> >>>>>'dark' address space
> >>>>>
> >>>>>Good Morning Mr. Okutani and APNIC Secretariat,
> >>>>>
> >>>>> Thank you for reading the proposal and your associated questions on
> >>>>>the sig-policy proposal
> >>>>>'Preventing the routing of 'dark' address space'. I have responded in
> >>>>>line using the tag [Response]
> >>>>>below for each one of your concerns. I have also included an example.
> >>>>>
> >>>>>Izumi Okutani wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Dear Gordon/APNIC secretariat,
> >>>>>>
> >>>>>>
> >>>>>>I understand the issue you have raised, but I still can't quite
> >>>>>>understand your proposal.
> >>>>>>
> >>>>>>Could you please clarify what specific actions you expect APNIC and
> >>>>>>possibily, the community members to take?
> >>>>>>
> >>>>>>I've also added my comments inline.
> >>>>>>
> >>>>>>From: APNIC Secretariat <secretariat at apnic dot net>
> >>>>>>Subject: [sig-policy] SIG Policy Proposal 'Preventing the routing of
> >>>>>>
> >>>>>>
> >>>>>'dark' address
> >>>>>space
> >>>>>
> >>>>>
> >>>>>>Date: Wed, 04 Aug 2004 17:39:27 +1000
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>This proposal is being sent to the mailing list on behalf of Gordon
> >>>>>>>
> >>>>>>>
> >>>Bader
> >>>
> >>>
> >>>>>>><gbader at cox dot net>. Feedback and comments about this proposal are
> >>>>>>>
> >>>>>>>
> >>>welcome on
> >>>
> >>>
> >>>>>>>this mailing list.
> >>>>>>>
> >>>>>>>regards,
> >>>>>>>APNIC Secretariat.
> >>>>>>>---
> >>>>>>>
> >>>>>>>
> >>>>>>>______________________________________________________________________
> >>>>>>>
> >>>>>>>prop-023-v001: A proposal to prevent the routing of "dark" address
> >>>>>>> space
> >>>>>>>______________________________________________________________________
> >>>>>>>
> >>>>>>>
> >>>>>>>Proposed by: Gordon Bader
> >>>>>>> <gbader at cox dot net>
> >>>>>>>Version: 1.0
> >>>>>>>Date: 4 August 2004
> >>>>>>>
> >>>>>>>
> >>>>>>>Introduction:
> >>>>>>>
> >>>>>>>"Dark" address space is unallocated IP address space. Bandwidth
> >>>>>>>originating from "dark" address space should not be routed at any
> >>>>>>>
> >>>>>>>
> >>>level.
> >>>
> >>>
> >>>>>>>Summary:
> >>>>>>>
> >>>>>>>Bandwidth originating from unallocated IP address space is being
> >>>>>>>used for SPAM. In addition, unallocated IP address space is being
> >>>>>>>used to host websites that support SPAM.
> >>>>>>>
> >>>>>>>APNIC has the ability to grant IP space. Given that ability, it also
> >>>>>>>has the inherent ability to remove what was granted. The implicit
> >>>>>>>grant of IP space, carries with it the ability to route, and route
> >>>>>>>in a "legal" manner. When "illegal" (dark address space) routing is
> >>>>>>>detected, then the price should be loss of the initial grant - in this
> >>>>>>>case the ability to operate which carries with it economic measures.
> >>>>>>>
> >>>>>>>Details:
> >>>>>>>
> >>>>>>>Routing tables should be configured for non routing (filtering) of
> >>>>>>>unallocated IP address space as well as allocated IP address space.
> >>>>>>>Traffic to and from unallocated (or allocated but unused) IP address
> >>>>>>>space should be dropped as soon as recognized, thus saving bandwidth up
> >>>>>>>channel.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>Are you proposing ISPs in the community to apply the above policy, or
> >>>>>>is this simply an explanation of something which should be done, and
> >>>>>>not a part of the proposal?
> >>>>>>
> >>>>>>If it's the first, I think it is out of scope of the address policy.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>[Response] - Yes, I am essentially proposing the first at ALL levels of
> >>>>>routing. I do understand that
> >>>>>this would be larger than APNIC's reach and would need to be applied
> >>>>>Internet wide. I am proposing
> >>>>>this be applied to ALL who receive their IP address allocations from
> >>>>>APNIC directly or indirectly.
> >>>>>Included within the proposal are the Tier 1 backbone providers as well
> >>>>>as individual ISP. I have
> >>>>>attached an example of what I am proposing below.
> >>>>>
> >>>>>However I do believe that it would be within APNIC's address policy
> >>>>>because if APNIC
> >>>>>was able to initially assign the IP address space to begin with, APNIC
> >>>>>should be able to
> >>>>>remove the address space it originally assigned.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Employ the basic law - what can be given, can be taken away. APNIC
> >>>>>>>should issue a warning first, followed by removal of IP space from the
> >>>>>>>offending ISP or entity at what ever level. IP addresses are provided
> >>>>>>>under a contract, thus using contract law, removal is possible.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>If the offending entities are using unallocated address blocks, I'm
> >>>>>>not sure what you mean by "removal". Would there be anything to remove
> >>>>>>if allocations were not made in the first place?
> >>>>>>
> >>>>>>I don't quite understand how APNIC can be invloved in this, and how
> >>>>>>effective it would be in addressing the problem. I hope you can
> >>>>>>clarify this a little bit more.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>[Response] - The proposal I have submitted proposes the loss of IP
> >>>>>address space at the point
> >>>>>where routing "drops off" in to "dark space". Let me provide an actual
> >>>>>traceroute. As of a couple
> >>>>>of minutes ago, node 19 222.233.52.27 was still active. That is 6 days
> >>>>>after this traceroute was
> >>>>>taken.
> >>>>>
> >>>>>I received an "Failure to Delivery Notice" for an email that I had not
> >>>>>sent, that was a item of SPAM
> >>>>>that directed the reader to the IP address 222.233.52.27.
> >>>>>
> >>>>>===============
> >>>>> 07/31/04 16:12:27 Fast traceroute 222.233.52.27
> >>>>> Trace 222.233.52.27 ...
> >>>>> 1 10.84.224.1 12ms 13ms 17ms TTL: 0 (No rDNS)
> >>>>> 2 68.2.4.73 11ms 13ms 13ms TTL: 0
> >>>>>(ip68-2-4-73.ph.ph.cox.net ok)
> >>>>> 3 68.2.0.37 14ms 11ms 12ms TTL: 0
> >>>>>(ip68-2-0-37.ph.ph.cox.net ok)
> >>>>> 4 68.2.0.113 12ms 14ms 15ms TTL: 0
> >>>>>(ip68-2-0-113.ph.ph.cox.net ok)
> >>>>> 5 68.2.14.13 14ms 16ms 14ms TTL: 0
> >>>>>(chnddsrc02-gew0303.rd.ph.cox.net ok)
> >>>>> 6 68.1.0.168 14ms 15ms 13ms TTL: 0
> >>>>>(chndbbrc02-pos0101.rd.ph.cox.net ok)
> >>>>> 7 64.154.128.29 17ms 15ms 16ms TTL: 0
> >>>>>(p1-0.hsa1.phx1.bbnplanet.net ok)
> >>>>> 8 4.68.113.253 14ms 17ms 23ms TTL: 0
> >>>>>(so-6-2-0.mp2.Phoenix1.Level3.net ok)
> >>>>> 9 64.159.1.30 25ms 25ms 22ms TTL: 0
> >>>>>(as-0-0.bbr1.LosAngeles1.Level3.net ok)
> >>>>> 10 209.247.9.214 28ms * 25ms TTL: 0
> >>>>>(so-7-0-0.gar1.LosAngeles1.Level3.net ok)
> >>>>> 11 4.68.127.134 25ms 25ms 31ms TTL: 0
> >>>>>(att-level3-oc48.LosAngeles1.Level3.net ok)
> >>>>> 12 12.123.29.2 28ms 27ms 23ms TTL: 0
> >>>>>(tbr1-p014001.la2ca.ip.att.net probable bogus rDNS: No DNS)
> >>>>> 13 12.123.199.185 25ms 23ms 26ms TTL: 0 (No rDNS)
> >>>>> 14 12.119.138.38 25ms 25ms 24ms TTL: 0 (No rDNS)
> >>>>> 15 210.180.97.21 181ms 105ms 161ms TTL: 0 (No rDNS)
> >>>>> 16 211.108.90.2 107ms 162ms 140ms TTL: 0 (No rDNS)
> >>>>> 17 211.108.63.138 145ms 171ms 146ms TTL: 0 (No rDNS)
> >>>>> 18 221.139.106.66 130ms 146ms 145ms TTL: 0 (No rDNS)
> >>>>> 19 222.233.52.27 141ms 145ms 94ms TTL: 49 (No rDNS)
> >>>>>=================
> >>>>>
> >>>>>You will notice that starting with node 15 the address space is un
> >>>>>allocated. Thus the last
> >>>>>legal space rests with node 14 which now has a problem with their
> >>>>>routing tables.
> >>>>>I am proposing that notification be given (in this case) to
> >>>>>12.119.138.38 "holder" to repair their
> >>>>>routing tables. If not acted upon within a reasonable period of time
> >>>>>and possibly a number
> >>>>>of similiar instances, then the "holder" of the 12.0.0.0 -
> >>>>>12.255.255.255 address space loose
> >>>>>their IP assignment. Yes, I am proposing that in this example, the
> >>>>>POSSIBLY that after 7 days of
> >>>>>inaction after being notified, AT&T WorldNet Services would loose their
> >>>>>IP allocation,
> >>>>>if they received their IP allocation from APNIC. In this case they did
> >>>>>not, and that is why I
> >>>>>do understand that this would need to be adopted Internet wide. I am
> >>>>>also interested to see how
> >>>>>long 222.233.52.27 remains active after this email is sent.
> >>>>>
> >>>>>How might this work. There are a number of SPAM services that receive
> >>>>>spam from their users.
> >>>>>They parse the spam extracting the possible originating IP addresses of
> >>>>>the spam, AND the IP addresses
> >>>>>the SPAM is directing the reader to. I am proposing to take the
> >>>>>extracted address the SPAM reader
> >>>>>is sent to, traceroute it, determine the last legal IP address on the
> >>>>>route and send an automated
> >>>>>notification to that service provider, whom ever that may be.
> >>>>>
> >>>>>With respect to the question of "removal" of IP address space, I would
> >>>>>propose the logical loss
> >>>>>of routing to the IP address space in question.
> >>>>>
> >>>>>I hope I have answered your questions.
> >>>>>
> >>>>>Thank you very much,
> >>>>>Gordon
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Izumi
> >>>>>>JPNIC
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Pros/Cons:
> >>>>>>>
> >>>>>>>Pros:
> >>>>>>>By adopting this policy, bandwidth utilization will be reduced.
> >>>>>>>
> >>>>>>>
> >>>>>Criminal
> >>>>>
> >>>>>
> >>>>>>>enterprises will no longer be served.
> >>>>>>>
> >>>>>>>Cons:
> >>>>>>>Disadvantages include new routing tables of increasing complexity
> >>>>>>>to handle the non routing issues associated with dark address space
> >>>>>>>activities and the associated traffic generated.
> >>>>>>>
> >>>>>>>Effect on APNIC:
> >>>>>>>
> >>>>>>>Reduction in bandwidth handled and in it's associated rate of growth.
> >>>>>>>
> >>>>>>>* sig-policy: APNIC SIG on resource management policy
> >>>>>>>
> >>>>>>>
> >>>>> *
> >>>>>
> >>>>>
> >>>>>>>_______________________________________________
> >>>>>>>sig-policy mailing list
> >>>>>>>sig-policy at lists dot apnic dot net
> >>>>>>>http://mailman.apnic.net/mailman/listinfo/sig-policy
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>______________________________________________________________________
> >>>>>
> >>>>>Samantha Dickinson, Technical Editor <sam at apnic dot net>
> >>>>>Asia Pacific Network Information Centre ph +61 7 3858 3100
> >>>>>http://www.apnic.net fx +61 7 3858 3199
> >>>>>______________________________________________________________________
> >>>>>
> >>>>>
> >>>>* sig-policy: APNIC SIG on resource management
> >>>>
> >>>>
> >>>policy *
> >>>
> >>>
> >>>>_______________________________________________
> >>>>sig-policy mailing list
> >>>>sig-policy at lists dot apnic dot net
> >>>>http://mailman.apnic.net/mailman/listinfo/sig-policy
> >>>>
> >>>>
> >>>>
> >>>>
> >>>* sig-policy: APNIC SIG on resource management
> >>>policy *
> >>>_______________________________________________
> >>>sig-policy mailing list
> >>>sig-policy at lists dot apnic dot net
> >>>http://mailman.apnic.net/mailman/listinfo/sig-policy
> >>>
> >>>
> >>* sig-policy: APNIC SIG on resource management policy *
> >>_______________________________________________
> >>sig-policy mailing list
> >>sig-policy at lists dot apnic dot net
> >>http://mailman.apnic.net/mailman/listinfo/sig-policy
> >>
> >>
> >
> >Regards,
> >
> >--
> >Jeffrey A. Williams
> >Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> >"Be precise in the use of words and expect precision from others" -
> > Pierre Abelard
> >
> >"If the probability be called P; the injury, L; and the burden, B;
> >liability depends upon whether B is less than L multiplied by
> >P: i.e., whether B is less than PL."
> >United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
> >===============================================================
> >Updated 1/26/04
> >CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> >IDNS. div. of Information Network Eng. INEG. INC.
> >E-Mail jwkckid1 at ix dot netcom dot com
> > Registered Email addr with the USPS
> >Contact Number: 214-244-4827
> >
> >
> >* sig-policy: APNIC SIG on resource management policy *
> >_______________________________________________
> >sig-policy mailing list
> >sig-policy at lists dot apnic dot net
> >http://mailman.apnic.net/mailman/listinfo/sig-policy
> >
> >
> >
Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
Pierre Abelard
"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng. INEG. INC.
E-Mail jwkckid1 at ix dot netcom dot com
Registered Email addr with the USPS
Contact Number: 214-244-4827