ARIN XVII Public Policy Meeting
Draft Transcript
Monday, April 10, 2006

"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."

Meeting Called to Order

      MR. PLZAK: We're just waiting for the people that are still consuming food in the breakfast room to get over here. So, I sent Leslie to go there and bring them back here in her amicable manner. So, they should be here shortly.

Okay. Welcome to Montreal and to ARIN XVII. And so, first of all, let me give you your Miranda rights. We are producing a video and so when you signed in at the registration desk, you were given the opportunity to opt out and if you want to opt out, you must sign the form. If you don't, you could end up in a movie. So -- and if you're looking for your chance to break into Hollywood, here's your chance right now.

What we're doing is that we're producing a video which will showcase the meeting activities and so you'll see the crew around today. They'll be at the social tonight and -- so, depending upon what you want to have in that video, you ask for an interview time at the social night and we'll also be doing it on Wednesday.

So, again, remember, if you want to opt out, go to the registration desk, fill out the form.

So, first of all, let's thank our sponsors. They're going to do us a really good job, so we'll see how it goes and I'm sure everything is going to be fine.

So, first of all, hotel floor plan. Everything is pretty much on this floor. You guys found a breakfast and lunch room and I'm going to go through a little bit where everything really is. The general session, everything is where we are right now. The meeting registration is at the foot of the escalators and the Cyber Cafe is around the corner.

So, the general session room is where you are at. The Cyber Cafe and the help desk are in the St-Pierre room. The Cyber Cafe is a new thing we started this time. It is -- we did away with the terminal room. That's what we did. And you still have the capability of printing and there is still a couple of terminals in there if you want to sit down and do stuff there. But there is a bunch of other things that are in there.

So, the cafe is opened at these hours, today from 8:00 to 5:30; tomorrow 8:00 to 6:00 and Wednesday from 8:00 until noon. And you visit it and you can sign up to win a Mobile Edge Premium backpack in the Cyber Cafe raffle.

So, in addition to the help desk being located there, there's also some flash presentations running, some information brochures. There's going to be a continual supply of coffee and so forth. There's some places and chairs to sit down and carry on conversations. There's a live audio feed from the meeting in there. So, there's a lot of things.

I will tell you this that the room that it's in this time is relatively small. The next time that we do this at the next meeting, the room will be much larger. It'll be more of a meeting area set aside, so more tables, more lounge chairs to sit and converse. But this is another place to have those little side bar discussions that you like to have without having to necessarily sit in a bar or wherever and be relatively close to the meeting.

So, if you need to step out and have a quick discussion, this is the place. If you want to relax, this is the place. So, please take advantage of it.

And in the Cyber cafe before I forget, we're going to announce the winner Wednesday morning some time. Registration Services Help Desk is located and also the Billing Help Desk. The Billing Help Desk registration service help desk keeps the same hours as the cafe.

Now, for those of you that are concerned about the fact, "Well, gee, I don't want to have anybody in the Cyber Cafe hearing me have this serious discussion with registration services or billing about my problems or my concerns and so forth", there is a room that's set aside close by so that private consultations can take place. So, going back to the first, yes, the psychiatrist is really in and so you have the opportunity to set up appointments or just to have a general chitchat with the registration services people. But at the same time, if you need to have a private conversation, facilities are available for that as well.

The Billing Help Desk, they're bankers so they have more banker's type hours and it's as shown here, 8:00 to 9:00 this morning, noon to 1:30 this afternoon and the same thing on Tuesday. And Wednesday, they'll be open all day.

So, in both cases, you can make appointment by sending e-mails to the e-mail addresses, that's helpdesk@arin.net for Registration Services and fsd.help@arin.net for the Billing Help Desk.

So, please take advantage of it. We're interested in your input and what we can do to improve this service for you to make your meeting experience more rewarding to you.

So, meeting registration, as I said, is at the bottom of the escalator, wireless cards, if you need them, are available there. Remember, at some point in time, you'll have to turn them in. Otherwise, they become here very expensive souvenir of the meeting. And, as I said, you found the breakfast and lunch room; it's on the other side.

Restrooms, there's two of them, as shown and it's marked.

So, before we proceed on, I thought we would want to get in the mood of things a little bit here so, let's -- and I know we all have concerns about this being Montreal and this being April and what it is. So, whether the weather be hot or whether the weather be nice, we'll weather the weather. Whatever the weather, whether we like it or not. So -- So, and I defy anyone to say that as fast as you can, 10 times in a row without making a mistake. So, I'm sure somebody we'll take me up on it tonight after having a few beers. So -- anyway.

Going out with that, we need to do a few introductions. So, in terms of looking at the weather, we have the board of trustees: John Curran, the Chair, Scott Bradner, the secretary and, at the back here, Lee Howard, the treasurer. I'm president. Bill Manning is somewhere out here -- back there, the trustee, Bill Woodcock is over there. Paul Vixie could not make it. And also not a member of the board, but a person that's present at the board meeting is little snow flake, Steve Ryan, our general counsel. So -- I don't know where Steve is. Oh there he is, he's back there. Okay.

So, now, that was sort of a winter tableau. Going to spring, we have the ARIN Advisory Counsel, the raise of sunshine causing the flower to bloom and this is the ARIN Advisory Counsel. And everyone is here from the advisory counsel except for Alex and Cathy. So, please feel free to grab them and talk to them. A number of them will be identified as we go through the policy processes today and tomorrow as being of specific policy proposals. They've been identified to a certain extent on the e-mail discussions as well.

But they're the ones you should really corner if you want to talk to someone about understanding what a proposal is about. And if you have some very specific questions and you want to get some input into the system a little bit.

So, the number of resource counsel, we've got three guys here: Sandy George over there, Martin Hannigan, Marty -- I don't see you, Marty. And then Louis Lee. So -- so, that's our weather for today but keeping on, we have our RR colleagues, AfriNIC. Today's weather, a high of 30 degrees Celsius, low of 23 with light showers. Ernest and Adiel are here.

From APNIC, we have Geoff, Gerard and Save. The temperature in Brisbane today is a high of 27, low of 15, sunny.

From LACNIC, Raúl is here. In Montevideo, it is nice 23 degrees centigrade -- uh, celsius, low of 19, partly sunny. So, it looks like the Australians are beating the Uruguayans again as far as sunshine goes. And from Amsterdam, for RIPE NCC, we have Axel, Paul and Leo. The weather is 9 for a high and low of 1, and very unusual weather, it is sunny in Amsterdam and Axel is here in Montreal. So, you missed the one day of sunshine for the year!

Anyway. Welcome to all the colleagues. If you want to get a little bit more in-depth discussion about what's going on in the other regions, I'm sure they would be glad to talk to you.

So, the key ARIN staff flying kites, Jenny -- there she is -- Susan -- Leslie -- Mary K, back there and Bob. Where is Bob? Oh, back over there. Okay. And Richard and Nate -- where is Nate? Oh, okay. Back over there. All right.

So, please feel free to see us. Also, the rest of the staff is here -- well, I would say a good chunk of the staff. We also have a contingent backing home making sure that business runs as usual. We don't stop doing business because we're having a meeting. The business of the registry goes on.

Staff can be identified by the yellow badge packets. So, we make easier targets that way. It's an easy target to look at. So, that's why I have the yellow shirt on, okay?

Okay. Some attendant statistics. This is the largest second quarter ARIN meeting we have ever had 155 people here. So, thank you very much.

So, first timers 58. People are here for the first time. That's a nice good number. The -- all the members here are from two of the countries, ARIN region, U.S. and Canada, 94 people here from the U.S. from 21 states and we have 40 people here from Canada, from three provinces. And from outside the ARIN region, we have 21 people here. So, thank you all for coming and we look forward to your participation.

So, first of all, welcome to first time meeting attendees. We did something new yesterday. We had a first timers luncheon held. We did it on Sunday, I should say. The attendees had a chance to meet the ARIN staff, some members of the board of trustees and advisory counsel. You can see pictures there of a few of them. And now, one of the things that we did is that as they went around, they had little slips of paper that had the names of all the board and staff members and AC members who are there. And as they met and chatted with each one, they had to put -- that person would put a little star or something on their sheet of paper and it took all of those and they put them into a bowl. And so, what we're going to do is take those things and draw.

Now, in order to be considerate for the raffle, you had to get all the little stars and dots filled in. So, if I could have -- I don't have Price-Waterhouse but I do have Susan to bring up the bowl here and I would like to have a volunteer come up who is not a member of ARIN staff to make the drawing. So, would someone please come forward? Let's not be shy. I know you're not shy, so -- come on! Ah, okay. Susan is here. Okay. So, Susan, if you would reach into the bowl and draw it out and give it to me.

Now, what is this person going to get? They're going to get a USB HDTV tuner with remote which -- what's down there. Right here. And -- the winner is Doug Wilson. Doug, are you here?

      MR. WILSON: Thank you.

      MR. PLZAK: Okay. Last night, we had the seventh annual foosball tournament and the tournament -- we were assisted to conduct this tournament by a member of the Canadian National Table Soccer Team, okay? We were politely informed in very strong words that we don't play foosball, we play table soccer.

Anyway, the interesting thing to note is that when we did the tournament two springs ago in Vancouver, the people that did it are also members of the Canadian National Team and so, I was talking to Adam last night, the gentleman that's here from the Canadian Team who was doing this last night and he said, "Oh!" And so, they are all, of course, on the same team and the team is going to Germany, by the way, to play in the World Cup. And so, I said, "Well, now you guys have something to talk about on the airplane". So, it was interesting, to say the least.

So, anyway unto the results. Third place rewarded trophy last night, Raúl and Scott. Second place, Scott and Owen. And the 2006 foosball champions are Lee and Bob. Now, for those of you who don't know or you do know is Lee is the treasurer of ARIN and Bob is the director of financial services. Now, probably many of you know, at ARIN, we have a small room where we have a foosball table. So, I thought these guys -- Lee was coming over to work on a budget but obviously, they weren't working on the budget, John, they were doing something else! So, we'll let it go at that.

There's one other thing that needs to be done and also present were Danielle and Jordi and I don't have a picture because they weren't there last night to receive their award. If they are here today, I have them and I will give them to you right now. So, Jordi and Danielle, if you are here, please come forward. And everyone knows what they look like and what they had to do to earn this esteemed honor. So --Yes, I will go there, Bill. So, anyway, join us tonight, 7:00 to 10:00, we're having a street party and we're going to have food and beverage of the local cheese sampling, we'll have a buffet dinner, open bar. Musical, we have a jazz trio. We'll have a DJ. For entertainment, we're going to have stilt walkers, jugglers, a magician. For Jordi and Danielle, there'll be foosball tables for practice and we're going to have some racing games. But it is literally going to be a street party. So, sponsored by Teleglobe. And so, be there tonight. There'll be more information given out later today.

Now, in the bag, you've got a bunch of stuff. You've got probably -- depending upon your point of view is what you think is most important. So, we'll get stuff out of here first. We have the meeting folder and I'll go back to it. Also, since we didn't know what the weather would be like, we included a blanket with the meeting logo on it. So, if you get cold, you can always wrap it up or wear as a the superman cape or something.

Also, you'll find, in here, some sustenance to help you get through the meeting -- that kind of thing. There's a travel guide. So, there's a lot of neat things in here. So, please enjoy it. Our sponsors went out of their way.

Also if you notice, at your disposition is another thing that's not in the bag, are these little folders with pens and so forth to allow you to take notes during the course of the meeting.

