Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-30 Thread Aftab Siddiqui
Hi Job,


> On Thu, Aug 22, 2019 at 11:52:13AM +0600, Sumon Ahmed Sabir wrote:
> > A new version of the proposal "prop-132: AS0 for Bogons"
> > has been sent to the Policy SIG for review.
> >
> > Information about earlier versions is available from:
> > http://www.apnic.net/policy/proposals/prop-132
>
> Attached is a rewrite of prop-132-v002 ('prop-132-v003.txt') where the
> word "bogon" has been mostly replaced with (in my mind) more descriptive
> terms.
>
> The reason for wording things a bit different is that when I first heard
> about this proposal I thought the idea was to create ROAs for bogons
> such as RFC 1918 space, and thought "THEY WHAT NOW?!" :-)



> If we think in Venn diagrams, indeed, "bogons" contain all "unallocated
> and unassigned APNIC address space", and "unallocated and unassigned
> APNIC address space" are "bogons", but "bogons" to many operators means
> much more than just the APNIC managed portion of it.
>
> A clear advantage of ensuring unassigned or unallocated address space is
> not in use by unauthorized parties is that such address space can be
> assigned to eligible APNIC members instead. This proposal may (slightly)
> increase the pool of available IP address space for the APNIC community.
>

actually, you are not the only one, many (off list+on list) shared the same
opinion and then I had to explain Bogon to them (exactly as you explained
in second para) :) somewhere during the initial discussion of this proposal
there were some points about bogons vs martians and sometimes the terms are
confusing as well to operators as they use it differently, I agree.

Your edits are providing clear description, I will accomodate in the v3.
Thanks.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-30 Thread Job Snijders
On Fri, Aug 30, 2019 at 03:55:00PM +0200, Job Snijders wrote:
> As of now, there are XXX IPv4 and YYY IPv6 routes in the global Internet
> routing table which cover address space managed by APNIC [snip]

I took today's delegated-apnic-extended-latest file, grepped for
'available|reserved', converted the IP count to prefix lengh and looked
for exact or more specifics matches in the BGP Default-Free Zone.

In summary, about 95 IPv4 BGP routes and 24 IPv6 BGP routes exist in the
DFZ which appear to be unallocated/unassigned and are managed by APNIC. 

Below is the list of these prefixes and the AS_PATH towards the
originator (from my ASN's perspective). In principle we shouldn't be
accepting the below BGP announcements from anyone, because the operator
from the originating ASN perhaps has failed to pay APNIC, or decided to
just take some IP space without consulting the RIR, or whatever.

If the community *wants* to nuke the below BGP announcements from orbit,
I'd recommend to adopt this policy proposal to allow APNIC to create
ROAs with Origin AS 0. The space can afterwards be reassigned to APNIC
members.

If the community does *not* want these BGP announcements to disappear
from the Internet (as a consequence of actions by APNIC), then oppose
this proposal.

It would be interesting if someone can share spam or abuse metrics for
the below address space. That may help us get an idea of whether the
below address space belongs to legit organisations and is the result of
unfortunate circumstances, or was whether the space was stolen by bad
actors and is used for spam/hacking. 

Kind regards,

Job

Unassigned / Unallocated APNIC managed address space in the DFZ:

27.100.7.0/2445629 45455 56096
27.126.156.0/22  3257 7473 9930 55827
27.126.156.0/23  3257 7473 9930 55827
27.126.158.0/23  3257 7473 9930 55827
43.229.16.0/22   64050 136800
45.115.16.0/24   6453 4755 45820 132933
45.115.18.0/24   6453 4755 45820 132933
45.115.19.0/24   6453 4755 45820 132933
45.252.236.0/22  15412 4826 38803
49.213.32.0/24   6453 4755 45820 132933
49.213.33.0/24   6453 4755 45820 132933
49.213.34.0/24   6453 4755 45820 132933
49.213.35.0/24   6453 4755 45820 132933
49.213.36.0/24   6453 4755 45820 132933
49.213.37.0/24   6453 4755 45820 132933
49.213.38.0/24   6453 4755 45820 132933
49.213.39.0/24   6453 4755 45820 132933
49.213.40.0/24   6453 4755 45820 132933
49.213.41.0/24   6453 4755 45820 132933
49.213.42.0/24   6453 4755 45820 132933
49.213.43.0/24   6453 4755 45820 132933
49.213.44.0/24   6453 4755 45820 132933
49.213.45.0/24   6453 4755 45820 132933
49.213.46.0/24   6453 4755 45820 132933
49.213.47.0/24   6453 4755 45820 132933
49.213.48.0/24   6453 4755 45820 132933
49.213.49.0/24   6453 4755 45820 132933
49.213.50.0/24   6453 4755 45820 132933
49.213.52.0/24   6453 4755 45820 132933
49.213.53.0/24   6453 4755 45820 132933
49.213.54.0/24   6453 4755 45820 132933
49.213.55.0/24   6453 4755 45820 132933
49.213.56.0/24   6453 4755 45820 132933
49.213.57.0/24   6453 4755 45820 132933
49.213.58.0/24   6453 4755 45820 132933
49.213.59.0/24   6453 4755 45820 132933
49.213.62.0/24   6453 4755 45820 132933
49.213.63.0/24   6453 4755 45820 132933
103.8.194.0/24   9498 135754 135754 135754 135754
103.8.195.0/24   9498 135754 135754 135754 135754
103.12.76.0/22   9304 133731 133731
103.18.188.0/24  6453 7545 2764 63850
103.24.227.0/24  9269 10103 38186
103.48.20.0/22   64050 136800
103.51.102.0/24  9498 15084
103.51.128.0/24  6453 4755 15084
103.83.29.0/24   6762 9498 58678
103.84.168.0/22  2497 17511 17511
103.84.196.0/22  2497 17511 17511
103.85.133.0/24  3491 55410 55410 133664 133664 133011 136285
103.119.170.0/23 6762 49666 48159 55330 138001
103.120.78.0/23  6453 7545 9749
103.209.220.0/24 15412 18101 132215 132323 134895
103.209.221.0/24 15412 18101 132215 132323 134895
103.209.222.0/24 15412 18101 132215 132323 134895
103.209.223.0/24 9498 132215 132215 132215 132215 132215 132215 132215 
132215 132323 134895
103.247.80.0/24  6453 4755 45820 132933
103.247.81.0/24  6453 4755 45820 132933
103.247.82.0/24  6453 4755 45820 132933
103.247.83.0/24  6453 4755 45820 132933
103.249.226.0/24 6762 9498 45154 45154
103.253.100.0/22 10013 4686
110.172.24.0/24  6453 4755 45820 132933
110.172.25.0/24  6453 4755 45820 132933
110.172.26.0/24  6453 4755 45820 132933
110.172.27.0/24  6453 4755 45820 132933
110.172.28.0/24  6453 4755 45820 132933
110.172.29.0/24  6453 4755 45820 132933
110.172.30.0/24  6453 4755 45820 132933
110.172.31.0/24  6453 4755 45820 132933
116.199.200.0/24 1299 58552 56246
116.199.201.0/24 1299 58552 56246
116.199.202.0/24 1299 58552 56246
116.199.203.0/24 1299 58552 56246
116.199.204.0/24 1299 58552 56246
116.199.205.0/24 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-30 Thread Owen DeLong
>> We're consulting our experts to provide a response to your query soon. 
>> Please allow us sometime.
>> 
>> Regards
>> Sunny
>> 
>> On 24/08/2019 12:28 am, Javed Khan wrote:
>>> For now, I'm neither for or against this proposal. I think the 
>>> intention of the author is good but the implementation is not as easy 
>>> as is explained in the proposal. QoS is very crucial for ISPs to 
>>> sustain the fierce market competition and if APNIC fails to timely 
>>> update the AS0 ROAs, this will effect the service delivery and/or 
>>> network downtime.
>>> 
>>> I request APNIC to provide a detailed review of this proposal from a 
>>> service and legal perspective so the community can better understand 
>>> the implementation, if this proposal reaches consensus.
>>> 
>>> 
>>> Kind regards
>>> Javed Khan
>>> MSCE and CCSP
>>> 
>>> 
>>> 
>>> *From:* sig-policy-boun...@lists.apnic.net 
>>>  on behalf of David Farmer 
>>> 
>>> *Sent:* Friday, 23 August 2019 10:48 AM
>>> *To:* Aftab Siddiqui 
>>> *Cc:* Sumon Ahmed Sabir ; Policy SIG 
>>> 
>>> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>> 
>>> 
>>> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
>>> mailto:aftab.siddi...@gmail.com>> wrote:
>>> 
>>> Hi David,
>>> 
>>> 
>>> On Fri, Aug 23, 2019 at 6:36 AM David Farmer >> <mailto:far...@umn.edu>> wrote:
>>> 
>>> The problem statement says;
>>> 
>>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons")
>>> is a packet
>>> with an IP source address in an address block not yet
>>> allocated by IANA
>>> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC,
>>> AFRINIC and
>>> LACNIC)...
>>> 
>>> 
>>> So that raises a question, what about resources that are
>>> deregisterd because they are returned, revoked, or otherwise
>>> reclaimed, for any of a myriad of reasons, including non-payment
>>> of fees? Do they become Bogons with AS0 ROAs the moment they are
>>> deregistered? Later, if so when? What if there is a ROA for them
>>> in the system? Are the ROAs removed, if so when?
>>> 
>>> 
>>> I also had some concerns about revoked and/or reclaimed space and
>>> closed account due to non payment so I asked Secretariat in advance
>>> and here is the response.
>>> ===
>>> APNIC membership account is classified as closed when its status is
>>> flagged as ‘closed’ in APNIC’s internal system.
>>> 
>>> 30 days - payment period upon issuance of invoice, if no payment is
>>> received within this period member receives expiry notice and the
>>> account status becomes 'suspended'
>>> After 15 days – member receives email notification for closure
>>> giving them another 15 days to pay
>>> After 15 days – the status of the account becomes 'closed' and all
>>> delegated resources under the account are reclaimed
>>> 
>>> All in all members have 60 days period to pay before the status of
>>> the account becomes ‘closed’.
>>> ===
>>> 
>>> As long as the account is suspended APNIC doesn't consider those
>>> resources as free/available/reclaimed and because they are not part
>>> of unallocated pool thats why no need to create AS0 ROAs for such
>>> resources. AS0 ROAs will be created once APNIC mark those resources
>>> available and remove them from their delegation record. Now, the
>>> second issue is if there is a ROA for them in the system. Because AS
>>> 0 ROA has a lower relative preference than any other ROA that has a
>>> routable AS then APNIC has to somehow delete the existing ROA from
>>> the system. Its easy if the member account is closed and all
>>> resources are reclaimed. But I leave this to APNIC to decide how
>>> they are going to make that happen.
>>> 
>>> 
>>> Currently, when the account is closed nothing actively makes the 
>>> resources unusable, accept for if you were also changing providers 
>>> durin

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-30 Thread Job Snijders
Dear all,

I've reviewed the proposal, and while I haven't yet made up my mind
whether this is a good or bad idea, I do want to propose some changes
to the text because the current wording introduces some confusion in my
operator mind.

On Thu, Aug 22, 2019 at 11:52:13AM +0600, Sumon Ahmed Sabir wrote:
> A new version of the proposal "prop-132: AS0 for Bogons"
> has been sent to the Policy SIG for review.
> 
> Information about earlier versions is available from:
> http://www.apnic.net/policy/proposals/prop-132

Attached is a rewrite of prop-132-v002 ('prop-132-v003.txt') where the
word "bogon" has been mostly replaced with (in my mind) more descriptive
terms.

The reason for wording things a bit different is that when I first heard
about this proposal I thought the idea was to create ROAs for bogons
such as RFC 1918 space, and thought "THEY WHAT NOW?!" :-)

If we think in Venn diagrams, indeed, "bogons" contain all "unallocated
and unassigned APNIC address space", and "unallocated and unassigned
APNIC address space" are "bogons", but "bogons" to many operators means
much more than just the APNIC managed portion of it.

A clear advantage of ensuring unassigned or unallocated address space is
not in use by unauthorized parties is that such address space can be
assigned to eligible APNIC members instead. This proposal may (slightly)
increase the pool of available IP address space for the APNIC community.

Kind regards,

Job
--

prop-132-v003: RPKI ROAs for unallocated and unassigned APNIC address space 

--

Proposer: Aftab Siddiqui
  aftab.siddi...@gmail.com


1. Problem statement

Address space managed by APNIC which has is either "Unallocated" or
"Unassigned" is considered "Bogon address space". Bogons are defined in
RFC3871, A "Bogon" (plural: "bogons") is a packet with an IP source address in
an address block not yet allocated by IANA or the Regional Internet Registries
(ARIN, RIPE NCC, APNIC, AFRINIC and LACNIC) as well as all addresses reserved
for private or special use by RFCs.

As of now, there are XXX IPv4 and YYY IPv6 routes in the global Internet
routing table which cover address space managed by APNIC, but which is not
allocated or assigned by APNIC. In the past, several attempts have been made
to filter out such bogons through various methods such as static filters and
updating them occasionally but it is hard to keep an up to date filters,
TeamCymru and CAIDA provides full bogon list in text format to update such
filters. TeamCymru also provides bogon BGP feed where they send all the bogons
via a BGP session which then can be discarded automatically. Despite these
attempts, the issue of unauthorized adverisments of APNIC's address space
hasn't be resolved so far.

