[arin-ppml] ULA-C

[David Farmer]

Michael Richardson wrote:

>     David> 7. ULA-C, even with a global well-known prefix, is just
>     David> another 128bit integer, there is nothing fundamentally
>     David> different about it, than PA or PI.  In fact, with registered
>     David> uniqueness, reverse DNS, and maybe even RPKI in the future,
>     David> the only practical difference between ULA-C and PI is the
>     David> non-routed property, applied realistically only by
>     David> convention. There is one possible other difference, random
>     David> prefix selection.  While this could help prevent some kinds
>     David> of abuse, I'm not sure this would provide much practical
>     David> deterrence in using ULA-C as a substitute for PI. Which I
>     David> believe is the primary abuse path of concern.
> 
> I put no value on the randomness, but I do not object to it, but that's
> not the crux of your point. (Scanning the lower /64 bits is sufficient
> randomness for me)

Yep, I don't care either way too. But there is one thing random 
assignment from the full ULA-C prefix would accomplish; it would prevent 
someone from easily accepting ARIN's ULA-C assignments and not the other 
RIR's ULA-C assignments.  And preventing it from becoming a regional PI 
substitute.  Is this worth the hassle?  I don't know.

> RPKI) I don't see why RPKI certificates would be issued for ULA-C space.
>       If they were, it would be for completeness, and would specify a
>       non-existant/reserved/invalid ASN.  This itself would provide an
>       additional hurdle against leakage.
>       
>       If RPKI was legitimately issued, it would be issued, in my
>       opinion, from a different CA. Most likely anyone that needed RPKI
>       for their ULA-C would be running their own CA.  My opinion (as a
>       security geek), is that running your own CA exceeds the cost of
>       getting PI space!!

I don't want to derail things with a discussion of RPKI for ULA-C, there 
are many different ways to deal with it I'm not sure what the right 
answers are.  But just like I think those that want Authoritative 
Reverse DNS for ULA-C should be able to get it, if someone wants an RPKI 
certificate from ARIN for their ULA-C assignment, why not?  And it is 
yet another reason to have the RIR's do ULA-C assignment.  ULA-C is just 
more of the same of what the RIRs do now.

>     David> Therefore, I believe the concerns about ULA-C becoming a path
>     David> for policy abuse cannot be completely discounted.  However,
>     David> in reality the risk is no where near as large as some are
>     David> claiming.  Further, I believe this risk can be easily managed
>     David> via the RIRs' number resource policy processes, if the RIRs
>     David> were to be given full policy control of ULA-C registrations.
> 
> I agree --- there could be abuse.
> Rather than overconstrain ourselves in advance, is there nothing we can
> do on a complaint basis?

Where do those complaints go? How do we resolve disputes? For PA and PI 
essentially that is dealt within the policy development processes for 
the RIRs. That is how we hash things out as a community, it seems 
logical to use the same processes for ULA-C.

But, I'm open to other ideas.

>     David> I believe, the stewardship the RIRs provide is necessary, and
>     David> the RIRs' policy processes can properly manage the risk.  As
>     David> for cost, while not a policy matter, in the shorter-term
>     David> ULA-C is not going to be as cost effective as some would
>     David> hope.  However, if in the longer-term the risks can be
>     David> managed, then I have to believe that the RIRs will do the
>     David> right thing.
> 
>     David> So, is some kind of compromise between the opposing camps
>     David> possible? Otherwise, I fear this is going to continue to be a
>     David> pointless shouting match.
> 
> I can deal with these statements. They *do* represent a compromise to
> me.
> 
> Michael Dillon?
> Bill Herrin?

I'm interested in what others think, is this a compromise we can all 
live with?

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================