So, looking at the meeting packet itself -- folder, I should say, inside there's the bulletin which has the agenda and everything else in it. There's the quarterly newsletter. There is the annual report, resource policy manual which you will probably want to have handy to refer to as discussions will float around that.

Also, the ARIN policy -- ARIN XVII public policy meeting policy proposals are in here in text form for you to have handy to read and also a copy of the Internet resource policy valuation process, the document that we're following to do this.

And also, you'll find a new item which are -- is a sheet that discusses some meeting courtesies and the rules of discussion and also a survey flyer.

So, as we go through things over the next couple of days, these things will all become very handy to you. So, please, take advantage of it. And, also, we'll do a little bit more about the survey.

Meeting information, remote participation is available. We have had people sign up for it so they will be on line and, as in the past, their questions will be taken and brought to the mic. Webcast information and presentations and announcements and agenda changes are all at these URLs and, by the way, there are several agenda changes and they will be announced as we go through things this morning. So, meeting survey.

You had two chances to fill it out. One is -- you can either fill out the IPv6 workshop sheet or -- if you went to that. And, also, at the same time, fill out the ARIN XVII meeting survey. If you've only gone to the meeting, you can fill out the meeting survey. The surveys are online at the URLs shown. But you get a chance to win another prize.

So, if you went to both workshops, you're only going to get one entry from completing two surveys, sorry. But on the other hand, there are two lucky winners and the lucky winners are going to get a iPod nano. And so, please fill out that raffle -- uh, survey entry and enter the raffle.

So, what are we going to do? Well, what's on tap? We had a couple of information presentations about what's the IGF and it's going to be done by Lynn St-Amour from the vice-presidency of ISOC and then, we're going to talk about law enforcement of uses of the WHOIS databases and that's going to be done by Don Blumenthal from the U.S. Federal Trade Commission.

Technical presentations, Thomas Narten will be doing and IPv6 activities report and also we have bogon filtering for the fun and profit by Team Cymru. And this morning, very important and something that is going to become extremely important this year from an ARIN perspective is we're having a round table discussion on X.5 -- X.509 resource and routing certification. We have a panel here. The names of the panel members are in the agenda. So, that'll be this morning after the coffee break.

So, what's on top of the tap in terms of policy discussions? Well, issue area number 1 in terms of AS numbers policy proposal 2005-9. Issue 2 in the directory services area, two proposals, 2006-1 and 2006-3. In issue area of IPv6 assignments, three policy proposals, 2005-1, 2005-8, 2006-4. For those of you that have been following the discussions on the PPML of 2005-1 and 2006-4 are very closely related and 2005-8 could actually have an influence on the outcome of 2005-1 and -4.

So, all those discussions will occur today and so, please be around and participate in that. It's been lively discussed before and we need to go forward.

And in issue area dealing with micro allocations, also two proposals: 2006-2 and 2006-5.

So, I've mentioned the PPML several times here. What is it? It's a forum. It's a forum in which can raise and discuss policy-related issues. It is an open forum. The only thing you have to do to participate in the forum is go to the ARIN website at the URL shown and subscribe. Once you do that, you're on.

All policy proposals are always introduced first on the PPML. So, subscribe to it and participate.

You may probably be one of those many people that just works and watches what goes on. That's fine. If, at some point in time, you want to say something, saying "me too" is a very valuable thing. So, don't just hold off because you say, "Well, I agree with what's being said so I don't need to say anything". Saying, "me too" is a very valuable input as the AC goes through the process of trying to determine consensus.

So, back on the weather topic again. You've got to learn the signs to navigate the road safely. ARIN is -- operates under actually a set of parliamentary rules known as Robert's Rules of Order. All of our meetings are conducted that way, whether it be the board meeting, the AC meeting, the members meeting or the public policy meeting. And these rules are there to do several things and one of which is to make sure we can have a good free and open and honest discussion.

So, there are a few courtesy. Let's please be courteous to those around us. So, please, pay attention. So, let's not do e-mail, let's not do any serving or whatever else needs to be done. We understand that some of you are here because your boss say, "Well, you can go but you still have to work". So, we can understand. But I don't understand your work being surfing -- reading the CNN news site or whatever you're reading.

So, please be courteous. Silence all cell phones, pagers, computers and other various electronic devices and we probably should think about doing something for somebody that -- whose device goes off first in a meeting. So, we'll probably think about that.

Okay. So, the proposal discussion road. Every proposal, as it goes through the meeting is going to follow this little path. So, the first thing is that it'll be introduced in the meeting. And then, we will also discuss the -- what has happened to date on e-mail discussion list and I don't know if Einar got up at 5:30 or 6 o'clock this morning to summarize the latest overnight mails but Einar is busy at this time of the year.

Then, you'll see a presentation of any legal impacts that counsel thinks that this policy proposal could have if it was enacted. And you'll see an implementation analysis from ARIN's staff, what we think it will take to implement this and we'll categorize it as being significant, moderate or minimal.

And something new, there's either question about, "Well, gee, how is the staff really going to understand what this means? What is their interpretation of it? What are some questions and so forth that they may have?"

So, we're introducing it at this meeting and for all future meetings, staff observations will be posted to the PPML prior to the meeting. So, it'll be out there for discussion but we wanted to do it at this meeting here so we could basically make sure people understood what we were doing.

So, you'll see staff observations. Now, this is not staff commenting on the merits of proposal. We will never do that. However, we are the ones that have to implement the wishes of the community and so we have to interpret what you're trying to tell us. And so, as in any form of communication, it's good for us to understand what you want us to do and so, if we have questions, you're going to be presented here. If we think that this is the way that we are going to do this, we're going to tell you that. And -- you know, what we're trying to do is table off those unintended consequences that may arise as policies get implemented. So, let's pay attention to that and perhaps our policy proposals can become a little bit more crispy clean and we can get rid of some more ambiguities.

I know in yesterday's open policy hour, there was some discussion about the text of -- wording and so forth of a proposal not necessarily being clear. So, perhaps the staff observations will help that along as well.

So, anyway, after that, the author of the proposal, if present, will give the presentation. If not, then one of the shepherds from the advisory counsel for that proposal will make the presentation. If the shepherd does it, it's going to be an objective presentation. They will not present it in terms of whether or not they agree with it or not. They're going to make just an objective presentation using material provided by the author. And then, lastly, we will have a moderated proposal discussion led by the Chair.

So, on to that, the rules of discussion, first of all, and there's 10 of them. And, as I said, these are derived from Robert's Rules of Order. So, think of this as Robert's Rules light. Okay? You know, I considered why don't we put, you know, these signs about maybe, you know, 10 commandments and then finding an appropriate board member to stand up and hold the two, but I decided we wouldn't go this way. We'll see what happens.

Anyway. So, Robert's Rules light. First of all, everyone has equal rights, privileges and most important, obligations. Okay? So, we were all -- we are all right there and say, "Hey! I've got my equal rights. I've got my equal privileges." Well, excuse me, you also have responsibilities to execute the obligations that go with those rights and privileges.

So, we are going to have a full and free discussion. No tolls here. So, you don't have to sign up to be anything, you don't have to pay money to get here. You just want to be here. But it's a full and free discussion.

One proposal at a time, please. We're not going to embark off on tangents and raffles and so forth and the Chair will make sure we stay on that single track road.

So, speak from a designated spot and they are very easy to be identified. They are called microphones and there are two of them here, there and another one over there. So, do that and only speak when you are recognized by the Chair. If you try him up from sitting in the centre of the audience, there's two things: A) we don't know who you are; b) good chance that people aren't going to hear you and the people that really aren't going to hear you are the people who are trying to participate remotely and so you're doing everyone a great disservice by sitting in the centre of the room and just yelling. So, it's not going to be recognized.

So, state your name, state your affiliation. And before you go on a long preamble about who you are and why you're glad to be here and all the rest of this stuff in diplo speak and everything else and about how important this proposal is and so forth, up front, state what your intent is to either support or not support the proposal.

So, as the sign says, speak your mind and ride a fast horse. So, let everyone speak before speaking a second time. Share the road. Now, the Chair will moderate this and make sure that everyone gets a chance to speak and the Chair will make sure that if -- you know, we'll remember if you've been up to the mic and all of a sudden, right back in line again and we'll want to make sure that everyone else has had a chance to speak before you get a chance to speak a second time.

So, basically, we have an imposed a three-minute speaking limit. We don't have a clock timer go up when you get up there and all the rest of the stuff. So, you're not playing beat the clock. However, be considerate and be prepared to stop. The Chair may ask you to summarize and cease your presentation.

If you need more time, I suggest that you have a private conversation with the Chair about that.

Direct all remarks to the Chair. You don't debate across the floor and you don't attack the other people that have made some presentations. So, no transgressing. Violators will be shot and survivors will be shut again.

So, suggest amendments or secondary proposals to the Chair, okay? And certainly, as we go through discussions, there will be changes of thought about the way things go and maybe a better way to do it but those suggestions and amendments go to the Chair so the Chair can take appropriate measures in the discussion.

And lastly, only the Chair can poll a participant. You are not permitted to stand up here and say, "Give me or show hands everybody thinks we should do this". That's the Chair's job. Okay? Because the Chair is the one that has to explain what an affirmative and negative response means. And for those who have been here before, you know that John takes a great deal of time to make sure that everyone understands when they raise their hand what they are saying. So, for that reason, only the Chair will be polling participants.

So, before I move on, does anyone here have any comments or questions that they would like to make regarding our rules here? Okay.

So, moving on, this is a shot of the Cyber Cafe. If you haven't been there, please go there. Oh, that little laptop in the corner, by the way, has been replaced by a much larger plasma screen and there's a flash presentation running on it.

But anyway, if you've been around there, you probably have seen these guys here too. And you may be wondering who those guys are. Well, I was there yesterday too and I took the opportunity, and you can do so too, and I got my picture taken with them. So -- now -- we are looking for character faces to put on -- maybe put on some of these guys. So, Alec, you may be a good candidate, I don't know. So -- although I do know that when we discussed this in a board at our meeting in March, the board told Susan that, "Eh! I don't want to see board faces in these pictures". So, anyways -- so, who are these guys? Well, they're team ARIN and I can't tell you. But Susan knows everything and on Wednesday, she will tell you more about this. So, they are coming soon.

So, on your mark, get set and let's roll. So, we are now onto the agenda. So, the -- are we ready? First order business are the regional policy updates. Einar -- I'll do this for him, Einar Bohlin, ARIN policy analyst, and he will tell you what's going on in the other regions. Einar?

Regional Policy Updates

      MR. BOHLIN: Thank you, Ray. I'm going to talk briefly about what's going on policy-wise among the RIRs. Under the category of IPv4 address base, there has been discussion in the APNIC and RIPE regions about changing the way they measure utilization. Instead of using 80 percent as where it used to, they're talking about using an HD ratio for that purpose. And just last week, LACNIC started talking about this too. I expect a proposal to come out about this.

In the APNIC region, this proposal is still under discussion; in the RIPE region, it's pretty far along. It's past last call and it's waiting a decision by the working group Chairs.

In the LACNIC region, they have a policy discussion similar to a policy that we already have which is multiple discreet networks and it would allow regional ISPs to come back for address base as a lower threshold. And in our region and the RIPE region, we're discussing any test -- IP for address based used for any cash services.

And more IP for discussion. At AfriNIC, they're moving forward with allowing assignments directly from AfriNIC to end users and they're -- the minimum for that is a /24.