2. Objective of policy change
-
The purpose of creating RPKI ROAs with Origin AS 0 for APNIC's unallocated and
unassigned address space is to restrict the propagation of BGP announcements
covering such bogon space. When APNIC issues a ROA with AS 0 for unallocated
address space under APNIC's administration, BGP announcements covering this
space will be marked as Invalid by networks doing RPKI based BGP Origin
Validation using APNIC's TAL.

Currently, in the absence of any ROA, these bogons are marked as NotFound.
Since many operators have implemented ROV and either planning or already
discarding Invalid, then all the AS0 ROAs which APNIC will create for
unallocated address space will be discarded as well.

3. Situation in other regions
-
No such policy in any region at the moment.

4. Proposed policy solution
---
APNIC will create AS0 (zero) ROAs for all the unallocated and unassigned
address space (IPv4 and IPv6) for which APNIC is the current administrator. Any
resource holder (APNIC member) can create AS0 (zero) ROAs for the resources
they have under their account/administration.

A RPKI ROA is a positive attestation that a prefix holder has authorised an AS
to originate a route for this prefix whereas, a RPKI ROA for the same prefixes
with AS0 (zero) origin shows negative intent from the resource holder that they
don't want to advertise the prefix(es) at this point but they are the rightful
custodian.

Only APNIC has the authority to create RPKI ROAs for address space not yet
allocated to the members and only APNIC can issue AS0 (zero) RPKI ROAs. Once
they RPKI ROA is issued and APNIC wants to allocate the address space to its
member, simply they can revoke the RPKI ROA and delegate the address space to
members. (this proposal doesn't formulate operational process).

5. Advantages / Disadvantages
-
Advantages:

Network operators who implement RPKI based Origin Validation and discard BGP
announcements with RPKI state "invalid", will automatically discard BGP

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-30 Thread Job Snijders
Dear all,

I've yet to make up my mind about this proposal, but I wanted to point
out an error in the interpretation of how RPKI based BGP Origin
Validation works.

On Wed, Aug 28, 2019 at 04:04:25PM -0700, Owen DeLong wrote:
> > On Aug 28, 2019, at 13:44 , Aftab Siddiqui  wrote:
> > On Thu, 29 Aug 2019 at 6:33 am, Javed Khan  > > wrote:
> > We may think we are living in a perfect world but we are not.
> > 
> > of course 
> > 
> > With this proposal I'm more worried about the network downtime as
> > managing an AS0 ROA by an RIR may be prone to errors as we all do
> > regardless if its a manual or automated solution.
> > 
> > Would you like to explain how AS0 ROA can create network downtime? 
> 
> One possible way I can think of (I’m sure there are others)…
> 
> ISP Q is issued 2001:db8::/32 by APNIC.
> 
> ISP Q does not participate in RPKI and does not create ROAs.
> 
> APNIC accidentally issues an incorrect AS 0 ROA for
> 2001:db8:8000::/33, taking down some fraction (up to half) of ISP Q’s
> customers and possibly their infrastructure.

Correction:

In the above example, if ISP Q announces 2001:db8::/32 in the BGP
Default-Free Zone, the presence (or absense) of a ROA covering only
2001:db8:8000::/33 (or longer) will not influence the propagation of the
2001:db8::/32.

Should APNIC create a ROA "2001:db8:8000::/33, maxlength 128, origin AS
0" this ROA will *not* take down some fraction of ISP Q's customers. A
ROA covering only a *fraction* of a covering "VALID" or "UNKNOWN" BGP
announcement does not influence said covering BGP route.

Now, it's of course another story if APNIC creates an AS 0 ROA for
2001:db8::/32, or if ISP Q wants to announce 2001:db8:8000::/33 for
traffic-engineering reasons.

ROAs only influence BGP announcements where the NLRI in the BGP UPDATE
is an exact match, or where the BGP NLRI is a more-specific of the ROA.
Not the other way around.

Kind regards,

Job
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-29 Thread Aftab Siddiqui
t; service and legal perspective so the community can better understand
> >> the implementation, if this proposal reaches consensus.
> >>
> >>
> >> Kind regards
> >> Javed Khan
> >> MSCE and CCSP
> >>
> >>
> >> 
> >> *From:* sig-policy-boun...@lists.apnic.net
> >>  on behalf of David Farmer
> >> 
> >> *Sent:* Friday, 23 August 2019 10:48 AM
> >> *To:* Aftab Siddiqui 
> >> *Cc:* Sumon Ahmed Sabir ; Policy SIG
> >> 
> >> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
> >>
> >>
> >> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui
> >> mailto:aftab.siddi...@gmail.com>> wrote:
> >>
> >> Hi David,
> >>
> >>
> >> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  >> <mailto:far...@umn.edu>> wrote:
> >>
> >> The problem statement says;
> >>
> >> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons")
> >> is a packet
> >> with an IP source address in an address block not yet
> >> allocated by IANA
> >> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC,
> >> AFRINIC and
> >> LACNIC)...
> >>
> >>
> >> So that raises a question, what about resources that are
> >> deregisterd because they are returned, revoked, or otherwise
> >> reclaimed, for any of a myriad of reasons, including non-payment
> >> of fees? Do they become Bogons with AS0 ROAs the moment they are
> >> deregistered? Later, if so when? What if there is a ROA for them
> >> in the system? Are the ROAs removed, if so when?
> >>
> >>
> >> I also had some concerns about revoked and/or reclaimed space and
> >> closed account due to non payment so I asked Secretariat in advance
> >> and here is the response.
> >> ===
> >> APNIC membership account is classified as closed when its status is
> >> flagged as ‘closed’ in APNIC’s internal system.
> >>
> >> 30 days - payment period upon issuance of invoice, if no payment is
> >> received within this period member receives expiry notice and the
> >> account status becomes 'suspended'
> >> After 15 days – member receives email notification for closure
> >> giving them another 15 days to pay
> >> After 15 days – the status of the account becomes 'closed' and all
> >> delegated resources under the account are reclaimed
> >>
> >> All in all members have 60 days period to pay before the status of
> >> the account becomes ‘closed’.
> >> ===
> >>
> >> As long as the account is suspended APNIC doesn't consider those
> >> resources as free/available/reclaimed and because they are not part
> >> of unallocated pool thats why no need to create AS0 ROAs for such
> >> resources. AS0 ROAs will be created once APNIC mark those resources
> >> available and remove them from their delegation record. Now, the
> >> second issue is if there is a ROA for them in the system. Because AS
> >> 0 ROA has a lower relative preference than any other ROA that has a
> >> routable AS then APNIC has to somehow delete the existing ROA from
> >> the system. Its easy if the member account is closed and all
> >> resources are reclaimed. But I leave this to APNIC to decide how
> >> they are going to make that happen.
> >>
> >>
> >> Currently, when the account is closed nothing actively makes the
> >> resources unusable, accept for if you were also changing providers
> >> during this timeframe, then when the new provider checks the resources
> >> they will be unregistered. But most providers don't recheck the
> >> registration of resources very often, if ever, other than at the time
> >> of setup of service.
> >>
> >> With this proposal at some point, the resource will effectively become
> >> unusable with nonpayment, when the AS0 ROA is created, and any ROAs
> >> are removed, I'm fine with this, but it should be called out as a
> >> consequence of the proposal, so no one can say they didn't realize
> >> that is a consequence of the proposal.
> >>
> >> This 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-29 Thread Srinivas Chendi
Hi all,

If this proposal reaches consensus and endorsed by the APNIC EC, this is 
how we would implement the policy.

**Creation of AS0 (Zero) ROA
- Based on the publicly available “delegated-apnic-extended-latest” 
stats file at https://ftp.apnic.net/stats/apnic/
- All resources (IPv4 and IPv6) flagged as “Available” and “Reserved” 
will be added to the AS0 ROA.
- On average 15 records are updated in the 
“delegated-apnic-extended-latest" file daily.
- AS0 ROA will be updated at the same time as resource (IPv4 and IPv6) 
delegation to exclude these prefixes.
- Relying party will see the changes when the propagation of updated AS0 
ROA is completed and this may take up to 24 hours.
- As a reference, the default sync periods of some relying party 
validation tools are as follows:

  - RIPE validator v2: every hour
  - RIPE validator v3: every 10 minutes
  - Routinator: every hour
  - rcynic: every hour

**Account closure
- APNIC makes extensive effort to contact the Member
- If all efforts failed, APNIC will decide to terminate and reclaim all 
resources delegated to that member. At the same time/day all whois 
objects for that account will be deleted.
- “delegated-apnic-extended-latest” stats file is updated within 24hours 
to flag the reclaimed resources as “Reserved”
- Reclaimed resource prefixes will be added to the AS0 ROA at the time 
of reclamation.
- If the closed member created any ROAs these will be deleted at the 
time of reclamation.

**Account reactivation
- If the APNIC Member reactivates the account within 3 months from the 
account closure, APNIC will re-delegate the reclaimed resources and 
reinstates whois objects and ROAs.
- “delegated-apnic-extended-latest” stats file is updated within 24hours 
to flag the re-delegated resources as “Allocated or Assigned”
- At the time of reactivation, AS0 ROA will be updated to exclude the 
re-delegated prefixes


**Clarifications requested:

The way in which the ROAs appear in the RPKI needs to be considered. 
Currently, the hierarchy involves a TA (for 0/0, ::/0, etc.), an 
intermediate CA (same resource set), five further CAs (one for IANA and 
one for each other RIR), and then the member CAs

