Re: [sig-policy] Forwarded reply from Gordon Bader
Please don't worry, I know that Japanese names are difficult to figure
out male or female:-)
Izumi
From: GB <gbader at cox dot net>
Subject: Re: [sig-policy] Forwarded reply from Gordon Bader
Date: Mon, 16 Aug 2004 06:35:50 -0700
> Hello Izumi,
>
> I would like to sincerely apologize to you, for addressing you in a
> prior responses as Mr.Okutani. I did not realize and I did it out of
> habit. Obviously my Japanese is not nearly as polished as your English.
>
> Again, my apologies.
>
> With warm regards,
> Gordon
>
> Izumi Okutani wrote:
>
> >Thanks for the clarification Philip.
> >
> >OK, I see that this proposal would not be effective unless it is
> >implemented globally, i.e, should be applied to NIR communities as
> >well.
> >
> >I am currently seeking for comments on our ML as well, so get back to
> >this ML with more comments.
> >
> >Izumi
> >JPNIC
> >
> >From: Philip Smith <pfs at cisco dot com>
> >Subject: Re: [sig-policy] Forwarded reply from Gordon Bader
> >Date: Mon, 16 Aug 2004 09:54:21 +1000
> >
> >
> >
> >>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
> >
> >
> >
>
>
>