Hi Aftab-bhai,

While I totally support the proposal, I think this will only identify
BOGON/Martian routes in AP region and so all the other regions must do
the same to make the idea fully functional. By that, I indicate of a
global policy, may be at the NRO level. But anyway, at least it can be
started from this region.


On 15/8/19 10:58 AM, Aftab Siddiqui wrote:
> Hi Owen,
> Thanks for your response, sorry for replying late though. 
> IMO, IETF has done its part already.
> RFC6483 defines the term “Disavowal of Routing Origination”.
> “A ROA is a positive attestation that a prefix holder has authorized
> an AS to originate a route for this prefix into the inter-domain
> routing system.  It is possible for a prefix holder to construct an
> authorization where no valid AS has been granted any such authority to
> originate a route for an address prefix.  This is achieved by using a
> ROA where the ROA’s subject AS is one that must not be used in any
> routing context.  Specifically, AS0 is reserved by the IANA such that
> it may be used to identify non-routed networks
> A ROA with a subject of AS0 (AS0 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 procedure will provide 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. 
> Consequently, an AS0 ROA has a lower relative preference than any
> other ROA that has a routable AS, as its subject.  This allows a
> prefix holder to use an AS0 ROA to declare a default condition that
> any route that is equal to or more specific than the prefix to be
> considered “invalid”, while also allowing other concurrently issued
> ROAs to describe valid origination authorizations for more specific
> prefixes.”
> RFC6491 says - "IANA SHOULD issue an AS 0 ROA for all reserved IPv4
> and IPv6 resources not intended to be routed." also "IANA SHOULD issue
> an AS 0 ROA for all Unallocated Resources."
> Once allocated to RIRs then IANA can't issue any ROA (they are not
> doing it to any resource anyway) but there is unallocated address
> space with RIRs, they can issue AS0 ROAs.
> I hope this clarifies your point of IETF's involvement first.
> Regards,
> Aftab A. Siddiqui
> On Sat, Aug 10, 2019 at 6:40 AM Owen DeLong <o...@delong.com
> <mailto:o...@delong.com>> wrote:
>     IMHO, while I’m perfectly fine with APNIC administering this and
>     maintaining the ROAs, etc., I believe that the decision to
>     allocate AS0 to this purpose and documentation of this intent
>     should be done through the IETF and be documented in an STD or RFC.
>     I support the idea, but I believe the proper place to start is the
>     IETF.
>     Owen
>>     On Aug 9, 2019, at 3:01 AM, Sumon Ahmed Sabir <sasa...@gmail.com
>>     <mailto:sasa...@gmail.com>> wrote:
>>     Dear SIG members,
>>     The proposal "prop-132-v001: AS0 for Bogons" has been sent to
>>     the Policy SIG for review.
>>     It will be presented at the Open Policy Meeting at APNIC 48 in
>>     Chiang Mai, Thailand on Thursday, 12 September 2019.
>>     We invite you to review and comment on the proposal on the
>>     mailing list
>>     before the meeting.
>>     The comment period on the mailing list before an APNIC meeting is an
>>     important part of the policy development process. We encourage you to
>>     express your views on the proposal:
>>       - Do you support or oppose this proposal?
>>       - Does this proposal solve a problem you are experiencing? If so,
>>         tell the community about your situation.
>>       - Do you see any disadvantages in this proposal?
>>       - Is there anything in the proposal that is not clear?
>>       - What changes could be made to this proposal to make it more
>>         effective?
>>     Information about this proposal is available at:
>>     http://www.apnic.net/policy/proposals/prop-132
>>     Regards
>>     Sumon, Bertrand, Ching-Heng
>>     APNIC Policy SIG Chairs
>>     ----------------------------------------------------------------------
>>     prop-132-v001: AS0 for Bogons
>>     ----------------------------------------------------------------------
>>     Proposer: Aftab Siddiqui
>>                aftab.siddi...@gmail.com <mailto: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 in its bucket 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 
>>     in its bucket
>>     (IPv4 and IPv6). Any resource holder can create AS0 (zero) ROAs
>>     for the 
>>     resources they
>>     have under their account.
>>     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 implementing ROV globally and discarding the invalids will
>>     be able 
>>     to discard bogons from
>>     APNIC region automatically.
>>     Disadvantages:
>>     No apparent disadvantage
>>     6. Impact on resource holders
>>     -----------------------------
>>     No impact to APNIC or respective NIR resource holders not
>>     implementing 
>>     ROV. Those implementing
>>     ROV and discarding the invalids will not see any bogons in their
>>     routing 
>>     table.
>>     7. References
>>     -------------------------------------------------------
>>     RFC6483 - https://tools.ietf.org/rfc/rfc6483.txt
>>     RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt
>>     RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt
>>     *              sig-policy:  APNIC SIG on resource management
>>     policy           *
>>     _______________________________________________
>>     sig-policy mailing list
>>     sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>>     https://mailman.apnic.net/mailman/listinfo/sig-policy
>     *              sig-policy:  APNIC SIG on resource management
>     policy           *
>     _______________________________________________
>     sig-policy mailing list
>     sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>     https://mailman.apnic.net/mailman/listinfo/sig-policy
> *              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

Attachment: signature.asc
Description: OpenPGP digital signature

*              sig-policy:  APNIC SIG on resource management policy           *
sig-policy mailing list

Reply via email to