(see diagram on slide 8 of 
https://conference.apnic.net/44/assets/files/APCS549/Transitioning-to-a-single-TA.pdf).

Three possible options are:

 - have the intermediate CA issue an AS0 ROA;
 - have each of the IANA/RIR CAs issue an AS0 ROA;
 - construct a separate CA under each of the IANA/RIR CAs
 containing the relevant unallocated resources, and have each of
 those CAs issue an AS0 ROA.

Does the community have any preference out of these three options?

Regards
Sunny
___

Srinivas (Sunny) Chendi
Senior Advisor - Policy and Community Development

Asia Pacific Network Information Centre (APNIC) |  Tel: +61 7 3858 3100
PO Box 3646 South Brisbane, QLD 4101 Australia  |  Fax: +61 7 3858 3199
6 Cordelia Street, South Brisbane, QLD  |  http://www.apnic.net
___


On 27/08/2019 9:25 am, Srinivas (Sunny) Chendi wrote:
> Hi Javed,
> 
> Thanks for your email and for your participation in the policy 
> development process.
> 
> We're consulting our experts to provide a response to your query soon. 
> Please allow us sometime.
> 
> Regards
> Sunny
> 
> On 24/08/2019 12:28 am, Javed Khan wrote:
>> For now, I'm neither for or against this proposal. I think the 
>> intention of the author is good but the implementation is not as easy 
>> as is explained in the proposal. QoS is very crucial for ISPs to 
>> sustain the fierce market competition and if APNIC fails to timely 
>> update the AS0 ROAs, this will effect the service delivery and/or 
>> network downtime.
>>
>> I request APNIC to provide a detailed review of this proposal from a 
>> service and legal perspective so the community can better understand 
>> the implementation, if this proposal reaches consensus.
>>
>>
>> Kind regards
>> Javed Khan
>> MSCE and CCSP
>>
>>
>> 
>> *From:* sig-policy-boun...@lists.apnic.net 
>>  on behalf of David Farmer 
>> 
>> *Sent:* Friday, 23 August 2019 10:48 AM
>> *To:* Aftab Siddiqui 
>> *Cc:* Sumon Ahmed Sabir ; Policy SIG 
>> 
>> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>
>>
>> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
>> mailto:aftab.siddi...@gmail.com>> wrote:
>>
>>     Hi David,
>>
>>
>>     On Fri, Aug 23, 2019 at 6:36 AM David Farmer >     <mailto:far...@umn.edu>> wrote:
>>
>>     The problem statement says;
>>
>>  

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Aftab Siddiqui
Thanks David for your points, I'm working on v3 to address some of these
concern.

Regards,

Aftab A. Siddiqui


On Thu, Aug 29, 2019 at 3:22 PM David Farmer  wrote:

> The increased consequences of an APNIC Member failing to pay fees or the
> extremely rare possibility of an error by APNIC Staff should be called out
> as a potential impacts of the proposal in section 7.
>
> Personally, I support the proposal, but it is a matter of informed
> consent, the community needs to consider the fact that this proposal
> increases the consequences if certain events occur.
>
> If these consequences are included in the proposal, when someone forgets
> to pay their bill and their resources get block by most of the Internet,
> then no one can claim it wasn't considered.
>
> Thanks.
>
> On Wed, Aug 28, 2019 at 11:07 PM Owen DeLong  wrote:
>
>>
>>
>> On Aug 28, 2019, at 20:37 , Aftab Siddiqui 
>> wrote:
>>
>>
>> Hi Owen,
>>  cutting some stuff out, just to keep the thread small.
>>
>> Anyone can very quickly put just about anything in RADB if they want to.
>>> It’s also relatively easy to put nearly anything in the current ARIN IRR
>>> (not to be confused with the ARIN RIR database). There are also some other
>>> IRRs that accept almost anything at face value.
>>>
>>
>> Exactly, thats why you have so much garbage in RADB and other IRR db.
>>
>>
>> It’s also why the RIR withdrawing an entry isn’t as likely to cause an
>> unmitigable outage than would occur under this policy.
>>
>>
>>
>>>
>>> Finally, route object based filters tend to get updated rather slowly
>>> and not everyone updates in sync, so it’s a gradually progressing outage
>>> that allows some reaction time before becoming completely catastrophic.
>>>
>>
>> Similarly, not everyone is doing ROV. But for the first time people are
>> worried about consequences of their laziness because RPKI is going to work
>> much better than IRR based filtering.
>>
>>
>> I’m not sure that’s a completely fair characterization of the situation,
>> but for whatever reason, despite its inability to do more than provide a
>> really good cryptographically signed hint at what to forge in your
>> hijacking announcements, RPKI is spreading like an unstoppable cancer and
>> more and more people are beginning to do ROV in a mode which permits
>> unknowns, but rejects known invalids.
>>
>> RIRs implementing AS0 raises the stakes by giving RIRs the power to
>> create “known invalids” where the previous state would be “unknown”.
>>
>>
>>> OTOH, if APNIC accidentally deletes the registration and issues an AS0
 ROA for the entire netback, then you’re (potentially) talking about near
 total catastrophic routing failure for this ISP and all of his customers.

>>>
>>> Let’s assume they accidentally delete the registration for any reason
>>> there are cooling off periods in place which goes up to 60 days or we can
>>> put measures in place through policy to have decent cooking off periods.
>>> Also let’s talk about stats, how many times how many RIRs have deleted
>>> their members by mistake? Do you have any case?
>>>
>>>
>>> Honestly, I have no way to know. Such an event would likely not be made
>>> particularly public. The RIR would consider it confidential to the affected
>>> party and the affected party would have little motivation to announce it to
>>> the world after the fact.
>>>
>>
>> So we are debating a scenario which we are not even aware ever happened.
>> I'm still not saying that it never happened and will not happen but
>> likelihood of such incident is just very small.
>>
>>
>> No… You asked for an example of how an AS0 ROA could get into the wild
>> erroneously and I presented one scenario which you are now arguing is
>> unlikely.
>> I agree that particular scenario may well be unlikely, but I’m not
>> convinced it is the only circumstance in which such an event could occur.
>> Depending on how AS-0 ROAs are generated, I see lots of possible ways for
>> fat-finger incidents at the RIR to result in dangerous issuances.
>>
>>
>>
>>>
>>> So I am not in favor of asking the RIR to create AS0 ROA.
>

 Thats absolutely fine we can agree to disagree but let’s have a clear
 understanding of the policy.


 What makes you think he does not understand the policy?

>>>
>>> Because the policy only addresses the bogon, how an address space
>>> becomes a bogon is APNIC operating procedure. Do you see the problem of
>>> understanding here?
>>>
>>>
>>> Yes, but it’s not his. The policy creates new more severe consequences
>>> for things moving “routable” -> “bogon”. When you increase the consequences
>>> of an action, it’s often a good idea to review the potential causes of that
>>> action and consider what avenues exist for erroneous triggers.
>>>
>>
>> Absolutely, its a good idea to have measures in place to avoid any
>> erroneous triggers and thats why I said APNIC can put operational practices
>> in place for that. Its shouldn't be part of the 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread David Farmer
The increased consequences of an APNIC Member failing to pay fees or the
extremely rare possibility of an error by APNIC Staff should be called out
as a potential impacts of the proposal in section 7.

Personally, I support the proposal, but it is a matter of informed consent,
the community needs to consider the fact that this proposal increases the
consequences if certain events occur.

If these consequences are included in the proposal, when someone forgets to
pay their bill and their resources get block by most of the Internet, then
no one can claim it wasn't considered.

Thanks.

On Wed, Aug 28, 2019 at 11:07 PM Owen DeLong  wrote:

>
>
> On Aug 28, 2019, at 20:37 , Aftab Siddiqui 
> wrote:
>
>
> Hi Owen,
>  cutting some stuff out, just to keep the thread small.
>
> Anyone can very quickly put just about anything in RADB if they want to.
>> It’s also relatively easy to put nearly anything in the current ARIN IRR
>> (not to be confused with the ARIN RIR database). There are also some other
>> IRRs that accept almost anything at face value.
>>
>
> Exactly, thats why you have so much garbage in RADB and other IRR db.
>
>
> It’s also why the RIR withdrawing an entry isn’t as likely to cause an
> unmitigable outage than would occur under this policy.
>
>
>
>>
>> Finally, route object based filters tend to get updated rather slowly and
>> not everyone updates in sync, so it’s a gradually progressing outage that
>> allows some reaction time before becoming completely catastrophic.
>>
>
> Similarly, not everyone is doing ROV. But for the first time people are
> worried about consequences of their laziness because RPKI is going to work
> much better than IRR based filtering.
>
>
> I’m not sure that’s a completely fair characterization of the situation,
> but for whatever reason, despite its inability to do more than provide a
> really good cryptographically signed hint at what to forge in your
> hijacking announcements, RPKI is spreading like an unstoppable cancer and
> more and more people are beginning to do ROV in a mode which permits
> unknowns, but rejects known invalids.
>
> RIRs implementing AS0 raises the stakes by giving RIRs the power to create
> “known invalids” where the previous state would be “unknown”.
>
>
>> OTOH, if APNIC accidentally deletes the registration and issues an AS0
>>> ROA for the entire netback, then you’re (potentially) talking about near
>>> total catastrophic routing failure for this ISP and all of his customers.
>>>
>>
>> Let’s assume they accidentally delete the registration for any reason
>> there are cooling off periods in place which goes up to 60 days or we can
>> put measures in place through policy to have decent cooking off periods.
>> Also let’s talk about stats, how many times how many RIRs have deleted
>> their members by mistake? Do you have any case?
>>
>>
>> Honestly, I have no way to know. Such an event would likely not be made
>> particularly public. The RIR would consider it confidential to the affected
>> party and the affected party would have little motivation to announce it to
>> the world after the fact.
>>
>
> So we are debating a scenario which we are not even aware ever happened.
> I'm still not saying that it never happened and will not happen but
> likelihood of such incident is just very small.
>
>
> No… You asked for an example of how an AS0 ROA could get into the wild
> erroneously and I presented one scenario which you are now arguing is
> unlikely.
> I agree that particular scenario may well be unlikely, but I’m not
> convinced it is the only circumstance in which such an event could occur.
> Depending on how AS-0 ROAs are generated, I see lots of possible ways for
> fat-finger incidents at the RIR to result in dangerous issuances.
>
>
>
>>
>> So I am not in favor of asking the RIR to create AS0 ROA.

>>>
>>> Thats absolutely fine we can agree to disagree but let’s have a clear
>>> understanding of the policy.
>>>
>>>
>>> What makes you think he does not understand the policy?
>>>
>>
>> Because the policy only addresses the bogon, how an address space becomes
>> a bogon is APNIC operating procedure. Do you see the problem of
>> understanding here?
>>
>>
>> Yes, but it’s not his. The policy creates new more severe consequences
>> for things moving “routable” -> “bogon”. When you increase the consequences
>> of an action, it’s often a good idea to review the potential causes of that
>> action and consider what avenues exist for erroneous triggers.
>>
>
> Absolutely, its a good idea to have measures in place to avoid any
> erroneous triggers and thats why I said APNIC can put operational practices
> in place for that. Its shouldn't be part of the policy.
>
>
> I never advocated for making it part of the policy. I advocated for
> reviewing it as part of the considerations BEFORE consenting to
> implementation of the policy.
>
> I never asked for a change to the policy text. I asked for APNIC to
> publish their anticipated operational procedures 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Owen DeLong


> On Aug 28, 2019, at 20:37 , Aftab Siddiqui  wrote:
> 
> 
> Hi Owen,
>  cutting some stuff out, just to keep the thread small.
> 
> Anyone can very quickly put just about anything in RADB if they want to. It’s 
> also relatively easy to put nearly anything in the current ARIN IRR (not to 
> be confused with the ARIN RIR database). There are also some other IRRs that 
> accept almost anything at face value.
> 
> Exactly, thats why you have so much garbage in RADB and other IRR db. 

It’s also why the RIR withdrawing an entry isn’t as likely to cause an 
unmitigable outage than would occur under this policy.

>  
> 
> Finally, route object based filters tend to get updated rather slowly and not 
> everyone updates in sync, so it’s a gradually progressing outage that allows 
> some reaction time before becoming completely catastrophic.
> 
> Similarly, not everyone is doing ROV. But for the first time people are 
> worried about consequences of their laziness because RPKI is going to work 
> much better than IRR based filtering. 

I’m not sure that’s a completely fair characterization of the situation, but 
for whatever reason, despite its inability to do more than provide a really 
good cryptographically signed hint at what to forge in your hijacking 
announcements, RPKI is spreading like an unstoppable cancer and more and more 
people are beginning to do ROV in a mode which permits unknowns, but rejects 
known invalids.

RIRs implementing AS0 raises the stakes by giving RIRs the power to create 
“known invalids” where the previous state would be “unknown”.

> 
>> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA 
>> for the entire netback, then you’re (potentially) talking about near total 
>> catastrophic routing failure for this ISP and all of his customers.
>> 
>> Let’s assume they accidentally delete the registration for any reason there 
>> are cooling off periods in place which goes up to 60 days or we can put 
>> measures in place through policy to have decent cooking off periods. Also 
>> let’s talk about stats, how many times how many RIRs have deleted their 
>> members by mistake? Do you have any case? 
> 
> Honestly, I have no way to know. Such an event would likely not be made 
> particularly public. The RIR would consider it confidential to the affected 
> party and the affected party would have little motivation to announce it to 
> the world after the fact.
> 
> So we are debating a scenario which we are not even aware ever happened. I'm 
> still not saying that it never happened and will not happen but likelihood of 
> such incident is just very small. 

No… You asked for an example of how an AS0 ROA could get into the wild 
erroneously and I presented one scenario which you are now arguing is unlikely.
I agree that particular scenario may well be unlikely, but I’m not convinced it 
is the only circumstance in which such an event could occur.
Depending on how AS-0 ROAs are generated, I see lots of possible ways for 
fat-finger incidents at the RIR to result in dangerous issuances.

>  
> 
>>> So I am not in favor of asking the RIR to create AS0 ROA.
>>> 
>>> Thats absolutely fine we can agree to disagree but let’s have a clear 
>>> understanding of the policy. 
>> 
>> What makes you think he does not understand the policy?
>> 
>> Because the policy only addresses the bogon, how an address space becomes a 
>> bogon is APNIC operating procedure. Do you see the problem of understanding 
>> here? 
> 
> Yes, but it’s not his. The policy creates new more severe consequences for 
> things moving “routable” -> “bogon”. When you increase the consequences of an 
> action, it’s often a good idea to review the potential causes of that action 
> and consider what avenues exist for erroneous triggers.
> 
> Absolutely, its a good idea to have measures in place to avoid any erroneous 
> triggers and thats why I said APNIC can put operational practices in place 
> for that. Its shouldn't be part of the policy.

I never advocated for making it part of the policy. I advocated for reviewing 
it as part of the considerations BEFORE consenting to implementation of the 
policy.

I never asked for a change to the policy text. I asked for APNIC to publish 
their anticipated operational procedures for review so that the community can 
consider them in determining whether or not to come to consensus on this policy 
proposal.

In other words, I agree they shouldn’t be part of the policy, but they MUST be 
part of the policy deliberation, IMHO.

>> Also it’s seems you are fine with people advertising bogons just because 
>> fixing it might make one/two people unhappy. 
> 
> I’m not necessarily fine with people advertising bogons, but I’m also not 
> necessarily convinced that I want the RIRs to become the routing police.
> 
> This proposal literally moves the routing police role from the hands of those 
> who run routers into the hands of the RIRs (well, specifically it moves part 
> of that 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Aftab Siddiqui
Hi Owen,
 cutting some stuff out, just to keep the thread small.

Anyone can very quickly put just about anything in RADB if they want to.
> It’s also relatively easy to put nearly anything in the current ARIN IRR
> (not to be confused with the ARIN RIR database). There are also some other
> IRRs that accept almost anything at face value.
>

Exactly, thats why you have so much garbage in RADB and other IRR db.


>
> Finally, route object based filters tend to get updated rather slowly and
> not everyone updates in sync, so it’s a gradually progressing outage that
> allows some reaction time before becoming completely catastrophic.
>

Similarly, not everyone is doing ROV. But for the first time people are
worried about consequences of their laziness because RPKI is going to work
much better than IRR based filtering.

>
> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA
>> for the entire netback, then you’re (potentially) talking about near total
>> catastrophic routing failure for this ISP and all of his customers.
>>
>
> Let’s assume they accidentally delete the registration for any reason
> there are cooling off periods in place which goes up to 60 days or we can
> put measures in place through policy to have decent cooking off periods.
> Also let’s talk about stats, how many times how many RIRs have deleted
> their members by mistake? Do you have any case?
>
>
> Honestly, I have no way to know. Such an event would likely not be made
> particularly public. The RIR would consider it confidential to the affected
> party and the affected party would have little motivation to announce it to
> the world after the fact.
>

So we are debating a scenario which we are not even aware ever happened.
I'm still not saying that it never happened and will not happen but
likelihood of such incident is just very small.


>
> So I am not in favor of asking the RIR to create AS0 ROA.
>>>
>>
>> Thats absolutely fine we can agree to disagree but let’s have a clear
>> understanding of the policy.
>>
>>
>> What makes you think he does not understand the policy?
>>
>
> Because the policy only addresses the bogon, how an address space becomes
> a bogon is APNIC operating procedure. Do you see the problem of
> understanding here?
>
>
> Yes, but it’s not his. The policy creates new more severe consequences for
> things moving “routable” -> “bogon”. When you increase the consequences of
> an action, it’s often a good idea to review the potential causes of that
> action and consider what avenues exist for erroneous triggers.
>

Absolutely, its a good idea to have measures in place to avoid any
erroneous triggers and thats why I said APNIC can put operational practices
in place for that. Its shouldn't be part of the policy.


>
> Also it’s seems you are fine with people advertising bogons just because
> fixing it might make one/two people unhappy.
>
>
> I’m not necessarily fine with people advertising bogons, but I’m also not
> necessarily convinced that I want the RIRs to become the routing police.
>
> This proposal literally moves the routing police role from the hands of
> those who run routers into the hands of the RIRs (well, specifically it
> moves part of that role in one region into the hands of one RIR).
>

This policy is not doing anything special and giving extra powers to RIR.
It happened when we (the community) agreed to move forward with RPKI. Any
consequences you are relating to AS0 are also true for any other ROA.
Whether its a good thing or bad, we can all have different opinion but its
a reality.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Owen DeLong
able” -> “bogon”. When you increase the consequences of an 
action, it’s often a good idea to review the potential causes of that action 
and consider what avenues exist for erroneous triggers.

> Also it’s seems you are fine with people advertising bogons just because 
> fixing it might make one/two people unhappy. 

I’m not necessarily fine with people advertising bogons, but I’m also not 
necessarily convinced that I want the RIRs to become the routing police.

This proposal literally moves the routing police role from the hands of those 
who run routers into the hands of the RIRs (well, specifically it moves part of 
that role in one region into the hands of one RIR).

Owen

> 
> 
> Owen
> 
>> 
>> 
>> J Khan
>> 
>> From: Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>>
>> Sent: Tuesday, 27 August 2019 6:16 PM
>> To: Owen DeLong mailto:o...@delong.com>>
>> Cc: Javed Khan mailto:javedkha...@outlook.com>>; 
>> Policy SIG mailto:sig-pol...@apnic.net>>; Sumon Ahmed 
>> Sabir mailto:sasa...@gmail.com>>
>> 
>> Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>  
>> Hi Owen,
>>  
>> I don’t think you actually addressed his concern…
>> 
>> Well, let me try again then :) 
>>  
>>> On Aug 26, 2019, at 17:17 , Aftab Siddiqui >> <mailto:aftab.siddi...@gmail.com>> wrote:
>>> 
>>> Hi Javed,
>>> I understand your concern, let me try to explain.
>>> 
>>> AS-0 ROA is an attestation by the holder of a prefix that the prefix 
>>> described in the ROA, and any more specific prefix, should not be used in a 
>>> routing context. The route validation consider a "valid" outcome if "ANY" 
>>> ROA matches the address prefix and origin AS, even if other valid ROAs 
>>> would provide an "invalid" validation outcome if used in isolation.  Since, 
>>> its not possible to generate a prefix with AS-0 there fore it is not 
>>> possible that valid ROA will impact the routing of a prefix even if there 
>>> is an AS-0 ROA for that prefix. Also, AS 0 ROA has a lower relative 
>>> preference than any other ROA that has a routable AS.  
>> 
>> Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
>> its subordinates) at or before the time when they would issue an AS-0 ROA.
>> 
>> Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
>> UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
>> routing table in most cases since there won’t be a validated route (in this 
>> instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
>> VALIDATED/GOOD.
>> 
>> Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD 
>> or UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
>> validating routers to discard the route.
>> 
>> There are only few reasons why APNIC would remove a valid ROA from member's 
>> account.
>> - Due to Non-payment and APNIC reclaiming the resources and closing the 
>> account
>> - Returned address space by the member for any reason and the space becomes 
>> part of free pool. 
>> 
>> In either case there are some cooling off period as I shared in previous 
>> email which goes up to 60 days before APNIC can mark those resources as 
>> free/available. IMO, there is absolutely no reason to have those ROAs in 
>> place but again this is an operational issue and this policy is not dealing 
>> with it. But can you suggest any reason when those ROAs should not be 
>> removed?
>> 
>>> For Example,
>>> - APNIC creates AS-0 ROA for 103.8.194.0/24 <http://103.8.194.0/24> (This 
>>> is an unallocated prefix announced AS135754, a bogon).
>>> - If I'm doing ROV then this prefix (103.8.194.0/24 
>>> <http://103.8.194.0/24>) will become invalid for me because it doesn't have 
>>> a valid ROA. Anyone not doing ROV or any other form of bogon filtering will 
>>> still accept this prefix and keep on treating it as normal.
>>> - Now, APNIC delegates this prefix to someone else after some time 
>>> (remember the AS-0 ROA still exist). That someone is AS139038 (myself).
>>> - Because this prefix is now under my administration I can create ROA with 
>>> my own ASN i.e. AS139038
>>> - Before delegating the prefix to me APNIC should have delete that AS-0 ROA 
>>> but lets assume they forgot to do so or some technical glitch happened and 
>>> the AS-0 ROA still exist for this prefix even 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Aftab Siddiqui
On Thu, 29 Aug 2019 at 9:04 am, Owen DeLong  wrote:

