No, they were announcing less specific BGP prefixes. So they only got traffic for legitimate blocks when there was an interruption in the announcement of the more specific.
Scott > On Mar 28, 2014, at 9:57 AM, Bill Buhler <[email protected]> wrote: > > So if my understanding is correct, they basically performed a routing man in > the middle attack on live IPv6 prefixes. Pardon my understanding level, but > how did they keep from creating routing loops and service interruptions. I’m > also a little concerned about performance and link loads. Are my concerns > legitimate and inline? > > Thanks, > > --Bill > > From: [email protected] [mailto:[email protected]] On > Behalf Of CJ Aronson > Sent: Friday, March 28, 2014 10:54 AM > To: David Huberman > Cc: [email protected] > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy > > I read some more of that article I sent. They specifically state that they > had LOAs from the RIRs to do these /12 advertisements. > > Thanks! > -----Cathy > > > On Fri, Mar 28, 2014 at 4:49 PM, CJ Aronson <[email protected]> wrote: > There is a paper here > http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf > > that says > "We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12, > 2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we > also announced RIPE’s 2a00::/12" > So I believe that the answer to your question is yes. > > -----Cathy > > > > On Fri, Mar 28, 2014 at 4:32 PM, David Huberman > <[email protected]> wrote: > David: > > That summary of the issue helps a lot, thank you! > > The question on my mind is: > Did ARIN provide a written LOA to Merit to announce 2600::/12 ? > > David R Huberman > Microsoft Corporation > Senior IT/OPS Program Manager (GFS) > > -----Original Message----- > From: David Farmer [mailto:[email protected]] > Sent: Thursday, March 27, 2014 11:43 AM > To: David Huberman; [email protected] > Cc: David Farmer > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy > > I'm the primary shepherd for this Draft; > > The author is Heather Schiller, and I'm only saying that because I'm going to > reference you to her comments at the mic at the last NANOG. > > The research that prompted the proposal was presented at the last NANOG in > Atlanta and is at the following link; > > https://www.nanog.org/meetings/abstract?id=2289 > > Heather's comments begins at about time stamp 17:10 or so on the video of the > NANOG presentation, and there are a couple other comments as well. > > Additionally, the reference for the published paper for the research in > question is; > > http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf > > Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING > DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS > > https://www.arin.net/participate/acsp/suggestions/2014-3.html > > [Shepherd hat - OFF] > > While I do not have a problem with this research and I don't think we should > restrict future such activities, I believe this is something the community > should discuss in detail and try to come to consensus on, one way or the > other. > > Also, while I disagree with the proposed policy text, what is proposed is not > without precedent. As discussed in the NANOG presentation, RIPE initially > gave permission for a covering prefix for its whole /12 and then it was > modified to a covering prefixes of a /14 plus a /13, excluding the space > where most allocations were. This significantly reduced the amount of > traffic for RIPE region and they were excluded from the analysis. > > Hope that helps. > > On 3/26/14, 21:55 , David Huberman wrote: > > Hi PPML, > > > > Can someone show me where in the mailing list archives this policy was > > actively discussed on PPML? I can't find it. > > > > Alternatively, can the policy author or someone who strongly supports this > > policy please either post to the list or email me privately and clue me in? > > I issued and managed almost every experimental assignment for almost 10 > > years from 2003 to 2013, and I am lost as to what this policy is saying. I > > would like to be educated so I can support, or not support, the efforts > > that have been made here. > > > > Thank you! > > /david > > > > David R Huberman > > Microsoft Corporation > > Senior IT/OPS Program Manager (GFS) > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > On Behalf Of ARIN > > Sent: Tuesday, March 25, 2014 11:28 AM > > To: [email protected] > > Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy > > > > On 20 March 2014 the ARIN Advisory Council (AC) accepted > > "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy. > > > > Draft Policy ARIN-2014-12 is below and can be found at: > > https://www.arin.net/policy/proposals/2014_12.html > > > > You are encouraged to discuss the merits and your concerns of Draft Policy > > 2014-12 on the Public Policy Mailing List. > > > > The AC will evaluate the discussion in order to assess the conformance of > > this draft policy with ARIN's Principles of Internet Number Resource Policy > > as stated in the PDP. Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The ARIN Policy Development Process (PDP) can be found at: > > https://www.arin.net/policy/pdp.html > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/policy/proposals/index.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Draft Policy ARIN-2014-12 > > Anti-hijack Policy > > > > Date: 25 March 2014 > > > > Problem Statement: > > > > ARIN should not give research organizations permission to hijack prefixes > > that have already been allocated. Research organizations announcing lit > > aggregates may receive sensitive production traffic belonging to live > > networks during periods of instability. > > > > Section 11.7 describes more than allocation size therefore updating the > > section heading to something more accurate is appropriate. > > > > Policy statement: > > > > Modify the section 11.7 heading to be more accurate. Modify the first > > sentence to prohibit overlapping assignments. Add text at the end to define > > how research allocations should be designated and prohibit LOA's without > > allocations. > > > > 11.7 Resource Allocation Guidelines > > > > The Numbering Resources requested come from the global Internet Resource > > space, do not overlap previously assigned space, and are not from private > > or other non-routable Internet Resource space. The allocation size should > > be consistent with the existing ARIN minimum allocation sizes, unless small > > allocations are intended to be explicitly part of the experiment. If an > > organization requires more resource than stipulated by the minimum > > allocation sizes in force at the time of their request, their experimental > > documentation should have clearly described and justified why this is > > required. > > > > All research allocations must be registered publicly in whois. Each > > research allocation will be designated as a research allocation with a > > comment indicating when the allocation will end. ARIN will not issue a > > Letter of Authority (LOA) to route a research prefix unless the allocation > > is properly registered in whois. > > > > Comments: > > a. Timetable for implementation: Immediate b. Anything else: > > -- > ================================================ > David Farmer Email: [email protected] > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
