Tuesday-Amal-11AM
Tuesday, 28 October 2008 11:00
Address Policy WG
**
The address policy session resumed as�follows:
CHAIR: Hello everybody welcome to the third session of the Address Policy Working Group. First, we are going to continue the end of IPv4 part of the Working Group agenda, and then we are going to do some cross Working Group material, which involves certification and AS number notation. But first, we have the usage of the final /8 presentation by Philip, so I think we should start with that presentation.
Phillip Smith:
CHAIR: Sorry for the delay, the presentation seems missing. We will just take a minute while Philip brings a USB stick to work around the network not working. The presentation is on the way up here. Maybe a few words of introduction. You all know Phillip Smith from coming to RIPE meetings regularly. These two policy proposals is material that has been in the APNIC region and been discussed there and Philip thought it might be useful to, well to have something similar in the RIPE region so he volunteered to bring it up here. Let's see what you think about it. Thanks, Philip.
Phillip Smith: All right. Sorry about the delay, I did upload the slides but they seem to have disappeared somewhere, so this is proposal 2008 06 which is about the use of the final /8, Nigel Titley and I basically have put this one together and we have� we want to present it for the community here.
So this proposal is really all about how the RIPE NCC should handle the final /8 of IPv4 resources it holds once the the IANA pool has depleted.
So if we look a little bit at the history. In the RIPE region, we have had policy 2008 03 which requests IANA to allocate one /8 to each RIR. You heard Philliz talk about this one yesterday in other registry regions, it's basically been passed by all the registry regions so this policy is actually going to happen, and the goal that have one was so that each registry community could plan to use its final /8 in a way that suits its needs and so really, this proposal that Nigel and irputting forward here is just one offer of a potential plan.
Some of you probably remember going back through the history of all this, I wasn't wildly keen on 2008 03 because I am not quite sure what problem it solved but rather than complaining about it, knuckle down and try and do something suitable towards this final /8.
So, the situation in other registries, just a reminder what was mentioned yesterday: Well the APNIC region ended last call, special interest group chair for endorsement, and APNIC region basically /8 is taken out of APNIC's remaining pool once the IANA free pool has run out and from this /8 new and existing local Internet registries will receive minimumallocation at the time they request the resource, as well as a /16 being set aside for unforeseen circumstances.
Within the ARIN region this is in last call proposal 2008 05 reserves a /10 out of ARIN's v4 pool to facilitate v6 transition and in the LACNIC region they have already approved a proposal which is LAC 2008 04 which reserves a /12 once the IANA free pool has run out and from this 12 new LIRs receive a /22 and critical infrastructure receives a /24.
So, just going over the details of the proposal, so the first item is that new LIRs would receive the NCC's minimal allocation from this /8 regardless of the size or their needs. And they will receive this address space once they fulfil the criteria to receive v4 address according to RIPE NCC'sicalication policy at the time. The same thing applies to existing LIRs so it's not being restricted just to new, existing LIRs, they come back requiring more v4 resources, and during the period of this final /8, then again, they can receive the NCC's minimum allocation. And the third item is again like the APNIC proposal, is a /16 should be reserved for future use. As unforeseen. The reasoning for this is, well, we don't really know what future technologies are going to appear that may need v4 addresses, to facilitate their use in v6 or something. We just don't know. So we feel that it's prudent to hold the /16 in reserve just in case. Note that if this /16 is not used at all, then it just goes back into the pool to be covered by items one and two that I mentioned before.
So, looking at the arguments, arguments for basically are NCC's final /8 will have a special policy applicable to it so it avoids the risks of organisations crafting well justified, fully justified resource application and consuming the whole lot. I mean there is still many new networks being rolled out and it's quite feasible for somebody to produce an application that could justify an entire /8.
Arguments against: Well, you know, again these are from when I talked about proposal in the AP region. Some organisations can believe and they can demonstrate that they need more v4 addresses than NCC's minimum allocation but this final /8 isn't really intended to try and resolve people's growth issues at this stage, but it's really intended for the migration from v4 to 6 to try and give organisations enough v4 for Nats and all the rest so they can actually go and sensible deploy IPv6. There is also a fear that some organisations could set up multiple LIR registrations just to get more address space. I suppose all we can really say is that we request the NCC to be vigilant regarding these. I am sure there are organisations already who try and game the system but I suspect effort of going to set up new LIRs and so forth just to do this seems fairly extreme, to me.
There are other questions arising: And these were brought up in the discussion in the mailing list so far. There is a people observed it might be useful to link allocations made here directly to v6 allocation. We discussed this again in AP region, there were few people for but quite a large number of people felt we should be trying to force people to deploy v6. If people want to get stuck in a v4 ghetto that is really up to them. They should be able to make an intelligent and informed decision to deploy v6 without having a policy here just to try and force them to do it.
That is pretty much it.
CHAIR: Thanks, Philip, for explaining what this is all about. And well, welcome your feedback. We have quarter of an hour for discussion on this, so please voice your opinions on this. Nobody any opinion? Do you think this is useful? Do you think we shouldn't be impeding the market flow by preventing Deutsche Telecom from taking a /9 of the last /8? OK. I am being provocative. I see somebody going to the microphone.
AUDIENCE SPEAKER: I think it is an interesting proposal, I am wondering whether� sorry. Yes, I am wondering whether you want to impose any restriction on a second request from an existing LIR after the exhaustion of the free pool, so after� when we got into the last /8, I mean, because I understand an existing LIR can request whatever amount of address space it will be given only minimum allocation, is that correct? Speak.
SPEAKER: No they only get one
AUDIENCE SPEAKER: They cannot apply again?
SPEAKER: That's correct
AUDIENCE SPEAKER: It was not clear. Thank you.
CHAIR: I am just collecting my thoughts, Daniel RIPE NCC.
Daniel: Did I miss� I was slightly distracted, did I miss the justification for the size /8, because /8 to /21 is 13, two to the 13s is more than we have members currently
SPEAKER: 8192.
CHAIR: That is not so many more.
Daniel. The it's double.
CHAIR: I think we have 5,000 members right now. I think do you want directly to respond�
Randy Bush I want to speak to Daniel and I am a co author in APNIC of the proposal, not here. The idea is that� the reason is the whole /8 was many people said the reason for the global five eighths proposal was that we could plan for the end, and then some cynics said oh, well what is the plan, people said what is the plan, and some people said "I am not going to vote for the global /8 policy unless there is a plan." So this is the plan and that is why it's for the /8. Now, why there is so many pieces and the proposal in APNIC that passed is that those pieces are of the current minimal allocation size, and that is a very special thing and the reason is that one very distinct possibility is over the next ten years, we are going to see new entrants want to come in and what they want is they are an enterprise that can only get v6 space and they are going to use whatever the IETF can call Nat PT next year and going to need a little bit of v4 space in front of it and there is going to be a lot of them so that is why, yes, you only have 5,000 members, but there is a lot more of these little slices, and our guess is there will be even more.
Daniel: Because the minimum size is /22 in APNIC region so it's� under the current rules you are setting aside.
Randy: Correct� well, no, remember when we run out, two years from now we run out, we give you a /22 under this, our guess is two years later it might be a /27.
Daniel: Thank you. I wanted that exposed. And the other thing is just a clarification, I am not in a position to this proposal, not at all, in your proslide, Philip, you had this prevents, you know, your large� your bad large tier one ISP from taking last /8, obviously that is not the intention, Randy has just exposed the real intention and because that is not a real argument because they will take the last but one, right, so it's not going to change anything material, right.
Randy: But it leaves something for, in my case, grandchildren.
Daniel: That one I accept but people might get the impression that this is about preventing the last one to be�
Randy: Here he is.
Daniel: So this is not what it's really about, what Randy says is what it's really about. Just prevent misunderstanding.
CHAIR: I think it's two sides of the, to reserve something for Randy's grandchildren but mean to prevent Rudi from taking it. I saw Rob Blokzijl standing on the microphone and he is walking away now so maybe everything has been said. Well other comments, I seem to hear a little bit the wish for clarification in the proposal as it is written, but I don't see major objections coming up. Anybody really violently opposing to this? All the� well, the question needs to be asked, if I say we go forward with this and have it and going to to the next phase which would be review, and we already have violent opposition, then we might need more work. But I see you quite happily, well, reading e mail and agreeing with everything, so� and actually, many of you are looking my way sour not reading e mail, thanks. Yes, it's sort of hard standing up here and seeing everybody stare at their laptop screen so sometimes it makes me wonder� OK. Thanks, Philip, anyway. I think this would go to the mailing list and we work on the arguments to more precisely describe what this is about and why and what, maybe not Randy's grandchildren since they might live in the APNIC region but our own and let's go to the next one.
(Applause)
Phillip Smith: OK. I guess me again. So, yes, please all stare at your laptops as you did in the last one. So this is, next proposal which is basically about ensuring efficient use of historical v4 resources and I am on my own with this one. So, basically, the motivation behind this, well all v4 addresses will be allocated by around 201112, depending where we sit in the world, so I feel it's actually pretty important that the remaining v4 addresses should be allocated responsibly and fairly.
The current issue is this. That. LIRs applying for new v4 and allocations from the NCC only have to include past allocations received from the NCC so they don't have to declare any historical addresses that they may have received prior to receiving address space from the NCC.
And so, RIPE NCC basically only assess previous allocations that they have made, so if LIRs are received address space from elsewhere the NCC does not take this into account at all, so this could end up using up the remaining v4 pool more rapidly than is necessary. I mean these historical addresses could be sitting unused in a corner of a network on somebody's back pocket somewhere, hoping for, I don't know, what, something to come along in the future, so all this this is kind of counter to our goals of being economical and prudent especially with the coming times of scarcity of v4 addresses.
So by historical addresses I am basically referring to all v4 address space registered in the RIPE database so, not just address space that is registered by the RIPE NCC.
So the situation in other registry regions: And this is /KA and case of when the registry make new allocations so if ARIN and LACNIC they consider historical address assignments and allocations before they make new allocations.
APNIC, well proposal 066 passed at the APNIC meeting in Christchurch, that was really to consider historical assignments and allocations as well.
AfriNIC does not consider historical address assignments and allocations at all.
So the details of the proposal are basically these: That the criteria for receiving v4 addresses should be modified to include historical v4 address holdings so the NCC will now consider all v4 addresses registered in the RIPE whois database when assessing further allocations.
Quite a few arguments for: It ensures efficient use of address space resource. The use of historical v4 addresses will follow current best practices for the address management. The remaining v4 free pool will be allocated to LIRs that actually have a genuine need for these addresses and well, it's just carrying on the responsible usage of v4 resources.
Arguments again:
Well organisations can no longer hoard the historical v4 address space they have while at the same time receiving more v4 address space from the NCC's pool.
And that was pretty much it. Questions, comments and discussion?
CHAIR: OK. Thanks for presenting. I see Daniel standing in.
Daniel. RIPE NCC we just half an hour ago we discussed the need for an accurate registry. I think if it's worded like this, it will cause people from deregistering legacy address space in order to hide it from the RIPE database. Deregistering legacy address space from the RIPE database will not cause them to lose routing, so what we actually doing is we are providing incentives for making our data that we have less accurate. So that is a real concern I have about this because it's actually contrary to our goal to have an accurate registry. If I am� if this is implemented, there is a big incentive to scrap these things and since they are legacy they are not controlled in any way so he, whoever is the maintainer can just delete them and they will delete them. So, either we recognise that this is against that goal and we have to make a decision on which goal is more important, accurate registry or this kind of conservation, or we find a better way of quantifying that the research that needs to be done because we have the historic RIPE database, we have routing registries but that is operationly much more expensive so we might do further, to counter this we might say do further investigations, if you delete it we will still count it because it was there once but that becomes operationly� I am concerned about the incentive this provides to deregister.
CHAIR: Thanks for that and I think it is actually quite an important point to take into consideration. I personally have been thinking about maybe we could get somebody from the Hostmaster department, from the registration services department, (registration) to give us a few words, if possible, on whether you actually know who is owning what on the earlier registration. I know the NCC is keeping very close records an address space allocated by the NCC, so even if somebody managed to mess up the RIPE database you know it anyway, but for the early registrations I am not sure whether you actually can sort of pinpoint that this is the same organisation as this one, or you have just an INET num there which is not necessarily tied to the same organisation.
Ingrid: From RIPE NCC. From the early registration that is people contacted us to get a password, we know who is using it, from the big chunk that has not been updated since the early transfer project, we know as much as everybody here. So at the moment they have been in contact, we have updated, we have formalised some ranges. If nobody contacted us, it's out there.
CHAIR: So for that cases you actually need to do full text search, like if the university of something comes up and there is an early registration, that matches that name.
AUDIENCE SPEAKER: Assuming that the information is still correct. There have been case that is companies have changed over the years, I mean by others, so we only know what is there.
CHAIR: Thanks. So if we go that way, the implementation will definitely not be straightforward. OK let's go ahead with the line. I think Shane was next.
Shane: I understand and I kind of agree with Daniel's concerns but I mean specifically about deleting the records, these are� technological means can be used to prevent this kind of problem, so and I think there are incentives that are going to be probably not nice because all of a sudden you have incentive to hide information from the RIPE NCC where you really didn't have so much incentive before but I think the main reason that this is a problem now is because we didn't do it five years ago, so I'd say let's do it now instead of having the same exact proposal three years from now and then have a real real real problem, so I'd say let's go ahead and do it now and recognise that it is not going to be perfect and there are going to be issues that are going to arise from this, but we just have to deal with them. The whole management of the v4 space is going to get increasingly ugly, so that is just the way it is.
CHAIR: Thanks.
David: Am I correct in assuming that when an LIR makes assignments on to its own customers it would be expected to enforce this rule as well?
Philip: I haven't put that in, I mean, I could include that if that is desire. I am talking about allocations, as such. (Desire.)
David: OK. I don't wanton formally make that suggestion because I have concern about it. If it's not in there, then I see a kind of a loophole F it is in there, then I think I am not convinced� I could be convinced, but I am not at this time convinced that LIRs have all the tools at their disposal to reliably make that check consistently across every single LIR.
CHAIR: Thanks.
Rob: How much do you think we gain with this? One week, two weeks, or three weeks of IPv4, and given the fact that I think there are other issues surrounding the legacy address space which are much more important in my view, I would be very reluctant to approach legacy address space holders whom have sort of disappeared behind the horizon for a long time, with kind of this difficult thing. I would be much more interested in approaching them with a more positive attitude like, isn't it time to do proper registration of your address space and oh by the way, you are a prime target for address space hijacks in the near future. Would you like to have� ditch the certificate? I don't want to scare them off by approaching a few of them now with something that will gain us, I don't know, even if it is a couple of months, because it can't be that much, and this final game, this end game fine tuning of a few knobs, I think we shouldn't go to that direction too much because it's a matter of weeks or months we shift the day that somebody asks for an address block, according to all our policies and we have to say "sorry, it's over." And so, I feel that there are side effects to this, if you look at it in an isolated way, a reasonable policy that we might not want top create. So (unreasonable) I think on the whole I would not be happy with this.
Philip: I probably should point out that it's really just for LIRs who also have address space that is kind of hidden away somewhere, that is� that they never got from the RIPE NCC. I don't envisage the NCC will go chasing after people they haven't heard of for years, because we are just not covering this at all. It's purely those RIRs that still have addresses that they got from elsewhere. So I mean, the context, if I put the context in the AP region. This was in the context of the transfer proposal that we had, there was a concern that LIRs in the APNIC region could transfer address space that they had got from APNIC� sorry address space� they could transfer historical address space or sell it or whatever, but then go back to APNIC and get more addresses so it's kind of concern about this, so this was really to try and bring the whole thing into the APNIC, I suppose, assessment bucket, if you like, so they can't get this sort of taking address space out of the public pool, if you like, and then selling whatever for profit, the address that is they had kept behind themselves.
Daniel: I said before that we have to� will have to make a determination on whether the goal of actually getting accurate registry or gaining a few tweaks say it in Rob's words is more important than� and thinking about it, I agree with Rob, that the accurate registration is the thing that we need in the long term, we need after v4 runs out, we need for a stable network and we need� our communities needs basically, I believe that very strongly, so my judgement would be or my preference would be very much in line with Rob's and say let's not try to fix something, you know, gain a couple of weeks or even months before it runs out, but let's focus on the long term goal and that is accurate registration. So that is to the policy. And then for the record, to add to what Ingrid was saying from the registration services department in the RIPE NCC, at the moment it looks grim and she basically said it looks grim, to actually find stuff. That doesn't mean we are not doing anything; actually, I am personally driving an effort in the RIPE NCC to actually assess the quality of our registration data, and to publish the results, and actually do this retrospectively so we can see over the last, 5, 67 years, how the quality of our registration data improves or deteriorates and to see where we can put our efforts� best focus our efforts to make improvements and that obviously, the easy targets are the address space that we are not concerned with in this proposal, the one that we were in the chain but very definitely on our radar screen is also the legacy stuff, so we are working on it, I just wanted to say that for the record so it doesn't appear like we say it's bad and we have threw up our hands. We are spending significant resources to improve the situation in the legacy and space just for the record.
Shane: Let me say that that is very cool, that is really good for the RIPE NCC.
AUDIENCE SPEAKER: Would you like to help Shane Shane sure. I think it's a bit of a false dichotomy meaning we don't have to choose about being responsible about how we handle this legacy space and having accurate registration of it. I think both are possible and it's going to be expensive but the cost of maintaining the v4 blocks are going to be increasingly higher and hopefully some magical day in the future it will be higher than getting v6 set up on your network. That is the dream, right? But I also think it doesn't really matter how much time we save by bringing these legacy spaces into the pool; it's a question of fairness and that is going to be very important when people from outside the community look at the processes that go on here. There is already a lot of misinformation about this and there has been attempts for years and years to kind of cure this misinformation but it's not going to work because, increasingly as it becomes more expensive and difficult to get new address space people who have never looked at this, have never looked at allocation policy before are going to start looking and they are not going to have the education and not going to know how things came to be the way they are and if they can say, look, there is these people with dozens of /16 and I can't get get /26 /#24* we are going to say unfair and they are right, we need to bring this space in regardless of how much time it buys us in the end. That is all.
CHAIR: I see no more people�
AUDIENCE SPEAKER: Well, Phil, the proposal is like the assignment process is� we are taking the data that the RIPE� that the RIPE NCC is seeing and making a final decision and no statement by the applicant about, that, well, OK they have actually presented their resources and their usage. My memory of 15 years ago or so, how we designed policies like them, I think was like, well, OK, the applicant tells what he has and it is his responsibility to provide that information and that could be requested now like 15 years ago. And well, Daniel's particular concerns probably would not apply if one actually says, well OK, the assignment is continual on that the represented information is true (conditional). If it turns out that someone is lying in large ways, it's kind of accepted practice in many places that, well, OK, the decisions will be revoked in some way.
CHAIR: I think that might actually be a good way to move this forward to reformulate this in a way that it doesn't hide the RIPE database but just requires the applicant to provide documentation about their address space, and if they are purposely omitting things, and the NCC finds out later on, then big stick, no carrot. So I suggest to, well, take into account what has been said, bring this back to the mailing list and then discuss the new wording with all these comments taken into account. I would ask the NCC to sort of help us do a reality check on this, whether you think this is feasible from the registration services side and I think Philliz will do the impact analysis, anyway, so we will get some feedback on is this going to work or is this just to make the NCC explode and you need 200 new host masters. OK, thank you all, thanks, Philip.
(Applause)
Chair: The next one on my list of victims for the tomatoes is Nigel Titley. As you are aware, hopefully, there has been a certification task force, well there still is a certification task force that is working on the mechanics and what sort of software do we need, what sort of processes do we need to get resource certificates issued by the RIPE NCC so that, eventually, you can really prove to be the holder of address space, prove that a certain AS is permitted by the holder of address space to actually advertise that address space into the routing system and that way prevent address space hijacks, prevent mistakes and prevent lots of evil things (hijacks).
The Certification Task Force has come up with a formal proposal, it was already presented as sort of an informal "please give us feedback" in Berlin. Now we have a formal proposal on, well, how to get the process started, basically. I can continue talking and explain about the proposal and anything but I would prefer for the machine to work and Nigel to do this.
Nigel: Thank you. As has been said, this policy proposal although it's got my name on it, it comes out of the Certification Authority Task Force. You should view me as a kind of medium channeling the spiritual essence of the Certification Task Force at this point which means of course I can deny all responsibility, which is lovely.
Quite summary: As you probably all know the RIPE NCC is planning to deploy a certification service, I think there is a presentation on this at some point later on in the conference. And this proposal lays out the guidelines for the initial way in which LIRs can receive certificates over specifically their provider aggregatable address space and how they can maintain these certificates.
As regards the mechanics of certification, it's not really relevant to the policy here and I don't propose to discuss it.
The scope: It's address space issued in the RIPE NCC service region only, as you might expect, and it's PA address space only. We have had to make this quite clear because a number of people have said, does it apply to ASs and PI and all the rest of it, but it doesn't.
Details:
The RIPE NCC will issue certificates upon request so you actually have to request these, we don't issue them automatically. They are only there if you ask for them. And the only people that can address, ask for certificates are a RIPE NCC member LIR. You have got a whole PA address space, fairly obviously, I suppose.
RIPE NCC, what� when it gets a request, may, note the may, ask for further details to ensure that you are actually� the correct holder for this address space. And then having decided that, the certificate will be issued via a secure channel and, again, this secure channel is left for further study, although the proposal is, at the moment, to use the LIR Portal. There have been opinions expressed maybe this isn't a secure channel, and again, this is reserved for future study and the validity period for the certificates is anything up to 18 months.
Renewal and maintenance is available to LIRs with an appropriate contractual relationship and that becomes important as you look later on in the proposal. And if that address space is revoked, it is returned or withdrawn, then the certificates are revoked, fairly obvious, really.
If there is a security breach, if you have left your securities in a tube train or put them on a CD and sent them through the post and somebody pinches them, then new certificates can be issued and the validity period is equal to the remaining validity of the revoked certificate so you can't artificially extend by leaving them on a tube train or getting them pinched.
The next bits are about what happens if you stop being or you stop having a contract with the RIPE NCC. If that contractual relationship ceases, i.e. if you don't pay your bills, or you become bankrupt or whatever, then the certificates may be revoked by the RIPE NCC, and in order to provide some sort of comfort factor for large organisations that have difficulty paying bills, there will be quite a bit of notification and a grace period and note the may be revoked as well, the RIPE NCC reserves the right to revoke certificates but may in actual fact not do so. Whatever. OK.
The pros for the proposal: It divides definitive proof of the right of use of PA address space. It doesn't say ownership. One day, if there is ever a secure routing system, then it may enable secure routing. It strengthens the relationship between the RIPE NCC and the member, quite obviously, and another pro, it may enable a secure trading market.
Cons: If secure routing becomes a reality, then it is a single point of failure. Revocation of certificates could actually prevent routing of particular PA address space. There are international government implications, there may well be some governments that see this as an abrowication of their rights, possibly. We have seen this sort of thing come up in the E164 delegation arena. And there is the problem of large organisations that can't pay their bills on time, they could find that their PA address space suddenly doesn't get routed. And the other con is that it may enable a secure trading market. It depends on your point of view, of course.
Any questions? And as I say, I am channeling the CA Task Force at this point so I may answer questions to them.
CHAIR: OK, Nigel, thanks for presenting and thanks to the task force for actually working out the mechanics to get this started.
AUDIENCE SPEAKER: John. Just a quick question, I am having some trouble trying to understand why certificates would expire on a regular basis so for the use of policy� of address space has been tied to the continued need for its use and the� performance to the policy of the requester, why, suddenly, would you have to renew the� something you didn't have to renew earlier? Why� I mean if you give a certificate, give a certificate. If there is a problem with security, if it needs to be revoked it can be revoked.
SPEAKER: I think it's generally regarded in security circles that the certificates and such like should regularly expire.
AUDIENCE SPEAKER: It's actually a basic feature of the PKI technology that is used, that every certificate has a limited lifespan.
John: 100 years.
Randy: I think I can rephrase. If I maintain my� Randy Bush IIJ� if I maintain my membership, then I will get a new certificate every year, the new certificate will be issued, you know, three weeks before the old one dies, etc.. so /SKWRO*EL's I think to put words in your mouth, what he is really saying is, currently, even if I don't renew my contract with RIPE, etc., etc., we currently do not revoke their address space, and by letting the certificate expire without issuing a new one, you are effectively revoking their address space.
SPEAKER: Correct. Randy: And that is a major policy change
SPEAKER: Correct.
CHAIR: Well actually we are revoking address space, if LIR is refuse to go pay their bills for long enough, they will be closed and the address space will be revoked. What we cannot do today is to stop it from being routed if, people just want to do. I see heads shaking, OK. Maybe I issued just go on in sequence. I think you are next.
AUDIENCE SPEAKER: Robert: There is a technical reason for doing this and that is when you revoke certificate they are put on to the revocation list and if the certificates have practically infinite lifetime and list practically gross. You can argue how long you want to make it but you shouldn't make it arbitrarily long so it shouldn't be multiples of dozens of years or ago.
Joel: Certificate renovation to continued membership because that is not how things work. I am not aware that anyone has had address space withdrawn because they cease to be members of RIPE NCC. They have had services suspended such as reverse mapping, another in addr.arpa service but not the address space itself.
SPEAKER: Just because it's not been invoked doesn't mean to say that the right doesn't exist.
CHAIR: Who are you?
AUDIENCE SPEAKER: Me?
Remco: And not presenting anybody. I would say that it is a very bad idea to limit what you can do in policy to whatever implementation you have chosen in technology, and I think well, certificates by themselves are good idea, perhaps choosing a certificate with a limited lifetime for technical reasons is is a bad idea.
CHAIR: So what is your suggestion; how to go ahead?
Remco: Find the technology that doesn't have the limitation.
SPEAKER: I don't see any particular reason why we shouldn't extend certificate lifetimes. We can still revoke certificates when the contractual relationship ends. Anyone from the CA TF would like to comment on that? I think 18 months was a fairly arbitrary decision.
CHAIR: I see Robert and Rudger here. Robert went into hiding. /A*UD.
SPEAKER: The question is whether there is a particular reason for having a short, well, fairly short certificate lifetime or whether we could extends that.
AUDIENCE SPEAKER: Well, first of all, the initial proposal for the 18 months was for a maximum of 18 months� was a minimum of 18 months, and turning a maximum� turning a minimum into a maximum of course is semantic significant, and so yes, well OK, obviously, obviously the idea doing short lifespan is expecting that revocations otherwise would have to be done fairly often and dealing with revocation lists is painful and down side or one of not so nice sides of PKIs.
CHAIR: I think I see Ingrid standing up to say a few words from the registration services.
Ingrid: Yes in response to Joel's comment on whether or not we take back over the last year more or less we have been contacting closed LIRs that had still allocations and announced and not announced, checking up whether they were still using them and if not, we have taken back quite a few blocks there.
AUDIENCE SPEAKER: That is conforming to policy. If there is no demonstrated use, the� if there is no longer a demonstrated need for these address spaces it can be reclaimed. At no time that I am aware of has this� the LIR continued membership. Two different things.
Ingrid: Yes, we spoke to the LIR to check what they were doing with the space if they needed it. If not, we took it back in agreement with them and in cases of violation of the policies of course.
CHAIR: What happens if gets address space from the NCC and then resides in the remaining lifetime of IPv4 I am not getting address space anyway so I am stop paying my bills but keeps using the address space what happens today?
Ingrid: At some point we will contact them as part of this project asking them what they are doing with it.
CHAIR: I would say I will just keep it because I like it. What do you do next? Where is your stick?
Ingrid: That is good question. At the moment, we don't really have a mandate to take it back if they said they need it and they are using it.
CHAIR: OK. In indeed Randy is right, this is� this would be a fairly significant change in policy. This procedure would then give you a stick and also sort of mandate use of the stick to revoke all certificates when an LIR closes down or is just not paying their bill, so this needs to be seriously considered. I abstain on saying whether I think that is good thing or not because that is standing up here, this is not my role. You, as a community, need to decide on what you want to see. I think Randy was next and then Robert and Dave Wilson.
Randy Bush: IIJ. Two things: Number one is what that little bit did was move effectively revocation of address space from revocation policy, which is worth discussing and doing, to certificate policy, and I think as has been pointed out, that is dangerous. The point that I am worried about further is, this is going to discourage people from playing in the certificate game, and I think the certificate game is extremely important in the long run and the mid run for routing security, and I want people to feel comfortable with certificates and not say "oh my God, if I start using certificates, if the community starts using routing security, I am going to argue against it because the RIR controls my routing." Right? I stop paying the bill and all of a /SURBGSD my packets don't move. (Sudden) and so I think this is� this is effectively, in the long term when routing is tied to these certificates, that this becomes address space revocation or return or grabbing or whatever you want to call it and so, therefore, the policy the how these� of expiration times, is one of revocation policy, not of certificate policy.
CHAIR: OK. So if I hear this right, I think one possible approach to this could be to reword the certificate policy in a way that says, as long as the address space is assigned, the NCC will continue to renew the certificate on a regularly basis Randy of the: And we all agree on short certificate lives.
CHAIR: We are use whatever lifetime is practical. And at the same time, we need to start an effort to define what we want our revocation policy to be but it would be a different policy document. I see Joel nodding as well so I think that is� what we are going to do with it anyway. But more comment. I see Robert.
Robert: The certificates are not there to introduce any new process in terms of assignment and revocation of address space. Certificates are there to provide a more secure means of being able to prove that you are the legitimate holder of any address space, right? So in this sense, revocation of the certificates and issuance of the certificates are going to be tied with the actual fact of holding some address space, so there is nothing� the policy should mirror that. That is my personal opinion. Back on the 18 months question, the reason for picking 18 months was that it is expected that when an LIR pays its annual fee, then they will receive the certificate until like mid next year or so, so that is roughly 18 months, it could be shorter, it could be longer. The basic idea that was said by Randy as well, is that we will give out the certificate as long as the LIR holds the resource for the� the end user holds the resource, if that is going to happen. Nothing new there.
SPEAKER: In which case we need to reword the proposal.
AUDIENCE SPEAKER: Can you put those words up?
SPEAKER: Sorry, which one?
AUDIENCE SPEAKER: The 18 months.
SPEAKER: There.
AUDIENCE SPEAKER: So there is no significance of the number 18 there; it could be one, it could be 60 but it couldn't be 600, that is for technical reasons.
SPEAKER: Right.
CHAIR: OK. Actually, it's Dave's turn but I see Jabber and� that might be a response to something more earlier.
AUDIENCE SPEAKER: From the NCC. I have a question from mark /STO*EL I can't have. Who will the decide to stop contractual relationship and revoke IPv4 network and how? Will the� will the core decision be mandatory or not, which country will be use /STPH D sure there will be a lot of cases where RIPE will cause contracts and get back the resource but the end user disagrees with the decision, how can this be so?
SPEAKER: I guess since the contract with the RIPE NCC is under Dutch law.
CHAIR: Well, there is a contract that says you pay money, the contract goes on. You stop paying money, the contract expires but I am not a lawyer. Randy: We just separated the contracts from the certificates. Fair ticket.
CHAIR: And basically, we managed to get these out of this policy discussion which I think is help envelope moving forward. Dave now, finally.
Dave Wilson: I will be quick because I think I am now only supporting what has already been said. It is already the case that, I want to emphasise, if there is a change in my address status in the RIPE database, this has an impact on my routing. If my addresses disappear from the RIPE database tomorrow then at 6�o'clock the following morning some of my peers and up streams will no longer accept announcements. I see nothing new, so if you are buying certificates to the RIPE database and separate it I see no change.
CHAIR: Rudger.
Rudger: Well, let me just state full agreement with the arguments of Randy and make the remark that, while, OK, there are people who think that routing checks based on the data that will be produced here can be done real quick and the techniques as such will actually help to (techniques) create more secure routing globally, which, OK, facing the lack of good information and homogenous solutions around the globe is not possible at the moment, so the question, well, OK, what are the consequences of a policies we are deciding here for routing security come in very quickly and, indeed, we want to have our policies done in a way so that people will feel secure and fine by moving forward to more secure routing.
CHAIR: Thank you. I ask ago that first because of Jabber.
AUDIENCE SPEAKER: I have a question from Leo this time. If the certificate can be renewed without a current business relationship with the RIPE NCC (I stop paying my bills) how will you RIPE NCC know how to use the certificate.
AUDIENCE SPEAKER: Bingo.
CHAIR: Well the certificate isn't actually issued to somebody, well, it's�
AUDIENCE SPEAKER: It is.
CHAIR: Well it's a private key that is sent to a person, of course if that person may no longer be known, it's getting somewhat awkward. Well, David.
Daniel: The answer to Leo's question is that it can't, very easily.
Randy: When the contract is still there, the RIPE NCC still can't use the certificate. The RIPE NCC does not use certificate, period.
AUDIENCE SPEAKER: That is true. But it's somewhat related to the point I was going to make, Daniel again. We have discussed here policies and the goal of getting a good registration on address space holders and that is a good thing, that is something that we want for stability. If we go and issue certificates with a very long lifetime, and only the possession of the private key will be used for anything consequential in routing, trading, in what not, the consequence will be that we will lose the registration because as Leo has pointed out, if there is no legal relationship between a certificate holder and a regional registry, we will not know who the certificate holder is. If we don't care, then we don't need to do the thing that is on the second� in the second bullet. If we do care we do need to do that and I agree with Randy, it's some father this creates is somewhat counterproductive so we have to� in my opinion, we have to find a way to do this and take away the fear at the same time if we can do that.
Randy Bush: IIJ. Daniel, it's first of all, known is suggest ago long cert, it's the auto renewal. It has the problem, irrelevant. You are going to be reissuing certs to somebody who is not responding to you having no contract. Agreed that that is a problem of identification and keeping data current, but the point people are making is, solve that in your keep data current, you have been allocated this policy. Don't solve it by making people fear the routing system. And just to be clear, for those people who track the IETF, you will see a new Internet draft this morning in the CIDR Working Group on using this RPKI for how it will be used to validate an origin. And that is a draft co operatively by a couple of strange geeks, SISCO and Juniper. In other words the routing stuff is real.
CHAIR: Which is good news.
Daniel: As a draft.
CHAIR: OK. I think what we definitely going to need is a clear revocation policy to address the point of if, I don't know that person any longer, where am I going to send the revocation certificate to. The renewal certificate to, not the revocation. Randy. No, no the certificates in the RPKI do not tie this to waiting for the whole process that is going to be a refivation policy for two reasons: One it's not necessary, but two, discussing pulling back address space, I don't think is going to be a very short discussion.
CHAIR: I wasn't actually suggesting holding up this proposal before we have revocation policy; I was actually trying to get to the point that we need a revocation policy because we don't have one, and LIRs acting badly are not� we don't have formal decision what we are going to do with badly acting LIRs. At the same time, we want this to go forward but with changes obviously, so the way forward is, I think, incorporates the spirit of what has been said and bring it back to the list.
AUDIENCE SPEAKER: Just wanted to clarify one thing about the current state of the policy, about revocation. Maybe it's not worded as a revocation policy in our document but there is a section which is called "closing an LIR" and it outlines when such a thing can happen and the last sentence is "the RIPE NCC takes on responsibility for address space hold by closing LIRs." So that is the related bit that you may want to work on as a Working Group, revocation policy, if you would like to. Just information.
CHAIR: I would welcome to and volunteer to draft, well, somewhat more detailed revocation policy. OK. I see Robert and /KAOUD Kerr still standing.
Robert: Speaking as an individual. I do think that since the certificates are mirroring the facts of life, right, they are not there to create new facts, they are there to create� to represent what is true, maybe we should not mention how this is done but we should only mention that the NCC should give out certificates over really resource for real holders of the resources and how we do it, how the NCC does it, sorry, is a procedural question. Maybe it shouldn't go into the policy. That is as an open question.
Rudger: I am tempted to ask, well, OK, is the wording that on withdrawal or return of address space, certificates will be revoked, not clear enough? The sentence kind of silently assumes that a proper procedure for doing that is actually in place and used.
CHAIR: We need to go over the text. That much is clear, to me.
SPEAKER: I think we have enough information to redraft the policy and resubmit it. Randy Bush: Thank you, by the way, this is real progress, you know, just because we found one little knit in it doesn't Mcit bad. We are engineers so we are talking about the problems instead of the success and this is a success. Thank you.
CHAIR: Thank you. Actually�
(Applause)
CHAIR: Thank you. The next one will have to be presented by me because the original proposer couldn't be here. Actually, I want to, even if you sort of find it a bit funny at times, thank you to, that you actually say your name all the time. For those in the rooms not a big thing because we see you and after the 942nd one, we know who you are, but the persons listening to the webcast don't always see or recognise you so for them it's helpful.
This is actually going to be a pretty quick one, I think. We have this AS number assignment policy that was changed to take 4 byte AS numbers into account. At that time, it was expected that the way these 4 byte AS numbers would be written was in a format called AS.that, means 16 bit.and then the second 16 bit of the 32 bit of the number. Like AS 3.3 for 4 byte AS number being assigned by the RIPE NCC, one specific example. There has been lots of discussion in various places, quite heated discussion, about which is the proper way to write 4 byte AS number. Actually, the discussion doesn't belong in the Address Policy Working Group at all, but we made the mistake of writing the specific format into our policy document, so the policy document now says 4 byte only AS numbers is written as 1.O265536.65535, and if everybody else agrees that this is not the way to write a 32 bit AS number, our policy looks a bit weird. So the proposal is about changing this specific wording to this specific wording, just to changing the way the numbers are written. There is pros and cons to it. I am not taking any side in this; I have my own opinion, but this is the way the proposal is written. The proposer says that ASPLAIN is having wide support. The ITF is progressing draft document to standard that says ASPLAIN is the way it should be written. There is some technical argument that filtering in routers which is using.sto express any character is going to be awkward if you have dots in the AS numbers. The claim is that router vendors appear to be supporting ASPLAIN
AUDIENCE SPEAKER: All?
SPEAKER: I don't know about Cisco. Juniper seems to be accepting both on input and ASPLAIN� they haven't been able to figure out what the filters index is using. That is the way it was written. The disadvantage of this would be that AS.is more easily remembered and the current database entries are actually entered into in the RIPE database in AS.notation.
Representing the AS presentations, one draft, there has been made to the address policy and routing and database Working Group mailing list this morning that this is� this has been approved by the IESG and is now sort of rapidly going to be an RFC, so I think whatever the benefits and drawbacks and implementation details and whatever of ASPLAIN and AS., I think the world is moving forward, well, (RFC) the routing people seemed to have decided� I claim the routing people because the ITF is not the address policy people. Even if Rudger is shaking his head. There has been lots of discussion on the proper way to express this. This policy is basically the ITF is going to say the standard is ASPLAIN so please change our documents the way the ITF says that this is the right way to do. I am not sure I can express this any more neutral.
Remco: I am in favour of changing the text as is proposed in this proposal, and I would also like to comment that any discussion on the merits between AS.and ASPLAIN should be at the ITF and not at this meeting.
SPEAKER: That is basically the stance I try to maintain.
Randy: I agree with Remco. I just cannot bring myself anywhere to discuss a dot. How stupid can we get. The question� by I the way, APNIC policy chair had on, we have passed a similar policy in APNIC. We are sitting on that policy because we did not make the mistake of putting things� putting either notation in our policies, so we don't need to push it through and what we said is, if the RFC comes out before the end of the year, we put our policy aside; if it doesn't, because we have to issue 4 byte AS numbers January 1st, we need the policy in place. We are hoping not to have to use it. But moving forward here to correct your text is something I think you have to do.
SPEAKER: Yes. Rudger.
Rudger: Well, OK, a couple of things. Some of these things look to me like, well, OK, they may be protocol, protocols should not be decided by policy actions. As far as protocols are actually the issue, well okay can we please, please make clear what protocols we are talking about. And when we are talking about protocols and changes at this time, I am surprised to find myself doubting the relevance of the IETF, if it comes out with irrelevant protocol definition, potentially on standard for something that has been done in the� in the base protocol a couple of years back and, actually, in the world already with some instanceiation of protocol, in particular RPSL as used in the registry databases with official policy actions two years ago, and coming in as a standards body and saying, two years after the world had to make up its mind how to operate on things, and two months before the known policies� well OK, we go from experimental to real production to, say, well, OK we change our mind, we think the protocols should be changed that has been around there and being a standards body claiming that interoperability is a big issue for them, well OK, I am really confused.
SPEAKER: I can share your sentiments (I can't). I would prefer to not have that discussion here but I am happy to sort of give inputs to the Routing Working Group that there might be some consideration needed
AUDIENCE SPEAKER: In the routing protocols there is absolutely no problem. There is senior representation, 32 bit string.
SPEAKER: Whatever. Dave.
Dave Wilson: I will be talking briefly at the Routing Working Group tomorrow about this but let me say this now as regards this Working Group: There is existing software deployed quite extensively that brakes in exciting and unpredictable ways on AS.we should make this change.
SPEAKER: We shouldn't start this discussion here.
Dave Wilson: OK.
Andrei: I would just like to know that 1st of January 2 now 9, doesn't probably� is not probably a milestone as regards to this particular proposal because we have been allocating 32 bit AS numbers with existing.notation for two years now.
SPEAKER: I am aware, this is actually going to affect existing registrations in the database as well, so the Working Group chairs have discussed this and database is aware that something will be ending up on their plate, as well. The question really is, who decides on how AS numbers get written and whether it's decimals, dots, colons, whatever in there, while I might not be happy with the way it happens, actually the IETF might be the right body to specify this as they are the technical standards body, and this is a notation for technical thing, it's not protocol per�se but it's a protocol element.
AUDIENCE SPEAKER: I wasn't questioning this proposal, I wasn't actually making any suggestion on the merits of this proposal; I was just from implementation point of view, because RIPE NCC will have to reimplement some of the stuff, we think 1st of January is not really a deadline or milestone.
SPEAKER: I think Marco first, /TP LS you want to directly respond.
Marco: I stated on the mailing list and here again, I think this shouldn't be a policy proposal; it's merely formative change it, doesn't touch the policy as such on how to design it and the discussion between ASPLAIN and AS.can be done in the IETF or we should it and discuss whether or not RIPE should follow international standards on how it should be adopted in policies when they change but not go over ASPLAIN or AS.whatever, change it at the moment it's a an RFP and leave this as such
SPEAKER: As it is today we cannot just change it. For upcoming policy changes, we are learning from this and we will try to avoid writing things in a way that if a standard body decides that notation changes it will affect us. All the other policies don't specifically mention how things are written. This is just here because it really wanted to be clear about what is a 4 byte, what is a 4 byte only.
AUDIENCE SPEAKER: I understand but I don't think in future we can, in general, avoid being depending on standards somewhere in a policy document, so maybe we should discuss the policy development process as well to see whether or not this is formatting changes are a change in policy or formatting changes are just and won't touch policy.
SPEAKER: The formatting thing will actually be on the agenda tomorrow, so we are taking this into account.
I think one last comment from Rudger and then we will wrap up.
Rudger: Deutsche Telecom. Identifying himself at last. The one thing that I am seeing that is actually of relevance is essentially a thing for the database Working Group. It is a change of the variant of RPSL that we have been using, and the point that I'm seeing is that, well, OK, if we are changing the RPSL protocol that we are using, even if it's minor syntax, I quite certainly want to see this done in a way that does inject less problems for the clients using the database than it has been done for the initial introduction of the extension.
SPEAKER: OK. I think this is important input to the database Working Group. I am not sure whether� yes, I see� I am not sure whether the database chair is in here, but I will make sure that he is aware of this, and this is sort of input to database, please think about this and come up with an implementation plan that will give people advance warning and will not make all the software explode.
AUDIENCE SPEAKER: Denis Walker, RIPE NCC. I think the implementation is a database issue. I think the bit that is relevant for this Working Group which I am still confused about is what is going to happen on the 1st of January. As far as I remember, two years ago the agreement was that all RIRs will start to issue 4 byte AS numbers by default on the 1st of January. Now, yesterday, when Philliz was talking about policy proposals, I saw that APNIC was going to do this on the 1st of July, so� is this a proposal�
Philliz: Can I make� that is not what they are going to do. By 1st of January, they will do the agreed thing, which is� which is common by all RIRs. By 1st of July 2009 if somebody who has been assigned a 4 byte ASN by default within the previous six months, can demonstrate that they can not use it, they will immediately change this with two byte ASN. That is� that is what they passed.
AUDIENCE SPEAKER: Does that mean on 1st of January all RIRs will start to issue 4 byte by default in whatever format we are currently implementing?
AUDIENCE SPEAKER: If you read the policy, yes.
AUDIENCE SPEAKER: So we may start issuing more AS dots and then have to change more to ASPLAIN?
SPEAKER: Yes.
Rudger: You are assigning 32 bit numbers, you are not assigning represent representations
SPEAKER: Yes people still like to think in representations.
Rudger: Some people have strange thoughts, including my hunger self
SPEAKER: I think that is a good closing Word. You have been absolutely perfect in discussing right to the edge of the time slot. So it's time for lunch now. Thanks for the good input and the good participation. I think we have really come forward. And I will see you again tomorrow at 9�o'clock. That is again 9�o'clock in the morning. So thank you for coming. And enjoy your lunch.
Conclusion of session.