>
>
> On Aug 28, 2019, at 13:44 , Aftab Siddiqui 
> wrote:
>
> Hi Javed,
>
> On Thu, 29 Aug 2019 at 6:33 am, Javed Khan 
> wrote:
>
>> We may think we are living in a perfect world but we are not.
>>
>
> of course
>
> With this proposal I'm more worried about the network downtime as managing
>> an AS0 ROA by an RIR may be prone to errors as we all do regardless if its
>> a manual or automated solution.
>>
>
> Would you like to explain how AS0 ROA can create network downtime?
>
>
> One possible way I can think of (I’m sure there are others)…
>
> ISP Q is issued 2001:db8::/32 by APNIC.
>
> ISP Q does not participate in RPKI and does not create ROAs.
>
> APNIC accidentally issues an incorrect AS 0 ROA for 2001:db8:8000::/33,
> taking down some fraction (up to half) of ISP Q’s customers and possibly
> their infrastructure.
>

Since there is no AS0 ROA today so let’s focus on your later example.


>
> Operators network downtime doesn't have any effect on APNIC business as
>> they can simply say we stuffed up and fixing it.
>>
>> But think about those networks facing the downtime and their business
>> obligations to their customers, who will bear this liability. Sure these
>> operators can drag APNIC to the courts but that costs money that they
>> cannot afford but accept the stuff ups.
>>
>
> Still you don’t understand how AS0 ROA works and what this policy is
> trying to address. If a network operator is using a Bogon (unallocated
> address space) then trust me mate that network has no chance defending that
> case in any court. In fact APNIC should be dragging these network operators
> to court.
>
>
> No, he understands (or at least I don’t see anything to say he doesn’t.
> However, he and I also understand that we don’t live in a perfect world and
> we’re talking about what happens when something goes wrong.
>
> Right now, say APNIC accidentally deletes the above registration from the
> database… Nothing super bad happens. Some possibility that his RDNS stops
> working, but his packets still get routed. Some of his RDNS continues to
> function for a while due to caching, so the damage is potentially
> significant, but not total.
>

Many IXes filtering on valid route objects will stop accepting their
prefixes. Many upstreams also filtering on route objects will stop
accepting the prefix. Total outage.

>
> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA
> for the entire netback, then you’re (potentially) talking about near total
> catastrophic routing failure for this ISP and all of his customers.
>

Let’s assume they accidentally delete the registration for any reason there
are cooling off periods in place which goes up to 60 days or we can put
measures in place through policy to have decent cooking off periods. Also
let’s talk about stats, how many times how many RIRs have deleted their
members by mistake? Do you have any case?


>
>
>> So I am not in favor of asking the RIR to create AS0 ROA.
>>
>
> Thats absolutely fine we can agree to disagree but let’s have a clear
> understanding of the policy.
>
>
> What makes you think he does not understand the policy?
>

Because the policy only addresses the bogon, how an address space becomes a
bogon is APNIC operating procedure. Do you see the problem of understanding
here?

Also it’s seems you are fine with people advertising bogons just because
fixing it might make one/two people unhappy.


> Owen
>
>
>
>> J Khan
>>
>> --
>> *From:* Aftab Siddiqui 
>> *Sent:* Tuesday, 27 August 2019 6:16 PM
>> *To:* Owen DeLong 
>> *Cc:* Javed Khan ; Policy SIG <
>> sig-pol...@apnic.net>; Sumon Ahmed Sabir 
>>
>> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>
>> Hi Owen,
>>
>>
>> I don’t think you actually addressed his concern…
>>
>>
>> Well, let me try again then :)
>>
>>
>> On Aug 26, 2019, at 17:17 , Aftab Siddiqui 
>> wrote:
>>
>> Hi Javed,
>> I understand your concern, let me try to explain.
>>
>> AS-0 ROA is an attestation by the holder of a prefix that the prefix
>> described in the ROA, and any more specific prefix, should not be used in a
>> routing context. The route validation consider a "valid" outcome if "ANY"
>> ROA matches the address prefix and origin AS, even if other valid ROAs
>> would provide an "invalid" validation outcome if used in isolation.  Since,
>> its not possible to generate a prefix with AS-0 there fore it is not
>>

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Owen DeLong


> On Aug 28, 2019, at 13:44 , Aftab Siddiqui  wrote:
> 
> Hi Javed,
> 
> On Thu, 29 Aug 2019 at 6:33 am, Javed Khan  <mailto:javedkha...@outlook.com>> wrote:
> We may think we are living in a perfect world but we are not.
> 
> of course 
> 
> With this proposal I'm more worried about the network downtime as managing an 
> AS0 ROA by an RIR may be prone to errors as we all do regardless if its a 
> manual or automated solution.
> 
> Would you like to explain how AS0 ROA can create network downtime? 

One possible way I can think of (I’m sure there are others)…

ISP Q is issued 2001:db8::/32 by APNIC.

ISP Q does not participate in RPKI and does not create ROAs.

APNIC accidentally issues an incorrect AS 0 ROA for 2001:db8:8000::/33, taking 
down some fraction (up to half) of ISP Q’s customers and possibly their 
infrastructure.

> 
> Operators network downtime doesn't have any effect on APNIC business as they 
> can simply say we stuffed up and fixing it.
> 
> But think about those networks facing the downtime and their business 
> obligations to their customers, who will bear this liability. Sure these 
> operators can drag APNIC to the courts but that costs money that they cannot 
> afford but accept the stuff ups.
> 
> Still you don’t understand how AS0 ROA works and what this policy is trying 
> to address. If a network operator is using a Bogon (unallocated address 
> space) then trust me mate that network has no chance defending that case in 
> any court. In fact APNIC should be dragging these network operators to court. 

