[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sig-policy] Forwarded reply from Gordon Bader
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@apnic.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@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
> > >
> > >
> >
> >* 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
>
> * 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