They're also moving forward with the policy to allow temporary address assignments. That's similar to our policy about experimental use.

In the LACNIC region, they're discussing a policy to recover unused resources. And essentially, this one would be if a number resource hasn't been seen in the global routing tables for over a year, then they'll put into motion a procedure to attempt to recover.

And in the category of IPv6, the first discussion item here is changing the HD ratio to.94, that's for utilization measurement. It's been implemented in our region. It was adopted in APNIC but theirs was -- there was a stipulation that they would wait to see what the other RIRs would do. It's under discussion in the RIPE region.

And once again, last week, on the LACNIC list, there was discussion about something similar here and I expect a proposal to come out in regards to this.

The second item is amending the IPv6 assignment in utilization requirement and it's under discussion in the regions as show, APNIC, ARIN and RIPE. This one concerns changing the default assignment for example to /56 perhaps allowing variable length prefixes, changing the ratio to be -- the utilization, not ratio but default prefix size to be /56. And in the RIPE region, any cast proposal also includes IPv6 base.

Additional IPv6 discussions or development, the global policy proposal on allocations from the IANA to the RIRs is moving forward. It's being adopted in three -- by three RIRs and it is pending review by the AfriNIC board and waiting -- it's in the final stage at RIPE.

And the bottom two items here are ARIN region discussions and they're on the agenda this week. They've already been mentioned.

Autonomous system numbers. All of the RIRs have the proposal for the four by AS numbers. That's going to be discussed this week and in the AfriNIC region, they are moving forward with the proposal to change their ASN policy. Essentially, you need to be an Afri -- you need to be an AfriNIC member to get that resource.

In the category of directory services, we have a policy on residential customers -- residential customers privacy and captioning origination in templates. Those are on the agenda this week.

Services, we have a policy on residential customer -- residential customer privacy and capturing originations and templates, those are on the agenda this week.

If you want to see those proposals and the proposal texts themselves, here are some links to the policy proposal pages and as Ray said, there are members from the other RIRs here and I'm sure they'd be happy to help you with any questions you might have. Thank you.

      MR. PLZAK: Thanks Einar. Okay, before we proceed, I did say there were some agenda changes today. At 1:30 will be the discussion of policy proposal 2005-8.

Today, at 3:15 will be the discussion of policy proposal 2006-1 and today at 3:45, Dave Deitrich will do the bogon filtering for fun and profit presentation.

Again, all these agenda changes are posted on the ARIN Web -- meeting Website and so I won't spend anymore time dwelling on it.

Next stop is Leslie Nobile and she will provide the Internet number resource status report. Leslie?

Internet Number Resource Status Report

      MS. NOBILE: Okay, good morning. First, I had to figure out how the -- the directions are right in front of me. This is an update on the joint statistics, the five regional registries otherwise known as the NRO collectively. Sorry, I'm still not getting this, okay. Okay, good, got it, thanks.

Okay. So, this is the -- actually the address -- the /8 address base, the IPv4 base, the current status of the v4 space.

In the bottom right is the space that's not available, it's deemed as special use by the IANA and there's 34/8 in that space.

What's available, above that, right now, in the IANA reserve, available for issuing to the RIRs are 62/8.

And then what's been allocated or what the RIR are allocating from presently is on the left -- the -- you can see, this space that we each have issued or are issuing from and then there's the central registry, that is the not the pre-RIR space, the old SRINIC, the DODNIC, et cetera, so there were 94/8 issued pre-RIR days.

So, this is the -- in a side-by-side format, we went back to -- I think it's 1997 and we -- through today, actually, there's a current as of March 31st, so they're pretty recent and we've looked at all of the P4 allocations from the RIR to their communities.

It says LIR, but this is actually the total space we've issued including End-user space. So, and 2005, basically, the things we note here is we've -- everyone of the RIR issued more space than they did the previous year, we're seeing some growth in all the regions in v4 allocations.

This is just another way to look at it, it's a cumulative total -- I'm sorry, it's from 1999, it wasn't 1997. So, the cumulative total that we've issued since '99 and this is kind of interesting because this is the first time that APNIC and RIPE NCC have actually issued more space in total, cumulative total, than ARIN has.

So, it's kind of interesting. These are the ASN assignments from the RIR to their customers and the thing that I've noticed about this in 2005, this isn't the first year that the RIPE NCC issued more ASN than ARIN, previously, it's been ARIN issuing the largest amount of ASN but RIPE is increasing their ASN assignments.

And again, the cumulative total from '99, ARIN in the big blue pie, there's really not much to note there, just to see the cumulative totals.

IPv6 allocations. These are the number of /23 that each of us have received from the IANA to date and you can see, the RIPE NCC, the growth in that region has been really incredible, they've gotten a 198/23 from the IANA thus far.

And the rest of us are just kind of trailing behind. APNIC, there's been some growth in that region as well.

And this is the IPv6 allocations to our customers to the ISPs obviously with the policy, right now, it is for ISPs and LIRs.

We all saw a growth -- well, we saw -- ARIN regions have growth last year. The RIPE region actually issued less space than they did the previous year as well as APNIC.

I'm not sure what that -- what to attribute that to. Just so that you note, RIPE NCC and APNIC have issued very large allocations in IPv6.

We typically issued LACNIC AfriNIC and ARIN so far, actually, I think LACNIC issued a big -- a larger than /32 allocations but RIPE NCC and APNIC have issued several /20s and /22s and very large allocations which is part of this growth that you're seeing here.

And the cumulative total again from us to our customers and the RIPE NCC has obviously issued quite a bit of space, 552 allocations they've made thus far in v6. And this is just a link to the RIR stats, they are on the Web page and then you can get actual raw data from the Website, the IANA Web sites and the ASO ICANN Website. So, are there any questions? This is -- that's it. No, okay? Thank you.

      MR. PLZAK: Thanks Leslie. Next stop is Thomas Narten and Thomas will be representing with his IPv6 activities report.

IETF Activities Report

      MR. NARTEN: Okay, I'm just going to do a brief update on what's going on in the IETF, and particularly what's happened since the last ARIN meeting in Los Angeles.

And I'll start off with Shim6, there's been a lot of work going on in here, I don't think I need to talk too much about what Shim6 is, there's been a fair amount of discussion, even the PPML list on the net and on other venues as well.

But the working group is moving along, they have sort of three core documents they're focused on, there are close to being done with all three of them and the current plan is actually to advance them together as a unit because they all really fit together, they depend on each other.

There's a cache-based addressing, addressing document that's already been declared done by the working group and is sitting on the ISG's plate; there is a protocol document which is undergoing working group last called to current time; and there's a failure detection document as well which is going to be going through working group as called fairly soon.

And I can't say -- enough time, now would be a good time to review these documents if you, you know, have any comments on them as they're going through the final stages of review.

The goal at this point is the working group actually had a pretty long discussion at the Dallas IETF meeting, you know, are they reading for implementation and so forth and there's a clear sense that they are ready for implementation in an experimental sense and if the specs are clear enough, we'd like to incur some experimental implementations.

But the working group is clearly also not sending a signal that they're ready for, quote unquote, production implementation and then deployment, okay, but there's definitely a desire to get implementation experience and operational experience from it.

In terms of what else is going on, and again, this is not new, we've talked about this in Los Angeles already, there have been Shim6 BOFs held at some of the various operative forum, there's been one held in NANOG recently, the was one in APRICOT -- well, not that recently.

There's an upcoming BOF plan for the ARIN region -- I'm sorry, for the RIPE region in two weeks and some of the feedback so far, this is as sort of summarized by Dave Meir is, you know, end systems complexes concerns about the complexity, DNS latency issues, what is the impact on traffic engineering and on the overall routing and dressing architectures.

And for more information, I'd encourage you to look at the slides that Dave Meir put together and presented, the Shim6 BOF reflecting the feedback.

Of course, one of the big concerns that have been raised, you know, in this forum and also other places is that Shim6 is not really what some of the operators were looking for and they want something that's more oriented towards having a lot of the policy and decisions being made, kind of an edge box in the network as opposed to the end host.

And the working group is starting to have some discussions about that, I wouldn't claim that they've gone very far but there is -- on a particular, there's one draft that's been produced for the last IETF draft, Nordmark Shim6 ESD which starts exploring the applicability of the Shim6 design to doing some of the offloading on edge devices.

And Dave Meir has also put together a draft that talks about Shim6 and traffic engineering, these are all very -- definitely it's a very early stages of work, need review, need feedback, need more discussions and again, I'd encourage you all to -- if you're interested, to go look at those and, you know, follow up with the authors and with the working group.

Over in the IPv6 working group, again, as I reported last time, this group is now really the maintenance mode, wrap-up mode, they did not have a face-to-face meeting in Dallas, there's no plans to have face-to-face meetings in the future.

They have three documents that they're close to being done and they revised RSC so there's nothing really new, they're really cleaning up ambiguities and making clarifications to the existing RFCs.

And in one area, they're still trying to nail down the policy discussion of when to invoke -- when to use DHCP and when to use stateless autoconfiguration and how much of that should be sort of forced by the standard versus just a recommendation on how to word that.

There's also a document that I -- Lay Roberts, myself and Geoff Huston submitted, 3177 bits which we talked about here before and the goal of this document is really to update and revise, replace RFC 3177 which is the original recommendation from the IETF, from the IAB and the IC on the /48 recommendation.

And finally, in the RFC Editor queue, they had one document that's been produced and approved by the ISG since the last year meeting, that's ICMP name look-ups which is another way of doing reverse queries, not using the DNS but by sending essentially an ICMP query to the node saying what is the DNS name associated with this address.

And this is something that's sort of experimental, it's been around for a long time, there have been implementations and people --have asserted that it's quite useful for debugging it, if not more.

Okay, in other words, the v6ops working group, there's a number of documents again that are under active discussion, there's enterprise analysis, this is really about, you know, v6 and how it applies to the enterprise, there's an ICMP v6 filtering document that talks about, you know, recommended guidelines on what to filter in the granularity and some of the issues relating to filtering ICMP.

There's one IPSEC documents, they've also set a number of documents up to the IESG for consideration, there's a broad band deployment scenarios which is really talking about different ways you could deploy v6 in broad band networks or in remote access scenarios in support -- there's a NATPT experimental, there's been long discussions in the ICF about whether protocol translation -- that protocol translation which is essentially the v6 to v4 conversion using that, but how good of an idea that really is.

There's a lot of concern that is really not a good idea and the -- doesn't really want to be recommending it, because whenever you sort of go in that direction, there's always these other issues that crop up and so, it's not really a good solution in any sense.

And the purpose of this document is to reclassify the NAT PT technologies experimental and include you to more warnings about why it's not really recommended and why, you know, it's not a good general solution.

There's also a document that describes some security issues that relate to v4 and v6 and running them both, you know, dual stack in the network.

And then since the last meeting, the IESG has approved a couple of other documents, one on VLAND usage and one on the on-link assumptions, it had to do with, like, determining which prefixes were on link and some of the implications of that.

Okay, one of the more interesting groups, again, for this venue, there's a softwires working group at the last ARIN meeting, this was still a BOF, this started off as tunnel config but the basic idea here is, it's trying to do tunnel set-up for v4 over v6 and for v6 over v4 and the specific scenario that's the main focus is for an ISP that wants to provide IPv6 service to its customers but doesn't necessarily -- in fact, it does not have IPv6 at the edges and so, there has to be some way of tunneling across -- at least the partial v4 infrastructure to get into the core of the ISP whereas IPv6 service.