No, he understands (or at least I don’t see anything to say he doesn’t. 
However, he and I also understand that we don’t live in a perfect world and 
we’re talking about what happens when something goes wrong.

Right now, say APNIC accidentally deletes the above registration from the 
database… Nothing super bad happens. Some possibility that his RDNS stops 
working, but his packets still get routed. Some of his RDNS continues to 
function for a while due to caching, so the damage is potentially significant, 
but not total.

OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA for 
the entire netback, then you’re (potentially) talking about near total 
catastrophic routing failure for this ISP and all of his customers.

> 
> 
> So I am not in favor of asking the RIR to create AS0 ROA.
> 
> Thats absolutely fine we can agree to disagree but let’s have a clear 
> understanding of the policy. 

What makes you think he does not understand the policy?

Owen

> 
> 
> J Khan
> 
> From: Aftab Siddiqui  <mailto:aftab.siddi...@gmail.com>>
> Sent: Tuesday, 27 August 2019 6:16 PM
> To: Owen DeLong mailto:o...@delong.com>>
> Cc: Javed Khan mailto:javedkha...@outlook.com>>; 
> Policy SIG mailto:sig-pol...@apnic.net>>; Sumon Ahmed 
> Sabir mailto:sasa...@gmail.com>>
> 
> Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons
>  
> Hi Owen,
>  
> I don’t think you actually addressed his concern…
> 
> Well, let me try again then :) 
>  
>> On Aug 26, 2019, at 17:17 , Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>> wrote:
>> 
>> Hi Javed,
>> I understand your concern, let me try to explain.
>> 
>> AS-0 ROA is an attestation by the holder of a prefix that the prefix 
>> described in the ROA, and any more specific prefix, should not be used in a 
>> routing context. The route validation consider a "valid" outcome if "ANY" 
>> ROA matches the address prefix and origin AS, even if other valid ROAs would 
>> provide an "invalid" validation outcome if used in isolation.  Since, its 
>> not possible to generate a prefix with AS-0 there fore it is not possible 
>> that valid ROA will impact the routing of a prefix even if there is an AS-0 
>> ROA for that prefix. Also, AS 0 ROA has a lower relative preference than any 
>> other ROA that has a routable AS.  
> 
> Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
> its subordinates) at or before the time when they would issue an AS-0 ROA.
> 
> Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
> UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
> routing table in most cases since there won’t be a validated route (in this 
> instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
> VALIDATED/GOOD.
> 
> Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD 
> or UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
> validating routers to discard the route.
> 
> There are only few reasons why APNIC would remove a valid ROA fro

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Aftab Siddiqui
Hi Javed,

On Thu, 29 Aug 2019 at 6:33 am, Javed Khan  wrote:

> We may think we are living in a perfect world but we are not.
>

of course

With this proposal I'm more worried about the network downtime as managing
> an AS0 ROA by an RIR may be prone to errors as we all do regardless if its
> a manual or automated solution.
>

Would you like to explain how AS0 ROA can create network downtime?

Operators network downtime doesn't have any effect on APNIC business as
> they can simply say we stuffed up and fixing it.
>
> But think about those networks facing the downtime and their business
> obligations to their customers, who will bear this liability. Sure these
> operators can drag APNIC to the courts but that costs money that they
> cannot afford but accept the stuff ups.
>

Still you don’t understand how AS0 ROA works and what this policy is trying
to address. If a network operator is using a Bogon (unallocated address
space) then trust me mate that network has no chance defending that case in
any court. In fact APNIC should be dragging these network operators to
court.


> So I am not in favor of asking the RIR to create AS0 ROA.
>

Thats absolutely fine we can agree to disagree but let’s have a clear
understanding of the policy.


> J Khan
>
> --
> *From:* Aftab Siddiqui 
> *Sent:* Tuesday, 27 August 2019 6:16 PM
> *To:* Owen DeLong 
> *Cc:* Javed Khan ; Policy SIG <
> sig-pol...@apnic.net>; Sumon Ahmed Sabir 
>
> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>
> Hi Owen,
>
>
> I don’t think you actually addressed his concern…
>
>
> Well, let me try again then :)
>
>
> On Aug 26, 2019, at 17:17 , Aftab Siddiqui 
> wrote:
>
> Hi Javed,
> I understand your concern, let me try to explain.
>
> AS-0 ROA is an attestation by the holder of a prefix that the prefix
> described in the ROA, and any more specific prefix, should not be used in a
> routing context. The route validation consider a "valid" outcome if "ANY"
> ROA matches the address prefix and origin AS, even if other valid ROAs
> would provide an "invalid" validation outcome if used in isolation.  Since,
> its not possible to generate a prefix with AS-0 there fore it is not
> possible that valid ROA will impact the routing of a prefix even if there
> is an AS-0 ROA for that prefix. Also, AS 0 ROA has a lower relative
> preference than any other ROA that has a routable AS.
>
>
> Presumably, APNIC would withdraw/invalidate any other ROA for the prefix
> (or its subordinates) at or before the time when they would issue an AS-0
> ROA.
>
> Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to
> UNVALIDATED/UNKNOWN status in any route validator. This would not affect
> the routing table in most cases since there won’t be a validated route (in
> this instance) to supersede the UNVALIDATED/UNKNOWN route which was
> previously VALIDATED/GOOD.
>
> Issuing the AS-0 ROA would subsequently move the prefix from
> VALIDATED/GOOD or UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus
> causing most validating routers to discard the route.
>
>
> There are only few reasons why APNIC would remove a valid ROA from
> member's account.
> - Due to Non-payment and APNIC reclaiming the resources and closing the
> account
> - Returned address space by the member for any reason and the space
> becomes part of free pool.
>
> In either case there are some cooling off period as I shared in previous
> email which goes up to 60 days before APNIC can mark those resources as
> free/available. IMO, there is absolutely no reason to have those ROAs in
> place but again this is an operational issue and this policy is not dealing
> with it. But can you suggest any reason when those ROAs should not be
> removed?
>
> For Example,
> - APNIC creates AS-0 ROA for 103.8.194.0/24 (This is an unallocated
> prefix announced AS135754, a bogon).
> - If I'm doing ROV then this prefix (103.8.194.0/24) will become invalid
> for me because it doesn't have a valid ROA. Anyone not doing ROV or any
> other form of bogon filtering will still accept this prefix and keep on
> treating it as normal.
> - Now, APNIC delegates this prefix to someone else after some time
> (remember the AS-0 ROA still exist). That someone is AS139038 (myself).
> - Because this prefix is now under my administration I can create ROA with
> my own ASN i.e. AS139038
> - Before delegating the prefix to me APNIC should have delete that AS-0
> ROA but lets assume they forgot to do so or some technical glitch happened
> and the AS-0 ROA still exist for this prefix even after delegating it to me
> - Since I have created a ROA with my ASN i.e. AS139038 then t

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Javed Khan
We may think we are living in a perfect world but we are not. With this 
proposal I'm more worried about the network downtime as managing an AS0 ROA by 
an RIR may be prone to errors as we all do regardless if its a manual or 
automated solution. Operators network downtime doesn't have any effect on APNIC 
business as they can simply say we stuffed up and fixing it.

But think about those networks facing the downtime and their business 
obligations to their customers, who will bear this liability. Sure these 
operators can drag APNIC to the courts but that costs money that they cannot 
afford but accept the stuff ups.

So I am not in favor of asking the RIR to create AS0 ROA.

J Khan


From: Aftab Siddiqui 
Sent: Tuesday, 27 August 2019 6:16 PM
To: Owen DeLong 
Cc: Javed Khan ; Policy SIG ; 
Sumon Ahmed Sabir 
Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons

Hi Owen,

I don’t think you actually addressed his concern…

Well, let me try again then :)

On Aug 26, 2019, at 17:17 , Aftab Siddiqui 
mailto:aftab.siddi...@gmail.com>> wrote:

Hi Javed,
I understand your concern, let me try to explain.

AS-0 ROA is an attestation by the holder of a prefix that the prefix described 
in the ROA, and any more specific prefix, should not be used in a routing 
context. The route validation consider a "valid" outcome if "ANY" ROA matches 
the address prefix and origin AS, even if other valid ROAs would provide an 
"invalid" validation outcome if used in isolation.  Since, its not possible to 
generate a prefix with AS-0 there fore it is not possible that valid ROA will 
impact the routing of a prefix even if there is an AS-0 ROA for that prefix. 
Also, AS 0 ROA has a lower relative preference than any other ROA that has a 
routable AS.

Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
its subordinates) at or before the time when they would issue an AS-0 ROA.

Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
routing table in most cases since there won’t be a validated route (in this 
instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
VALIDATED/GOOD.

Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD or 
UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
validating routers to discard the route.

There are only few reasons why APNIC would remove a valid ROA from member's 
account.
- Due to Non-payment and APNIC reclaiming the resources and closing the account
- Returned address space by the member for any reason and the space becomes 
part of free pool.

In either case there are some cooling off period as I shared in previous email 
which goes up to 60 days before APNIC can mark those resources as 
free/available. IMO, there is absolutely no reason to have those ROAs in place 
but again this is an operational issue and this policy is not dealing with it. 
But can you suggest any reason when those ROAs should not be removed?

For Example,
- APNIC creates AS-0 ROA for 103.8.194.0/24<http://103.8.194.0/24> (This is an 
unallocated prefix announced AS135754, a bogon).
- If I'm doing ROV then this prefix (103.8.194.0/24<http://103.8.194.0/24>) 
will become invalid for me because it doesn't have a valid ROA. Anyone not 
doing ROV or any other form of bogon filtering will still accept this prefix 
and keep on treating it as normal.
- Now, APNIC delegates this prefix to someone else after some time (remember 
the AS-0 ROA still exist). That someone is AS139038 (myself).
- Because this prefix is now under my administration I can create ROA with my 
own ASN i.e. AS139038
- Before delegating the prefix to me APNIC should have delete that AS-0 ROA but 
lets assume they forgot to do so or some technical glitch happened and the AS-0 
ROA still exist for this prefix even after delegating it to me
- Since I have created a ROA with my ASN i.e. AS139038 then the validators will 
mark the prefix originating from my ASN as valid even though there is an AS-0 
ROA for that prefix.

Different example:

APNIC issues 2001:db8:feed::/48 to XYZ Corp. who creates a ROA for AS65551.
If you’re doing ROV, then this prefix 2001:db8:feed::/48 is validated assuming 
you receive the route with an AS PATh that matches "* 65551 $”.
Subsequently, XYZ Corp forgets to pay their APNIC invoice and APNIC revokes the 
space.
Under current policy, APNIC Simply deletes the ROA and anyone doing ROV no 
longer sees 2001:db8:feed::/48 as valid, but they don’t see it as invalid. It 
moves to unknown.
In the current (and foreseeable future) world, and unknown route is probably 
still going to be accepted by the vast majority of peers, so this has little 
effect on routing.
Under the proposed policy, at some point, APNIC issues a new ROA for 
2001:db8:feed::/48 tied to AS0.
Thi

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-28 Thread Javed Khan
Thanks Srinivas. I understand and may be its premature to ask for legal review 
of this proposal but at least if we can get APNIC proposed implementation that 
might help.

J Khan


From: Srinivas Chendi 
Sent: Tuesday, 27 August 2019 7:25 AM
To: Javed Khan 
Cc: mailman_SIG-policy 
Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons

Hi Javed,

Thanks for your email and for your participation in the policy
development process.

We're consulting our experts to provide a response to your query soon.
Please allow us sometime.

Regards
Sunny

On 24/08/2019 12:28 am, Javed Khan wrote:
> For now, I'm neither for or against this proposal. I think the intention
> of the author is good but the implementation is not as easy as is
> explained in the proposal. QoS is very crucial for ISPs to sustain the
> fierce market competition and if APNIC fails to timely update the AS0
> ROAs, this will effect the service delivery and/or network downtime.
>
> I request APNIC to provide a detailed review of this proposal from a
> service and legal perspective so the community can better understand the
> implementation, if this proposal reaches consensus.
>
>
> Kind regards
> Javed Khan
> MSCE and CCSP
>
>
> 
> *From:* sig-policy-boun...@lists.apnic.net
>  on behalf of David Farmer
> 
> *Sent:* Friday, 23 August 2019 10:48 AM
> *To:* Aftab Siddiqui 
> *Cc:* Sumon Ahmed Sabir ; Policy SIG
> 
> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>
>
> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui  <mailto:aftab.siddi...@gmail.com>> wrote:
>
> Hi David,
>
>
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  <mailto:far...@umn.edu>> wrote:
>
> The problem statement says;
>
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons")
> is a packet
> with an IP source address in an address block not yet
> allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC,
> AFRINIC and
> LACNIC)...
>
>
> So that raises a question, what about resources that are
> deregisterd because they are returned, revoked, or otherwise
> reclaimed, for any of a myriad of reasons, including non-payment
> of fees? Do they become Bogons with AS0 ROAs the moment they are
> deregistered? Later, if so when? What if there is a ROA for them
> in the system? Are the ROAs removed, if so when?
>
>
> I also had some concerns about revoked and/or reclaimed space and
> closed account due to non payment so I asked Secretariat in advance
> and here is the response.
> ===
> APNIC membership account is classified as closed when its status is
> flagged as ‘closed’ in APNIC’s internal system.
>
> 30 days - payment period upon issuance of invoice, if no payment is
> received within this period member receives expiry notice and the
> account status becomes 'suspended'
> After 15 days – member receives email notification for closure
> giving them another 15 days to pay
> After 15 days – the status of the account becomes 'closed' and all
> delegated resources under the account are reclaimed
>
> All in all members have 60 days period to pay before the status of
> the account becomes ‘closed’.
> ===
>
> As long as the account is suspended APNIC doesn't consider those
> resources as free/available/reclaimed and because they are not part
> of unallocated pool thats why no need to create AS0 ROAs for such
> resources. AS0 ROAs will be created once APNIC mark those resources
> available and remove them from their delegation record. Now, the
> second issue is if there is a ROA for them in the system. Because AS
> 0 ROA has a lower relative preference than any other ROA that has a
> routable AS then APNIC has to somehow delete the existing ROA from
> the system. Its easy if the member account is closed and all
> resources are reclaimed. But I leave this to APNIC to decide how
> they are going to make that happen.
>
>
> Currently, when the account is closed nothing actively makes the
> resources unusable, accept for if you were also changing providers
> during this timeframe, then when the new provider checks the resources
> they will be unregistered. But most providers don't recheck the
> registration of resources very often, if ever, other than at the time of
> setup of service.
>
> With this proposal at some point, the resource will effectively become
> unusable wit

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-27 Thread Owen DeLong
der their purview in a particular database (or set of databases). 
That’s a service APNIC can and does provide.

