[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sig-policy] Forwarded reply from Gordon Bader
Dear secretariat, Gordon and all,
As many here have seen and/or observed the addressing policy
making procedure is terribly flawed on several fronts have been
discussed and debated on this forum. Of course as with ARIN's
addressing allocation and routing policy making of years past,
it is as you pointed out with your AT&T example below repeating
those bad decisions yet again and adding Ipv6 addressing policy
to these already historically noted and known decisions.
It is and remains still obvious that effecting good routing table
maintenance practice or policy is not likely to be in effect any time
soon until or unless a real measured consensus is determined.
APNIC Secretariat wrote:
> 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@cox.net>
> >To: Izumi Okutani <izumi@nic.ad.jp>
> >CC: secretariat@apnic.net, sig-policy@apnic.net, sig-policy-chair@apnic.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@apnic.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@cox.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@cox.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@lists.apnic.net
> > >>http://mailman.apnic.net/mailman/listinfo/sig-policy
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
> >
> >______________________________________________________________________
> >
> >Samantha Dickinson, Technical Editor <sam@apnic.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@lists.apnic.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@ix.netcom.com
Registered Email addr with the USPS
Contact Number: 214-244-4827