And it is a formal working group now, they had an interim meeting prior to the Dallas IETF and they're moving along fairly quickly, they -- you know, they're -- in some sense, if we don't get this done quickly, then we've missed our window and the main focus at this point is finishing up the problem statement and then they have some solution documents that are in the works that they're also actively discussing it at this time.

Okay, so another BOF, this isn't really IPv6 related specifically but there's a secure inter- domain routing BOF, this is a topic that's been discussed here a little bit in the past and in the IETF on and off.

I won't say too much about it because it's an ARIN topic for this week as well other -- then, there's -- you know, been a proposal to create a formal working group to follow-up on this work in the IETF. Okay. Questions or comments? And that's really all I have.

      MR. PLZAK: Before we do proceed, one comment. You know, the continual battle, if you will, back and forth between the RIR and the IETF is about staying out of each other's business.

And so, just as we don't want -- or the IETF doesn't want us running technical working groups, and we don't want them running policies, it's important for us to communicate back and forth to each other.

So, that's one of the reasons that Thomas comes to our sessions and presents this information.

And he did make a few calls in there for you to pay attention to what's going on because the last thing we need to have is an IRSC get propagated that's called policy implications in it and all of a sudden, he says, well, why did they do that?

Well, he has the opportunity to participate and so, that's a very open and public form as well. So, please take and pay attention because there are a number of policies that we have in effect today that are the result of actions by the IETF and some of those are causing controversy factors, policy proposals on the docket today is the result of an IETF action several years ago.

So, I ask you to please go back and look at those things that Thomas has been talking about and really pay attention to it because some of them obviously do have policy implications for us.

Policy Proposal 2005-9: 4-Byte AS Number

      MR. PLZAK: So, off the soap box on that one. Now, we're on to the first policy proposal of the morning and that's policy proposal number 2005-9, the 4-Byte AS Number.

And a description of the proposal is to establish three dates for changes to autonomous system numbers.

The policy, first of all, in January of '07, the request will be processed for 32-bit ASN but otherwise, the default is a 16-bit.

In other words, if you come and ask for a 32-bit, you can get it, otherwise, you're going to get a 16-bit.

On the 1st of January is that that situation reverses, that you can ask for a 16-bit but otherwise, you're going to receive a 32-bit and then lastly, on the 1st of January in 2010, you'll cease to make that distinction.

The AC shepherds for this are Alec Peterson and Mark Kosters. Brief history proposal, I was first introduced in December of '05 and was designated a formal proposal - we have a little problem with the slide there, how about that?

On the 26th of January of this year, the first public policy meeting discussion of it is this meeting.

This policy has been revised one time since the text was submitted and that was in February of '06.

And the URL is listed and as I said earlier, the proposal text and the meeting docket. So, from an implementation assessment that was done in March of this year, resource impact is significant in that it's going to require a template change, registration software changes, guidelines change, staff training and some educational material.

Some of that staff training is training the staff on how to answer the questions that the community is going to have to -- is going to have in regard to this, so the help desk needs to know what to say when they're talking to the community.

And we will be producing educational material to have available, for example, in the Cyber Cafe for people to read, and also on-line.

So, counsel sees no legal risks in this policy at this time as of March of 2006 and to date, staff really has no comments about this proposal in terms of understanding it or how we would interpret to do the job.

So, the PPML discussion -- approximately 112 posts, 23 people, 12 number against a couple of comments and I won't really read those for you, you can read them or you can go to the archives and read them all.

And that proposal is on-line and I will now turn it over to Geoff who is the author of this proposal.

      MR. HUSTON: Thanks Ray. Good morning everyone, good morning John. Bonjour, mesdames et messieurs, ladies and gentlemen.

This is a proposal actually which was introduced 2005 RIR simultaneously. And I must admit, the one thing I do want to note is that only the PPML mailing list was active in reviewing this across the entire global RIR system and thank you all for your constructive and detailed review, I really appreciate it, actually.

And in fact, I've been quoting the PPML review and comments raised to the RIRs and I hope that sooner or later, they actually pick up the picture of these things that are here to be discussed. So, thank you.

What is going on here is that what I wanted to do is to actually create a policy framework that eases this into a transition from one numbering plant into a second numbering plant with as much predictability and clarity as possible.

So, what I'm trying to do here is to actually set up some dates here that allow us, as industry players, if you will, to figure out what we need to do and by when and how needs to do it.

This is based on earlier work in the IETF, the entire sort of technology behind this is now sitting with the IESG, it's gone through the idea of working group and is now sitting there as a proposed standard, I expect that to be published relatively quickly.

And what it proposes in the ARIN policy proposal is to take that work and then nominate three dates which are actually critical milestones as Ray has already described.

So, what I'm anticipating as a result of this is that IANA will be there with an expanded 32-bit AS number registry completed by the 1st of January 2007, and the other assumption behind this proposal is that ARIN, in this case, would ensure that its systems are now 32- bit claimed by that same date.

So, those are the assumptions behind this proposal and what is going on here is, as Ray has already gone through, is that three dates happened.

As of the 1st of January next year, you can ask for larger number. If you don't, you'll get a number from the existing 16-bit, in other words, the higher with a 16-bit will be zero.

That will go to two years, there's no particular conditions under which you can ask for larger number, if you want a larger number, simply say, I want a larger number, is the idea behind this.

In two years time from that, however, it will go the other way. If you ask nothing in particular, you'll get a number with norm zero -- bits.

If you want a 16-bit number with zero -- bits, explicitly ask for one. So, it just flips the bits.

Commencing on 2010, there'll be no more distinctions between the two. So, that's the essence of the proposal here.

What it does not do, it does not propose any further additions to the private AS numbers base, so the private AS numbers base is between 64,511 to 65,535 and that's the way.

It doesn't define any documentation these AS numbers, there's no additions to that. It doesn't advocate the continuation of any legacy number, so I'm not saying that ARIN should hold any 16-bit numbers in reserve.

On 2010, it simply becomes a larger pool and that's it. This is a temporary policy so the 1st of January 2010, it vaporizes and this number pool was a 32-bit number pool.

This can be done separately by each of the IRRs so there's no coordination across the IRRs being implicated, yes, the same policy is being submitted to all five IRRs and yes, the unbelying predictions of the exhaustion of this 16-bit AS number space are still laid globally and it's still somewhere around 2010/2011, so this makes sense in all the regions, but there's no precondition that we actually have to coordinate this. And nor does it define any different AS number allocation practices, so the existing policies for AS number allocations remain precisely as they are today.

So that's the essence of the policy proposal. I believe the next step is to hand it to the Chair. Thank you.

      MR. CURRAN: Thank you. Okay, microphones at this time are open for any questions on the presentation, or questions about the policy proposal. Please speak your name --

      MR. DILLON: Michael Dillon, BT Radiance, and I don't support this policy proposal. I'm wondering, there are three dates; on the second date, you propose that people can apply for an AS number and specifically request one less than or equal to 65,535. That's some two years from now. How do you know there will be any left?

      MR. HUSTON: If you're asking what are the ranges of how do I know there will be any left, the last three to five years has actually seen a relatively uniform rate of AS number consumption. The underlying assumption behind these dates is that that industry trade will largely continue as it is. By 2009, there is an expectation over roundabout 15,000 AS numbers left in the pool.

      MR. DILLON: Okay. Can I ask a second question, Mr. Curran?

      MR. CURRAN: Oh, yes, proceed. Sorry.

      MR. DILLON: I don't understand why this proposal introduces a classical nomenclature for these AS numbers. As far as the policy is concerned, it's a 32-bit number, and yet we have this confusing nomenclature which makes them look like floating point numbers, where 1.0 is not the same as AS number 1. Why?

      MR. HUSTON: My brain is small, I find numbers bigger than a few tens of millions difficult to remember. Segmenting into number-dot-number just made it easier for my brain, and I hope that it will make it easier for others.

      MR. DILLON: Well, I don't think any of us have to remember these numbers, they get configured into a system somewhere, and you forget it. It's handled all by machines, not by people. But from the policy point of view, you know, we're simply dealing with numbers that range from zero up to some four billion or four million, or something like that. Why do we need to stick dots in the middle of somewhere and make the number different from what it really is? I don't understand this.

      MR. CURRAN: Just let me ask this question of Geoff. The proposal has a discussion about, in various time ranges, what happens if you make a request and it's not specific about the range that you want your assignment from. The proposal also introduces some nomenclature. Is the nomenclature part of the proposal that's mandatory? Would you be amenable to not having the nomenclature in the proposal?

      MR. HUSTON: I'd be entirely amenable to not having the nomenclature in the proposal. It was simply, as I said, an aide to actually describing what was going on. So it's not a part of the proposal, it can be dropped, yes.

      MR. DILLON: Well, my brain works a lot better with 65,535. It's either less than or equal to that, or it's bigger than that, and there are three dates relating to what you do with those two ranges. Anyway, thank you.

      MR. CURRAN: Thank you. Back to the microphone.

      MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I just had a question about the dates listed in the proposal. There's some specific dates numbered, mentioned, and are these dates in line with when the RFC is likely to be accepted and when vendors are likely to have running code, or say, for example, if by 2010, we don't have routers that support longer AS numbers, what happens to this policy?

      MR. HUSTON: There are a couple of things, I suppose, that we should all be aware of, and the current run rate of AS numbers by or roundabout October 2010, if we do nothing and the current run rate continues, we've all got a relatively large problem, vendors, industry, the lot of us.

Now, this proposal doesn't require that everyone with existing AS numbers does anything at all, because the way the transition scheme works, this is a transition scheme where the deployer of the longer number actually has to do the work in new BGP implementations. Part of the reason for this proposal is not just for, if you will, the ISPs, but this is an industry with suppliers, and if you will, customers, and we need to give clear signals to suppliers as to when technology is actually necessary in order to stop disruptive transitions that cause pain and expense. So these dates are deliberately pushed in a fair way.

So we're actually saying here to industry that there will be -- in 2007 who have a legitimate need to run BGP implementations that support 32-bit AS numbers, and this is as much a policy proposal signaling to the supplier side of the industry as it is to the customer side of the industry, the ISP.

      MR. SCHILLER: So if I understand that comment, this should drive IETF and vendors to provide a solution by these dates, or sooner?

      MR. HUSTON: This should be a clear signal to those vendors who haven't released code in that area that this is a good date to have which tested as well as then starting releasing implementations of code to support this, yes.

      MR. SCHILLER: Okay, thank you.

      MR. CURRAN: Okay, far microphone, Marla.

      MS. AZINGER: Marla Azinger, Frontier Communications. The last time this was discussed, I had the same question, and I haven't heard it since. Has there been testing with 32-bit on v4 and v6, and what were those results, if there were?

      MR. HUSTON: This is testing with BGP as distinct from the protocol of the payload. The IETF in the inter-domain area, in fact in the routing area of the IETF, is now insisting that implementation and inter-operability reports being prepared as part of the submission of the draft to the ISG. There have been two implementations known and reported on that have been tested to meet the requirements of the draft and inter-operate. There is a draft describing that the implementations are, and here I'm trying to remember correctly, Juniper and I believe Red Sand; I'm not sure.