>> You can also check prefix 103.114.191.0/24 <http://103.114.191.0/24> via any 
>> validator you are running which has both AS-0 ROA (created by them) and also 
>> a ROA with their routable ASN (AS397702). Many operators have created AS-0 
>> ROAs along side the ROA with their own routable ASN. 
> 
> Yes, but this doesn’t cover the case Javed expressed concern about.
> 
>> I hope this helps answer you concern. Please let me know if you still have 
>> any question.
> 
> Even if Javed is somehow satisfied with your answer, I think that we need a 
> detailed explanation from staff how this policy would be implemented and
> what measures would be taken to avoid the erroneous (and potentially 
> disastrous) combination of revocation of all previous ROAs and issuance of
> an AS-0 ROA.
>  
> The policy doesn't talk about revocation of resources and subsequent ROAs 
> associated with it and its mechanism. Fee schedule, Revocation and membership 
> termination/cancelation is part of the membership agreement and how APNIC 
> executes the revocation is the operational issue of the APNIC. 

No, but it _DOES_ affect the outcome of all of those circumstances in a rather 
large and graphic way that is previously unprecedented on the internet. If you 
cannot see that, then you really are not thinking this through adequately.

> Also, a clear description of the timelines for how non-payment/cancellation 
> would be handled in terms of when ROAs would be revoked
> and when the AS-0 ROA would be issued for a reclaimed block in relation to 
> the revocation of previous ROAs and in relation to the invoice due date.
> 
> I hope that’s a clear enough expression.
> 
> I will leave that for APNIC to respond and its a fair enough concern that a 
> clarity is needed.

Thank you. I’m sure staff will respond promptly. I suspect it will take them 
some time to formulate a thorough response and they may well be scrambling to 
pull together procedures and documentation needed to address it as we type. I’m 
sure it falls into the category of “Answer requires thought” for them.

> That is my current question about this proposal. I am sure Javed will speak 
> up if it doesn’t also reflect his question/concerns.
> 
> I once again tried to answer your questions and happy to hear from Javed as 
> well :)

Thanks. Hopefully you now understand my concerns about the implications beyond 
the policy text that go with implementation and how they are related.

Owen

>  
> 
> Owen
> 
>> 
>> Regards,
>> 
>> Aftab A. Siddiqui
>> 
>> 
>> On Sat, Aug 24, 2019 at 12:29 AM Javed Khan > <mailto:javedkha...@outlook.com>> wrote:
>> For now, I'm neither for or against this proposal. I think the intention of 
>> the author is good but the implementation is not as easy as is explained in 
>> the proposal. QoS is very crucial for ISPs to sustain the fierce market 
>> competition and if APNIC fails to timely update the AS0 ROAs, this will 
>> effect the service delivery and/or network downtime.
>> 
>> I request APNIC to provide a detailed review of this proposal from a service 
>> and legal perspective so the community can better understand the 
>> implementation, if this proposal reaches consensus.
>> 
>> 
>> Kind regards
>> Javed Khan
>> MSCE and CCSP
>> 
>> 
>> From: sig-policy-boun...@lists.apnic.net 
>> <mailto:sig-policy-boun...@lists.apnic.net> 
>> > <mailto:sig-policy-boun...@lists.apnic.net>> on behalf of David Farmer 
>> mailto:far...@umn.edu>>
>> Sent: Friday, 23 August 2019 10:48 AM
>> To: Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>>
>> Cc: Sumon Ahmed Sabir mailto:sasa...@gmail.com>>; Policy 
>> SIG mailto:sig-pol...@apnic.net>>
>> Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>  
>> 
>> 
>> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>> wrote:
>> Hi David,
>> 
>> 
>> On Fri, Aug 23, 2019 at 6:36 AM David Farmer > <mailto:far...@umn.edu>> wrote:
>> The problem statement says;
>> 
>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
>> with an IP source address in an address block not yet allocated by IANA
>> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
>> LACNIC)...
>> 
>> So that raises a question, what about resources that are deregisterd because 
>> they are returned, revoked, or otherwise reclaimed, for any of

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-27 Thread Aftab Siddiqui
Corp hasn't paid the due fees (even after several reminders which
are in place by the RIR and after the cooling off period as per the
operational practice of RIR) then XYZ Corp doesn't have the right to use
2001:db8:feed::/48 and APNIC will mark those resources as free/available.
The policy deals with the resources part of free/available pool, how they
become part of that pool is not part of this policy and its an operational
issue.

Today, a terminated member can keep on using the resources without any
consequences unless APNIC reach out to them (which doesn't work at times)
or their upstream and tell them to stop advertising it.


> I’m not saying whether this is good or bad (who am I to judge at this
> point), but I am saying it’s a valid concern and a huge potential
> operational consequence
> of this proposed policy.
>

I'm still unable to see that as a concern, XYZ Corp has to pay the fees to
use those resources. Its part of the membership agreement they signed

"3.2 The Member must: Promptly pay all fees and charges due to the Company
in accordance with the Fee Schedule"

But again this is not part of the policy.


>
> You can also check prefix 103.114.191.0/24 via any validator you are
> running which has both AS-0 ROA (created by them) and also a ROA with their
> routable ASN (AS397702). Many operators have created AS-0 ROAs along side
> the ROA with their own routable ASN.
>
>
> Yes, but this doesn’t cover the case Javed expressed concern about.
>
> I hope this helps answer you concern. Please let me know if you still have
> any question.
>
>
> Even if Javed is somehow satisfied with your answer, I think that we need
> a detailed explanation from staff how this policy would be implemented and
> what measures would be taken to avoid the erroneous (and potentially
> disastrous) combination of revocation of all previous ROAs and issuance of
> an AS-0 ROA.
>

The policy doesn't talk about revocation of resources and subsequent ROAs
associated with it and its mechanism. Fee schedule, Revocation and
membership termination/cancelation is part of the membership agreement and
how APNIC executes the revocation is the operational issue of the APNIC.

Also, a clear description of the timelines for how non-payment/cancellation
> would be handled in terms of when ROAs would be revoked
> and when the AS-0 ROA would be issued for a reclaimed block in relation to
> the revocation of previous ROAs and in relation to the invoice due date.
>
> I hope that’s a clear enough expression.
>

I will leave that for APNIC to respond and its a fair enough concern that a
clarity is needed.


>
> That is my current question about this proposal. I am sure Javed will
> speak up if it doesn’t also reflect his question/concerns.
>

I once again tried to answer your questions and happy to hear from Javed as
well :)


>
> Owen
>
>
> Regards,
>
> Aftab A. Siddiqui
>
>
> On Sat, Aug 24, 2019 at 12:29 AM Javed Khan 
> wrote:
>
>> For now, I'm neither for or against this proposal. I think the intention
>> of the author is good but the implementation is not as easy as is explained
>> in the proposal. QoS is very crucial for ISPs to sustain the fierce market
>> competition and if APNIC fails to timely update the AS0 ROAs, this will
>> effect the service delivery and/or network downtime.
>>
>> I request APNIC to provide a detailed review of this proposal from a
>> service and legal perspective so the community can better understand the
>> implementation, if this proposal reaches consensus.
>>
>>
>> Kind regards
>> Javed Khan
>> MSCE and CCSP
>>
>>
>> --
>> *From:* sig-policy-boun...@lists.apnic.net <
>> sig-policy-boun...@lists.apnic.net> on behalf of David Farmer <
>> far...@umn.edu>
>> *Sent:* Friday, 23 August 2019 10:48 AM
>> *To:* Aftab Siddiqui 
>> *Cc:* Sumon Ahmed Sabir ; Policy SIG <
>> sig-pol...@apnic.net>
>> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>>
>>
>>
>> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
>> wrote:
>>
>> Hi David,
>>
>>
>> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  wrote:
>>
>> The problem statement says;
>>
>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
>> with an IP source address in an address block not yet allocated by IANA
>> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
>> LACNIC)...
>>
>>
>> So that raises a question, what about resources that are deregisterd
>> because they are returned, revoked, or otherwise reclaimed, for any of a
>> myriad o

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-26 Thread Owen DeLong
 measures would be taken to avoid the erroneous (and potentially 
disastrous) combination of revocation of all previous ROAs and issuance of
an AS-0 ROA. Also, a clear description of the timelines for how 
non-payment/cancellation would be handled in terms of when ROAs would be revoked
and when the AS-0 ROA would be issued for a reclaimed block in relation to the 
revocation of previous ROAs and in relation to the invoice due date.

I hope that’s a clear enough expression.

That is my current question about this proposal. I am sure Javed will speak up 
if it doesn’t also reflect his question/concerns.

Owen

> 
> Regards,
> 
> Aftab A. Siddiqui
> 
> 
> On Sat, Aug 24, 2019 at 12:29 AM Javed Khan  <mailto:javedkha...@outlook.com>> wrote:
> For now, I'm neither for or against this proposal. I think the intention of 
> the author is good but the implementation is not as easy as is explained in 
> the proposal. QoS is very crucial for ISPs to sustain the fierce market 
> competition and if APNIC fails to timely update the AS0 ROAs, this will 
> effect the service delivery and/or network downtime.
> 
> I request APNIC to provide a detailed review of this proposal from a service 
> and legal perspective so the community can better understand the 
> implementation, if this proposal reaches consensus.
> 
> 
> Kind regards
> Javed Khan
> MSCE and CCSP
> 
> 
> From: sig-policy-boun...@lists.apnic.net 
> <mailto:sig-policy-boun...@lists.apnic.net> 
>  <mailto:sig-policy-boun...@lists.apnic.net>> on behalf of David Farmer 
> mailto:far...@umn.edu>>
> Sent: Friday, 23 August 2019 10:48 AM
> To: Aftab Siddiqui  <mailto:aftab.siddi...@gmail.com>>
> Cc: Sumon Ahmed Sabir mailto:sasa...@gmail.com>>; Policy 
> SIG mailto:sig-pol...@apnic.net>>
> Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons
>  
> 
> 
> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui  <mailto:aftab.siddi...@gmail.com>> wrote:
> Hi David,
> 
> 
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  <mailto:far...@umn.edu>> wrote:
> The problem statement says;
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC)...
> 
> So that raises a question, what about resources that are deregisterd because 
> they are returned, revoked, or otherwise reclaimed, for any of a myriad of 
> reasons, including non-payment of fees? Do they become Bogons with AS0 ROAs 
> the moment they are deregistered? Later, if so when? What if there is a ROA 
> for them in the system? Are the ROAs removed, if so when? 
> 
> I also had some concerns about revoked and/or reclaimed space and closed 
> account due to non payment so I asked Secretariat in advance and here is the 
> response.
> ===
> APNIC membership account is classified as closed when its status is flagged 
> as ‘closed’ in APNIC’s internal system.
> 
> 30 days - payment period upon issuance of invoice, if no payment is received 
> within this period member receives expiry notice and the account status 
> becomes 'suspended' 
> After 15 days – member receives email notification for closure giving them 
> another 15 days to pay
> After 15 days – the status of the account becomes 'closed' and all delegated 
> resources under the account are reclaimed
> 
> All in all members have 60 days period to pay before the status of the 
> account becomes ‘closed’. 
> === 
> 
> As long as the account is suspended APNIC doesn't consider those resources as 
> free/available/reclaimed and because they are not part of unallocated pool 
> thats why no need to create AS0 ROAs for such resources. AS0 ROAs will be 
> created once APNIC mark those resources available and remove them from their 
> delegation record. Now, the second issue is if there is a ROA for them in the 
> system. Because AS 0 ROA has a lower relative preference than any other ROA 
> that has a routable AS then APNIC has to somehow delete the existing ROA from 
> the system. Its easy if the member account is closed and all resources are 
> reclaimed. But I leave this to APNIC to decide how they are going to make 
> that happen.
> 
> Currently, when the account is closed nothing actively makes the resources 
> unusable, accept for if you were also changing providers during this 
> timeframe, then when the new provider checks the resources they will be 
> unregistered. But most providers don't recheck the registration of resources 
> very often, if ever, other than at the time of setup of service.
> 
> With this proposal at some point, the reso

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-26 Thread Aftab Siddiqui
Hi Javed,
I understand your concern, let me try to explain.

AS-0 ROA is an attestation by the holder of a prefix that the prefix
described in the ROA, and any more specific prefix, should not be used in a
routing context. The route validation consider a "valid" outcome if "ANY"
ROA matches the address prefix and origin AS, even if other valid ROAs
would provide an "invalid" validation outcome if used in isolation.  Since,
its not possible to generate a prefix with AS-0 there fore it is not
possible that valid ROA will impact the routing of a prefix even if there
is an AS-0 ROA for that prefix. Also, AS 0 ROA has a lower relative
preference than any other ROA that has a routable AS.

