- db-wg - mailman.ripe.net

Deal with "non-breaking-space"-characters in updates
by Marc Grol 09 Jul '15

09 Jul '15

Summary: Currently the whois database accepts “non-breaking-space”-characters in updates. We propose that whois replaces these “non-breaking-space”-characters with regular spaces before storing the object. Context: Currently the whois database accepts updates with "non-breaking-space”-characters as part of attribute values. This behaviour is fairly acceptable, since the "non-breaking-space”-character is part of the “latin1”-character-set which is supported by whois. The whois database treats these "non-breaking-spaces”-characters as regular spaces and considers the object to be syntactically correct. However, the object is stored exactly as it was received from the client: including non-breaking-spaces Problem: We think most of these "non-breaking-spaces” where intended to be regular spaces, but ended up mangled due to copy and paste. So, when such an object is being queried for, the original object (including non-breaking-spaces) is being returned. This is inconvenient. since most clients cannot handle this “exceptional” character. It many clients it will end up as something like a “?’-character. Alternative solutions: -1- Let whois software accept the update but convert "non-breaking-spaces” into regular spaces before storing -2- Consider requests containing "non-breaking-space”-characters as syntactically incorrect, and do not accept updates containing them. -3- Keep current solution: You get what you asked for. Some additional statistics that can be used to understand the size of the problem: Approximately 3.000 objects (out of 8.000.000) contain "non-breaking-space”-characters. Mostly in “remarks"-, “description"- and “address"-attributes? Marc Grol member of ripe’s whois database team mgrol(a)ripe.net <mailto:mgrol@ripe.net> +31648928856

5 5

Re: [db-wg] Temporary origins
by snash 02 Jul '15

02 Jul '15

Alex I think the notification to the ASN holder is a good thing. The notification could include a reference to the inetnum holder so that the ASN holder could make contact more easily, if necessary. If we accept that the inetnum holder has the authority to create, then it is not clear to me why the ASN holder should have the right to delete. If there has been a mistake it is to the detriment only of the inetnum holder's organisation, and they can remove the Route Object and correct it. For clarity - By "ASN holder" we are referring to the origin ASN in the new Route Object, not any other. This policy change would enable a clear and simplified instruction for organisations needing authority to originate temporarily. Thanks Steve > On 26 Jun 2015, at 06:43, George Michaelson <ggm(a)apnic.net> wrote: > > > > On 25 June 2015 at 21:42, Job Snijders <job(a)instituut.net> wrote: > On Thu, Jun 25, 2015 at 09:33:44PM +0200, George Michaelson wrote: > > For your information, APNIC Hostmasters have moved to a mode of > > operation where for inetnum owners where the AS holder is not the >same > > person, and a request is lodged with helpdesk for assistance, the > > hostmasters manually override and create the object for the inetnum > > holder, only removing it if an AS holder objects. The inetnum holder > > needs to be recognised in our systems. > > > > Its a hand-mediated inetnum-only route object. Previous practice was > > to wait for explicit approval from the AS holder. Now, its created > > first, and withdrawn if there is an objection. > > > > There have been no complaints. APNIC HM are considering portal >changes > > and other process work to automate this. > > What is the benefit of the hand-mediation? > Or is that just an artifact > of the software implementation? > > Its an artefact of the s/w implementation. I imagine once they work >out how to do this in the portal, this will be changed. > > Does APNIC send a notification to the AS > holder that an object was created in which they were referenced? > > Yes. The following template is used: > > ====== > > Dear (ASN custodian), > This is to inform you that the following route/route6 object has been >registered in the APNIC Whois Database with your AS number referenced >in the "origin" attribute. > > --- > insert route object > --- > > The IP addresses holder has asked that APNIC help register this route >object in the APNIC Whois database. > > If you believe your AS number should not be referenced as the "origin" >in this route object, please contact us by replying to this email. > > Kind Regards, > > ====== > > cheers > > -George > > > Kind regards, > > Job > End of db-wg Digest, Vol 47, Issue 1 ************************************

1 0

Re: [db-wg] re-evaluate route-object authorisation model
by George Michaelson 27 Jun '15

27 Jun '15