To the extent that there are implementations out there, they have been tested for improbability. To the extent that it affects the payload of the protocol, it is unclear that this would affect the payload of the protocol. This is BGP signaling not what's inside the packet, if you see what I mean.

      MS. AZINGER: I do, and that answers some of my questions about it, because there were more actually doubt I guess the last time we talked about it, whether or not there would be issues, and if we needed to reserve special 16-bit, a certain amount of 16-bit numbers in case all hell broke loose with the 32- bit. So, that was --

      MR. HUSTON: We do not believe there are issues around that require a reservation of 16-bit numbers, no.

      MS. AZINGER: Okay. Thank you.

      MR. CURRAN: Marla --

      MS. AZINGER: Oh, and I support this policy. Sorry.

      MR. CURRAN: Thank you. Side microphone, Owen.

      MR. DELONG: Owen DeLong, Netli Networks. I do support this proposal. The nomenclature is actually not part of the proposal, it's part of the explanation that went with the proposal, so hopefully the fact that it's not actually part of the codified proposal will align Michael's concerns and perhaps he can change his opinion on that basis.

      MR. CURRAN: Thank you. Far microphone?

      MR. SEASTROM: Robert Seastrom, ARIN AC and Inter dot net. I'm generally in favor of this proposal, although I am not in favor of the nomenclature, and hopefully the fact that we all seem to have a pretty good luck rate at remembering telephone numbers, which are similar numbered digits in length, will allay some of Geoff's fears about that.

      MR. HUSTON: Either that, or you can help me with my small brain. Thank you very much.

      MR. CURRAN: Thank you. Other microphones are open? Yes, Jason.

      MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I just wanted to point out that telephone numbers have dashes between the numbers.

      MR. CURRAN: Okay. Microphones remain open. Randy.

      MR. BUSH: Randy Bush, 3130, I agree with 702.

      MR. CURRAN: Okay. Yes, Leo?

      MR. BUCKNELL: Leo Bicknell, ARIN AC, and Harrah's Entertainment. I support the proposal and my comment would be that because the nomenclature is not part of the proposal, I would hope ARIN would use whatever industry standard nomenclature is developed, since we are not the nomenclature development group. So whoever makes that decision, because I'm not even sure who it is, I hope we just make our documentation map so it's not different.

      MR. CURRAN: Okay, thank you. Further comments? Okay, let's all thank Geoff. Thank you. At this time, it's necessary to provide guidance to our Advisory Council so they can know what to do with this recommendation, with this proposal. We've had a good discussion of the topic, and now it's going to be necessary to put it to a show of hands for people who are in favor of this policy proposal and people who are opposed. So first, I want to verify, do I have my counters ready? Yes. Yes. Yes. Very good.

Okay, so, the question is, Policy Proposal 2005-9: 4-Byte AS Number, I'm going to ask for a show of hands for everyone in favor of advancing this policy proposal, and I'm going to ask for a show of hands for the people opposed to the policy proposal. Okay?

All right, all those in favor of Policy Proposal 2005-9: 4-Byte AS Number please raise your hand. Hold it nice and high. Hold it high; no waving your arms, please. Okay, thank you. All those opposed to Policy Proposal 2005-9: 4-Byte AS Number please raise your hand. Raise your hand high. Okay, thank you. And the numbers are coming up. Thank you.

So, in favor of Policy Proposal 2005-9 is 70 votes in favor; opposed, 3. So that information will be brought to the AC for them to do their work. Thank you.

      MR. PLZAK: Okay, thank you, John. We are actually going to have a long coffee break this morning, so -- or should we just do a half hour?  What do you guys think? Do you want to go up for a longer coffee break? Well, I tell you, you guys are really asleep. I don't know how 70 of you got a chance to raise -- 73 of you could even have the strength to raise your hands. Okay. Okay, anyway, let's take our break.

Please take the opportunity to visit the Cyber Cafe and to chat with the AC folks, especially about the stuff that's coming up, and please be back here at 10:45 and you will be called back in the room if you aren't here. Thank you. 

X.509 Resource and Routing Certificate Panel

      MR. PLZAK: Okay. We're now going to convene a discussion panel, X.509 resource routing and certification and the members of the panel are on stage here, really left right, we got Geoff Houston, Steve Kent, Steve Bellovin, Randy Bush and John Curran.

And in regards to certification and so forth, it's no longer a matter of it, it's nor a matter of when.

And so, I won't go any further than that and I will turn it over to the moderator of the panel which is Mr. Bush. Pardon?

      MR. BUSH: No, I'm not. I just got nominated as a moderator, I never had any notice of this, et cetera. I'll fake it.

For those who weren't there at the time, by the way, this was the first ARIN T-shirt, it is nine years old, how it managed to put up with me for all those years, we'll leave as an exercise to the student.

The discussion is certification of allocations, of resources by the registries, this work is being spearheaded by APNIC, we're trying to give you a little perspective on the subject. Steven Bellovin will kind of motivate it from the routing security view point which is where we all hope to end up in five or 10 years, which is secured routing.

In the interim, we're also interested in secured and verified data in the registry of -- you know, I can actually check that you really do have those allocations, et cetera, I'll cover that.

Then I think it's -- Geoff is going to cover -- give you a status report on APNIC's trial and there was a second piece, give me a clue, Geoff. Tools, there we go.

And then Steve Kent will tell you some about the dirty bits and then John will kind of wrap it up in ARIN perspective. Doctor Bellovin.

      MR. BELLOVIN: You know, as an Internet security guy, what's much less known, though I have stated thinking about routing security issues that got me interested in Internet security in the first place.

So, I've been worrying about this problem for literally 20 years. We've made a little progress.

So, what is routing security? Well, it's bad guys playing games with the routing protocols to divert the traffic in some fashion.

The enemy can see your traffic, the enemy can modify the traffic, the enemy can drop traffic and of particular interest to an organization such as this, makes it easy to do things like prefix hijacking and prefix stealing and prefix assertion, land grabs.

If you have anti-encryptography which not very many people on the Internet do, that will help what is well known by no means solve the problem.

It's also a different kind of threat and most of the threats that we deal with when we're dealing with Internet security, most communication security failures happen because of buggy code or broken protocols.

With routing security, the protocols can be 100 percent correct and the implementations can be 100 percent correct and you'll still have a problem because of a dishonest participant, it's got to do with people lying or routers lying, not routers misbehaving because the coder is having a bad day.

And the simple kinds of authentication that we know how to do the hop-by-hop authentication, I think IP set or TLS or something of that order is not sufficient to solve the routing security problem, the BGPMD5 hack is not sufficient to solve the routing security problem.

So, when this very simplified Net, we've got site A trying to talk to site B and the -- it should go through XY and W to reach there, the problem is we have an enemy out there, Z and the enemy is trying to divert the traffic to go through Z.

It's a longer path, it shouldn't happen, besides, that's where the bad guy lives, we don't want it to happen and it can.

The way it happens, the enemy would generate some sort of fake routing advertisement, pick the prefix of your choice, the one you're trying to hijack or the one belonging to your target, he can't make that in the BGP world with a fake AS path.

One that looks more attractive to the next top, then legitimate advertisement for that prefix.

Your neighbor is going to be -- is going to look at the two advertisements and say, oh, this one looks shorter, I'll take this one, I'll believe this one and we'll route traffic to that prefix towards the attacker instead of down the correct path.

And if you just want to spy on traffic and not completely hijack it, after you look at it, after you modify it, you set up a -- to something that is closer to your victim, close enough that that router won't be deceived by your fake advertisement and reinject the traffic over there.

It means basically you need to own two routers, one near the source, one near the victim. From all reports, even if we don't have -- the easiest way to do it is simply buy connectivity at two different points on the Net.

If you don't want to spend your money, you can go hack into a router some place but all accounts, that's not particularly hard.

So, again, in this particular example over here -- the -- Y is telling Z and X legitimately that it's got a 2 AS hop path to site B but Z is telling X it's got a 1 AS path to site B.

It's easy to see which X is going to believe. The problem is that X has no knowledge of these real connectivity, even Y has no knowledge into these real connectivity, the problem isn't the link from X to Z, the problem is what Z is saying.

And, of course, in this example, Z being dishonest, but Z, in fact, could have been completely honest but deceived by some upstream neighbor of it, say Q.

Unless you know the full topology of the Internet, the full AS interconnectivity, and everybody's policies and no one knows either of any degree of authority, you can't solve this a priority, you're just looking at these paths and they look right, your neighbors may be completely honest, no one is playing games with the link, it's just that somebody is lying.

So, next question is: Who's launching these attacks? The most visible use of this has been the spammers, they've actually lately backed off on this a bit as best I can tell, it's easier to go create bot nets, have worms create bot nets and launch the spam, that way, to close that down, you know, in five years, Windows just might shut some of that down, they'll switch back to routing attacks.

We have people who want to do genial service attacks, take somebody else off the air, we get that for vandalism, you see, there's a lot in the D dos world for extortion, especially against bedding sites, all you guys are ISP, you know this better than I do. There are industrial spies who can do this and well, let's just say that there are other people who are playing these games and I'd rather not say more but these are the first reports I heard, well, this actually happening in the wild.

The biggest attack would have left off this category, the accidental misconfiguration, things like the AS 7007 incident, like last September, AT&T, backbone being largely off the air because a Bolivian ISP was announcing 12/8.

All of this is threats that could be averted if we had proper routing security. You want a spy on traffic? Well, traffic that should be encrypted isn't, especially e-mail, even stuff that is encrypted, say secured Web pages, you generally get to that Web page by clicking on a link on an unprotected page.

So, I divert all traffic to that site and when the unprotected page goes by, I change the link, a secure link to go some place that I control -- certificates, who checks certificates?

I won't ask in this room who knows where a certificate is, though I've had fun asking that in other audiences, but let me ask, and I hope this doesn't violate the world against voting, John or the Chair. Who always checks the certificate of a site when doing a purchase on-line?

Very good, I see about four people. Steve, I'm not surprised that you are one of them. The attack has been modified, think fishing on steroids and of course, most e-mail is not encrypted, even if it should be.

Signing up for some Web site for some activity and they had a great privacy policy, great guaranties and I was logging in and sending my password -- not even HDPPS, but they're really protecting my privacy.

Denial of service, you attract the traffic by sending out this fake prefix and divertissement but you don't forward it, or a subtle attack as you forward most of it but not all, you forward things that look like traceroutes and pings but you selectively

 drop TCP traffic that you're interested in and really slow that connection, you selectively drop DNS queries, think about that way to attack.com or the route.

But the pings and traceroutes will all work just fine unless you're using a DNS protocol based to traceroute or a TCP base traceroute.

You know what prefix is? In general, just connect to a clue as ISP, one it's not filtering the advertisement from their own immediate customers, there are plenty of those out there.

ISP you have PI space, and start using your stolen prefix or a land grab, there have been articles, places like security focus, people are finding prefixes that aren't used and reselling on them what they will call the gray market, I will call the black market and people just start announcing them.

How many put these sites three hops upstream checking all of the AS path they receive against routing registries.

You know the answer to that as well as I do. We don't fix routing, we don't fix routing security, we will see more attacks. As some of the other attacks vectors are closed, the bad guys will pay more attention to routing.

The worst thing about spam is not spam per se, it's that it's created a profit motive for hacking.

The spammers and the extortionists are paying the hackers, well, this is already in their tool kit, they will dust it off.

Anyone not using end-to-end encrypt will be susceptible to eavesdropping or packet modification, everyone will be vulnerable to highly tunable denial of service.

You get more from others on what to do to fix this? We have to have digital signatures, no other technology will let us let people -- on an arbitrary points, in the network, verify a routing advertisement without knowing some secret in that in a way that doesn't scale.

We need certificates of some form to bind resources but AS numbers and prefix is to the legitimate owner and particularly to the public key so someone can verify it.

