[arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

Bill Buhler bill at tknow.com
Fri Mar 28 12:57:44 EDT 2014


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: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of CJ Aronson
Sent: Friday, March 28, 2014 10:54 AM
To: David Huberman
Cc: arin-ppml at arin.net
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 <cja at daydream.com<mailto:cja at daydream.com>> 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 <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> 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:farmer at umn.edu<mailto:farmer at umn.edu>]
Sent: Thursday, March 27, 2014 11:43 AM
To: David Huberman; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
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: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>]
> On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> 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: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815<tel:1-612-626-0815>
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<tel:1-612-812-9952> ================================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/f52afa8c/attachment-0001.html>


More information about the ARIN-PPML mailing list