For Example,
- APNIC creates AS-0 ROA for 103.8.194.0/24 (This is an unallocated prefix
announced AS135754, a bogon).
- If I'm doing ROV then this prefix (103.8.194.0/24) will become invalid
for me because it doesn't have a valid ROA. Anyone not doing ROV or any
other form of bogon filtering will still accept this prefix and keep on
treating it as normal.
- Now, APNIC delegates this prefix to someone else after some time
(remember the AS-0 ROA still exist). That someone is AS139038 (myself).
- Because this prefix is now under my administration I can create ROA with
my own ASN i.e. AS139038
- Before delegating the prefix to me APNIC should have delete that AS-0 ROA
but lets assume they forgot to do so or some technical glitch happened and
the AS-0 ROA still exist for this prefix even after delegating it to me
- Since I have created a ROA with my ASN i.e. AS139038 then the validators
will mark the prefix originating from my ASN as valid even though there is
an AS-0 ROA for that prefix.

You can also check prefix 103.114.191.0/24 via any validator you are
running which has both AS-0 ROA (created by them) and also a ROA with their
routable ASN (AS397702). Many operators have created AS-0 ROAs along side
the ROA with their own routable ASN.

I hope this helps answer you concern. Please let me know if you still have
any question.

Regards,

Aftab A. Siddiqui


On Sat, Aug 24, 2019 at 12:29 AM Javed Khan  wrote:

> For now, I'm neither for or against this proposal. I think the intention
> of the author is good but the implementation is not as easy as is explained
> in the proposal. QoS is very crucial for ISPs to sustain the fierce market
> competition and if APNIC fails to timely update the AS0 ROAs, this will
> effect the service delivery and/or network downtime.
>
> I request APNIC to provide a detailed review of this proposal from a
> service and legal perspective so the community can better understand the
> implementation, if this proposal reaches consensus.
>
>
> Kind regards
> Javed Khan
> MSCE and CCSP
>
>
> --
> *From:* sig-policy-boun...@lists.apnic.net <
> sig-policy-boun...@lists.apnic.net> on behalf of David Farmer <
> far...@umn.edu>
> *Sent:* Friday, 23 August 2019 10:48 AM
> *To:* Aftab Siddiqui 
> *Cc:* Sumon Ahmed Sabir ; Policy SIG <
> sig-pol...@apnic.net>
> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
>
>
>
> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
> wrote:
>
> Hi David,
>
>
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  wrote:
>
> The problem statement says;
>
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC)...
>
>
> So that raises a question, what about resources that are deregisterd
> because they are returned, revoked, or otherwise reclaimed, for any of a
> myriad of reasons, including non-payment of fees? Do they become Bogons
> with AS0 ROAs the moment they are deregistered? Later, if so when? What if
> there is a ROA for them in the system? Are the ROAs removed, if so when?
>
>
> I also had some concerns about revoked and/or reclaimed space and closed
> account due to non payment so I asked Secretariat in advance and here is
> the response.
> ===
> APNIC membership account is classified as closed when its status is
> flagged as ‘closed’ in APNIC’s internal system.
>
> 30 days - payment period upon issuance of invoice, if no payment is
> received within this period member receives expiry notice and the account
> status becomes 'suspended'
> After 15 days – member receives email notification for closure giving them
> another 15 days to pay
> After 15 days – the status of the account becomes 'closed' and all
> delegated resources under the account are reclaimed
>
> All in all members have 60 days period to pay before the status of the
> account becomes ‘closed’.
> ===
>
> As long as the account

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-26 Thread Srinivas Chendi
Hi Javed,

Thanks for your email and for your participation in the policy 
development process.

We're consulting our experts to provide a response to your query soon. 
Please allow us sometime.

Regards
Sunny

On 24/08/2019 12:28 am, Javed Khan wrote:
> For now, I'm neither for or against this proposal. I think the intention 
> of the author is good but the implementation is not as easy as is 
> explained in the proposal. QoS is very crucial for ISPs to sustain the 
> fierce market competition and if APNIC fails to timely update the AS0 
> ROAs, this will effect the service delivery and/or network downtime.
> 
> I request APNIC to provide a detailed review of this proposal from a 
> service and legal perspective so the community can better understand the 
> implementation, if this proposal reaches consensus.
> 
> 
> Kind regards
> Javed Khan
> MSCE and CCSP
> 
> 
> 
> *From:* sig-policy-boun...@lists.apnic.net 
>  on behalf of David Farmer 
> 
> *Sent:* Friday, 23 August 2019 10:48 AM
> *To:* Aftab Siddiqui 
> *Cc:* Sumon Ahmed Sabir ; Policy SIG 
> 
> *Subject:* Re: [sig-policy] prop-132-v002: AS0 for Bogons
> 
> 
> On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui  <mailto:aftab.siddi...@gmail.com>> wrote:
> 
> Hi David,
> 
> 
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  <mailto:far...@umn.edu>> wrote:
> 
> The problem statement says;
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons")
> is a packet
> with an IP source address in an address block not yet
> allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC,
> AFRINIC and
> LACNIC)...
> 
> 
> So that raises a question, what about resources that are
> deregisterd because they are returned, revoked, or otherwise
> reclaimed, for any of a myriad of reasons, including non-payment
> of fees? Do they become Bogons with AS0 ROAs the moment they are
> deregistered? Later, if so when? What if there is a ROA for them
> in the system? Are the ROAs removed, if so when?
> 
> 
> I also had some concerns about revoked and/or reclaimed space and
> closed account due to non payment so I asked Secretariat in advance
> and here is the response.
> ===
> APNIC membership account is classified as closed when its status is
> flagged as ‘closed’ in APNIC’s internal system.
> 
> 30 days - payment period upon issuance of invoice, if no payment is
> received within this period member receives expiry notice and the
> account status becomes 'suspended'
> After 15 days – member receives email notification for closure
> giving them another 15 days to pay
> After 15 days – the status of the account becomes 'closed' and all
> delegated resources under the account are reclaimed
> 
> All in all members have 60 days period to pay before the status of
> the account becomes ‘closed’.
> ===
> 
> As long as the account is suspended APNIC doesn't consider those
> resources as free/available/reclaimed and because they are not part
> of unallocated pool thats why no need to create AS0 ROAs for such
> resources. AS0 ROAs will be created once APNIC mark those resources
> available and remove them from their delegation record. Now, the
> second issue is if there is a ROA for them in the system. Because AS
> 0 ROA has a lower relative preference than any other ROA that has a
> routable AS then APNIC has to somehow delete the existing ROA from
> the system. Its easy if the member account is closed and all
> resources are reclaimed. But I leave this to APNIC to decide how
> they are going to make that happen.
> 
> 
> Currently, when the account is closed nothing actively makes the 
> resources unusable, accept for if you were also changing providers 
> during this timeframe, then when the new provider checks the resources 
> they will be unregistered. But most providers don't recheck the 
> registration of resources very often, if ever, other than at the time of 
> setup of service.
> 
> With this proposal at some point, the resource will effectively become 
> unusable with nonpayment, when the AS0 ROA is created, and any ROAs are 
> removed, I'm fine with this, but it should be called out as a 
> consequence of the proposal, so no one can say they didn't realize that 
> is a consequence of the proposal.
> 
> This proposal changes the consequences for nonpayment, that should be 
> made clear in t

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-23 Thread Javed Khan
For now, I'm neither for or against this proposal. I think the intention of the 
author is good but the implementation is not as easy as is explained in the 
proposal. QoS is very crucial for ISPs to sustain the fierce market competition 
and if APNIC fails to timely update the AS0 ROAs, this will effect the service 
delivery and/or network downtime.

I request APNIC to provide a detailed review of this proposal from a service 
and legal perspective so the community can better understand the 
implementation, if this proposal reaches consensus.


Kind regards
Javed Khan
MSCE and CCSP



From: sig-policy-boun...@lists.apnic.net  
on behalf of David Farmer 
Sent: Friday, 23 August 2019 10:48 AM
To: Aftab Siddiqui 
Cc: Sumon Ahmed Sabir ; Policy SIG 
Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons



On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
mailto:aftab.siddi...@gmail.com>> wrote:
Hi David,


On Fri, Aug 23, 2019 at 6:36 AM David Farmer 
mailto:far...@umn.edu>> wrote:
The problem statement says;

Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
with an IP source address in an address block not yet allocated by IANA
or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
LACNIC)...

So that raises a question, what about resources that are deregisterd because 
they are returned, revoked, or otherwise reclaimed, for any of a myriad of 
reasons, including non-payment of fees? Do they become Bogons with AS0 ROAs the 
moment they are deregistered? Later, if so when? What if there is a ROA for 
them in the system? Are the ROAs removed, if so when?

I also had some concerns about revoked and/or reclaimed space and closed 
account due to non payment so I asked Secretariat in advance and here is the 
response.
===
APNIC membership account is classified as closed when its status is flagged as 
‘closed’ in APNIC’s internal system.

30 days - payment period upon issuance of invoice, if no payment is received 
within this period member receives expiry notice and the account status becomes 
'suspended'
After 15 days – member receives email notification for closure giving them 
another 15 days to pay
After 15 days – the status of the account becomes 'closed' and all delegated 
resources under the account are reclaimed

All in all members have 60 days period to pay before the status of the account 
becomes ‘closed’.
===

As long as the account is suspended APNIC doesn't consider those resources as 
free/available/reclaimed and because they are not part of unallocated pool 
thats why no need to create AS0 ROAs for such resources. AS0 ROAs will be 
created once APNIC mark those resources available and remove them from their 
delegation record. Now, the second issue is if there is a ROA for them in the 
system. Because AS 0 ROA has a lower relative preference than any other ROA 
that has a routable AS then APNIC has to somehow delete the existing ROA from 
the system. Its easy if the member account is closed and all resources are 
reclaimed. But I leave this to APNIC to decide how they are going to make that 
happen.

Currently, when the account is closed nothing actively makes the resources 
unusable, accept for if you were also changing providers during this timeframe, 
then when the new provider checks the resources they will be unregistered. But 
most providers don't recheck the registration of resources very often, if ever, 
other than at the time of setup of service.

With this proposal at some point, the resource will effectively become unusable 
with nonpayment, when the AS0 ROA is created, and any ROAs are removed, I'm 
fine with this, but it should be called out as a consequence of the proposal, 
so no one can say they didn't realize that is a consequence of the proposal.

This proposal changes the consequences for nonpayment, that should be made 
clear in the proposal one way or another.

Also as Owen noted the RIRs frequently have a hold period after the account is 
closed, resource are usually held for some period after account closure and 
before they are reissued to a new user.

Personally I think they should be deregistered for some amount of time before 
the becoming Bogons and have an AS0 ROA created them, also for the AS0 ROA to 
be effective any ROAs for these deregistered resources need to be removed as 
well.

I would propose something like the following;

  1.  Upon de-reregistration any existing ROAs are removed from RPKI
  2.  30 days after de-registraion, AS0 ROAs are created except for non-payment 
fees
  3.  90 days after de-registraion, AS0 ROAs are created in the case of 
non-payment fees

Thanks.

Thanks for these suggestions but do you think the existing waiting period as 
outlined above in APNIC's response is good enough to mark them as 
free/unallocated? or you think additional cooling-off window should be added 
after the account is closed? How about 30 days after de-reg

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-22 Thread David Farmer
On Thu, Aug 22, 2019 at 9:04 PM Aftab Siddiqui 
wrote:

> Hi David,
>
>
> On Fri, Aug 23, 2019 at 6:36 AM David Farmer  wrote:
>
>> The problem statement says;
>>
>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
>> with an IP source address in an address block not yet allocated by IANA
>> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
>> LACNIC)...
>>
>>
>> So that raises a question, what about resources that are deregisterd
>> because they are returned, revoked, or otherwise reclaimed, for any of a
>> myriad of reasons, including non-payment of fees? Do they become Bogons
>> with AS0 ROAs the moment they are deregistered? Later, if so when? What if
>> there is a ROA for them in the system? Are the ROAs removed, if so when?
>>
>
> I also had some concerns about revoked and/or reclaimed space and closed
> account due to non payment so I asked Secretariat in advance and here is
> the response.
> ===
> APNIC membership account is classified as closed when its status is
> flagged as ‘closed’ in APNIC’s internal system.
>
> 30 days - payment period upon issuance of invoice, if no payment is
> received within this period member receives expiry notice and the account
> status becomes 'suspended'
> After 15 days – member receives email notification for closure giving them
> another 15 days to pay
> After 15 days – the status of the account becomes 'closed' and all
> delegated resources under the account are reclaimed
>
> All in all members have 60 days period to pay before the status of the
> account becomes ‘closed’.
> ===
>
> As long as the account is suspended APNIC doesn't consider those resources
> as free/available/reclaimed and because they are not part of unallocated
> pool thats why no need to create AS0 ROAs for such resources. AS0 ROAs will
> be created once APNIC mark those resources available and remove them from
> their delegation record. Now, the second issue is if there is a ROA for
> them in the system. Because AS 0 ROA has a lower relative preference than
> any other ROA that has a routable AS then APNIC has to somehow delete the
> existing ROA from the system. Its easy if the member account is closed and
> all resources are reclaimed. But I leave this to APNIC to decide how they
> are going to make that happen.
>

Currently, when the account is closed nothing actively makes the resources
unusable, accept for if you were also changing providers during this
timeframe, then when the new provider checks the resources they will be
unregistered. But most providers don't recheck the registration of
resources very often, if ever, other than at the time of setup of service.