A lot of details need to be worked out, including exactly how we want to do this over the wire, I have my own preferences, I won't go into them now but all possible solutions rest on these two points, and is also very very clear to me and I suspect to most people in this room, that the certificate infrastructure for this has to rely on the RIRs because it's the RIRs who are issuing the prefixes and issuing the AS numbers. Thanks.

      MR. BUSH: Thanks Steve. Okay. The quicksand we're in, the quality of WHOIS data is, to be polite, unknown. The quality of the RIR data, the routing registries is in a similar really brilliant state, okay.

There is no formal means of verifying if a new customer, if I'm an ISP, and you know, Axel comes to me and says, hey, here's my prefix route, I have no way of formally rigorously testing that, I can go to the WHOIS data but since the WHOIS data is kind of weak, I'm up creak, okay.

There is -- and the routers, as Steve says, have no formal means of verifying routing announcements, okay.

The issue, as Steve has pointed out, is not router security, let's not worry about how they're tracked but routing, the protocol attack -- infrastructure, creation, storing and moving it, okay.

What is a PKI. For us, in our context, it's a database of the identity certificates for the routing registries, for the ISPs, for the end sites, the resource certificates for the IP allocations, for ASN allocations and rights to route, and rights to route are when Axel came to me and said, route my prefix, he has to put something in the routing infrastructure that says Randy's AS 3130 should be able to announce my prefix, 66642/16. Okay.

So, okay, what we need is a formal verifiable system that allows me to verify that a customer has actually been allocated a resource they're asking me to route and that could be a manual process for the moment, this is kind of in time, how usage will progress.

Next is, you know, hey, I'm debugging, somebody says a prefix has been hijacked, can I verify in a formal fashion which cryptographically signed that they do or do not really own that prefix.

How about when I'm building route filters in my routers to filter announcements from my neighbors, this isn't a change to secure BGP, this is just building the route filters we have today, I have the ability to validate that data formally.

And lastly, in the long terms, as Steve says, allow routers to formally verify BGP announcements so that actually the routing itself is formally signed.

Okay, the underlined architecture that I, as an ISP, would like to see is to have one implementation underneath which is used by all registries and by all ISP who want to run this kind of infrastructure.

The RIRs have to each be allowed to have their own business processes, user -- et cetera as will be the ISPs run this, the way things happening now are different than they happen in APNIC or different than they happen in LAPNIC, et cetera. Okay.

And it allows ISP to build our own processes on top of the base tool set. The applications we want to handle are the ownership of ASs and IP space and certified transactions with the RIR.

In other words, this is the business part of it, how it's -- to be able to send a formal request to the RIR, to get an allocation, the RIR knows that is from me because it's a certified request, et cetera, et cetera and the same for billing, the same for DNS Delegation, et cetera. Okay.

I want to operate across RIRs, I don't want to have a problem when the prefix I got from ARIN, I want to route it over an AS I got from RIPE.

I want to be able to take and mix and match these things and I want to be able to mix and match normal allocations with experimental, with legacy, et cetera, okay.

Some ISPs are so big that they have spent tenths of thousands of dollars on getting formal certification structures already and they have large security departments and formal ways of handling certificates already.

They are not -- you don't want to place, you know, my friend 702 in the position of going upstairs to some telco minded -- security people and saying, by the way, for my routing, you're going to have to change the way we do things.

And our certificate's useless, we're going to need new private keys, et cetera, et cetera. So, I should be able to come into the system and use the private public key pair I got from Verizon or whoever, to enter this game, okay. That doesn't mean that we're going to dynamically check to the Verizon registry for identity because it turns out that that is, they charge you 25 cents every time you want to know. Okay. Most members are not going to want to do this.

Most members are going to go to a web site at the registry, are going to say, "give me a certificate", they're going to install that certificate in the web browser, and it's just all going to magically work for them because they're just, they don't have funny bell heads with funny security policies in the company. Some of us aren't so lucky.

There are some key aggregation things, I want to be able to de-aggregate a resource and route the parts independently. So that means, you know, I've got a 16 and I want to route the two 17 separately. I want to de-aggregate a resource and transfer part of it to a third party. Geoff Huston has done a lot to try to get in our minds, but as the IP-4 space gets used, that there's going to be an active market in v4 address space, so I don't want to speak to whether or not that should happen business and culturally, but if it does, we need to be able to handle it technically.

I want to be able to acquire a resource allocated to an ARIN member while I'm an APNIC member. I want to be able to aggregate resources that were obtained separately. If I get two /9s, I want to be able to pull them together into a /8. Those could have come from two different RIRs.

The RIRs identities are the trust anchors for the system. In other words, when an end site has an allocation, that allocation was signed and given to them by an ISP that was signed and given to them by an upstream ISP, it was signed and allocated from them -- to them by an RIR. Plunk, we've reached the top of the tree, maybe. There could be a further top of the tree, the NRO or the IANA. This is a policy in business decision that RIRs have to make, okay.

Alternatively, they could have generated their own, et cetera. But the tough issues, by the way, are key roll over and levitation, what happens if ARIN's key is compromised. So there's some business and technical policy and process that has to be wrapped around that, and there are some alternatives. Okay.

Similarly the ISPs and the end sites, they have certs that are generated by the RIRs. Note that these only need to be reproducible. They're not formal identities, they're just used in business transactions, and to create, allocate -- resource allocation CERTS. They could be started with the keys from an external CERT. ISPs might use an ARIN identity for an APNIC allocation or business transaction, so ISPs that span the globe really want to do that, okay.

The mess kind of looks like this, there's the database, RIRs, do a CERT, you know, do the CERT for the ISP, ISP for downstream, downstream to the end site, each one putting the CERTs in for the things they allocate, so when the RIR allocates an address space to me, they put that CERT for the allocation into the database.

Let's call it an API for the management of the public key infrastructure database. It has to be across RIRs for dealing with multiple pieces of the repository. The entire repository just isn't going to be in one computer in Fort Mead, Maryland, okay. It describes interfaces and the transactions for publishing, validating in certificates, et cetera, note that the PKI is self-authenticating, in other words the CERTs form a formally verifiable hierarchy, or grass. It can be traversed and tested. You don't have to take and get a CD-ROM with the stuff on it that's signed by somebody and handed to you with a secret handshake, okay. So there's no need for transport security. The data play is just going to talk about the APNIC trial code, which has some more work on it. We've been converging on requirements. Geoff and George have a good sketch of the API, so there's the questions of how we're actually going to go forward as a community, getting common code. The coordination of updates in central repository is not feasible, so we're going to R-sync the pieces, et cetera.

This is the wrong presentation. I'd like to stop here. And I do wish to thank Geoff, George, APNIC for taking long lead on this, and so why don't we hear from Geoff next?

      MR. HUSTON: So, if you've got a router handy, or you can get access to one, if you want to play the game of trying to find out who's lying right now, go and look for 61.0.0.0/8. It appears for about a minute or two, and then it disappears for 10, and then appears for about a minute or two, and it's been doing that for about a year and a half. No one actually owns 61.0.0.0/8, do they? Anyone here? You don't. It's a /8, it's a /8, we're actually doing allocations from. So why are you seeing it in the routing table? It's not real. It's a base for spam launching.

If you have a look at the lightning torques at NANOG 35, there's some brilliant piece of detective work by Nick Feemster in matching spam sourced from the vacant addresses in 61/8 to the appearance of the router. It's not a bogon in the sense of IANA are still holding it, therefore we can't route it. It's out there, but they're doing a massive aggregate. It's lying in the routing system.

So what's the problem here? As Steve said, there are many ways to lie in routing. And what really happens out there is that our current mechanisms of bogon filters and routing policy databases and IRRs are about the best example I could possibly give you of what Bruce Shania describes as a security pantomime. It's the appearance of trying to do something without the substance. It might make you feel good, but it doesn't actually get close to what the problem is. They're not robust forms of defense.

So, what we're trying to understand here in APNIC is our business's uniqueness and validity. How can we help you? Because quite frankly, if you're in the ISP world and you get routing requests, "Please route this address," you have to do data mining across WHOIS data. It's a very fuzzy match. The better you are at it, the more expensive you are as an employee. The better you are at it, the more it costs your business to have you doing this. Now, if you're getting, oh, about two bucks a month margin on that particular customer, how many hundreds of dollars are you going to spend to validate that routing request? The pragmatic answer is that as an industry, we're not equipped to do that kind of expensive data mining. So these very basic questions need to be answered in a manner that is better than what we're currently doing. Is 61/8 valid? No. Who injected this prefix? Go look. Did they have the credentials? Evidently not. And that's the kinds of questions you need to ask every time. And sometimes they're remarkably difficult questions to answer just by data mining.

So the motivation we had in APNIC in looking at this is can we provide you, the industry, with tools and techniques that would allow these questions to be answered automatically? Request the person who's asking you to route this to sign it digitally, and then validate that signature against resource holdings.

So what would be really cool is, as we've heard already, a public key infrastructure that is actually designed to talk about assertions, about resources and their use. You know, is this address real? Can it be routed? Is it actually out there? Is the person claiming to originate that, the origin AS, authentic, or is that too a lie? And most importantly, it might be my address, and you might have a good AS, but I have never told you to route it. So can you actually uncover that explicit authority from the address to the AS to actually punch it into the routing system? It would be really cool if we could do this through digital certificates without spending an enormous amount of time on fuzzy matching in WHOIS data mining. And if you've ever looked hard at the accuracy and validity of WHOIS information, you'll appreciate that that is a world away from where we are today. If we could answer those basic questions with the PKI systems, we'd be miles ahead.

The ICS has done some good work here in laying down some standard infrastructure, they're talking about a different kind of use for PKIs. Identity certificates were normally all about who I am. I bring my 100 points to some authority, passports, bills, or whatever, and they say, "Yeah, Geoff has presented this, it's really Geoff, we're going to sign his public key to say that's Geoff." This is not a case of talking about who.

The X.509 extensions are actually trying to define a different certificate, a certificate that talks about resources. And what it allows you to do is to hang an extension into that certificate that actually lists IP address box and AS numbers. And what we're talking about now is authorization of the subject to actually say, "I am the unique current holder of these resources." And whenever I sign something with my private key, the public key in that certificate can validate that assertion. So it's a critical extinction in PKI turns, and I think Steve will talk about this. The validation of anything I do must include a validation that the IP addresses I talk about are contained within that resource blocking the certificate.

So, in APNIC, we've been talking about this for, ooh, about eight years, and spent a lot of time looking at various ways of doing this. Over the last year, it's crystallized into a trial. The trial is actually all about three things I think that are useful. Trying to understand if PKI systems and certificates in particular, this kind of format, are the right thing. Is this a right use of that kind of technology? Is it a good fit? And the other thing is, can it be useful?

So, in terms of sort of looking at this, the best thing we thought to do was to actually start generating these certificates. So, this is the kind of thing we are talking about, and there a few features of this certificate that I'd actually like to point out. This is a standard certificate, version 3, it has a serial number, it keeps on rising, it has a signature algorithms, which these days is SHA 1 and should be actually SHA 256, yes, that's fine. The issuer would have actually said, "This is the CA trial." Why? Because down at the bottom, you'll find that the certificate authority bit is on. People can then generate subordinate certificates from this, so if you go back and say, "Well, hang on a second, what was this about?" If you look at the issuer, it's APNIC trial, not APNIC, the registry. It's trying to make it very clear.

