Internet2 Network Security SIG

[David Farmer <>]

I would agree, it is out of scope for this proposal but I can easily imagine proposals at each of the other RIRs and probably to IANA from the IETF or a global policy from all the RIRs to cover the IANA resources at least the ones in the scope of the Internet Registry System as defined by RFC7020 and RFC7249. Probably the IETF has to define what to do about the special use resources of each class.

https://tools.ietf.org/html/rfc7020

https://tools.ietf.org/html/rfc7249

Thanks

On Fri, Aug 9, 2019 at 4:11 PM Dale W. Carder <> wrote:

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               
> > 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               
> > 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               
> 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              
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
===============================================