Live Transcription - Tuesday - 11:00 - 12:30
Note: Please be advised that this transcript is the output of the real-time captioning that was used on a trial basis during the RIPE 55 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.
SPEAKER: Welcome back from the longer coffee break than expected. We have four presentations in this session. First we have two presentations, one from Geoff Houston about ID locater split maybe I needed more coffee but anyway, so Geoff Huston starts with the ID and then we have Richard Lamb going to talk about the inner sack. After that we have two task force reports and those will be a little bit shorter. So, Geoff...
GEOFF HUSTON: Good morning everyone. My name is Geoff Huston. I am with APNIC. I have joined the Chief Scientist Union along with Daniel. If you want to join it too, you will have to apply to us now it's a closed union shop.
This morning what I would like to talk about, what I have been thinking about, a lot of us think about the RIRs, the Regional Internet Registries and RIPE NCC is one of the icons in this place as the place where you go to get addresses, and a lot of you have come and we hand out a lot of addresses but pretty soon in looking particularly in IPv4 that is not going to be our role per se. Where do you go to get IPv4 addresses when we have run out? What is our role in IPv4? Why do we think that the RIRs are still a valuable and necessary part of the environment of the Internet?
In thinking about that kind of question, wondering what really our address is all about, you actually start thinking about what are the fundamentals of the communications architecture that we built. What do addresses actually do? What is the difference between who I am and how to send packets to me? So in this talk, I want to explore some of these notions about identity and location inside the IP architecture.
Certainly, the one thing about addresses that makes networking work is that addresses need to be horrendously stable and they need to be used uniquely. I am getting old, you know, tragedy of all of us. I remember Deck Net. I actually remember Deck Net phase 3, I think it was, and we bought this whacking great machine from Digital for the national ransom and there was Deck Net, what are we going to call the big machine? Well obviously it's Node 1, Area 1. And you did the same. What about the second little machine? Well, that is Area 1, Node 2, Node 3, so we all started numbering, we clashed all over the place. What is this global networking nonsense? My computer says it's fine, so is yours, we will never talk to each other. When did these [LON] knees over in the corner in the US originally, but everywhere in the end, start doing IPTP stuff with global addresses? What is the uniqueness business we all asked ourselves. I am Area 1, Node 1, what is the problem? We now understand a little bit more and understand the true value of addressing in terms of understanding if I want to be 203.10.23.3 you can't be 203.23. Addresses are unique.
However, addresses are more than that because one of the other things that happen in the very early parts of the IP design was a cut through with [OCUMS] rates for simplicity, do as much as you need to do but no more and make some pretty amazing and sweeping assumptions as you go. I remember being alive in 1980. I remember being alive in 1970. Do you remember the computers of the time? Machine rooms were about the size of this room. Disc drives, well this is obviously a small disk drive cabinet because the real disc drives were enormous. Mobility is what you got with a crane. So obviously where I am and who I am was cemented into place and bolted to the floor. There was no concept of anything else, so we were allowed to make some amazing assumptions about what addresses in a networking context were all about at the time and they were valid for that kind of environment and we have actually kept them, which is pretty weird. So now addresses do a number of things: They are who I am, you know. They are an end point identifier. My machine has this address. If you want to get to it, send it to here. They are also where I am because that address sits inside the routing system. And it actually is a place on the Internet; it's a postal address, if you will, for packets. It's, you know, where I am and you use that address as a lookup in forwarding tables all over the planet to tell you which interface gets closer to me. So it's actually a forwarding identifier. It's who, it's where, and it's how.
Now, it's not a necessary part of networking that you need to make all of those three the same. And mobile telephony did it differently because the real, the underlying who is actually the IMEI, and all the rest of it, the phone number and so on, are actually different semantic objects. But in IP we didn't do that. We wrapped it all up into once we overloaded the semantics, that made for really simple stacks, simple networking; even I could understand it, right? However, those folk down there who are making silicone not only had the key results for the year in their bonuses, they didn't just achieve; they overachieved. It was all of a sudden silicone became astonishingly small. It did fit in your pocket you could take it anywhere and you wanted to take the network with you and as soon as you started doing that, that association of identity to location became really, really painful. So all of these things here are roaming end points. Mobility, you know, started to use addresses in strange ways and that tight binding of address to identity and location is starting to stress out, and then we started being agile with addresses, with NAT. Who am I? Well you think I am this address but I know I am that address. And all of a sudden applications and application level gateways get a lot more complicated. And then we started to try and deploy voice over IP with NAT and anybody who has tried to do that with NAT, how do you make my phone ring if you don't know my number? is really quite fascinating.
And, of course, when we get into the bit [or] not realm, how do you do peer to peer when you don't know who I am as your peer? So all of a sudden most of the assumptions that we had about addresses and most of the assumptions we had about networking start to get questioned.
Now, you know, we can all fantasize; it's wonderful. Wouldn't it be really good if the right thing had happened; that wherever I am on the planet, I really am still Geoff. That wherever I am on the planet if my laptop is equipped with a web server, you can still get to it with the same identity. So it may sort of be different IP addresses but I want my identity to be stable irrespective of my location. Wouldn't it be really cool if I could keep my TCP session open, you know, when I travel in a train from here to Spain, when I hop on the plane. Wouldn't it be really cool if I could keep sessions open while being mobile; that I could maintain my identity and you could still communicate with it across locations. Because what we really want is dynamic locater use with stable identities. And wouldn't it be really, really cool if we could validate it; there was some security associations where we could simply say "is that Geoff or is that Gordon masquerading as Geoff?" Because there is a difference. And wouldn't it be be good if you could know who you were talking to. Wouldn't it be good if the promise of what we said we were going to build, we actually had built, rather than the rather small amount, I think, that we have done instead.
Now, in looking at this kind of wish list, obviously v4 doesn't do it today so obviously v6 has to, so wouldn't it be really good if, through somewhere inside this entire exercise, v6 offered us some solutions that v4 is finding very, very hard to do. Because, quite frankly, v4 as we know it doesn't go through those hoops of complete agility and separation of location identity.
I use that kind of strange tense in English, the future imperfect, we-stuffed-it-up tense, because the problem is we did indeed stuff it up. V6 doesn't offer solutions in this space that distinguish truly between location identity. That is a problem. And let me just wander into some slight digression here. V6 suffers from two problems, and the first problem it's [AP] second come up.
We all knew and know v4's shortcomings. The whole issue around trying to shoehorn mobility and security into v4 has been really very, very hard. Very, very hard to the extent that we don't do it very well. That, realistically a lot of things around mobility don't happen in v4 very nicely. It would have been really good if v6 had done it, but it didn't. Our expectations of v6 were far higher than the reality, and all we have managed to do is simply reproduce IPv4 with larger identifiers but without anything else. So it's failed on the second comer test which is a bit of a problem. It's just a small step sideways.
But, on the other hand, just be aware that sometimes things don't get solved, not because we are lazy or, you know, we would prefer to go out and play. It's because they are really, really hard problems. And some problems are really, really hard, and we have been here before with identity and location in v4 and we have tried awfully hard to solve it and we haven't, and the real strong signal is we have been here before and, quite frankly, this is an amazingly hard problem. If it was hard in v4, it's just as hard in v6, because v6 never changed the architecture.
So, you know, it shouldn't stop us exploring but, just remember that this entire issue is astonishingly difficult.
So, you know, what do we want from identity? When IEMD called Geoff, what does that really mean? Preferably I would like to be the only Geoff on the planet. Why? Because when anyone says "Hey, Geoff you are talking to me," uniqueness is really important and for networking it's incredibly important. I haven't seen your machine. I have never been personally introduced to your machine. I don't know what operating system your machine runs, but if you and I want to talk, I have to send packets and I have to receive packets from it. I have to trust a whole bunch of things. And I have to trust the addressing system is doing the best [proof]. I have to trust uniqueness of identity. I have to trust persistence, that what I did yesterday is going to happen again tomorrow. Yes, it was my bank yesterday, I hope it's my bank tomorrow because it's still my money, hopefully. I want some structure. And if anyone has ever dealt with routing tables and routing table explosion, the only one reason we don't try and show [torn] 4 bill YM we have aggregation and structure, a bunch of identities and be treated as a single object. Structure is good.
It's also really good to understand where addresses are admissible, when you can use and them and when you can't. Validity and authenticity and clear lines of authority; where did you get that address from? is a really important question. Because, if anyone wants the number 10, see me afterwards just down here. What does that mean? You know, what do you do with the transaction, does it have any validity outside that? Somehow when we start distributing addresses within all of these attributes and structures because uniqueness is not trivial. I can mumble to myself down here, I own the number 1 and no one else in the planet does, it's my number and it doesn't matter. But as soon as I loudly proclaim up here the number 1 is mine, and all of a sudden I have done something very, very different here. I am saying number 1 is uniquely associated with me and if anyone has a problem with that, then all of a sudden you start to question exactly how did these numbers get distributed. So uniqueness isn't a private assertion. It's actually a public recognition of a derived authority through a context which is very important when you start to apply that into networking.
So yes, we have a problem, we have a problem about identity and location because what we really would like to do is disambiguate the two and understand when silicone travels in my pocket, it would really be good if it was the same silicone, it had the constant identity, but as it moves around the network, it is obviously moving around the network, its location is changing. It's a wonderful problem and very valuable problem because a problem is valuable, everyone wants to solve it and everyone does.
So far the ITF has tried almost everything under the planet to solve this. If you have a quick list of the kind of technologies we have been playing with, all of these have attempted, in their own unique and special way, to try and get to grips with identity and location. I always found that hard. Mobile IPv4 is different to IPv6. I have never understood why, but anyway it is. Weird. The real illustration is that everybody wants to solve the problem (ad hoc networking) and none of those are the subset of the others; they are all quite unique.
Why? Because oddly enough while you can state the problem pretty easily, oddly enough solutions abound, absolutely abound and it's not really easy to figure out what the right one is. You can put identity up at the application, as Skype does, your Skype number, and if you think about it, almost the telephone numbering system, identity, the number, is not a property of the network; it's a property of what you dial. So yes, you can do it at the application level, you can do it at the transport level, you can do it all the way down at the host level and IP level, so there are all kinds of choices. Let's explore just a few of them just to understand the playground here because it's pretty weird.
The first one is, you can actually drive this at the application level and as soon as you start talking about identity at that level, you start thinking about web browsers and all of a sudden the DNS pops its head up and in some way there is the schooling of DNS thought says it doesn't matter what the problem, DNS is the solution. And with the amazing amount of resource records that were produced over the last few years, if it's not a solution today, it will be a solution tomorrow because we just need another resource record and we are there. So if you think about it, you know, the DNS is too slow. You can't put this kind of stuff in the DNS. If you want to do increment updates, if you want security and all the entities, you just need to run DNS. If I want direction in the DNS referral, we have got these two, all these Napster records and it's too complicated, the simple record and so on. So all of a sudden you have this amazing richness of application level, agility and identity and there are folk who actually see this as being a wonderful area of exploitation if you will, and all of a sudden you start to see application level identities that start to do multiparty complexity. I am behind a NAT, you can't ring me, but I make a deal with some agent, you can be GIH, [sip] VoIP and the incoming calls can come to you and you and I [do] will relationship that gets through the NAT gateway, I have association that will allow anyone to ring. All of a sudden VoIP becomes a multiparty [REND] vow but the identity that allows that to happen is way up at the application level. No longer am I an IP address. So one of the ways of getting around this problem of having a very simple underlying architecture is to push the complexity up to the application level and get them to solve it. And they have and they will.
Now, this raises a few questions. Everything in the DNS is really good if your business is selling to main names but if your business is actually operating a DNS nameserve, you might have an entirely different view as the thing gets into melt down and heads for the middle of the [ET]. At some point you have good a [side] KAL and speed problem here is the whole issue is as you overload the DNS with all these wonderful behaviours, does the query system and the servers keep on working? The other thing is of course identity prevention: How many Geoffs do I need to be? Am I Geoff when I do a web browsing SIP? This kind of identity [MRIF] ration that ENUM decided it would go through, look it's OK, everything is mapped to your phone number, just type that into a browser and you will get to me, you know?
So there is this tension between convergence of identity and mapping into applications and saying to each application just do what you want.
It's pretty clear that application designers now see a world that is entirely and intensely NAT based and it's pretty clear that is not a barrier; that is just reality. And it's pretty clear that applications are now astonishingly NAT agile and it's also pretty clear that we can't agree on a single identity structure and from application perspective, what the hell? So we don't. So at the moment we are just proliferating large families of diverse identities up in the application stage and let's not debate whether it's wise or not; that is just the world we are living in. But the transport folk are in a world of denial. Applications don't do this. They need to solve it at the level down that is where I make my money; that is a TCP problem. So all of a sudden we have to do this identity location match at the PCP level or transport level as well, so all of a sudden the folk like it and so start to say "look, the whole issue is that when you change our locations, you change the underlying IP address, but no problem, we will make the PCP level addresses constant." So all of a sudden the underneath stuff can change but the [a]SIRS will stay up. Applications are done, we can't trust them. Application designers know nothing about agility and identity. We have to solve it. All the money comes to us. Now you get layering at that level but the IP folk looked at this, said "no, no, you transport guys are ephemeral. Sessions come and go. I am [hoping] to see the underlining mechanism here is ICHL. Let's do there down there at the IP level." So now it's my machine and your machine. We actually do the dance about identity and locators down at that level so TCP doesn't have to worry about this stuff as well.
Everybody wants to solve it. That is the first problem.
The second problem is that there is no SIG solution either. So, what you'd like is on this slide here, generically, that the upper level thing simply goes "talk to Geoff" and then one level down you translate Geoff, which is some kind of English word, into a suitable string of numbers that computers understand, talk to some ID Number 12356; that mapping should be pretty unique. But it has no locational semantics. It's not 123, here in Amsterdam; it's just the equivalent of "Geoff". And then you go through one more transform, this identity transform that actually changes that into a fully blown locater still address, you know, down here, 201360 because I am in a IPv6 state today, it translates that through and then all of a sudden you send the packet.
Interestingly, if you did this right, it really wouldn't matter what that address family was, it really wouldn't matter in the slightest. I mean, it's just a packet format, so if you got this identity location thing done, the underlying protocol family underneath is largely irrelevant.
And of course if you want to change stuff, you are only really changing your location at the lower levels. It's still "Geoff", it's still the upper layer association. So that is the idea of all of these approaches one way or the other. And there are a number of approaches that instantiate this, and if you sort of look back far enough and at MMPLS or this new [lisp] work, they are very similar to this and it's the same approach all over again.
The first approach is the conventional approach where they take the traditional network layering a stack and simple thinking, that every SIG element of the stack adds more bits to the header so the upper level protocol is the payload. Then you have your TCP or uniP header, if you are going to do identity you have some identity field in the packet and BoF is that, is the IP protocol. So if you sort of the packet and the model have a one to one relationship. And if I am doing [IM] in IP, it's just the same thing; that the way you actually do this is to encapsulate. But that is not the only solution.
The other way of doing this is to say let's have two conversations. The first conversation is the real conversation but the second conversation is hey, I am about to move three foot to the left, send me the same packets, it's still me, my location has changed but you can believe me. So this out of band idea that not every packet has identity in it but there is a separate conversation that talks about identity.
Another way of doing this is to lift the entire identity conversation up a bit, put it all in the application so that now the application says, "well, you know, I am about to move left." This next session that opens up is all part of the same session. And we see that as well.
And of course the last one is reference: Where you go look I don't know what is going on, DNS help me, some mapping system helped me and if you look hard at LIS, the major problem with that in terms of where the effort goes is not the encapsulation, you know, that bit is easy. What is really quite hard is the mapping issue that really gets us all, how to get those mappings tight and accurate and on time. And then we get into self-referencing like HIP so, you know, there is every solution under the sun.
This one is really quite neat; I like it. We start talking and then we exchange very, very magic little keys just for this session, and then we make the next amazing leap of faith. Any packet that comes to me that has this key value is part of the same conversation. So then it doesn't matter what locators are used, what headers are used as long as it has that key value that says "this is really the same conversation" and now I am not talking about Geoff or anything more substantive. I have actually created identities that are ephemeral, identities that just exist one time. You can get into the room once, use it, but then when you go, you have to reinvent a new identity for the next conversation. Rather cute, because identities cost.
So we can start to distinguish these and lots of text and so on but realistically, what I am trying to drive at is there is only two kinds of identities in this world: There are structured, persistent identities that if you really look hard, are identical to the DNS every time. And indeed why wouldn't you put structured, persistent identities into the DNS? Because no matter how you sort of think about it, you always return back to how does this differ from the DNS? And the answer is, it doesn't. And there is this other kind of identity which is really bizarre, unstructured tokens which are actually ephemeral; they exist for short times. I can't use it to get in touch with you but if I have used some other identity to establish the first packet exchange, after that I am unleashed, after that we can actually create our private state for the private conversation to head on and all of these approaches that we have looked at in the ITF fall into one of those two categories and typically, maybe because it's the ITF, most of them are DNS, most of them are actually quite persistent identity.
So, you know, why do you use an identity value? You know, if you try to make the mother ship of identity, what does it actually look like? We use IPv4 addresses in an IPv6 world because one, we have got to see who needs those 32 bits. Let's reuse them for identity, or if we take this rather contentious area of IPv6 which is the [SEN] TRAE assigned unique logical address, let's use them for [YID] and never bother routing them less into ephemeral and start doing crypto-hashes there is no end to the kinds of choices. Although I must admit, I could never understand ENUM, out of all that richness of choice why would you resite a phone number? Boring.
So no matter how and what you choose, you go back to the same set of questions: How long do these identities last? How dynamic are they? Are they configured beforehand? Are they statically set up in the DNS? Are they simply negotiated on the fly? Am I Geoff to the planet or Geoff to the conversation? What is the scope and role of law of identities? How do I do the locater mapping? Are applications dumb or are applications smart? Do I need to expose this upwards or do applications tell me what to do in the stack? What about scoping? Am I Geoff at home but Geoffrey somewhere else? How does your identity change if you [will] scope of visibility? All of these questions sit there inside the identity system going, wow, you, there are different properties for identities, it's not just one thing.
But understand that, too, you get into another observation. That no matter what the system of identity, if it's going to work, it's never cheap. The DNS, if you think about the top level domain system and think about this registration fee for all of these first level names underneath the tops of 6 bucks per year and you start to think about, wow, there are about 150 million such registrations at 6 bucks a year US, which is less than yesterday but it's still a fair deal of money, that system costs the planet billions of dollars. As an identity system, that wasn't a cheapy. Billions of dollars.
By comparison minor ad for the RIRs IP addresses are dirt cheap. If you add up the entire money around this registration system, you don't get near billions, but anyway it's cheap and, in fact, on the whole, however, you can never do it for free, because when you try and do uniqueness in identity, it's a displacing function; I am saying to the world "this one is mine." And how I make that, how I ensure that you can all see it and do the honour, the displacement is not cheap. Registration systems and so on are always there. Of course you can try and recycle; ENUM tried it. IPv6 tried it. What are those low order 64 bits, where did they come from? Well, they came from MAC addresses, we recycled. What it [FOES] guys change it? Whoops, because once you try and [re]SIEBLG someone else's number plan to use for your own system, as we found with ENUM, very, very strange things happen. Who owns that space? Who controls it? Where is the locus of change? The ENUM experience was certainly fascinating. My advice: Don't ever use someone else's identity; it's unclean, it's dirty, it stinks, don't go there.
So, yes, understand that when you try and do identity on the cheap, you invariably end up paying, no matter what. Understand the difference between speed and accuracy and protocol overheads. So I come back to this and sort of think does IPv6 actually make any particular difference in this? Can we do something better even now at this late stage? Well, the 64 interface seemed to be a very nice place to play and indeed some of us have tried but it is difficult because all of this auto configuration stuff to make IPv6 plug and play seems to need 64 bits. That is bizarre. They seem to need 64 trillion addresses just to do auto plug and play. Whatever Apple Talk did 20 years ago for plug and play, we seem to have forgotten completely because they did it in under 16 bits. But of course maybe we shouldn't be playing there. Any problem in IPv6 can be solved as long as you use the flow ID bits in the header. So, you know, the flow ID needs to be exploited for this one as well. And if you can't do it in the flow ID, but you should, you just simply whack up another header extension and then the packer gets so big and you get into MTU problems and we are back in the same 6 issues we always have. It's not clear that the bits and hooks that v6 actually provided were indeed architecturally useful for this problem.
So, you know, maybe identity is something completely foreign, but maybe when we have played with this we really don't understand what we are playing with.
If you are right at the front row you will see that was Mao Ze Do: "let's a hundred flowers bloom, let's a hundred schools of thought contend." Because what we have done is over solved. Everyone, everyone is playing with this space. And that there is no clear and coherent view inside this networking protocol.
Maybe there should only be one flower blooming, one school of thought. He didn't say that by the way, and getting that translated took years; Chinese is not fun. Maybe there should be just one model. Can we get everything down to a single identity function or is true identity such a wild and diverse thing that networks just have to cope with? That is an interesting question and I am not sure we truly understand the answers, but what I do know is I really don't know anything about identity and that I have no clear idea when we try and do an identity locator split, I don't think I understand the identity part of that splitting location is easy. Identity is hard. But if we truly want to avoid this whole IPv4/IPv6 transition, oh my God, life is hard and so on. I think we have got to understand that it is not a case of trying to do IPv whatever. It's not trying to get there from here with small incremental steps. That if you truly want to address the issues of identity and location, go back to a cleaner slate and understand what you are trying to solve first and then come back and do the technology because, quite frankly, if we are trying to build something that extends way beyond our lifetimes, then really understanding the difference between who wants to talk and how they are going to talk is fundamentally important and I am not sure we are thinking about it enough.
So thank you.
[APPLAUSE]
[SPEAKER]: Thank you, Geoff. So do we have any questions?
[Geoff]: If it's foreign, identify who you are please.
SPEAKER: Daniel [OOUN] [body].
[SPEAKER]: Speaking together, solidarity.
[SPEAKER]: This is markedly different from your shim6 presentations, but what is the solution? I mean, come on, these are people who have these problem; you just told them we over solved it. Which are the next steps we should be taking to actually get something done? Sorry about that.
GEOFF HUSTON: You kind of asked this question that comes straight to the heart of my uncertainties and how do you feel about it? I think trying to solve it at the IP level, while trying to think applications are dumb and networks should be smarter, I have this sort of gut feeling we are going against gravity and the natural inclination. I actually think we invented, if you will, software and computers to solve really hard problems and that part of this is indeed to stop trying to obsess about the lower levels and start trying to think about applications. If you regard NATS as being a transform of locators and start to think about identity as being something different to that and how you make applications work even when locators get transformed, I suspect, Daniel, there are parts of a long standing and viable space there that we can build from the current system without, you know, breaking too much, which gives us the keys to decades, if not centuries, without trying to hop from v4 to v6 to v8 to v whatever. So maybe it is indeed in applications.
So my view on this one, if we really thought about this long and hard and looked at what folk are already doing with what some folk call over the top, that I can still get to my G mail irrespective of what this hotel does with NATS and everything else, maybe what is going on in that direction is productive. I am not sure that that access at the application level implicitly requires v4 or v6. It doesn't care. So from that point of view, Daniel, I would look to the applications and say "please save us."
DANIEL: I understand that part. The question is then, for me as a user, as how many identities do I have to maintain with whom and what do I have to give them in terms of insights into my digital life in order to maintain these different identities?
GEOFF HUSTON: The beauty about communications networks is that I can talk to you without ever having met you but I can only do so if you publish enough details that allow me to hit you with an introduction: I am Geoff, I want to talk. So no matter what, networking requires some degree of exposure of information about who you are. Whether my application needs to know where you are is kind of irrelevant, because that is something the packets need to do, not the application. But yes, exposure is part of this and I actually believe that proliferation of identities is going to happen.
DANIEL: I wasn't so much concerned about the exposure, I was more concerned about that I have to maintain, you know, my identity with, you know, whatever Skype these folks, and they actually get some of my, some more information than I expose to the rest of the world.
GEOFF HUSTON: You can always go down the ENUM way; you have got to be a true believer but there is
PATRICK: I am trying to fill in myself on what I think Daniel is asking about is how much we should accept the identity, [two], the application itself. Because the actual the actual resolution, the identity for something [ ] Skype is something that could be very much tied together with just one entity.
GEOFF HUSTON: This is this tension between trying, as an application, to, if you will, keep my arms around what I am doing versus open exposure because in Skype I have an identity but if I want to [FLAUG] into a browser doesn't work, the Skype identity is not the browser identity and the more you have separate applications with identity spaces you can't flick across applications and keep talking to the same person.
PATRICK: So how come you think we in application space, how do you think we have done better.
GEOFF HUSTON: You are such smart people. I am in constant awe of you. It's just software, I am sure you can solve it.
[QUESTION]: And you know me, I guess. So I would like to say that application space solutions have a number of disadvantages. Number one: They don't really work. I mean, Skype sort of works but doesn't really work. You will end up going through multiple relays and your core quality will, at some point, be degraded, because some DSL connection somewhere is going to have packets, that is one thing. And second, the amount of contortion that the developers have to go through that get something that sort of works is horrendous and they all have to do it separately. So there is a lot of duplication of effort there. Thirdly, solutions like voice over IP, STAM providing NATS and providing proxies are very good for whoever is controlling those proxies because they get to charge for their use, but they are not very good for the users, because if nobody gives them a proxy, then the users can't use their applications, so the use of applications actually either requires contortion or requires paying someone, and that is an obstacle to adoption, or can be. So if there is a network solution then, please, roll on.
GEOFF HUSTON: I am stunned. Normally, the applications people go, "No, no, leave it to us," and IP phoning, go, "Leave it to us". I have never seen folk from IP go, "It's too hard, you applications folk should do it." But you do understand I think that there are a bunch of tensions and dynamics there inside the [] stray because we are not one big factory, and generally, each of us believe that inside our cubicle, at our level of the protocol stack, we can, if you will, solve the problem. So we are all desperately hard trying to solve the problem, and yes, the applications folk are going ahead with what they are doing and the IP folk are really going ahead, one way or the other. As I said, my intuition was a purely personal one. If I had to bet on this, I think I would bet on the application folk over IP. The IP stuff is hard. The application folk, I have faith, I just believe because I don't could do it?
Q. It's hard for us, they must be able to deal with it.
GEOFF HUSTON: That is what you are hearing from me.
Christian Forest with Ericsson. I don't have a question, just a small addition. The original overloading of IP addresses as identifiers and locators, the large reason for the the main reason for this was simplicity, and probably laziness, but it also provided the minimum level of security, actually. If I know or if I believe that my packets will be routed to a particular location, then I also know that the packets will reach the identity that I want to talk to. And if we are now trying to split the identity from the location then it is exactly this kind of binding that we still need to ensure in order not to lose security and this requires either a trust relationship as in the case of what we have in telemobile telephony networks or it requires us to do some sort of cell certification which we are seeing in cryptically generated addresses or HP addresses which you mentioned in your presentation with playing around with the interface identifier for instance. So yes, there was this original overloading, it also provided a minimum layer of security and splitting this binding now apart is exactly what makes this task very difficult.
Geoff: Right and certainly I would agree but one point I would disagree, neither bob car or wind surf were lazy, the original design and binding this together was objectingly insightful at the time and for the machinery and network at the time it was amazing because it was just the right amount to do the job, and as we now, 30 years later, try to unpick it, we actually realise what an insightful and brilliant idea it was for the time because unpicking it is damn hard. So thank you for your comment.
Q. I actually fully agree.
SPEAKER: Thank you very much, Geoff.
SPEAKER: I guess that was not the last RIPE meeting when you talk about these issues.
Richard lamb from IANA to talk a little bit about DNS deployment in the real world.
Mr. Lamb: This is my first RIPE meeting so I wasn't quite familiar with the protocol here.
That is a hard act to follow, but I am my presentation is going to be a little bit more engineering orientated and kind of dry but hopefully, you will find some interesting points and come up with some good questions.
What I want to talk about is some of the work I have done in IANA with their DNS secretary deployment. It's been an interesting trip (DNSSEC) been dealing a lot of with some of the security issues as well as reliability issues, what we want to do is come up with a genuinely reliable system.
First I have to say, most importantly, thanks to some of the people at dot S E. Itation is something that is really rare and hard to find and without dot S Es work, trail blazing work, I know it's a buzz word there would be no way I would be as far as I was so I have that thank them. The how to is absolutely the most, the best starter document that I could find, I mean very well written easy to go through. As well RFC 4614, very helpful as far as picking specific parameters.
All through this you will see our design very much mirrors the dot S E design.
Some of our main goals to or our deSIERNGS maintainability SHLGS some people would say security would be the first one, for us main table was the most important, DNSSEC the problem is the whole key role over and a lot of details actually end up stopping people from implementing these things so we try to ought mate as many things as possible. Reliability was very important because with DNSSEC let's say difficulty in being accepted in some ways, we certainly don't want to add to that in anyway WASHGS it should work off the back, no surf fail you are a OOR any kind of negative response. We looked at reliability. Security, it's must look and be secure. Technically making something secure is one thing but we particularly in our position in IANA the system has to pass muster as far as the way it looks to people as well.
All right. Our target is by the beginning of the ICANN meeting which is coming very soon, so I am still a little bit worried about this but as far as the engineering goes, I think there is some on line issues that have to be solved but we want in RO DUKS meeting a secondary as well as a secondary serving up dot ARPA NOENS are needed except B I 64 and don't NT and we look wow like these things signed and served. At this point we have aer up and it's been running for many months at N SI and dot organise, however we would look at a full system available for by the ICANN meeting.
All right. I just jump right into the details here. This is what it looks like it's simple diagram, you can see a lot of the design is similar to and at terminology is similar to dot enJ, zone siren where the zones are signed and key generation box which actually generates the new KSKs, this time it goes along and key signing keys and probably jumping ahead there and then zone generation machine that pulse in information for each one of the zones, creates a zone file and I will talk about this later but we basically look at the SO A serial number for the glean file and this that is has changed DWOE a resigning. The stuff in the dotted line is what we have functional today, and it's advisable, available, it's the second Reese that (visible) that we have not set up yet or the proposed European location.
So more detail, specific actually IP addresses, the internal deSIERNGS one of the things that we set out to do is to make the this as transparent as possible, no secrets here, we want to show exactly how all this stuff works, no HOOPS through you are the, explain how keys get backed up, the top secret private KSK keys get backed up, all this stuff have you been very well understood, another reason for doing that is since this is DK DK so much of this is new territory, I am looking very much for NOIN give me some feedback corrections or things that I may have missed because it is new territory and a lot of will be riding on this.
Specific hardware that we are dealing with, very simple, some WUN use servers. Second item KRIP toe box, FIPS 140 2 if it's tampered with it deletes the keys. Level 3 if it's tampered with it says it's been this, one saysor get it, deletes everything. That makes it a little more difficult later on have to make sure the keys are backed up, what if someone kick the unit or drops it, this has caused me a lot of trouble. So there is a console, flash cards, it all sits in a rack right now, inside an ICANN cage this, could change, you know, if powers that be feel that it's not scuff enough or it is we certainly could NOF somewhere else.
So maintainability. The main focus like I said is keep this thing as simple as possible, it's got to be easy to use, it's got to be as automated as possible, I mean, this is got to be something you just load and run and forget about for as long as you can and when it needs maintenance I should be able to get almost anyone to go in there and generate keys if they for some reason the regular people don't have the ability to do that because if something can't get signed NEEM DNSSEC are going to see failures in the request. So we have got two scripts, something called sign all it goes through and looks at serial number for the zone files, pulse any new DS records for significance, hits reload, checks key status and then all these scripts generate these files which eventually bubble out of the system and get sent out as e mail notification on our stats page as well.
On the key generation machine that is the one that is off line and Hayden and generating the new KSKs key all, that has been manually run, every secure system must have is a human component, we don't want something like that to happen automatically so that is once a month at this point. Someone a couple of people actually have gone have to go to the location of this rack and actually run this key all VIPT. That is all they have to do don't have to understand anything else. It will automatically look to see if keys need to be regenerated and if not it won't be and be run multiple times. Again, try to spend all this time trying to make this as simple as possible.
All right. Again, borrowing from the fine people at dot SE, having overlapping keys even if this means a lot of DNS key records, found this to be very common sense, this is a great idea because it means that any time I need to roll over keys it's just a matter of introducing another one. Phasing out the old one. Particularly in KIK, we have two KSKs actually signing the zones and that is very important because that means any time there is a XO MIEZ ma thank can change one having to worry too much about the order of things and so this has really simplified a lot of things. Again this is all automated in one script, in key all, it takes care of this automatically for everyone. There is a diagram at the bottom, it's probably too small to read but it just shows the typical overlap and timing for the keys and in fact, it's what gets sent out the e mail to administer straighter every so often. So you can see that if the slides get published.
All right. Also, it's not often spoken about, how you deal with compromise keys. Since that is production implementation, we really have to address this issue, and it's something that at so point is going to happen for some reason or another so we want today make sure this too was also somewhat automated simplified, so also spent a lot of time run ago script bad key for lack of a better name to actually allow someone to go in and pick a specific key and have it replaced and then just pass that along. It also takes into account some of the DNS propagation delays for new keys and if it has to be run twice or zone files have to be updated twice to completely purge old keys it will completely do that as well.
All right. Next point is reliabilities liability. Any failure to sign in time is going to cause failure (reliability). Very bad user experience. We just this is one of the things that you know we want to guard against very much. I mean, we DNSSEC aDOCHTed so we have to make this look, work as smoothly as possible and not have any errors. So it was realise that had just having, instead of having very expensive single piece of hardware that has you know, back up drives and very caringfully designed double power supplies and all that we decide today just a couple of commodity pieces of hard wear and they just basically ping PONG off each other making sure the zones are signed all the time and pretty easy to implement. Up at the top there I talk about how long the actual signatures on the zone records are good for. They are good for about six days so it gives us an enough time to recover should something really bad happen.
All right. Reliability again, since the keys for our design are STOERDZ in a device which if tampered with everything disappears, we needed to make sure, it's part of reliability to make sure we can recover from that some way so we actually enCRYPT using the device itself, the internal private keys and propagate them out, again this is all built into the regular script, the guy using this does not have to OORy about it at all, it automatically gets enCRYPTed and September out of the system. (Sent). Talk more of that later.
As far as the SPLILT between where K S Ks are generated and D S Ds are generated, again very nice design where in the where you had K S K and any K S K related material all in a key bundle or group generated within the key Jim machine so by the time it goes to actually be used to sign something you are taking this public blob and stuffing it into the zone file and signing so it really does separate the security there. It's very good to do that. The key GEN machine is also not usually connected, it's off line most of the time, the only timing corrected to transfer keys from itself to some of the zone signers for signing operations.
To protect the K S Ks, it was deemed important to put them in something that, again, both was secured and looked secure, so we actually spent a fair amount of time and money to find some pretty sophisticated H S M is is a hardware security module, but a pretty sophisticated deVOOIS to actually store the keys and do all the signing and back up and that is where it is now. I spent sometime modifying the buying tools to give them P K C 11 support is the standard, it's an industrial standard used bay loft the financial industry and in these H S Ms in order to read and write keys, to perform signatures inside these operations, all done inside the device, no one ever knows, the private key is generallated inSIECHLTD no one ever sees that or knows what that is. It's not like one person holding that. It's unknown to anyone.
So, for some of the zones underneath DOT we decide today use regular soft keys bus they are ones we can recover from kickly since dot ARP Pa as a zone would be controlling. It's not that difficult to actually replace those if they have to be because we can juggle the keys instantly.
As far as key live times goes and sizes, we used R F W 61, K S K 204 bit and bit for K S Ks. Again two K S Ks always so if one goes bad we can replace it, if it's time to actually role over the key at the end of the year we can introduced one veryees lease that way. Z S Ks, we have three so there is one old on time and ahead. So the new one is always published, the old one is pub LISHLD, this takes care of a loft the DNS propagation issues, again and SIFRP will Iifies role over greatly. Basically, the bundle or the blob of keys that is generated in the key GEN machine that goes to the key signers is good for one and a half months so theoretically in the worst case scenario, someone could wait one and a half months before they had to go to the facility to generate new keys. But right now we have it at once a month, the half month is there strictly for guarding and allowing a little bit of flexibility in the times.
All right. How we back up the keys. Keys are all generated inside this security desize so never visible outside, they are also encrepted inside so you never can actually see the private key; you can only see inCRYPTed versions of the private keys. We also use the device because we have it to enCRYPT a bunch of other items that are sitting on the key generation machine. And that whole group is propagated out to the back up site when that becomes available or just simply backed up somewhere. This is some of the terminology, H S M key is BAKDZ up on N of M, by Mcing up an internal key on a number of cards, it means that you need to have at least a certain number of those cards in order to be able to recover that internal key, if you WANLed to DUP Kate the site, the H S M or this key inside another device that is how you would go about doing it, so WUBS again no one ever has the keys, it's only segments or piece of the key they might have.
This someone is a little smaller font but this is an area that is still under consideration. It's the whole idea of who actually controls how the process goes. You wouldn't want one person to have full access to everything here. You would want, I mean, at least two people involved, controlling different parts. You wouldn't want the same person to have both the ability to generate the key by themselves and the ability to enable the KRIP toe device so there is a whole bunch of thought that has to be placed here. We are paralleling some of this work on what we have seen out there but I think there is still a little more thinking to be done here to think how many personnel, let alone who, controls various pieces of this puzzle and has the ability to either generate keys or be able to copy or copy the keys into another device. As I said before, the the we have one script, the propagates a lot of this information via e mail so that takes care of that. At the very bottom, LAT bell ET most important thing if there is some catastrophic fail USHGS I mean right now we have all this stuff sitting in Los Angeles, someone of an ET quake zone so it might be nice to be able to recreate this stuff if we had to rery YAT it and that material THOOS live somewhere and so the process we have now is one where we actually have again pieces of the key stored in separate safety deposit boxes as well as back up of the keys in those various various places. That would allow someone to do stuff.
Almost done. So all the software that we have developed we are going to make open source, some of it I have already put out but I will keep publishing this stuff, particularly some of the PC K 11 stuff, other have gone down this path and it's it's a difficult path at first to understand this, different world, this KRIP toe world, but once you got it it's not so bad and particularly as examples I think will be useful for many others. So pub LISHG all that as well as all the scripts and any support programmes as well documentation on how to go about maintaining this, I have been spending the last couple of years trying to generate a big master maintenance manual for this and operational manual nor thing which is writ then a way so that anyone should be able to pick it up. These the various pieces. Up site is something that takes all the pieces of STMENT STKS and information and general race a web stage for the end user. So
S so this is live, you can go to that website and actually see a status page which gives you the live health of the system, if you look at that time now you will see a couple of those a couple of the key entriesually in red they are there to indicate just may have been ROLD over recently so this site is both S S L secured and it's got PGP keeps underneath the (keys) trust ANGers or DNS keys. The idea is belt and suspenders RS basically, S S L to make sure you are not getting the wrong site and P G to P to further verify that. And again the demands viewable on the standard page are ARP Pa INT and experimental route zone. Some of the information on SGLUT zone right SNOU just being scraped in, we don't have a specific neck MICHL. HOUFR just a demonstration an I wrote a simple mechanism that actually queries, gets DNS keys from whatever TLD you type in and comes generates DS records for that, you can look at those DS records and if they are OK click OK and they will be POOTed in the next update which happens a couple of times a day, the root zone file. That is one way. The long term view for us we have something called route zone management system for other elements, contact information, N S records as well, no reason to not use that for DS records as well in fact, we will have a field for that if someone needs that. So that will be one way to get DS Lords, I am open to suggestions for other ways to get, I have spoken to other people about thousand deal with DS records in mass and that would be useful.
Right. That is basically it. I have looking for as much feedback as possible, if I have done anything wrong I would like to know sooner rather than later. I would like to know what to do in the face of this one of the problems is how do you get these trust ANGers out to people? Is it windows update. Is it anti virus software. I mean, what is the process doing and how do we detect compromise keys? Do we just listen to hope for some e mail from the outside. There is still a lot of unanswered questions. OK and another DS records acceptance mechanisms would be very much well Co. I have heard there is a desire to control web that update happens. So that would be good. That is it. Sorry to bore with you with some of the technical stuff. Everything looks on track to be available for ARP Pa and INT. The route zone has a lot of layer 9 issues that are many out of our control but we have a system in place, we have commit today it, the idea is to it's a production system, hopefully all the security checks and everything in place and we just would love people to play with it and try it and give us feedback.
SPEAKER: Thank you very much. So I see that we so I see that we already have one person on the microphone
Q. Daniel scientist first of all let me say I am very happy to see this, thank you very much that actually stuff gets done and I can I an NASHGS also demonstrating that this can be done very for the route zone so I Anna the discussion on whether it can be done and it can be done reliably is is probably sort of next. Also the openness associated with it all is very laudable, it's the only way actually to get confidence. So I like with an I am seeing there. I have one slightly technical question: Your greatest in this whole scheme, one of the big mishaps that can happen is that BOS your K S Ks get compromised and I saw on your recovery side that that was the place where the question mark was. (Slide). My question is have you thought about any way of actually separating those, maybe into two H S Ms or whatever, to make that a less likely occurrence?
A. I haven't thought about that, that is definitely something we can experiment with. We have multiple units, H S Ms available for us for experimentitation as well and I would love to find a way to do that. I have not thought about that yet. I mean, my question mark there and it's a question that is asked of me all the time so I am asking it of you, I mean it's how do you recover from that. Two H S Ms may keep you from two H S Ms might keep make it more difficult to compromise but the XHO MIEZ could still happen. One of the thoughts that has been floated around is just to and this is again in transparency I will say secretly we would have an extra K S K sitting in there so instead we would have two signing with but a third one kind of sitting in there, I mean,.
Q. If it's not published PTS not GSH GSH?
A. It's not going to do any good exactly there is going to be this downtime.
Q. But there is a general property of systems, if the top gets compromised you have a problem, so that is one thing that you actually even if you make it less likely there is a gap?
A. There is a gap.
Q. And the other thing that I am seeing is, I noticed that on SI Anna dot organise you KWEERD reed in port 53 as well not just 80 or whatever GP Ss, so there is actually in that sense a DNA SEK a seasons server there that has DNS SEK assigned route?
Q.
A. Yes.
Q. And that is also very interesting to play with, but I would it's more statement than a question, is before people rush out and start using that, they should think a little bit about the consequences when they use it operationally because it says "demo" on the whole thing and there is certainly, at least yesterday, there was some people who were concerned about this being a" becoming route server system.
A. That certainly is not the intention.
Q. I understand. We know in lay terms there can be lots of con PIR see theories and one of them could be that I can of all places is starting alternative route system. Just be careful before you become dependent?
SPEAKER: That has happened before. Let's speed up a little bit. Jim.
Jim reed: I want to amplify the comments Daniel made and say that is great piece of work and all be very grateful for T one question I have for you Richard, which we touched on in the task force discussions yesterday is about procedural process issues. Are there any plans yet in your work about how to actually have TLD owners of the be able to submit keys, have those keys verified, do things like change keys and all that kind of stuff and what sort of processes and procedures do you envisage for that even if it's just for some kind of ex perment?
A. OK, we SDRONT any process for that at the moment but as I said, we have this route zone management project that is on track to be finished and that would will most likely will be the default way of accepting DS records. Now this has its own trust relationship, own security tokens and access to SO so that would be way to get some of the DS records in that. Being said, we are open to suggestions at this point. We don't have anything in place just yet except pour this little demo page that I have up which I think is SOMG people may have a problem with and so something that involves some sort of PKI would be perfectly reasonable, I have spoken to somebody from APNIC about something like that for take not guilty blocks of DS records, so we are open to that but we don't have anything at the moment.
Q. OK. Thank you. Question new: Or laugh: Talking about thousand make a six month joke but I don't have one yet. As a deemployer of the system is one of the early deemployers of the DNS SEK in a fairly significant and serious way, what was the most significant hurdle, what can we learn from your projects going towards the future as people who are planning about deemploying the DNS SEK? What was your biggest barrier?
A. The biggest barrier was to find was the security aspect, the KRIP to go RAF fee aspect of it, where to store the private K S Ks, private keys, that was the most difficult part required, a few leaps of faith there, the industrial that creates these kind of KRIP toe boxes is not really well versed in DNS SEK OOR Internet issues and so it was a learning experience for both sides and I think others have echo that had problem as well and so BSH BSH but they are coming on board. I think some of us are going to be visiting this RIPE meeting tomorrow but I think they finally see the interest and that is helpful because it will give us all more tools and make this process much easier.
Q. And given that you have documented your stuff, I want to stress that you have documented your learning experience and are feeding back to open source we can all use that?
A. Absolutely, absolutely, and you can thank STREEF crocker for that. He is the one who came to me and said it's got to be open and as transparent as possible. Of course. But that is very important in this whole process. I don't want someone to go down the same learning experience path that I had to it's not that complicated, you can really break this down into a few simple scripts if they are done carefully.
SPEAKER: Thank you very much Richard. And our next presentation is report from the data protection task force and going to try.
York em derue or something.
OK. I will keep it quite short, we are all waiting for lunch. Yesterday, we met with the task force that was our third meeting already so I will just want to quickly run you through where we are at the moment and what we are working on.
First of all, I want to emphasise a bit the relevance and it's becoming more and more relevant I think data protection, especially on the Internet, and also, there are actually steps taken more and more by data protection authorities, local countries and I am thinking especially countries like Spain and Italy, they are quite strict in data protection and they are actually moving forward in taking steps towards data control and making them remove data, for instance.
This also relates especially to on line privacy, recently the Dutch data protection authorities published a lengthy document stating how you have to deal with these kind of issues and how you have to implement that. And I was reading our Tribune this weekend and I don't know really know why my eyes focused on this article, but because it's not such an interesting title, I would say, but when reading it, it actually turned out that it would be a nice example to show you here that this is becoming something that was this person who wanted to be removed from the church records, the baptism records and he went to the data protection authorities in Spain and he got his ways, so they actually had to remove it, because they didn't keep the data up to date and they only have to conserve it for as long as needed. So this is happening, this could happen to the RIPE as well that people ask to be removed from the RIPE database and that we actually have to follow that up.
Quick introduction of the task force. Involved is man Fred dough myself and Denis from the RIPE NCC. We had quite a nice big group yesterday. Fredder chairing the session and we have had had so far three meetings, one we started off in TAL Lynn, we had interim summer meeting and we met yesterday to follow that up. We are planning to have two more sessions, one in February and inter meeting and then a RIPE 56 we hope to more or less wrap most of these things up and actually have a framework in place.
We communicate mostly by e mail. D P F P at ripe.net, actually there is more people on the list than listed here so if you are interested in this topic and want to follow what is going on you can register yourself.
We focus mainly on 3 areas: The set up of the legal framework to comply with data protection regulation. We are looking at the framework from the RIPE NCC peck pecktive, privacy statement, general terms and conditions covering the website and some general services and of course have RIPE database terms and conditions which are key for data protection.
Then, following to actually support this framework, we need some new policies and two policies actually have gone through the database working group and that is to maintain a by mandatory, so we have a contact person who has taken the responsibility over the accuracy of an object in the database and as the data controller, we every now and then have to audit the data, the personal data in the database so we have to clean up objects that are not referenced, personal objects I am talking about.
Also, yesterday, we discussed new procedure to remove or change personal data in the database. And we are moving forward with that.
The last big topic we looked at is the bulk access, and that is the mirroring and we have some near real time mirror streams from some companies who have requested that who use that in their operations.
I just want to mention yesterday we had quite a lengthy discussion about something a bit bigger and actually about what personal data needs to be in the database and who can access this. And I think we are still discussing that and we hope to continue this discussion in the next few meeting and maybe in the next RIPE meeting we can report on our findings and have something useful.
The legal framework, well, I have said this two or three times already, RIPE NCC is seen as Dale at that controller from data protection perspective but we delegate quite a large responsibility to the maintainer and that is to notify the individuals when you register someone that they are in this database, to make sure the data is actually accurate because for us it's almost impossible to guarantee this. And to support the removal change process of personal data.
We also need to audit the data and that is why we clean up on reference objects.
Where we we finished the legal framework, we have a draft privacy statement, we have a draft terms and conditions. We have defined purposes of the RIPE database and we are now working on implementing these in database terms and conditions and actually finalising this document for the next house meeting and then taking it to the next RIPE meeting.
The new policy proposals, well first of all, the mandatory maintain by, this policy was accepted, we had some technical difficulties in actually implementing this but we are working on this and then we actually have a direct contact person if there is a problem with this person object.
The clean up of the unreferenced objects. These objects are still growing. We are trying to investigate a bit why this is happening and well, we haven't really come a conclusion yet but we are going to clean them up in as soon as possible. But important thing.
Then yesterday we discussed procedure for change and for removal of personal data. I think we have a good initial set up and we will move forward with this to make a proper policy proposal.
And another item we are looking at is to structure address field a bit. Now, it's an open field, so you can fill you have your street, you have your Zip Code and your country in one field. Actually to make a structure in this so we can O remove the personal personal data from the non personal, so it becomes non identifiable and we can give people access to non personal data.
And the last policy proposal which is still ongoing is the white page facility which I talked about last time, as well.
Then the bulk access. Requirering and then N R T M. We reviewed the list of N R T Ms. It's not that long, it's five, six SURNT ones. We have some mirrors with the other and we want to make an R T Ms possible but only on a case by case basis so we are going to look into this, reSEFRNGS we are thinking about security providers and maybe possibly IP to country mapping but this will be looked at definitely on a case by case basis. This will abstandard contract I have to rush there is a standard EU model contract which will use as a template. For countries outside EU we need to request the full permit from the minister of justice and we will offer for everyone, we will offer N R M T stream without personal data so anyone can have this. With N R T M stream with personal data you will need to build your case with personal data and why it's LENL hit mat. We are going to public all these N R T M. And these are the items we are working on.
SPEAKER: Thank you. And actually the amount of time the speakers got is actually part of negotiation that already happened in the coffee break so it's not only myself deciding, it has to do with Naas, I want still give for people to ask questions if there are any, please. Or are you just hungry. OK thank you very much.
SPEAKER: So the last presentation before lunch is Malcolm hutty, that is going to talk about the whatever it was. I will supposed to know very well what this is.
Malcolm: OK thank you, Patrick. OK, RIPE 54 create add tasks force on enhanced cooperation. My name is Malcolm hut and I am the task force chair and this is an advert for the first meeting for prospective volunteers and everyone who is interested to come along this afternoon at 2:30 in St. John's room 2 everyone is welcome. Enhanced KOPGS is the FERD TORM government relation let me recap some of the background on why you should come.
For some years governments likes china have been punning for UN agency to take over control of the Internet and that just mean condition tent, also structure and institutions and things like RIRs and America on the other hand was leading with a position that the which we run the Internet is just fine with bought um up organise with RIRS doing their thing and there were a lot of governments including most of Europe that were somewhere in the middle. And so we ended up with a compromise. And part that have compromise was RIRS prom sitting to take part in enhanced cooperation. Well what does enhanced cooperation mean? Depending on who you are actually you will probably give it a slightly different deaf NIS, being very carefully left undefined to give people some flexible. If you are a government like china you want to to mean strong government control. Most of us here would probably like cooperation with governments mean something a bit more cooperative. So if we are going to maintain the confidence of the governments that are in the middle on this issue and also just because it's plain a good idea we need to get involved in some of this genuinely cooperative stuff that. May mean doing a lot more to explain what the RIPE is what N cc is, what our role is how we develop policy and so forth and probably a lot of other things like security and the resilience of critical infrastructure that governments are really concerned about, how we make sure that all that is really under control.
Now the N cc has been doing lots of in this area already but with F we wants governments to have involve dense we immediate to recommend SFRAN on IT what the this. Cc is doing on your behalf rale does have our backing some more formal conversation than just chatting with the N cc staff in hallways today. Otherwise, the N cc people are going to be atracked by the unfriendly political interests who will be claiming that what they are doing is just their own thing and that they don't have the backing of the RIPE community and that the bottom up policy making process, bottom up institutionings like RIPE are just a sham. We all know that is not true that means we need to formalise some of the process of consultation on this issue to show that we are doing the right thing. And that is where the task forms comes in. The job ever the task force is going to produce report to the RIPE community in plenary about what we think the RIPE and the N cc on its behalf should be doing on enhanced cooperation and by doing this, through the community will bring both the genuine Ben its of getting all your idea and the wisdom of the whole community to the process and equally importantly, will be demonstrating the bottom up process in action to STIEMGS sceptical governments. Now I am the chairperson and I now need volunteers for the task force. We are in a boot strapping phase at the moment, we have never quite had a task force that has been quite like this one before. Today, we are going to have some discussions on the detail the charter and what is MRARNGD the draft charter is up on the RIPE web side and we also need to how to select volunteers for the task force if there is too many people interested or if indeed we should have a completely open membership so please come along, it's at 2 KO 30 and it's in St. JONS room two just around the corner. Thank you.
SPEAKER: Thank you very much. And I guess there are no questions. You are collecting them until this afternoon. We are all hungry. And I think lunch opens in about 3 or 4 minutes. Thank you.
THE CONFERENCE THEN ADJOURNED FOR LUNCH.
|
|
|
 |
| RELATED TOPICS |
| RESOURCE LINKS |
|
|
|
|
| |
|
you
are here: RIPE -> RIPE
Meetings -> RIPE 55 