With this proposal at some point, the resource will effectively become
unusable with nonpayment, when the AS0 ROA is created, and any ROAs are
removed, I'm fine with this, but it should be called out as a consequence
of the proposal, so no one can say they didn't realize that is a
consequence of the proposal.

This proposal changes the consequences for nonpayment, that should be made
clear in the proposal one way or another.

Also as Owen noted the RIRs frequently have a hold period after the account
is closed, resource are usually held for some period after account closure
and before they are reissued to a new user.


> Personally I think they should be deregistered for some amount of time
>> before the becoming Bogons and have an AS0 ROA created them, also for the
>> AS0 ROA to be effective any ROAs for these deregistered resources need to
>> be removed as well.
>>
>
>> I would propose something like the following;
>>
>>1. Upon de-reregistration any existing ROAs are removed from RPKI
>>2. 30 days after de-registraion, AS0 ROAs are created except for
>>non-payment fees
>>3. 90 days after de-registraion, AS0 ROAs are created in the case of
>>non-payment fees
>>
>> Thanks.
>>
>
> Thanks for these suggestions but do you think the existing waiting period
> as outlined above in APNIC's response is good enough to mark them as
> free/unallocated? or you think additional cooling-off window should be
> added after the account is closed? How about 30 days after de-registration
> whether it was closed due to non-payment or otherwise.
>

They were just suggestions, but I will note that you only discussed the
timing for nonpayment, resources can be returned voluntarily or they can be
revoked for cause, this is rare but it does happen and the timing
assoicated with these instances should be understood as well.

Also, I was suggesting the AS0 ROAs should not created immediately on
account closure but some period of time after that,

Right now there seems to be two phases, suspension and account closure, I'm
proposing a third phase resource deactivation, the creation of the AS0
ROAs. I suppose account closure and resource deactivation can occur
simultaneously, I think they should be separate as an escalating series of
events.

Thanks

On Thu, Aug 22, 2019 at 12:52 AM 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-22 Thread Aftab Siddiqui
Hi David,


On Fri, Aug 23, 2019 at 6:36 AM David Farmer  wrote:

> The problem statement says;
>
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC)...
>
>
> So that raises a question, what about resources that are deregisterd
> because they are returned, revoked, or otherwise reclaimed, for any of a
> myriad of reasons, including non-payment of fees? Do they become Bogons
> with AS0 ROAs the moment they are deregistered? Later, if so when? What if
> there is a ROA for them in the system? Are the ROAs removed, if so when?
>

I also had some concerns about revoked and/or reclaimed space and closed
account due to non payment so I asked Secretariat in advance and here is
the response.
===
APNIC membership account is classified as closed when its status is flagged
as ‘closed’ in APNIC’s internal system.

30 days - payment period upon issuance of invoice, if no payment is
received within this period member receives expiry notice and the account
status becomes 'suspended'
After 15 days – member receives email notification for closure giving them
another 15 days to pay
After 15 days – the status of the account becomes 'closed' and all
delegated resources under the account are reclaimed

All in all members have 60 days period to pay before the status of the
account becomes ‘closed’.
===

As long as the account is suspended APNIC doesn't consider those resources
as free/available/reclaimed and because they are not part of unallocated
pool thats why no need to create AS0 ROAs for such resources. AS0 ROAs will
be created once APNIC mark those resources available and remove them from
their delegation record. Now, the second issue is if there is a ROA for
them in the system. Because AS 0 ROA has a lower relative preference than
any other ROA that has a routable AS then APNIC has to somehow delete the
existing ROA from the system. Its easy if the member account is closed and
all resources are reclaimed. But I leave this to APNIC to decide how they
are going to make that happen.

Personally I think they should be deregistered for some amount of time
> before the becoming Bogons and have an AS0 ROA created them, also for the
> AS0 ROA to be effective any ROAs for these deregistered resources need to
> be removed as well.
>

> I would propose something like the following;
>
>1. Upon de-reregistration any existing ROAs are removed from RPKI
>2. 30 days after de-registraion, AS0 ROAs are created except for
>non-payment fees
>3. 90 days after de-registraion, AS0 ROAs are created in the case of
>non-payment fees
>
> Thanks.
>

Thanks for these suggestions but do you think the existing waiting period
as outlined above in APNIC's response is good enough to mark them as
free/unallocated? or you think additional cooling-off window should be
added after the account is closed? How about 30 days after de-registration
whether it was closed due to non-payment or otherwise.


>
> On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir 
> wrote:
>
>> Dear SIG members
>>
>> A new version of the proposal "prop-132: AS0 for Bogons"
>> has been sent to the Policy SIG for review.
>>
>> Information about earlier versions is available from:
>> http://www.apnic.net/policy/proposals/prop-132
>>
>> You are encouraged to express your views on the proposal:
>>
>>   - Do you support or oppose the proposal?
>>   - Is there anything in the proposal that is not clear?
>>   - What changes could be made to this proposal to make it more effective?
>>
>> Please find the text of the proposal below.
>>
>> Kind Regards,
>>
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>>
>>
>> --
>>
>> prop-132-v002: AS0 for Bogons
>>
>> --
>>
>> Proposer: Aftab Siddiqui
>>aftab.siddi...@gmail.com
>>
>>
>> 1. Problem statement
>> 
>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
>> with an IP source address in an address block not yet allocated by IANA
>> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
>> LACNIC) as well as all addresses reserved for private or special use by
>> RFCs.  See [RFC3330] and [RFC1918].
>>
>> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global
>> routing
>> table. In the past, several attempts have been made to filter out such
>> bogons
>> through various methods such as static filters and updating them
>> occasionally
>> but it is hard to keep an up to date filters, TeamCymru and CAIDA
>> provides full
>> bogon list in text format to update such filters. TeamCymru also
>> provides bogon
>> BGP feed where they send all the bogons via a BGP session which then can
>> be
>> discarded automatically. Beside 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-22 Thread Owen DeLong
Most, if not all RIRs have a process for address recycling with appropriate 
hold-down times and grace periods for the resource holder to act to preserve 
their claim on the resources.

It seems to me that lining this up with those procedures can be left as an 
operational manner at the discretion of staff, but I wouldn’t be opposed to 
specific minimums being elaborated in policy if people feel that is needed.

Staff should always be given the flexibility to accommodate entities staff 
believes to be acting in good faith, IMHO and the unintended consequences of 
any hard maximum time limits in policy could, be dire.

Owen


> On Aug 22, 2019, at 13:36 , David Farmer  wrote:
> 
> The problem statement says;
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC)...
> 
> So that raises a question, what about resources that are deregisterd because 
> they are returned, revoked, or otherwise reclaimed, for any of a myriad of 
> reasons, including non-payment of fees? Do they become Bogons with AS0 ROAs 
> the moment they are deregistered? Later, if so when? What if there is a ROA 
> for them in the system? Are the ROAs removed, if so when? 
> 
> Personally I think they should be deregistered for some amount of time before 
> the becoming Bogons and have an AS0 ROA created them, also for the AS0 ROA to 
> be effective any ROAs for these deregistered resources need to be removed as 
> well.
> 
> I would propose something like the following;
> Upon de-reregistration any existing ROAs are removed from RPKI
> 30 days after de-registraion, AS0 ROAs are created except for non-payment fees
> 90 days after de-registraion, AS0 ROAs are created in the case of non-payment 
> fees
> Thanks.
> 
> On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir  > wrote:
> Dear SIG members
> 
> A new version of the proposal "prop-132: AS0 for Bogons"
> has been sent to the Policy SIG for review.
> 
> Information about earlier versions is available from:
> http://www.apnic.net/policy/proposals/prop-132 
> 
> 
> You are encouraged to express your views on the proposal:
> 
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
> 
> Please find the text of the proposal below.
> 
> Kind Regards,
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> --
> 
> prop-132-v002: AS0 for Bogons
> 
> --
> 
> Proposer: Aftab Siddiqui
>aftab.siddi...@gmail.com 
> 
> 
> 1. Problem statement
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC) as well as all addresses reserved for private or special use by
> RFCs.  See [RFC3330] and [RFC1918].
> 
> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global 
> routing
> table. In the past, several attempts have been made to filter out such 
> bogons
> through various methods such as static filters and updating them 
> occasionally
> but it is hard to keep an up to date filters, TeamCymru and CAIDA 
> provides full
> bogon list in text format to update such filters. TeamCymru also 
> provides bogon
> BGP feed where they send all the bogons via a BGP session which then can be
> discarded automatically. Beside all these attempts the issue of Bogon 
> Advertisement
> hasn't be resolved so far.
> 
> 
> 2. Objective of policy change
> -
> The purpose of creating AS0 (zero) ROAs for unallocated address space by 
> APNIC
> is to resolve the issue of Bogon announcement. When APNIC issues an AS0 
> ROA for
> unallocated address space under APNIC’s administration then it will be 
> marked as
> “Invalid” if someone tries to advertise the same address space.
> 
> 
> Currently, in the absence of any ROA, these bogons are marked as 
> “NotFound”. Since
> many operators have implemented ROV and either planning or already 
> discarding “Invalid”
> then all the AS0 ROAs which APNIC will create for unallocated address 
> space will be
> discarded as well.
> 
> 3. Situation in other regions
> -
> No such policy in any region at the moment.
> 
> 
> 4. Proposed policy solution
> ---
> APNIC will create AS0(zero) ROAs for all the unallocated address space 
> (IPv4 and IPv6)
> for which APNIC is the current administrator. Any resource holder (APNIC 
> member) can
> create AS0 

Re: [sig-policy] prop-132-v002: AS0 for Bogons

2019-08-22 Thread David Farmer
The problem statement says;

Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
with an IP source address in an address block not yet allocated by IANA
or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
LACNIC)...


So that raises a question, what about resources that are deregisterd
because they are returned, revoked, or otherwise reclaimed, for any of a
myriad of reasons, including non-payment of fees? Do they become Bogons
with AS0 ROAs the moment they are deregistered? Later, if so when? What if
there is a ROA for them in the system? Are the ROAs removed, if so when?

Personally I think they should be deregistered for some amount of time
before the becoming Bogons and have an AS0 ROA created them, also for the
AS0 ROA to be effective any ROAs for these deregistered resources need to
be removed as well.

I would propose something like the following;

   1. Upon de-reregistration any existing ROAs are removed from RPKI
   2. 30 days after de-registraion, AS0 ROAs are created except for
   non-payment fees
   3. 90 days after de-registraion, AS0 ROAs are created in the case of
   non-payment fees

Thanks.

On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir 
wrote:

> Dear SIG members
>
> A new version of the proposal "prop-132: AS0 for Bogons"
> has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
> http://www.apnic.net/policy/proposals/prop-132
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-132-v002: AS0 for Bogons
>
> --
>
> Proposer: Aftab Siddiqui
>aftab.siddi...@gmail.com
>
>
> 1. Problem statement
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC) as well as all addresses reserved for private or special use by
> RFCs.  See [RFC3330] and [RFC1918].
>
> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global
> routing
> table. In the past, several attempts have been made to filter out such
> bogons
> through various methods such as static filters and updating them
> occasionally
> but it is hard to keep an up to date filters, TeamCymru and CAIDA
> provides full
> bogon list in text format to update such filters. TeamCymru also
> provides bogon
> BGP feed where they send all the bogons via a BGP session which then can be
> discarded automatically. Beside all these attempts the issue of Bogon
> Advertisement
> hasn't be resolved so far.
>
>
> 2. Objective of policy change
> -
> The purpose of creating AS0 (zero) ROAs for unallocated address space by
> APNIC
> is to resolve the issue of Bogon announcement. When APNIC issues an AS0
> ROA for
> unallocated address space under APNIC’s administration then it will be
> marked as
> “Invalid” if someone tries to advertise the same address space.
>
>
> Currently, in the absence of any ROA, these bogons are marked as
> “NotFound”. Since
> many operators have implemented ROV and either planning or already
> discarding “Invalid”
> then all the AS0 ROAs which APNIC will create for unallocated address
> space will be
> discarded as well.
>
> 3. Situation in other regions
> -
> No such policy in any region at the moment.
>
>
> 4. Proposed policy solution
> ---
> APNIC will create AS0(zero) ROAs for all the unallocated address space
> (IPv4 and IPv6)
> for which APNIC is the current administrator. Any resource holder (APNIC
> member) can
> create AS0 (zero) ROAs for the resources they have under their
> account/administration.
>
>
> A ROA is a positive attestation that a prefix holder has authorised an
> AS to originate a
> route for this prefix whereas, a ROA for the same prefixes with AS0
> (zero) origin shows
> negative intent from the resource holder that they don't want to
> advertise the prefix(es)
> at this point but they are the rightful custodian.
>
>
> Only APNIC has the authority to create ROAs for address space not yet
> allocated to the members
> and only APNIC can issue AS0 (zero) ROAs. Once they ROA is issued and
> APNIC wants to allocate
> the address space to its member, simply they can revoke the ROA and
> delegate the address space
> to members. (this proposal doesn't formulate operational process).
>
> 5. Advantages / Disadvantages
> -
> Advantages:
> Those