[arin-ppml] Closing the reassignments to multihomed downstream customers loophole

[Scott Leibrand]

In the Policy Experience report at ARIN XXIX in Vancouver (
https://www.arin.net/participate/meetings/reports/ARIN_XXIX/PPT/tuesday/nobile_policy_experience.pptxor
https://www.arin.net/participate/meetings/reports/ARIN_XXIX/PDF/tuesday/nobile_policy_experience.pdf),
Leslie identified a:

Potential loophole where customers can game the system:
>
>    - Set up two OrgIDs
>    - Get an ASN for each
>    - Issue every customer a /24 and claim the two companies they control
>    are the upstream providers  for each customer
>
> Basically an org who wants to sell a /24 as part of a service plan can do
> so, and still be in compliance with policy, even though their customer has
> no ASN or router and is not really multihomed


Her report also suggested a fix, which was discussed during the Q&A.  Based
on that discussion, I modified the suggested language and came up with the
following:

In NRPM 4.2.3.6 (https://www.arin.net/policy/nrpm.html#four236):


Insert "Downstream customer must have or qualify for their own ASN, and the
customer (or both ISPs) must intend to originate a BGP route announcement
for the /24 to their BGP neighbors." prior to "Customers may receive a /24
from only one of their upstream providers under this policy without
providing additional justification."


Change the following sentence to read "ISPs may demonstrate they have made
an assignment to a downstream customer under this policy by supplying ARIN
with the information they collected from the customer, as described above,
and by identifying the AS number(s) that will be originating the /24.


The idea is to require all ISP customers' making use of this policy to
qualify for (but not necessarily receive) an ASN, and to require that they
(or their ISPs, in rare cases) originate and announce the /24 into BGP.  I
think that would be sufficient to close the loophole without preventing
legitimate non-BGP customers from getting a /24 for their ISPs to announce.

I heard several people say at the microphone in Vancouver that this was a
real problem they'd like to see addressed.  Do you agree?  Do you think
this language addresses it?  Do you see any possible unintended side
effects?  Is there anything you'd like to see changed about this language?

If anyone thinks this would be a useful change, I'll be happy to submit it
as a policy proposal.  Alternately, if anyone else is interested in the
issue and would like to be the policy proposal's originator, I could help
as one of the AC shepherds instead.

Any other thoughts, questions, or concerns?

Thanks,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120429/21c89573/attachment.htm>