Validity dates, we were using explicit validity dates in this trial based against your membership periods, in other words, based against our view of the holding of that resource as it sits within the membership system of APNIC. So this is a trial about member services in this instance.

The bit that I want to highlight however is the subject name. We're not saying you are who you claim to be. What we're actually saying here is this is all about resources, and the holder of the private key is the current controller of those resources. The subject name is actually blurred out. And what we're providing instead is basically a hex digit field. In this case, you know, FC00- whatever. We'll be using, and have used in the trial, this kind of anonymized subject name because it's not really about who you are, it's the resources that you currently control. And of course public key info.

There are some extensions, the extensions we're talking about are over on the right, the IP address and AS numbers in a block. These are your current holdings as current member database. The CA bit is on. That means that if you're a local registry and you do allocations further down, you can issue the same kinds of certificates yourself. So this is a system that is transitive in that respect.

It's critical, the digital signature is there, the key set certificates, they are real signers, and so on. There will be a certificate practice statement referenced by an OID. This is an evolving system, and we are looking at a number of extensions to the current trial, and those are grayed out in the middle. Maybe you would actually like to say, "Look, it's really Geoff. You may have given me FC00-whatever, but it's really Geoff." We're looking at doing the subject alt-name field to actually identify who you claim to be. It's an alt- name because it's not something that we in particular are saying you are really that entity, but if you wish to add a field in there, the alt- name would be the place.

In looking at how validation would work, one model is to put everything in one massive repository, in which case, you wouldn't need to actually reference where the certificates are being held. In looking at also with these kinds of certificates, you can introduce pointers to repositories, and we're looking at in particular the authority information access location, the subject information access location, and the CRL distribution points to allow someone who wants to operate their certificates in their repository to be linked into the system.

All of that is signed with, your public key info, signed by the APNIC key. So this is a certificate signed by APNIC.

What are we certifying? I think the blandest statements, or the most crisp statement I can do is, APNIC is certifying that the certificate subject who's public key is contained in the certificate - that's all we're saying - whoever owns that matching private key is the current controller of the set of IP and AS resources that are listed in that certificate extension. So we're not saying who you are, or that your intentions, good or evil, whatever they may be, we're simply saying that whoever owns that private key is the current holder of those resources.

What can you do? You can start talking to other folks saying, "If I sign this routing request, it's really me and it really refers to addresses that I control." So you can sign routing authorities, or you can even submit stuff into Internet routing registries with your private key signature on this, sign it. The recipient can validate. All of a sudden, you're talking about validatable trust here. The matching certificate's public key works and you can then validate this. Or, you could actually sign routing information that could be propagated in a routing protocol, and if you've looked at things like SBGP, SOBGP, PSVGP and so on, there are various proposals flying around who actually use this as part of the protocol payload carried around in routing. And of course given that sort of structure of the hierarchy of delegation, and there are LIRs that do further allocations, you can issue signed certificates, subordinate certificates, for further delegation.

So the trial, we're going to, in fact we have issued a dummy, 3779 compliance certificates that reflect all of the APNIC membership holdings so that there's one certificate per member actually has been generated. We are now looking at the policy and technical infrastructure to support this. In particular, we're looking at the CPS, the certification practice statement, trying to say right up front that even though the CA bit is set on, even though you can issue subordinate certificates, if you wish to use subordinate certificates for other than allocated resources, the CPS says don't trust them. Don't look at them, they make no sense. The practice statement says this is all about IP resources. But looking at the mechanisms for the certificate repository and how to gather certificates together to validate them, and also the issues around revocation, and also now, working on developing open source tools, and they really open source, about the kinds of things you need to do in order to work with certificates.

Currant status, you'll actually find that the URL down there is trial certificate repository. This is the more unique form of certificate repository. You'll also look hard and you'll find the private keys in there as well. Why? This is not normal practice, but if you want to play with these, then there's enough information to play to your heart's content. If you try and use them in any other context, beware; they're not intended for that kind of use, but they are intended to help you and the open source community look at these and start developing tools and techniques. So you'll find in that repository a key pair generation, all of the holdings, and even an explicit re-issuance, so there is a revocation list as well.

The tools that we're working on finally, there is a fair deal of tool work, because quite frankly, in this kind of area, we haven't had a lot of experiences in industry in dealing with resource certificates, so we are looking at generating and actually creating some open source tools to really strap this up. If you want to validate certificates and you want to do it quickly, you may need most of the certificates nearby. They're not actually very big, but you're going to have to synchronize with external repositories. So then that tool that wanders and validates will be looking at open source tools to assist.

So, the synchronize repository tools, the tools around validating certificates or routing authorities or of assigned objects. How to generate a routing request or a routing authority? Tools to let you do that in what's called private -- generate the block. How to generate subordinate certificates and actually do, if you will, sign certified suballocations? And of course, the issue around revocation of these subordinate certificates and, of course, otherwise how to update certificate revocation list and how to manage them.

Those tools are being developed now. Now, the current time line for this work is we would like to get most of these tools in place in the trial across this calendar year. So, APNIC is certainly well under way to try and push this forward, if you will, as a real trial that you can actually use and work with across this year. And that's about what we're up to. Thank you.

      MR. KENT: Well, I have more slides than is appropriate for this time but the good news is that some of the things I was going to talk about have been discussed by previous speakers. Why PKI? If you look at the various proposals that Geoff Huston just mentioned for improving routing security, most of them rely on public key infrastructure at some level to attest to holdings of the resources that we've been talking about; PKI is a natural way to deal with this. And I'll go into a few more details compared to the previous speakers on what this might look like.

And the things that we can do with are the things that have been mentioned previously and that is we can provide an infrastructure that will allow ISPs to be able to detect bogus route origination and if we get fancier about it, in fact bogus half information, at least on a static basis and also help avoid social engineering attacks where an ISP is easily convinced that they should be originating route for someone who in fact does not hold the prefix in question.

In terms of principles, again, previous speakers have talked about these things. I think we should be doing this in a standard base fashion which translates in X.5 or 9 certificates or the peak X profile of the IETF and RC37-79 extensions which are ways of specifically listing ranges of address space and AS numbers.

A goal here is to not created a trusted third party kind of PKI, to have the entities that allocate addresses and AS numbers and suballocate them take on responsibility as certification authorities. So that we're not bringing anybody else new into the party, we're relying on people who do the job now to do this extra step in doing the job but not trying to bring in someone new to do this.

And we have to deal with all the kinds of allocation practices and suballocation that takes place. Portable allocations, form registries, multi-homed subscribers, subscribers moving from an ISP from which they have address space and bring that address space with them, legacy address allocations, transfers among registries, et cetera.

There are multiple parts to the PKI certificate and CRL portion form or basis for it. The repository portion which we've just been talking about and also the notion of signed objects that allow participants in the PKI to make what we can consider the attestations about resource holdings, the simplest form of this being authorizing an ISP to originate routes for prefixes that you hold or to advertise a route not just a prefix but actually a path if you're an ISP.

What would we do with certificates in this kind of an environment? Well, the goal is to issue certificates that attest to the resource holdings and these would be done by registries as essentially the top tier by ISPs and even, in some cases, by subscribers.

Because these resources are done in a simple hierarchic fashion today, the notion is that we should be able to parallel this in PKI. That forms the simplest kind of PKI and avoids a lot of complexity that otherwise would show up. So, we get this kind of address allocation hierarchy and this kind of AS number assignment hierarchy and the idea is to be able to have a public key infrastructure that exactly parallels these, not to deviate from that.

So, if we assume for a moment that we have a route for the system and admittedly as Randy mentioned earlier, there are questions about whether or not we absolutely have to have a route and, if so, you know, get to place in the bottle and decide who gets to be the route.

But assuming we do, IANA does form the top tier in the allocation hierarchy and so you could imagine the allocations to the RIRs themselves representing their holdings. Then each RIR would issue certificates as appropriate to national or local registries if applicable and to ISPs and to subscribers with portable address allocation.

The ISPs would in turn issue certificates to downstream providers if they've done that in terms of address suballocation and to subscribers if the subscribers are multi-homed subscribers.

A subscriber who starts off getting an address allocation from an ISP and has only that ISP as its gateway to the rest of the Internet doesn't really need to participate in the PKI because they are invisible to the rest of the Internet. They're just one portion of the address base held by their ISP and until they do something different, they don't have to do anything as part of the PKI.

The organizations issue certificates that match the address base and AS number allocation records in their database; that's all you can ask for them to do. All of these resource holder certificates are certification authority certificates and there's a reason for that that I'll get to in a couple of minutes.

The proposed PKI uses the extensions, the X.509 extensions from our C37-79 that I mentioned earlier and the certificate path represents suballocations. So, they're directly traceful in that fashion.

So, if we pick APNIC and Geoff and his colleagues have been up front with this, we could imagine looking at it in a little more detail. So, starting from a route down to the five RIRs and then under APNIC, looking at five registries and then if we pick one of, you know, those portions of the path and zoomed in on a little bit, we go from an RIR possibly to a national registry and from the national registry to ISPs or to subscribers from the ISP in the middle down to another level of ISP, et cetera.

So, a kind of path starting here and working your way down but all these other paths are also legitimate things that could appear in the PKI to reflect how allocations and suballocations take place.

If we look inside the certificates, certificates form a chain. That's how we do certificate validation. And so, we would start, let's say, at the root which owns everything in terms of address base and AS numbers and then going down to APNIC, we'd see that the issuer who would hear the route, whatever that name is and the subject would be APNIC and I have shown a subset of address blocks allocated to them and a few AS numbers. In fact, when Geoff and his colleagues produce thereon a certificate based on what their holdings are, it's in the neighborhood of 8,000 bytes which is a pretty big certificate. But when we checked it later, we discovered that there were a few little bugs that would allow it to be compressed some more using the RC37-79 detail. So, it'll shrink a little bit.

Then, under APNIC going down to JPNIC notice, a subset in the addresses are allocated and a subset of the AS numbers and then if JPNIC issues a certificate to some ISP, a further subnetting, a further AS number subnetting and all the way down to a subscriber.

So, that's reflective -- representative of a simple case of this kind of allocation.

As Geoff mentioned, while we need to put names on certificate, that's part of the format, it's not clear that we want to put meaningful names in most of the certificates.

At the top level for the RIRs and maybe national, local registries, it makes sense to do this but once you get further down in the hierarchy, it's better, from the perspective of this PKI to not put in a meaningful name into the certificate. It discourages their use for other purposes and reduces the potential liability for the CAs in this environment who are just in the business of using their existing database records. So, they shouldn't turn -- shouldn't be assuming any additional liability in the course of doing this.

So, for an RIR, you know, country, Australia organization, APNIC organization or unit resource registry, CA might be a reasonable name for a production version of the system that APNIC now has on a trial basis. Underneath that, for instance, for JPNIC, country Japan, organization JPNIC, similar kind of organizational unit name. But when you get to the next level in the hierarchy, we expect that you could have a non-meaningful name of the sort that Geoff had mentioned earlier in terms of a X number.

If you've got a certificate, a question naturally arises: If I get additional resources, what do I do? And the answer is: Whatever you'd like. You could have those resources added to your existing certificate, no need to change the name, no need to change the public key in the certificate. A new serial number will be assigned because we always do that with a new certificate and we could update the validity if that was appropriate based on your relationship with the issuer of the certificate.

Alternatively, you might decide you want to get completely new certificate just with these resources because your business practices, are you going to use the new allocations, make that more appropriate? Either way works fine in a system like this.

