At 16:02 10/08/2004 +0900, Izumi Okutani wrote:
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.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.
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