Internet2 Network Security SIG

["Dale W. Carder" <>]

My reading of the policy text is that only unallocated APNIC resources
would be signed with AS0 by APNIC.  I think IANA resources are clearly 
out of scope.

https://www.apnic.net/wp-content/uploads/2019/08/prop-132-v001.txt

Dale


Thus spake David Farmer () on Fri, Aug 09, 2019 at 03:54:34PM 
-0500:
> Yes, that or the other way around too. You might want general RPKI ROA
> validation but I don't want ROA based bogon filtering.
> 
> And there are many different classes of bogons there is IANA reserved and
> RIR unallocated, you might want to treat them differently.
> 
> On Fri, Aug 9, 2019 at 12:37 PM "Montgomery, Douglas (Fed)" <
> > wrote:
> 
> > Ah, I see, you are thinking of someone opting-in for ROA based bogon
> > filtering, but not general RPKI based route origin validation and 
> > filtering.
> >
> >
> >
> > It is a sad enough state of affairs right now that we have 5 trust
> > anchors, I don’t want 10.
> >
> >
> >
> > I think from the RIR’s perspective, this is a RPKI-ROV value add (i.e.,
> > you get bogon filtering for free with the same infrastructure).   That is,
> > an incentive to enable RPKI ROV.
> >
> > If part of the rationale here is an incentive model, I doubt that the RIRs
> > would be interested in making the bogon list a separate TAL.
> >
> >
> >
> > dougm
> >
> > --
> >
> > Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST
> >
> >
> >
> >
> >
> > *From: *<> on behalf of David Farmer <
> > >
> > *Reply-To: *" List:" <>
> > *Date: *Friday, August 9, 2019 at 12:52 PM
> > *To: *" List:" <>
> > *Subject: *Re: [Security-WG] Fwd: [sig-policy] prop-132-v001 AS0 for
> > Bogons
> >
> >
> >
> > I interpret the proposal as APNIC issuing AS0 ROAs for only it's
> > unallocated space, not the other RIR's unallocated space, and maybe the
> > IANA reserved space.
> >
> >
> >
> > I was thinking a separate TAL would simplify the opt-in or opt-out. Or,
> > maybe that is too big of a stick. Otherwise, as an operator, how would I
> > separate these unallocated AS0 ROAs from resource holders AS0 ROAs, or
> > maybe there is another way to do that?
> >
> >
> >
> > I was thinking IANA could issue a TAL with AS0 ROAs for the IANA reserved
> > space as appropriate.
> >
> > Then the RIRs issue TALs with AS0 ROAs for their unallocated space,
> > separate from the TALs for their allocated space.
> >
> >
> >
> > But, I have really worked with the validator tools yet, so I'd be
> > interested in other opinions.
> >
> >
> >
> > Thoughts?
> >
> >
> >
> > Thanks
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Aug 9, 2019 at 9:48 AM "Montgomery, Douglas (Fed)" <
> > > wrote:
> >
> > Seems like a good (and obvious) idea.  I don’t think we need a separate
> > TAL for this, although it was not clear to me if APNIC would be doing this
> > only for resources that should be in their region or if they would be 
> > doing
> > it globally?  The latter would raise interesting questions.
> >
> >
> >
> > Individual resource holders can also issue AS0 ROAs for parts of their
> > address space that are not currently advertised in the routing system.
> >
> >
> >
> > dougm
> >
> > --
> >
> > Doug Montgomery, Manager Internet  & Scalable Systems Research @ NIST
> >
> >
> >
> >
> >
> > *From: *<> on behalf of David Farmer <
> > >
> > *Reply-To: *" List:" <>
> > *Date: *Friday, August 9, 2019 at 8:34 AM
> > *To: *" List:" <>
> > *Subject: *[Security-WG] Fwd: [sig-policy] prop-132-v001 AS0 for Bogons
> >
> >
> >
> > The is an intriguing policy proposal in APNIC's hopper that I thought I
> > would bring to our group's attention.
> >
> >
> >
> > I kind of like the idea.
> >
> >
> >
> > However, it does create questions regarding chronically late payment of
> > your RIR bill and when reclaimed resources become bogons.
> >
> >
> >
> > Also, maybe this should have a separate TAL so you can opt-in or opt-out
> > of this.
> >
> > ---------- Forwarded message ---------
> > From: *Sumon Ahmed Sabir* <>
> > Date: Fri, Aug 9, 2019 at 5:01 AM
> > Subject: [sig-policy] prop-132-v001 AS0 for Bogons
> > To: Policy SIG <>
> >
> >
> >
> >
> > 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
> > <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apnic.net%2Fpolicy%2Fproposals%2Fprop-132&data=02%7C01%7Cdougm%40nist.gov%7Cdbfd4ec8264041ddef7408d71ce9faa1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637009663567330157&sdata=eM4rxaS27WXSbIP4g5srlvbaGrZH8wYpeAC1Tn2LUgI%3D&reserved=0>
> >
> > Regards
> >
> > Sumon, Bertrand, Ching-Heng
> > APNIC Policy SIG Chairs
> >
> >
> > ----------------------------------------------------------------------
> >
> > prop-132-v001: AS0 for Bogons
> >
> > ----------------------------------------------------------------------
> >
> > Proposer: Aftab Siddiqui
> >            
> >
> >
> > 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
> > <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfc%2Frfc6483.txt&data=02%7C01%7Cdougm%40nist.gov%7Cdbfd4ec8264041ddef7408d71ce9faa1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637009663567340146&sdata=xNntkHGS5p%2FHN2%2BLh5E6uRqGL9ik665BJIyzywSttHo%3D&reserved=0>
> > RFC6491 - https://tools.ietf.org/rfc/rfc6491.txt
> > <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfc%2Frfc6491.txt&data=02%7C01%7Cdougm%40nist.gov%7Cdbfd4ec8264041ddef7408d71ce9faa1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637009663567340146&sdata=Tbs17KP7RnoUH9i43gP%2FHl%2FVsf%2BKlYxGfm95BIKtUos%3D&reserved=0>
> > RFC7607 - https://tools.ietf.org/rfc/rfc7607.txt
> > <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfc%2Frfc7607.txt&data=02%7C01%7Cdougm%40nist.gov%7Cdbfd4ec8264041ddef7408d71ce9faa1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637009663567350140&sdata=1bAefTIlOy2lA6h%2FEj36Mb0wWyAMIZU%2BO2KCb45iDzk%3D&reserved=0>
> >
> > *              sig-policy:  APNIC SIG on resource management policy
> >    *
> > _______________________________________________
> > sig-policy mailing list
> > 
> > https://mailman.apnic.net/mailman/listinfo/sig-policy
> > <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.apnic.net%2Fmailman%2Flistinfo%2Fsig-policy&data=02%7C01%7Cdougm%40nist.gov%7Cdbfd4ec8264041ddef7408d71ce9faa1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637009663567350140&sdata=j3oTg5YrLRdiSUrAtSHOWfyLh9R8wtoUp977teNwUMw%3D&reserved=0>
> >
> >
> >
> >
> > --
> >
> > ===============================================
> > David Farmer               Email:
> > Networking & Telecommunication Services
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE        Phone: 612-626-0815
> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > ===============================================
> >
> >
> >
> >
> > --
> >
> > ===============================================
> > David Farmer               Email:
> > Networking & Telecommunication Services
> > Office of Information Technology
> > University of Minnesota
> > 2218 University Ave SE        Phone: 612-626-0815
> > Minneapolis, MN 55414-3029   Cell: 612-812-9952
> > ===============================================
> >
> 
> 
> -- 
> ===============================================
> David Farmer               Email:
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================