On 27 June 2015 at 09:17, Job Snijders <job(a)ntt.net> wrote: > On Sat, Jun 27, 2015 at 06:32:10AM +0200, George Michaelson wrote: > > > > and note that, with one mouth, job has said that the ripe irr is the > > > > only one he will trust. > > > > > > Unsure if i follow you exactly, but indeed, I only trust the RIPE IRR > > > when it comes to RIPE managed space. > > > > Why then, do you expect anyone to trust RIPE IRR for all the un-RIPE > > managed space which can be freely added, to permit RIPE managed space > > related objects to be made? > > I don't recall expecting that? Did i in some earlier email forget to > insert a criticial 'not' in a sentence or something? > So those route objects which refer to RIPE managed space, and non-RIPE managed space. Do you filter them out? The ones which have non-RIPE objects inserted? I thought you meant that if it was in the RIPE IRR you trusted it. I didn't realize you were performing a post-check on the origination of the referred elements in route and other objects. Sorry _G > > > Surely from a consistency point of view (and yes, its reductionist, > > but so is software) this means we shouldn't be trusting all the > > additional objects added 'for your convenience' under the open > > password maintainer? > > Yes, the open password maintainer is a thorn in our side. Relevant to > the discussion: https://ripe70.ripe.net/archives/video/132/ (Title is > actually 'IRR Homing project') > If we're clear that a goal is to stop having it, and by implication stop having out-of-region data inserted into the RIPE IRR Thats good!

2 1

Re: [db-wg] re-evaluate route-object authorisation model
by George Michaelson 27 Jun '15

27 Jun '15

> > > > and note that, with one mouth, job has said that the ripe irr is the > > only one he will trust. > > Unsure if i follow you exactly, but indeed, I only trust the RIPE IRR > when it comes to RIPE managed space. > Why then, do you expect anyone to trust RIPE IRR for all the un-RIPE managed space which can be freely added, to permit RIPE managed space related objects to be made? Surely from a consistency point of view (and yes, its reductionist, but so is software) this means we shouldn't be trusting all the additional objects added 'for your convenience' under the open password maintainer? -G > > Kind regards, > > Job > >

2 1

Re: [db-wg] re-evaluate route-object authorisation model
by snash 26 Jun '15

26 Jun '15

Job Responding to the Questions in your 13 May email, thanks for helping me get up to speed. | - should the authorisation model work differently for RIPE managed | space versus non-RIPE managed space? Should we even continue to | allow route-objects covering non-RIPE managed space? No. Authorisation for an AS to originate a route needs to come from the maintainer of the address space. If the address space is assigned by a different RIR then Creating a Route Object in RIPE should be disallowed. Legacy v4 may need special case, I do not know. However, a global routing information database will need to contain copies of information from other regions, but it would support no modification of the copied records. Mirror only. | - should the authorisation model work differently when creating a | route-object for RIPE managed space with a non-RIPE managed | autnum? If yes, how so? No. We should follow the more recent thinking behind RPKI: "the design of the rpki is that an address resource holder is the sole authority over what ASs may announce that resource", Randy Bush | - although in this idea the autnum owner is no longer required to | approve /creation/ of a route-object, would it be a good idea to | allow the autnum owner to /delete/ any route-object in which their | autnum is referenced as origin? I see no need, since the AS still has the choice whether or not to announce the route. The database grants authority, not compulsion, to announce. | - Is RFC 2725 the only reason why the authorisation model was | implemented as it was implemented, can someone remember practical | reasons for doing it this way? During the BoF it was pointed out | that any potential DoS vector already exists today. Wilfried Woeber's concerns in 2006 seem largely to be about accreditation and authority of what is now the inetnum maintainer. Those concerns may still be valid, and may need addressing, but are not directly related to this discussion. The worst examples of IRR seem to have many exploitable faults independently of this. Our objective is to inspire confidence in RIPE's routing database for use in routing policy, to facilitate the completeness of the routing database by reducing a hindrance to maintaining its correctness, whilst retaining the higher standards adopted in RIPE. Steve Nash

4 5

Re: [db-wg] Temporary origins
by George Michaelson 25 Jun '15

25 Jun '15

For your information, APNIC Hostmasters have moved to a mode of operation where for inetnum owners where the AS holder is not the same person, and a request is lodged with helpdesk for assistance, the hostmasters manually override and create the object for the inetnum holder, only removing it if an AS holder objects. The inetnum holder needs to be recognised in our systems. Its a hand-mediated inetnum-only route object. Previous practice was to wait for explicit approval from the AS holder. Now, its created first, and withdrawn if there is an objection. There have been no complaints. APNIC HM are considering portal changes and other process work to automate this. -George On 25 June 2015 at 21:24, Gert Doering <gert(a)space.net> wrote: > Hi, > > On Thu, Jun 25, 2015 at 09:17:12PM +0200, Havard Eidnes wrote: > > Think of the "route" objects in the IRR as "these may be > > announced", not "these *are* being announced", and in a > > transition phase for a prefix (re-homing to another ISP), two > > route objects for the same route will be required. > > ... and there is nothing wrong with that. > > Just to spell it out again very explicitely. > > gert > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >

2 1

Temporary origins
by snash 25 Jun '15

