<HTML><HEAD> <STYLE id=eMClientCss>blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc } blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; } .plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weight: normal; font-style: normal; white-space: pre-wrap; } a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;} .plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;} </STYLE> </HEAD> <BODY scroll=auto> <DIV dir=ltr> <DIV> <DIV>At RIPE70, in the DB Workgroup and the Cross Region BoF, there was some discussion of authority to originate a route. There was indication of one major operator's intent to look to the RIPE IRR for validation of OriginAS.</DIV> <DIV>In addition to Cross Regional concerns about the correctness and authority to originate, there was also a need to support temporary redirection (change of originAS) mentioned. </DIV> <DIV>Temporary redirection is often accomplished by BGP announcement.</DIV> <DIV> </DIV> <DIV>There was some discussion of the ownership of address-blocks by an AS.</DIV> <DIV>RPKI has answered these in ways that are not universally adopted, but do place the authority to originate (ROA) in the responsibility of the "prefix holder" <A href="http://www.potaroo.net/ispcol/2011-07/bgpsec.html">(4)</A>, not an AS with which it might normally be associated.</DIV> <DIV> <DIV align=left>rfc 2725 also says, in section 9.4 route objects:</DIV> <DIV align=left><PRE style="MARGIN-BOTTOM: 0px; FONT-SIZE: 13px; COLOR: rgb(0,0,0); MARGIN-TOP: 0px">"There is a legitimate reason to be in more than one origin AS." </PRE><PRE style="MARGIN-BOTTOM: 0px; FONT-SIZE: 13px; COLOR: rgb(0,0,0); MARGIN-TOP: 0px"><BR></PRE></DIV></DIV> <DIV>I propose that we aim to validate that the IRR database model is consistent with the RPKI model in requiring the authority of the maintainer of the <EM>inetnum </EM>to originate a route.</DIV> <DIV>However RIPE current documentation opposes this, "<FONT size=3><SPAN><SPAN style="WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FLOAT: none; COLOR: rgb(51,51,51); FONT: 14px/22px 'Open Sans',Helvetica,Arial,sans-serif; DISPLAY: inline !important; LETTER-SPACING: normal; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; font-stretch: normal">authorisation for creation of<SPAN> </SPAN></SPAN><B style="WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; COLOR: rgb(51,51,51); PADDING-BOTTOM: 0px; PADDING-TOP: 0px; FONT: 700 14px/22px 'Open Sans',Helvetica,Arial,sans-serif; PADDING-LEFT: 0px; MARGIN: 0px; LETTER-SPACING: normal; PADDING-RIGHT: 0px; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; font-stretch: normal">route(6)</B><SPAN style="WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FLOAT: none; COLOR: rgb(51,51,51); FONT: 14px/22px 'Open Sans',Helvetica,Arial,sans-serif; DISPLAY: inline !important; LETTER-SPACING: normal; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; font-stretch: normal"><SPAN> </SPAN>objects can and must be provided by both the address space holder and the holder of the<SPAN> </SPAN></SPAN><SPAN style="BACKGROUND: rgb(255,255,255); WHITE-SPACE: normal; WORD-SPACING: 0px; BORDER-BOTTOM: rgb(204,204,204) 1px dotted; TEXT-TRANSFORM: none; COLOR: rgb(51,51,51); PADDING-BOTTOM: 0px; PADDING-TOP: 0px; FONT: 14px/22px 'Open Sans',Helvetica,Arial,sans-serif; PADDING-LEFT: 0px; MARGIN: 0px; LETTER-SPACING: normal; PADDING-RIGHT: 0px; TEXT-INDENT: 0px; font-stretch: normal">AS number</SPAN></SPAN>" </FONT><A href="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation-1.78/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object">(5)</A> . </DIV> <DIV> </DIV> <DIV>We need to allow for more than one AS to be authorised to announce an origin for a prefix, even though we expect only one originator to announce normally. Multiple Origin AS (MOAS) conflicts occur today and do not appear to cause problems in their own right, as discussed in reference <A href="http://www.cs.colostate.edu/~massey/pubs/conf/massey_imw01.pdf" target=_BLANK>(1)</A>. Indeed the motivation for this discussion was to create policy for selecting routes in MOAS cases.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV><SPAN>I would like to propose for discussion that a basic set of objectives might be</SPAN>:</DIV> <DIV> </DIV> <DIV>1. An <EM>inetnum</EM> is globally unique and has a maintainer that is at least unique to each RIR (perhaps legacy address space may show different maintainers in different RIRs); </DIV> <DIV>that maintainer has the responsibility to identify which ASNs are entitled to announce an origin for that <EM>inetnum</EM>, </DIV> <DIV>and to <SPAN>register allowed ASNs in the IRR of that RIR. </SPAN></DIV> <DIV><SPAN>In this way the authentication of the person and their right to make changes stays within the one RIR.</SPAN></DIV> <DIV><SPAN>It is of no significance whether th</SPAN>e ASNs identified are registered in the same RIR, or not. </DIV> <DIV> </DIV> <DIV>2. Clarification, if necessary, that more than one <EM>route </EM>object for a subnet is permitted, where each RO has a different originAS. I have found no prohibition of multiple <EM>route</EM> objects for the same subnet. If one exists we should review its merit.</DIV> <DIV> </DIV> <DIV>2. Each RIR should feed up its IRR to a global 'read-only' IRR. Alternatively each RIR should provide its IRR to all other RIR so that each may maintain an independent global view.</DIV> <DIV>Data structures may also need to be adjusted to accommodate more than one authorised originator.</DIV> <DIV> </DIV> <DIV>3. T<SPAN>he routing announcements actually made by an AS are the responsibility of the AS-maintainer, and that AS-maintainer should be accountable in cases where the AS announces origin for a subnet for which the AS does not have the authority.</SPAN> If this is useful.</DIV> <DIV> </DIV> <DIV>Notes:</DIV> <DIV>a. More than one route object record with different originAS may be appropriate:</DIV> <DIV>- where there is multi-homing without BGP or </DIV> <DIV>- where organisations make use of BGP redirection for temporary third-party services, like DDoS mitigation</DIV> <DIV> </DIV> <DIV>b. rfc 1930 (BCP-6) section 7 says: <PRE style="MARGIN-BOTTOM: 0px; FONT-SIZE: 13px; FONT-VARIANT: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT-WEIGHT: normal; COLOR: rgb(0,0,0); FONT-STYLE: normal; MARGIN-TOP: 0px; LETTER-SPACING: normal; LINE-HEIGHT: normal; TEXT-INDENT: 0px">"Generally, a prefix can should belong to only one AS". </PRE></DIV> <DIV>The first word indicates that there should be allowance for exceptions. The rfc was written at a time when the relationship between AS number and IP block was much more stable than it is today. </DIV> <DIV> </DIV> <DIV align=left>c. There seems to me to be some ambiguity about route objects and Origin. rfc 2725, section 9.4 route objects <A href="https://tools.ietf.org/html/rfc2725#page-12">(3)</A> says:</DIV> <DIV align=left><PRE style="MARGIN-BOTTOM: 0px; FONT-SIZE: 13px; FONT-VARIANT: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT-WEIGHT: normal; COLOR: rgb(0,0,0); FONT-STYLE: normal; MARGIN-TOP: 0px; LETTER-SPACING: normal; LINE-HEIGHT: normal; TEXT-INDENT: 0px">"There is a legitimate reason to be in more than one origin AS." </PRE><PRE style="MARGIN-BOTTOM: 0px; FONT-SIZE: 13px; FONT-VARIANT: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT-WEIGHT: normal; COLOR: rgb(0,0,0); FONT-STYLE: normal; MARGIN-TOP: 0px; LETTER-SPACING: normal; LINE-HEIGHT: normal; TEXT-INDENT: 0px"><SPAN style="FONT-FAMILY: arial,sans-serif"> </SPAN></PRE></DIV> <DIV align=left>But route objects have only one origin field. If multiple route objects pointing to exactly the same subnet are allowed then who has the authority to create route objects? <BR>I suggest that the authority should reside with the <EM>inetnum</EM> maintainer. This makes the origin part of a route object rather than an attribute of <EM>inetnum</EM>.<BR></DIV> <DIV align=left>d. An alternative, might be to require (best practice) that temporary route announcements should prepend the ASN of the owner's AS. But this has an impact on the effectiveness of the announcement in the case of hop-count tie-breaks. <BR></DIV> <DIV> </DIV> <DIV>References:</DIV> <DIV>(1) <A href="http://www.cs.colostate.edu/~massey/pubs/conf/massey_imw01.pdf">http://www.cs.colostate.edu/~massey/pubs/conf/massey_imw01.pdf</A></DIV> <DIV>An Analysis of BGP Multiple Origin AS (MOAS) Conflicts {Xiaoliang Zhao, Dan Pei, Lan Wang, Dan Massey, Allison Mankin, S. Felix Wu,Lixia Zhang}</DIV> <DIV> </DIV> <DIV>(2) <A href="https://tools.ietf.org/html/rfc1930">https://tools.ietf.org/html/rfc1930</A></DIV> <DIV>BCP-6</DIV> <DIV> </DIV> <DIV>(3) <A href="https://tools.ietf.org/html/rfc2725#page-12">https://tools.ietf.org/html/rfc2725#page-12</A></DIV> <DIV> </DIV> <DIV>(4) <A href="http://www.potaroo.net/ispcol/2011-07/bgpsec.html">http://www.potaroo.net/ispcol/2011-07/bgpsec.html</A> {Bush & Huston}</DIV> <DIV> </DIV> <DIV>(5) <A href="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation-1.78/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object">https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation-1.78/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-1-description-of-the-aut-num-object</A></DIV> <DIV> </DIV> <DIV> <DIV align=left> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" dir=ltr align=left><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">________________________</SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" dir=ltr align=left><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN> </P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt" dir=ltr align=left><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"></SPAN><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Steve Nash CEng MIET</SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Consulting Engineer</SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Arbor Networks<U></U><U></U><U></U></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">office <A href="tel:%2B44%20118%20967%204917" value="+441189674917">+44 118 967 4917</A><BR></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">mobile <A href="tel:%2B44%20772%20029%201359" value="+447720291359">+44 772 029 1359</A></SPAN></P> <P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A title=http://www.arbornetworks.com/ href="http://www.arbornetworks.com/">http://www.arbornetworks.com/</A></SPAN></P><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">________________________</SPAN></DIV> <DIV> </DIV> <DIV> </DIV> <DIV><SPAN><BR style="FONT-VARIANT: normal; WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT-WEIGHT: normal; FONT-STYLE: normal; LETTER-SPACING: normal; LINE-HEIGHT: normal; TEXT-INDENT: 0px"><BR></SPAN> </DIV></DIV> <DIV> </DIV></DIV></DIV></BODY></HTML>