Also, if you want AS numbers in certificates all by themselves separate from your address allocations, sure. That works too. You can consolidate things or you can leave them separate. It's just a question of what makes sense in your environment but it will all work in the end.

You also have to accommodate in a system like this allocations from multiple sources, getting AS numbers from one place and address base from another or perhaps more commonly address space from two different places over time. You have to be able to do it. It's possible. There are several choices on how you can accommodate it.

One thing you can choose to do is once you've got a certificate from one provider is to go to another provider and say, "When I get a new resource allocation from you, instead of generating this random looking number to put in there, I want to re- use the number I have in the other certificate". And that can be helpful for a technical detail relating to PKI design that allows the result to be looked at in a more uniform fashion. You don't have to do this. It's just an option.

And so, this is the kind of diagram that would show up here. Let's say that this subscriber has an allocation from a regional registry as well as from an ISP, they can appear inside this dotted box to be the same entity because they are the same entity. But they have to have two different CA certificates because of the subsetting property for the allocation system that allows automated verification to take place.

They can then issue what I'll talk about in a moment which are shadow certificates. These are the first end-entity certificates as opposed to CA certificates in the system and from that, sign what are the labeled route origination authorizations, either separate ones or a combined one, if you want to glue it all together.

So, route origination security is one of the first and easiest things to make use of here in support of improving route filter generation. We're talking about creating signed objects. You could name them anything you want. I call them ROAs because that was the acronym -- that sounds like a bird, probably, from New Zealand or Australia.

If you want, you can have one ROA that combines all of your allocations if you have them from multiple sources and you can then indicate which ISP or ISPs are authorized to advertise all of them or, if it makes sense in your environment, you can create separate ROAs and a motivation for doing this is to allocate different chunks of your address based to be advertised by different ISPs.

So, any kind of mix and match there that you want to do works. This is a rough format for this kind of thing. A list of one or more prefixes up front, a list of one or more AS numbers identifying the ISPs that you're authorizing to originate these, a validity in a -- because experience shows if you're going to sign something, putting a validity in a -- in it is a good idea, and then a signature list and inside that list, if it's more than one, what you have is a sequence of pairs of things which are signatures and you might have to have multiple signatures because you might have multiple certificates representing the different sources of allocations, and then, a back pointer to help on this issue of: "Okay, which certificate is the right one to use to verify this signature?" So, that's the rough notion for this.

We've talked about how to do route filter generation easy. The approach here is you go to repository system, one or more repositories, download either all the stuff that changed from the last time you went there and asked the question or just download everything. Certificate CRLs and these ROAs, verify the cert paths, use those shadow certificates that are added in there at the last stage to verify the ROAs themselves and then, from that, you can construct a table, for instance, that for each AS, what are the prefixes it has been authorized to originate or the other way around.

You could also do a variant on this if you're a subscriber going up to an ISP and saying, "Please, advertise my prefix". You would go ahead and send the ROA in some locally secured fashion, locally good enough for the ISP to show that you are in fact authorizing them to advertise this prefix and that you are the holder of the prefix in question. The ISP can even automate that process and verify that, yes, you're the legitimate resource holder and therefore, it's reasonable if you are their customer -- if you are a customer of theirs to advertise this on their behalf.

You could do something more ambitious and Geoff Huston, in fact, suggested this at meetings at APNIC just last month which is create fancier signed objects to authorize a neighbor, an ISP neighbor, to advertise a route, not just to originate a route. And you put in the AS number of who you're authorizing. You put in your AS number. You put in the prefixes and you allow these signed objects to be nested. And, in that fashion, you can pass them around or put them in a repository and create a static representation of the kind of information one would use for fancier kinds of route filtering.

So, this is the kind of technology that in some level of detail we're talking about creating. It has tremendous promise both for near term improvements in terms of route filtering and convincing ISPs in orderly fashion to legitimately originate routes for you. It also provides the basis for fancier, more dynamic sorts of things through modifications to routers and BGP in the future.

And so, I just ask you to contemplate this sort of thing over lunch. That's my Ninjia. Thank you.

      MR. CURRAN: I'm John Curran, I'm the chairman of ARIN and my purpose for being up here on this panel is very simple. You've had a number of folks talk about possibilities for using PKI to better secure the chain of allocation and potentially there are announcements in the routing infrastructure.

All of these are functions that certainly, if you take a look, the function of better securing the chain of allocation information is something that's within the scope of ARIN. And what I mean by that is we presently provide these allocations to people and the infrastructure we use to do it has some degree of security or insecurity and there's nothing wrong with looking at alternatives to tighten that up if that's desired.

The real challenge is that it's hard to know if it's desired. All the people on the panel here think that it would add value. We've seen other RIR go through some preliminary efforts to forge ahead in this area but, at the end of the day, the ARIN board is going to have to know whether or not we should invest ARIN's resources in securing the allocation infrastructure and providing effectively information that's of higher value than just performing the allocation, information that would let you actually perform some verification and improve the quality of the data that Randy was talking about on his first slide.

So, my request to everyone is: We've seen a lot of slides that have a lot of technology regarding encryption and security and PKI but I don't know whether or not people think that this is a place where ARIN should put resources and that's going to have to be - as we move forward in the discussion today - that's going to be an important part because we don't want to invest in something if it's not valued. Likewise, we don't want to turn down an opportunity if this is important to some of the members. So, that's my speech. Thank you.

      MR. PLZAK: I guess I'll say the floor is open and I'll take the back microphone. Go ahead.

      MR. WEILER: Thank you, gentlemen. Sam Weiler, Sparta.

First, I wanted to thank you gentlemen and APNIC for working on this, particularly on the cross-registry bits and on using certificates who don't have identities in them.

However, as I listened to the earlier presentations, particularly Randy's, I've heard the first problem that he's stated as an ISP wanting to verify that a particular customer is entitled to advertising address block.

And if you look at that first stated problem in isolation, along with Dr. Bellovin's analysis which I didn't hear him mention any threats against WHOIS look ups. No one's attempted to -- WHOIS data, at least, I didn't hear him say that.

One might reasonably ask why is doing all this PKI stuff going to help? How is it going to improve the WHOIS data? Even if we were able to improve the underlying data, why would you need the PKI stuff? And even, why isn't this worse? Because once you start doing automated things for cartography, you start introducing extra breakage.

So, I would encourage the panel to explain, again, why is this better? How does it improve the data? Why do you need the PKI stuff? And I would encourage the Chair in asking the room to ask exactly what bits membership wants resources spent on it, whether that's improving the underlying data or doing the encrypting, as a separate question.

      MR. BUSH: In the ARIN database, underneath all this, the data of what ARIN has actually allocated way back is stuck in Oracle is actually pretty good. The WHOIS data by the time you get out to the front and the RIR data are weak. This obviates both of them in the long run. It replaces them, period. You may want auxiliary WHOIS data or who -- what's the postal address of the person -- the entity to whom this has been allocated. Okay? And that can be signed and certified with this.

But what this gives you is the same data structure in a verifiable certified fashion. And I think that's a distinct improvement organizational for the manual procedures.

And I've lost the -- I haven't answered the second half of your question. I forgot it, Sam. I'm sorry.

      MR. WEILER: That's okay. I had trouble keeping track of it myself. So, the first question was: How do you think this proposal will improve the data. And then, why do we need the crypto once we've improved the data? We haven't heard that WHOIS look-ups are threatened.

      MR. BUSH: Because why should I trust it? How do I know it? How do I know you have -- somebody hasn't put false data in the WHOIS? Oh, you mean that you drew this data in, it's going to require some sort of signature and -- oops! Aren't just following the same trails from a different entry point? This is an invitation.

      MR. KENT: Sam, you're right, that crypto is low replacement for correct data in the first place. Getting that data correct is absolutely prerequisite for -- you know, you don't want to issue the certificates to the wrong parties. This is an issue that needs to be worked for other reasons and it is being worked. We need to clean it up.

As for why this is better than WHOIS, WHOIS -- you know, really improve through his data, even populated in the routing registry helps if you are the first hop. It doesn't help if you're four hops away. In the example I gave where I said, you know, your immediate neighbors are being lied to by someone three hops upstream from them. You have no idea what connectivity is supposed to be. That's what this is supposed to solve.

      MR. HUSTON: But the take away point is that the first problem Randy posed, you know, the ISP -- verifying the origination in the first place --

      MR. KENT: That's already a problem we -- the RIRs have already tightened up their procedures for change of registration because of paper base highjacking of prefixes and domain names. This is not a new problem.

      MR. HUSTON: Sam, there's another part to it. Last year, this kind of question was asked at a routing security workshop that department of homeland security sponsored and the folks at ARIN did an analysis and came back and the -- and I'm just going to paraphrase it. But the answer is that the vast majority of the data in WHOIS database of course is not put there by the registries. It is put there by the suballocators and the suballocators, in many cases, don't have a strong incentive to maintain the data accurately.

So, this system creates such an incentive in terms of facilitating the routing, that is if people start demanding that certificates be in place and ROAs be signed in order to accept route origination information, it creates that motivation further down the tree which previously has not existed.

So, there is a rational basis for saying, "Yes, this can be improved" and it is not primarily the responsibility of the registries to do that improvement however. There's a distinction.

      MR. CURRAN: Okay. Should one people -- we are going to go a little late for lunch but not too far, if you're going to speak on this, please find a microphone. Centre microphone.

      SPEAKER: I support this work. I think it's very important for us to move forward. I'd like to see ARIN commit financial resources as well as people resources to supporting APNIC work as well as specifically working on the tools and the use cases for ISP because I think that is where we must spend the majority of our time to make this deployable and operationally feasible.

      MR. CURRAN: Okay, far microphone?

      MS. MURPHY: I actually have a couple of different questions. I'll ask one and then circle around them.

      MR. CURRAN: Name and facility you are, please?

      MS. MURPHY: Sandra Murphy, Sparta. I was getting there.

I'd like to point out that Randy's presentation said that a central repository was not operationally feasible and Steve Kent spoke a lot about a repository because these items are digitally signed, they maintain their assurance separate from the transport mechanism and Randy said from their source.

So, we have other communication models available to us. I was wondering if the panel members would like to discuss their difference of opinion there.

      MR. HUSTON: This has certainly been a topic that we've looked at in the context of the APNIC trial. And the original model that we did have was this -- if I could describe it as mothership repository because no matter where the certificate is, its assurance is part of the validation chain. But actually collecting the certificates to do this is the issue.

We have looked at the fields that have been included in the version 3 of the X.509 certificate structure. The subject of authority information access fails --

      MS. MURPHY: M'hm.

      MR. HUSTON:  -- and still undecided as to, you know, precisely what we would do with them. But it seems that if someone there said, "I want to operate my own repository", then the ability to point to that repository inside those fields of the certificate allows us the flexibility to have more than one repository as the prime resource --

      MS. MURPHY: M'hm.

      MR. HUSTON:  -- while still having a plain way of collecting the certificates together in order to do reasonably efficient validation.

      MS. MURPHY: And what you just suggested would be a hierarchy of repositories?

      MR. HUSTON: The APNIC trial is certainly looking at three repositories in a hierarchy, certificates that APNIC issue themselves.

      MS. MURPHY: M'hm.

      MR. HUSTON: Second, certificates that are lodged with APNIC are verified at the point of lodgment and cycled through continuously refreshed on verification.

      MS. MURPHY: M'hm.

      MR. HUSTON: And thirdly, a repository where we actually work from the top to the bottom collecting the certificates for the chain and validating names. So, we would certainly