25 Jun '15

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. 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. Temporary redirection is often accomplished by BGP announcement. There was some discussion of the ownership of address-blocks by an AS. 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" (4), not an AS with which it might normally be associated. rfc 2725 also says, in section 9.4 route objects: "There is a legitimate reason to be in more than one origin AS." 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 inetnum to originate a route. However RIPE current documentation opposes this, "authorisation for creation of route(6) objects can and must be provided by both the address space holder and the holder of the AS number" (5) . 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 (1). Indeed the motivation for this discussion was to create policy for selecting routes in MOAS cases. I would like to propose for discussion that a basic set of objectives might be: 1. An inetnum 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); that maintainer has the responsibility to identify which ASNs are entitled to announce an origin for that inetnum, and to register allowed ASNs in the IRR of that RIR. In this way the authentication of the person and their right to make changes stays within the one RIR. It is of no significance whether the ASNs identified are registered in the same RIR, or not. 2. Clarification, if necessary, that more than one route object for a subnet is permitted, where each RO has a different originAS. I have found no prohibition of multiple route objects for the same subnet. If one exists we should review its merit. 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. Data structures may also need to be adjusted to accommodate more than one authorised originator. 3. The 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. If this is useful. Notes: a. More than one route object record with different originAS may be appropriate: - where there is multi-homing without BGP or - where organisations make use of BGP redirection for temporary third-party services, like DDoS mitigation b. rfc 1930 (BCP-6) section 7 says: "Generally, a prefix can should belong to only one AS". 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. c. There seems to me to be some ambiguity about route objects and Origin. rfc 2725, section 9.4 route objects (3) says: "There is a legitimate reason to be in more than one origin AS." 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? I suggest that the authority should reside with the inetnum maintainer. This makes the origin part of a route object rather than an attribute of inetnum. 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. References: (1) http://www.cs.colostate.edu/~massey/pubs/conf/massey_imw01.pdf An Analysis of BGP Multiple Origin AS (MOAS) Conflicts {Xiaoliang Zhao, Dan Pei, Lan Wang, Dan Massey, Allison Mankin, S. Felix Wu,Lixia Zhang} (2) https://tools.ietf.org/html/rfc1930 BCP-6 (3) https://tools.ietf.org/html/rfc2725#page-12 (4) http://www.potaroo.net/ispcol/2011-07/bgpsec.html {Bush & Huston} (5) https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… ________________________ Steve Nash CEng MIET Consulting Engineer Arbor Networks office +44 118 967 4917 mobile +44 772 029 1359 http://www.arbornetworks.com/ ________________________

7 7

Temporary origins
by snash 24 Jun '15

24 Jun '15

Thanks for comments. My interest was to continue the discussion that Job hosted at RIPE70, and to get to some guidelines for those that need to exploit temporary redirection with BGP; whether customers or providers of services. Job, thanks for your observation that "the RIPE database supports this, you can create multiple route-objects covering the same prefix but with different "origin:" values.". Randy states agreement. However, this does conflict with some other Internet documents, like BCP-6. That can only be confusing and may inhibit global consensus. If IETF BCP documents are inaccurate then the RIPE community has some responsibility to point it out. The dual authorisation that RIPE requires on a ROUTE object seems an unnecessary hurdle, and gives rise to the cross-border concern that Job raised in the BoF. The consensus from RPKI seems to be that the inetnum maintainer has the authority to grant ROA. I do not know the history of why RIPE asks for AS maintainer also. Is there still some good reason? (If so, I am puzzled that it does not apply to RPKI, but that is a separate discussion). Removing the AS maintainer from the route object Creation authorisation seems to solve the cross-region problem. Are there reasons not to do this? Job mentioned that RaDB seems to have neither authorisation requirement, so creating a global view of the IRR is challenging without policy agreement leading to trust on these things. Summary: 1/ ask IETF to update BCP-6. Is this something RIPE NCC should do? 2/ discuss why AS maintainer authorisation is required for RIPE ROUTE object Creation. I subsequently read the article by Den Is May 2015, which comments that there is no written policy for IRR. Steve

3 2

Personalised authorisation
by Sascha Luck [ml] 19 Jun '15

19 Jun '15

Hi Alex, > Our current proposal allows authorisation on person objects for > those who want it, through maintainer objects Does this mean that calling a maintained object will spit out a reference to a mntner: object which will spit out a ton of references to person: objects which are authorised to make changes on the original object? rgds, Sascha Luck

2 2

[training] RIPE NCC Webinars - new dates
by Training Services 18 Jun '15

18 Jun '15

Dear colleagues, We are pleased to announce the dates for the RIPE NCC Webinars for the coming quarter. These interactive on-line learning sessions take about one hour, and give you the opportunity to learn and interact with our trainers without leaving your desk. In the next 3 months you can participate in the following Webinars: - Advanced RIPE Atlas Usage (NEW!) - Introduction to the RIPE Database - RIPE Database - Advanced Topics - IPv6 in the RIPE Database - IPv6 Addressing Plan - Webinar for New LIRs - Resource Certification (RPKI) Register now at https://www.ripe.net/support/training/learn-online/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have any questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0