These are unedited transcripts and may contain errors.
Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24
The test traffic Working Group commenced on 6th of May 2010,:
CHAIR: Good morning, everybody. Welcome to what is probably the last test traffic Working Group, there is more of that in a little bit in a moment's time. My name is Ian Meikle, I am one of the chairs. But again, that is probably going to change very shortly. This is this morning's agenda. Just a quick reminder, if you do get up to ask a question or make a comment, state your name and affiliation in the mic. We do have a Jabber room for the Working Group, so if you listen to this on the audio cast, do you have the opportunity to ask questions through there. I haven't seen the blue sheet, I don't know if there is a blue sheet going around: Have we started any other business already, George? We do have ?? we do have /REPB nay scribing the meeting.
I think, I am not entirely sure that we circulated the minutes from the last meeting, I don't know if this means this is an illegal session, but if we haven't we will get them to the mailing list very shortly.
We are going to start first with a rechart erring of the Working Group which is what I mean by this being the last session, we are going to relaunch the Working Group as part of the rejuvenation of the RIPE meeting and give it another name, as well. Following that, we have got Emile from the NCC, Hi. I thought you weren't in the room, who is giving a technical background to the talk that you gave in the IPv6 Working Group earlier this week about measuring IPv6 web clients and caching resolvers, we can get some idea. Erik is going to give an update on the measurement network. Rubens from nick dot PR has got some suggestions of improvements he would like to see to the test traffic measurement network and equipment used for that. George from APNIC is not going to give us an argument about administrative procedure in the Working Group but is going to talk about ? R IPv6 and Casey has got a visualisation if, time permits we may have a small demo of the tool as well but he is going to present on DNS visualisation tool that he has developed and hopefully a little bit of time at the end to talk about any other business.
So, to start with, rechart erring of the Working Group, we talked a little bit about this in Lisbon and put something on the /HRAEULG list. The current charter is quite old, it reflects the fact that the Working Group was set up to discuss the NCC's test traffic measurement network and the ?? the uses that that can be put. It's been clear for some time that that doesn't allow us to fill a full Working Group session, and we have really been taking other talks about measurement activities. We have had other things from the RIPE NCC IS group talking about the things that they do beyond test traffic and we wanted to legitimise that and hopefully relaunch the Working Group and make it more relevant to the community now.
So this is the charter. This has been sent to the mailing list. We had some positive comments /PH the meeting last time, some positive comments on?line. I have not had anybody who has got any objections to the way that we have done this. If anybody does want to comment on it or make any objections, now would be the time.
Seeing as we are moving away from being just the test a traffic Working Group, we thought he would give it another name. The name that we settled on is the measurement analysis and tools company. As I have said, my preferred option was Internet measurement but that is just because it matches my initials, but I think this is a very good name for the Working Group and it does describe what has that we are about and gives it a broad basis for the kind of presentations that we have.
So, as I said, we have posted this to the list in 2009. We have put no comments were received, we did get some comments, more verbally than by e?mail but I think that most people are in support of it. What I would like to do is say that we approved this new charter today and if we do, I will move to present that tomorrow in the plenary session, along with a new name for the Working Group. And then he will obviously update the web page, relaunch the mailing list, etc..
With the new name, the new charter, we have decide it's time for some new blood in running the Working Group, and Henk has decided, having done sterling work running the Working Group for many years, that it's time to step back and just be a member of the community, for which I'd like to thank him for the work he has done so far.
(Applause)
Obviously, that leaves me chairing the Working Group on my own. We need a new chair, we have had two people who have already expressed an interest; that is Richard Barns of BBN and Christian Kaufmann of Acami, I would like to ask is there anybody else who would be interested in being a chair of this new MA T Working Group? No. OK. In that case, I would like to say that rather than have an election, we just move to aclamation and Richard and Christian become the Working Group chairs, OK.
I should probably have done this before I asked for volunteers, just a little bit update on what is involved in being a chair. There is a bit of work ?? there is a bit of work in obviously setting up this meeting in, getting the agenda sorting out, bringing interested parties into the community. There is also a bit of work in the overseeing the RIPE policy development process. That is not actually driving what policies are adapted but making sure that that process has been followed correctly. We said you get a free lunch. It usually involves sitting listening to people argue about whether or not the policy is being followed and how the meeting plans being organised so it's not quite a free lunch. But they will experience that this afternoon.
OK. I think that covers the first point.
So can we have the first speaker, which is Emile.
EMILE ABEN: Good morning. So first of all, I am Emile Aben RIPE NCC science group, I am going to talk about measuring IPv6 at web clients and caching resolvers which is sort of a technical background behind the talk I gave on Wednesday. I don't know how many of you saw this talk on Wednesday? There is a little bit of repetition in here, a couple of minutes, so if you had a nice party yesterday, you can do a micro sleep or something.
So, what this is all about is that we want more insight into IPv6 deployment and there is two numbers that really stood out to me where we see a large discrepancy between the numbers. If you look at the routing table, 6 percent of the ASs that we see in RIS announce one or more IPv6 prefixes, whereas if you look at web traffic, there is a quarter to two percent of web clients that we see doing IPv6 and that also depends on who is measuring and where they are measuring. Google measures the.25 percent and APNIC measure 2 percent, we measure about 1, a little over 1 percent, so but these numbers are significantly different, so we are interested in where this difference actually came from and so we, what we did was to measure the IPv6 connectivity of end users combined with the ISP infrastructure that they are using and the way we are doing this is we have a little bit of code on a participating website; it's a little piece of Java script, end user visits this website; gets the Java script back and starts executing that and in that execution you measure the v4 and v6 preference of an HTP connection which is what most of the measurements have been doing up until now, but new thing about this measurement is that we are also measuring the resolvers that the clients are using and the idea behind that is that the resolver is typically part of the provider infrastructure so this will give us a bit more insight into things that are not the total edge but things hopefully near the edge or typically near. So what we do is we measure the v4 and v6 capabilities of these resolvers to our measurement infrastructure.
So this is where you can wake up. This is the new part. So, as I told in our case, we instrumented ripe.net, we put a piece of Java script up there for the people that execute this they generate a series of four unique URLs, they insert into the domain so that makes a web client fetch these four URLs and they are of this form, they have a unique ID, they have what are called an H label and that is for measuring the HTP connectivity, either v4, v6 or B both for dual stack and the D label is for measuring the DNS connectivity, same way of labelling.
And I thought it would be easiest to explain this with an example so in this case, the client is fetching this object which has H 4 D 6 in it, and this is just looking at the HTP part of it, so client goes to caching resolver and that asks authoritative name server and because there is an H 4 in that label, it will only return an A record so the client with only fetch over v4. So the whole key to the HTP measurement is that the authoritative DNS server determines IPv4, IPv6 for the client web server communication so you can restrict to v4 and v6 or you can allow both and see what they are actually doing. So this is the part that also have been doing.
The step before that, the DNS lookup, you can also play with that in that the server that is delegating towards your authoritative name server does something with this D4 label ?? D label in our case. So in this case, the image that is fetched or the URL that has fetched has this D 6 label in it, so caching resolver makes a ?? does its normal lookup process and ends up at the last delegating DNS server and because there is a D 6 in there it refers to the authoritative name server with only a quad A records. For the name server that is authoritative. So the caching resolver is only able to reach the authoritative name server over v6 so if it doesn't have v6 cablibilitiesibles you don't see any connection coming at all and the lookup for this object will fail both on the authoritative name server and of course you won't see it at the measurement web server either.
So this is actually the matrix of the measurements that we did, because I mean, if you have three options for DNS, three for HTP you have nine possible permutation of nine. And so we decided to only do four, partly because you don't want to load these clients with too many measurements. H 4 D4 which is sort of your baseline, assuming everybody in the current Internet is still doing v4. I think that is a fair assumption, right? Who is only doing v6? This is also bi?assembling I think.
So we decided to look at sort of do, change one parameter so from H 4 to D4 G to H 4 D 6 so that is given v4 HTP connection or ?? v4 connection is HTP and see if the DNS over v6 works. Also, the same for H 6 D4, so a v4 DNS and a v6 HTP, so the H 6 D 6, we didn't do that because you can infer that from clients who are able to do H 6 D4 plus clients who are able to do are going to be in the same, basically in that part of the matrix, and we decided to do HB DB because that way you measure the dual stack capabilities of HD B of the clients and caching resolvers at the same time. So in the back end, it looks like this: Just using apatchy log and normal DNS query logs. So this is an example of ?? for the HTP in this case you see all four measurements coming in, so this client was able to successfully complete all four of our subtests, and in the DNS query logs you see, you see the same URLs in here, so you can actually stitch these together, which you see in a mix and match part here. So, the resolver with 2222 did this query, did an A query and quad A query which ended up ?? which came from the web client at IP address 1111. We flow that because there is that unique ID in this string and you have this H 4 D4 label for both of them, so this ?? this whole thing is one single measurement of one client so you measure the four sub measurements to this one client and you get a combination of their abilities.
So, we put the unique ID in the domain name for two reasons, it allows for this correlation of these sub measurements and also forces the DNS lookups and DNS is wonderful protocol that has lots of caching in it and for this you don't want that. So we use very low DNS resource record TD Ls just to be sure. We limit the number of measurements to be one run of the script per client per day. We filter out local RIPE NCC traffic because that would skew it towards IPv6, of course, and of course we have a measurement bias here; we are measuring on wwwripe.net so we are measuring an operator community so you expect these numbers to be higher than your Joe Average Internet user, and we also measure using Java script which is also a selection of what you measure.
So measurement results, and this is where people can go to sleep for a minute because this was also shown two days ago. For the client IPv4 preference, so this is given you have v4 and v6 transport available, will the client use the v6? And you see it's about one ?? it's slightly increasing but, over the period of the three months we have been doing these measurements now. We have client IPv6 capabilities which is given the client has only the option of v6 it is going to use it and this difference is actually caused by local policy to prefer IPv4 over tunneled IPv6 so Teredo 6 to 4, that is basically this difference is caused by that. And the blue line is the clients with IPv6 capable resolvers so that is basically the H 4 D 6 test and you see this is nicely at around this 5 percent so this is where you see a difference between the ?? between the clients and resolvers. So, if you filter out all of this tunnel traffic so only count IPv6 when it is native, where native means no Teredo, no 6 to 4, so that way you filter out all of this auto tunneling, you actually see the client IPv4 preference and capability, basically be the same number, whereas the clients with IPv6 capable resolvers stay up at this five percent and this actually shows you a little bit where this difference in IPv6 deployment or at least indicates where this difference in IPv6 deployment is. It's not reaching the clients as well as it is reaching the resolvers that the clients are using. So, it's an indication that people are deploying IPv6 but not rolling it out to their clients, at least not massively.
So are things in the same AS? Of course, we have this assumption that the clients and the resolver are close to each other, so you want to know if they are in the same autonomous system to sort of see if this is actually a valid assumption. First thing here, IPv4 HTP and IPv6, HTP so we are comparing the autonomous system that we see for the v4 and v6 for the same client because you can do that because they are in the same measurement, and for this we had eighth K measurements and 64 percent of this of cases, the v4 and v6 are in the same AS. I find this number surprisingly low, and I will get back to why this number is, might be so low. The mixed AS column is for the DNS ?? for the comparisons where we have DNS, because you can have multiple DNS servers that you see in your logs and they can be in multiple ASs. So that is that column.
So if you compare the v4 HTP and v4 DNS, so this is comparing if the things, the different thing that you measured, the clients and resolvers, if they are actually in the same AS and roughly 80% of cases that is the case. So there was, I thought that was a night result.
If you look at v6 HTP and v4 DNS you see that 76 percent are in a different AS, whereas I count Teredo and 6 to 4 as a special case of AS.
If you filter these out, it becomes 61 percent in the same AS, so if you give from 76 to 61 that difference is basically caused by Teredo and 6 to 4 and if you look at all the other combinations between, that are below there you also see numbers in this 60 percent range. And if you compare that to the 80% for v4 HTP and v4 DNS that is an indication of how much configured tunnel brokers and stuff like that is happening, which yes, get there in a minute. These are just some random things that I find interesting here. One thing Google does Java script so we see Google bought in our measurements, which surprised me. In '05 percent of the measurements we see two large provider of DNS that the clients AS is not the resolver AS, so this is 80% number where the client AS is not the resolver AS, 5 percent of that is caused by people providing DNS services. And we also see that at least 10 percent of the client AS v4 is not client AS v6 is caused by ASs involved in tunnel brokering. There is a couple of well?known ones, Hurricane Electric and a couple that are used by 6 success which is the cause of that. Other thing you can do with this data is look at the host ID so last 64 bits, how does that look for clients and resolvers? What method do they use to ?? for ?? for determining these last 64 bits and that is classification method that David Malone was kind enough to provide us his scripts. He did a 2008 paper on this. Low means only using the last bit ?? last eight bits out of the 64 that are available, and as you can see, this is kind of expected that you don't see that happening too often in clients, but you see it a lot in resolvers and that has actually a little bit of repercussion for security because one of the things IPv6 is more secure that IPv4, but this ?? because people are ?? cannot do random scanning any more, they cannot scan your whole address space if you just loose a lot of zeros in there your address space becomes more scannable again. We see autocom E O I 64 type stuff is about the same for clients and resolvers. Others is unclassifiable stuff v6 where you have the last two quads that haven't encoded IPv4 address or something that looks like IPv4 address and that is basically some tunneling protocols use that. Privacy is privacy extensions and recent versions of windows use that by default and you can see that here.
So, what is next for this? We want to keep this run. We live in interesting times. Something is going to happen with IPv6 sooner or later, so you can also see this as we are starting something, that is baseline data. The other thing that we would really, really want is more data and specifically on your Joe Average Internet user. I want to know when my mom or everybody's mom here starts using IPv6, and she is not going to visit wwwripe.net any time soon.
AUDIENCE SPEAKER: You don't know my mom.
EMILE ABEN: I want to measure. What we want to do is have people participate in this experiment. We want, if the community wants more useful data out of this, we want to get something back from the community which is host ago little bit, this little bit of Jabber script on a web page that is visited by your mom or by ?? by the more average Internet user. I don't think this room is the average Internet user. So we really want people to host a piece of Java script so we get more data, we get more representative data for what is the state of IPv6 deployment. So, it is really simple if you know a website like that, just ask me and I will give you details on how to do this but it's no work to a web master. So, questions, comments? This is my e?mail address, I will be around for the rest of the week, so with that, are there any questions here.
Geoff Houston: APNIC. , you know, it's sort of funny that we are I think both sort of come across this and a few other folk as well at about the same time. The thing that I do find extraordinarily surprising is the diversity of results. The first thing is we did have this theory about a year ago that most machines, when given the option of dual stack, naturally preferred 6. And what we are seeing is that that is decreasingly the case, that most machines at the end client point when given a choice, actually prefer 4, so if you just look at the v6 visitors on a dual stack you tend to under count. The next thing is when you flush them out by giving them a 6 only piece of web object, one by one P N G what I find incredibly surprising is the really small amount of Teredo. When I look at this, I actually categorised it by 6 to 4 native and Teredo, and what you expect is, a huge amount of home folk, if they have got windows vista 7 and behind a NAT, 6 to 4 won't work, but the Microsoft system, as far as I understand, is smart enough to understand it's a dud, so it will move on to Teredo and try it, but it doesn't. Or, in customers smart enough, including your moms, to turn it off, or it doesn't work. I don't know. But what I do know is that the Teredo level of all the 6 access is about 10 percent and unicast and 6 to 4 are both at 45 percentish. I find that really surprising, that sort of shouldn't happen.
The other thing to quickly note, the folk in Asia, or the folk who go to the APNIC website are higher by your numbers by about a percent. Weird. That are some regional things going on that highlight this. The bottom line though, we never thought 5 percent was going to be uncovered here, and this is a bit of a revelation, because 5 percent of a market of 1.7 billion users, if that is the real number, is an amazing market.
AUDIENCE SPEAKER: Bias.
Geoff Houston: That is what we are trying to understand.
EMILE ABEN: That is why we have to have this deployed on your new sites and stuff like that.
Geoff Houston: At APNIC we get to measure 7,000 unique visitors a day, it's not a lot. I don't know what the RIPE raw number is.
EMILE ABEN: 8,000.
Geoff Houston: So out of these 1.7 billion source addresses we don't see a huge amount, but what we see is lifting our eyebrows, we thought we would see a much lower figure. So I would encourage that to anyone who has access to larger sites, we have been doing huge amount of work in the Java script to make it invisible, so happy to share that code with RIPE. We are wondering through most of these browsers trying to understand how we can clean off all of the test from the status bar so the page just loads, it says it loaded, it's all done, and then the Java script quietly starts going boing, boing, boing, so it isn't user visible at all, so we are happy to share that as well. Thank you.
EMILE ABEN: Thank you.
CHAIR: Have we got any more questions? Comments? OK. Thanks very much Emile.
EMILE ABEN: Thank you.
(Applause)
CHAIR: Next up we have Erik giving us an update on the test traffic measurement network.
ERIK ROMIJN: Good morning. My name is Erik Romijn, I work for the NCC in information services and I am going to tell you about our measurement network.
A quick introduction: We do a set of active and passive measurements. We have test traffic measurements which measures one way delay and other metrics, trace routes regularly and that happens between about 90 boxes in a mesh, actively. We also use this cloud to use, to monitor route and TLD name servers, that is the DNSMON service. And we have the routing information service which is a passive service where we collect and store BGP updates from about 600 peers. They are all put in a database and we put tools on that.
So some of the highlights since RIPE 59:
We have been working very hard on the reimplementing DNSMON. I will show a very tiny bit of that and Franz will show you more later. We implemented a number of new features in Netsense which was launched at RIPE 59 and we did some experiments with one /8 and two /8, most of you will have seen the presentation from APNIC. So that resulted in a very good RIPE labs article.
So for node deployments, we have five new TTM boxes, this time. Most of them deployed in Asia with the help of APNIC. We are also working on a number of others in mostly remote, more remote countries and we have a number of partnerships in which we deploy these to use their local ?? to use local contacts of the RIRs to help us with deploying.
We are also working on replacing all the TTM boxes, a number of them have been running for eight years, I think, they still work, but we'd like to see them replace sod we are working on that as well.
For RIS, we replaced one of our R AC and we are planning further lifecycle replacements there. This RRC is also first of a new one we are deploying which is more aimed as being able to be self sufficient so it has remote consul built in, dual power supplies so that will increase the availability.
We have a new deployment here, this is the hotel roof, this is unfortunately a very short deployment, we are going to take it away Friday.
So if we look at the active TTM boxes in the past, we can see an incline, sharper incline at the end basically, which is where we started the RIR partnerships. It also at 89 boxes and still growing. If we look at the number of DNSMON subscribers we also see a slow but steady growth there. There is not as much room for growth there as DNSMON because we are ?? we restrict ourselves to route servers, TLD servers, ENUM and basically arpa, we don't do just people's own servers.
So that is now at 43.
So reimplementing DNSMON, we worked on the front end and back end parts, that's of the processing of data, so this is a lot more flexible, scaleable and we have worked a lot on usability improvements. There will be more work in there. We also did a a survey along with our users, got quite some nice responses out of there and used those in our work. Franz is going to give a lot more detail about that in the DNS Working Group at 11:00 so if you want to see more of that, I will only show one nice preview. This is the ?? this is part of the new interface where you can basically do random queries by just typing normal text and it will also complete and it will figure out what you are trying to do and show you nicely. But more from Franz in DNS Working Group.
So, we also worked on various new features in Netsense, we launched this in RIPE 59 in Lisbon. So, there is this little tab here on the right and if you click it we now have stability data in there. So we tracked the announcements and withdrawals so you can get a picture for how stable things are, when certain events happened. This is a beacon that switches on and off every two hours so you can see the regular withdrawals and announcements.
Then another thing we added is this little plus at the prefix list and basically, it gives you all sorts of extra data now. And you can see there stuff like do we have any remarks like this is Marshal, this is /25, you might not want this and we track visibility, consistency with RCC, overlaps with other prefixes, so, yes, we added all that data there.
Then the last thing we added is the DNS lameness, our DNS department has been measuring this for quite a while now and it is now integrate into Netsense so you get this nice list showing for each of your prefixes whether we see lameness. For prefixes allocated by other RIRs we usually don't have data so, this doesn't work for everything. And if you have like lameness it will show you and you can see exactly what the problems were while measuring this. This was the RIPE meeting prefix while it was being shipped. So that is why it was lame.
Our plans for the coming time are to finish and deploy the new DNSMON. That will happen soon. We are also looking at different TTM hardware to look at stuff that is easier to deploy and less costly so to look at smaller boxes or different types of timing. We currently need a GPS antenna on a roof and that is often difficult.
Also, a thing we are going to work on the is TTM back end improvements. This is following the DNSMON back end. There is a lot of work there, it's quite old. And we are going to look at that. And then the last thing is that we are going to look at overall service performance, probably the first will be Netsense and RIS we are going to work on making them faster.
So, that is from me. Do you have any questions?
CHAIR: Any questions for Erik? I have got one question, actually. If you go back to the graph you had showing the number of test traffic boxes that are out there. The typical up and to the right graph, that one; why was there such a drop between sort of 2004 and 2006?
ERIK ROMIJN: I don't know.
CHAIR: Any idea,?
ERIK ROMIJN: Where it starts going up again that is when Mark joined us.
Mark: RIPE NCC. I don't actually know the specifics behind this actual drop, but what I will say is that the network is a community?run thing by hosts who are very kind enough to host these boxes for us and sometimes those hosts lose interest and the boxes goes away.
CHAIR: Thank you very much. Anybody got any more questions? OK. Thank you, Erik.
(Applause)
CHAIR: Next up we have got Rubens Kuhl from nick dot B R so is going to tell you, Erik, what you are doing wrong.
RUBENS KUHL: Good morning everyone. Rubens Kuhl from N IC Brazil. N IC Brazil is arm of the Brazilian Internet steering committee, we currently have same rough number of employees as RIPE NCC, but as you see, we are not only a number resource registry, we also run the CCTLD registry for dot B R so we have like 1.2 million customers paying for domains. These funds our heris operation and also funds a lot of projects of social and one of them, which is highlighted in blue over there, it's measurement and that when I came in. We also run secondary services or host Anycast ccTLD servers, some route servers, we also run 12 Internet exchanges throughout Brazil, agrigate traffic on some of all those 12 exchanges of 26 gigabits. And we are also the proud owners of 6 TTM boxes, five of them are deployed, one is not. I will talk about them soon enough.
As we got some experience in running those five TTM boxes, we bump into some things that we really like and to be improved, like feature requests kind of thing. One of them is IPv4 MTU measurements. I know there is currently IPv6 MTU measurements because IPv6 is more prone to MTU issues due to tunneling and so forth, but sometimes when one fibre breaks the other one, the restoration path is actually a tunnel. Usually between two or the three?ring providers that we have there, but although I have only seen this happening in South America, two of these companies are European companies so they might have the same bad idea and do it as well, so it might be going to look at those.
We also had some events when power failures to the TTM boxes made them unusable for some days. Two times, the configuration simply vanished and we had to go other process of configuring AP addresses and so forth. We don't know if it's some kind of bug or operational issue, and one recent case, the server have gone into F SC K mode. I hope Mark can tell us when open for questions. We also notice, we also missed one of the old TTM boxes that Erik was telling about that they are going through lifecycle problems, but we was using the Anne ARBOR data, TT 23 data to create this map that I am projecting now, that we were trying to establish a quality index so, you know, hey today Internet is better, today Internet is not doing that well. We have now changed it from the Anne ARBOR box to reston box but most of the boxes on the United States are pretty old and they are pretty soon reach end of life on those machines. So, we are pretty concerned about that.
We also found that only and buying a TTM box is somewhat costly and Dutch €500 for the first box and 2,200 for the next box is a pretty high amount for developing countries, not only South America. We also found it was somewhat, sometimes difficult to do installation of the GPS enten in as, like Erik showed the one in the Prague hotel over there, and both factors prevent deployments running one another, so the reason why we have six boxes and only deployed five, one was because of we don't manage to have one outdoor antenna for the GPS and probably bought some more TTM boxes if they were not so costly. And we also looking at measurement of broadband services like the telecom regulator in the UK, like the telecom regulator in Portugal, but in the order of hundreds of measurement points so we thought, hey, like to look at some alternatives and we find two alternatives.
First of them is GPS from Garmin, which is 18 X L V C, which is a pretty cheap GPS unit. US full price is 70 dollars. Taxes may come ?? make that become twice as that in Brazil and from country to country. It has a very nice sensitivity, so we mostly deployed those indoors. The picture you are seeing is one of 100 boxes we are deploying to measure broadband, users' broadband so how else is their user broadband going. But it has one limitation which the five metre cable length and antenna is not full weather?proof. It's not that bad but it's not full weather?proof.
So we keep looking, we kept looking. We would like to have greater cable length between the computer and the GPS, and we would like to have a more than ?? sorry, less than optimal satellite coverage because sometimes you have this windows that have look for, that have line of sight for some satellites along one period of the day but not 24 hours a day. So we went, if you went good timing for centuries people looked at for the Swiss, so we found Swiss GPS receiver model from U BL O X that only needs one satellite after the first fix, so if it's not moving, if you are not on Mach 3 cruise missile, you only need to get the first fix and then you only have, you only need one satellite to keep precision, one post per second, one microsecond thereafter. So we built some GPS units of our own and to our surprise and the unit prices was only twice of that as the Garmin unit and we only made 50 of those, so it came out pretty cheap. They also have very high sensitivity and when European deploys the Galileo constellation you also have the option of looking at those as well, not only depending on the United States, GPS networks.
So, having high sensitivity and one satellite timing, we could deploy all these indoors without very little concern at where it's deployed. It must be somewhat near window, not, you have, you need some capability to the satellite, but in all those measurement points, we are now getting 100 percent GPS coverage, which was more than we expected, we expected half of the times we couldn't make it but the GPS solution had to be pretty good.
This is a block diagram. It's in Portuguese but I don't expect you to know Portuguese. I took this picture, it was an original design. It has one block on the left that is the GPS receiver and which is that is in weather?proof casing and it can be directly connected to computer, it has RS 222 interface and RS 485 interface so it can, you can have the computer further than the antenna. We tested the solution to 50 metres but we think it will go longer than that. There was some design considerations that we made that is not ?? we know that the RIPE NCC team, when they did GPS receiver they decided to put everything on the PC I boards, so it could be housed inside the computer and we decided to move external, so have external AC adapters, external converters and we also did have that much electrical as RIPE NCC receiver but that could be added as, as an external we could add if you want.
I am proud to give two of the GPS units of RIPE NCC representatives so they can play with them, as well. Thank you, I would like to open for questions?
(Applause)
CHAIR: Thank you very much Rubens. I see we have some people heading for the mikes straightaway. I would like to give the NCC a chance to.
AUDIENCE SPEAKER: Research group. You mentioned you would like TTM to be able to do IPv4 so the Scamper, the tool talked about on Tuesday, it can got a traceroute mode and can report at each hop if anyone is interested in that getting integrated into TTM would be very happy to help. Thanks.
CHAIR: Thank you.
AUDIENCE SPEAKER: George Michaelson, APNIC. I think this is a very interesting initiative. I spoke with a member of the Australian Government research body that has responsible for time keeping, including their contribution to UTC, and the Paris protocol of exchanging long time information. He also said that he was quite comfortable that single satellite visibility GPS was viable for long?term time?line if you were stable and I believe the system that RIPE deploy at the moment is quite comfortable doing that. It doesn't depend on multiple satelite use 1 positions. We had some discussions about 5, 67 with other people and they all said single satellite for stationary object is fine. So getting a unit saying this unit is acceptable in that behaviour is is a good thing. Some sense locations are reluctant to have, I echo that, the high quality cable deployed through their infrastructure, he encountered several partners in Asia to say we are not comfortable. Do you do this a different way, do we please interrogate with an existing URL, they wanted spliters and their existing GPS investment to provide the signal to multiple sources so I see some similarities in experience with things that you have been seeing.
RUBENS KUHL: Yes, yes. I forgot to mention when we deployed those measurement points, three computers in one house, one for each broadband provider, we only used one GPS, so we took advantage of the configuration from time to time. Thank you.
Daniel: One of the designers of the, now I think ten?year?old ??
AUDIENCE SPEAKER: 199 ??
DANIEL: Was it 1997? It's 13 years old, with a couple of revisions, architecture. I wanted to observing owe, get a few misunderstandings out of the way. I think it is a great thing. Need to get cheaper and need to use basically GPS receivers that have a bit more sensitivity than we are currently doing but what is not true is that exactly that you have to be outside with the NCC, current NCC solution, it works very nicely near a window, and actually it has for 13 years. So that is a misunderstanding. And the second one about the one satellite is also true for the receivers we are using so as soon as you had a fix it does the one satellite time keeping and it actually gives you quality indicator that is quite useful. I am not saying that this cannot be improved, I think the antennas are expensive because they are made from rink purposes so they are really weather proof and all that kind you have stuff but they can be used behind a window and they do the one satellite thing. And the ?? I didn't quite understand the special cabling thing that George brought up because that solution and as I see from the Portuguese diagram, both of these are designed to run on cat 5. And what we also see, what we use ourselves is basically if you have 3 or 4 of these things in a computer room and I think Sam was the first one I know did that 10 or 12 years ago is user re?radiator, put one antenna on top of the building, you reason an HF cable and rebroadcast the signal in the computer room and that also works quite well. But, again, you are using more modern GPS chips that have sensitivity so that you can go further away from the window, is a good thing.
CHAIR: Mark, would you like to respond quickly.
Mark, RIPE NCC again. I am operational responsible for this network so I would like to thank you for your presentation and your interest and your support to the by hosting the boxes you do. Some of the comments you have made are very interesting as other people have observed. We can certainly I think take that on board. Just a few specific comments to respond to some of the things you have said. We are aware that the software could be improved. We are about to embark on a fairly large scale exercise to revisit that, to look at some of the improvements and changes we can make. We have heard these requests for different boxes that have different GPS needs or even boxes without GPS or different ways of doing it. We within the NCC, within the science group have already done some research into different sorts of hardware, different sorts of measurement hardware, and within my group we have been observing what has been going on in Brazil with quite some keen interest and as we begin to look at this more closely in the rest of this year I think we would like to engage in dialogue with you about how we can do that. Thank you very much for your kind gifts which will help us with that.
One of the other comments I wanted to make is about the, some of the older boxes which I think is quite a concern to you. As you understand, we as the NCC don't specifically manage, own or run the vast majority of these boxes and as I mentioned earlier, unfortunately, from time to time, people that are kind enough to host these for us do disappear, fall off the net, loose interest, go away, retire, who knows what they do, they do go away. Where we can, we do engage in dialogue with these people to try and maintain the boxes but unfortunately some of them will disappear. What we do actively do is try and encourage fresh deployments so we are trying to keep the network fresh and alive in that way. We have not put a great focus on North America to date but I think it's quite clear that we should probably do that. Is that everything? I think that is all I have got to say unless you have any questions.
CHAIR: OK. Thank you both, thank you.
(Applause)
Next up we have George Michaelson from APNIC.
GEORGE MICHAELSON: Hi everyone. The talk that Emile gave about the measurements for v6, he alluded to the different nature of IPv6 addressing plans and highlighted the structured config plan in there and this talk is about a little bit of measurement I have been doing in that. It's a presentation that was given earlier in the year at the APNIC meeting in Kuala Lumpar. The Stateless order config is doing a rememberivation for the bottom half of your address. This is the old 48 bit Mcspace that we all new and loved long ago, and it's not really structured in the same sense that our address management; it's just the uniqueness label. Vendors come and get these in blocks and if they are selling a lot of product and come back for another block they don't get configurious, just another unique prefix instance. If you look through this catalogue you see Del or HP or Apple have a large number of these things scattered through a number space. They are known as if you played with DECNET you would have been quite familiar with these. I believe that was the last protocol that attempted to use beyond?the?wire Mac address as part of it's protocol addressing, a very strange decision that caused nightmare at times.
So there is RFC sense that you use these as part of the construction of your IPv6 address in one of the addressing models. It's really very simple: You take that part of your Mac address, you split it into two chunks, you put some magic text in the middle, FFFE, you do a one bit inversion, you have now got a low order 64 bits of your address when you get given your upper prefix you will notice this is coming off good old FFFE space, you get a unique identifier. Well that is a reversible process. If you see an address spring that has FFFE in it, unset that bit, rederive the full EUI 64 value, look it up in the registry and count them. So I thought I would see what happened when did I this and did I a 24 collection of the queries on our servers against IPv6 and I looked at the data. So this is what I am calling the vendor beauty pageant. It isn't particularly meaningful but it's just an interesting observation of some of the information that is out there in the address space. The thing that you have to bear in mind that are actually two sub states that can be measured here, the source address of the packets that are seen on the wire, the reserver, who is making the query. We see a large amount of people in infrastructure using IPv6 as their transport so they are asking about IPv4, they are a reserver with IPv6 address, I don't believe anyone consciously said I am going to run v6. But one day, it just happens to find that it's got an NS that it's going to on v6 and it works. And at that point, that is remembered as a valid transport in the system and it uses v6 to go at and fetch DNS so without any conscious decision, people are now using v6 as their transport to fetch DNS and we are seeing that
The other thing is the target of the PTR is a AAAA address request, who is the holder of this when someone sees a year to their website or SSH port or e?mail. I might add almost all reverse address lookup appears to be coming from mail systems, probably the last major deployed system that does a live query of reverse for almost every transaction. Most other uses are delayed. SSH can often do it but I think as people are disabling that feature because it's very low information but it looks like mail is actually driving a large A the reverse DNS traffic that we see. Anyway that is an aside.
So, if we go to the first case of the source addresses, this is a graph of the top list of vendors that are being seen on the wire, and there really are no advises here. Intel is a huge spike but they domain board and on equipment selling direct to a lot of grey box manufacturers, people that don't want to pay for their own identity and ASIC design, if do you that and get a chip set includes an ethernet you could Intel's OUI. The manufacturers like via, inside Del have actually gone out and said no we are sourcing direct and want the product damaged against our equipment so these guys have said we are going to use our own registry. Apple appeared in this which I thought was quite interesting, I didn't expect to see quite so many apples IPs high in the list that do DNS queer he is Reese. So you go down the list and start to see the things that are more expected infrastructure embedded systems like soup micro, IBM, Sun, Zen, you know, classic vendors so this is quite an interesting distribution.
Cisco, I actually saw less than I thought. I had expected to see quite a lot because I had assumed all of the home boxes that are doing NAT and other activities and have to do redo DNS on your behalf would have shown up on this and it looks like the nature of the back end purchasing that Linx and other use don't expose a single consistent OUI, I had expected to be able to measure that class of equipment. It turns out Cisco have done quite a lot of Internet business. That is a lot of people. The Zen and VM, where I am making an assumption that is probably looking at things like blade chassis.
If we go the other one what are people asking about this. Beauty contest is really about a super model and there is only one currently on the stage. It's a very stark situation that the client base out there is essentially using apple so if we did the small amount of finger showing how many in this room are using an apple product. Ms. Heidi Klume you are on the strange. So vendor choices are actually visible in this behaviour. I would like Mr. Jobs to give me a job. No, I probably don't. So, it is Apple, but it might not actually be the case. This might just be people are doing strange tricks and I am not actually measuring what I think I am. But I kind of suspect it is what I am measuring. They have about 47 entries in the I IEEE registry and it looks like Apple have a really strong sense of ownership of the chip certificate, the story I have been told is the first generation of a product they go to small smart companies, a good example of this is I am told the I pod has an ASIC which does some PM 3 work, really smart company in Scotland. Second generation they took the APR of that design went into Asia and said make this ten times cheaper and you will get our business and they did. So the second gem went an original source from Scotland, the IPR was redeployed into the marketplace and I think Apple's approach is if we make anything it's our technology so I think the expression of the OUI is not they are not buying commodity equipment, they are very careful to make, they make sure they have ownership of the ?? I really do think I am seeing Apple out there and I think the applied stuff is accounting for this, the use of small devices which do DNS.
So if I do this again and do I the log scale it brings up the other players, and you will notice the distribution has subtly shifted some of the parties that are showing up high in the circuit here, Intel is obviously still high, Del is still high, HP is still high but some of the relativities have shifted there in terms of what people are asking about. Sun for instance, has gone right the way down, it was about 5, 10 positions further up in popularity, and I suspect that is because they no longer actually have much end user applicability whereas if you look at all the other things they tend to be quite likely to wind up being on people's desks. I also drilled down into 6 to 4 to just see if there was anything happening there and yet again, it's a similar situation; although this time there does appear to be marketedly more non?Apple content which I found quite interesting. So, it isn't really that informative it, it's a beauty pageant and the real name of the game is not about where you are getting stuff from, it's about how simple it is and how well integrated it is and how clean. I think we could agree Apple have done a good job of making v6 something that people can deploy and that probably accounts for high visibility.
I would like to understand this a bit better, the total amount of vendor codes was far larger and I am thinking it's something easy to track, but obviously when has to accept the reality that not everyone wants to reveal this class of information, and what I have been told is that in Windows 7, the default setting is privacy address. Now I don't believe anyone else has has default adopted this behaviour. To the extent nobody else does do privacy addressing, that is not so bad, because it means we can track Windows 7 IPv6 deployment if we can detect the privacy address in this use of the system so probably this is going to become one of the other signatures that is used by people to try and classify what class of traffic they are seeing. It's not the end of the world but I have to accept there is an end of life in this class of activity. That is it.
(Applause)
CHAIR: OK. Daniel.
Daniel: Daniel again. A couple of things you might want to consider, and you have it right there. There is of course a bias here, you have to use the FFFE thing. The other thing that occurred to me is that the Intel thing is probably of estimated or at least contains some vitalization solutions because a number of virtualisation solutions, if you look at parallels they just emulate.
GEORGE MICHAELSON: Right and they have to do a good enough job which means stealing the Intel OUI, I hadn't thought of that.
Daniel: You might want to think of. If you are really getting into this, is probably look for some resources out there that give you a bit more insight into the EEE blocks, not just the manufacturer but what kind of product it is.
GEORGE MICHAELSON: I made some gentle inquiries of people saying I would love to understand what registry you use internally for substructure management of this space and they wrote back saying I know you are tired of getting that, it's a are the security statement and we won't tell you answer, if you think this through George telling you which exactly of our product line lies in the Mac address is inviting people to know what devices are worth attacking so they didn't want to tell me.
DANIEL: No, no, maybe that is not the source.
GEORGE MICHAELSON: You think wire shark might have better database.
DANIEL: There is something out there, maybe it's not complete. You can do some research yourself.
GEORGE MICHAELSON: I did do some ?? I did some of that in asking informally, the way I found out that Apple didn't have a structured model is I mailed my comrades that I thought had Apple devices and said can you tell me your Mac address and they were just ?? through the space. It's actually crowd sourcing it, that is really beautiful actually. I think there is something in there.
DANIEL: This is some interesting information but I think it's going to go away because of what is on your slide there and it should actually.
GEORGE MICHAELSON: It should indeed. I think it's not something that should necessarily be made public.
CHAIR: Any further questions or comments? OK. Thank you very much, George.
(Applause)
We have got the last scheduled presentation now who is going to talk about the DNS visualisation tool that he has developed.
Casey: All right. Thank you. I am going to talk about DNS visualisation specifically with regard to DNSSEC both for understanding it and DNSSEC deployment as well as troubleshooting, things that may come across from both the deployment perspective as well as the resolver perspective, validation. I am going to motivate this talk talking about a few examples, then talk about the tool itself business called DNSViz and talk about some ideas for going forward.
So first of all, just a brief review of a DNS query and standard DNS, what we are typically used to looking at is a response that looks something like this, and mostly what we are interested in as a user or a client is what is shown in green here. The alias and then of course in this case the address for the alias.
When we add in DNSSEC, we get some extra information that we have to sort through at least as humans, tools are helpful in this respect. One other thing we might look at is the authenticated data bit is set here but again for the most part as clients we don't really do much with the signatures themselves. That is usually done by the validating server.
So, this is fine, but what happens if, when something goes wrong, we have some type of a failure? Well, at the stub resolver end, we get the surf fail message which tells us a lot about what went wrong. It could have been something with a signature somewhere along the line, some other type of dependency such as an alias that didn't validate properly. Now, if we are accustomed to manual troubleshooting such as in standard DNS, we might pull out our dig tool and with a few well directed queries, sort through some of this information, I have highlighted some of it that might be useful, and we might, pardon the pun, dig down and determine that the problem in this case is that either DNSKEYs 26508 is missing or that it's simply not being used to sign this particular DNSKEY RR set, in either case we have kind of narrowed it down and we think we know the problem. The problem is, it's a little bit confusing, messy and error prone.
So, in addition to that, we can't really tell if the signatures are correct, if the problem lies there, identifying the key tags is not natively available in dig although it is in drill. And one other thing to consider in this is the idea of DNSKEY roles, and that is simply put that there are certain flags in the DNSKEY resource record specifically the SEP bit and revoked bit for establishing certain roles. However, the roles of the actual keys don't necessarily correlate with the attributes that are set on the keys, and so there needs to be a little bit of work done to describe what is actually being done and I will explain that a little bit with regard to DNS visualisation.
So, there are some more automated methods than what I have shown here, specifically some extensions to DIG using the SIG chase and one other thing you can do with drill, among others, is using ?S which traces a name. Both of these trace a name to a trusted key so you can get some kind of an analysis. These are two examples. There are more methods out there. However, these are mostly textual and it's difficult at a glance to kind of get an idea of what is going wrong. These are very powerful tools, don't get me wrong. I just felt it was necessary to do some kind of a visual approach. So, without further ado, DNSSEC visualisation, and now the website for this is DNSViz.net where I have put up this. I still consider it a work in progress but I would like to show a little bit about this. So a little bit of background first of all:
The, just up here at the top, this shows, let's see ?? for visualisation, I basically am creating a graph of nodes connected by directed edges. The nodes themselves represent either DNSKEYs or DS records or domain names. And the DNSKEYs, the attributes are set by making the nodes either shaded or with a darker border, etc., as shown here. The arrows between the edges, so for example, here, those represent either signatures or hashes and there are really three choices: It's either valid, bogus or expired. And then finally, here in terms of delegations, I am grouping the DNSKEYs into a cluster which I will show in just a moment and also classifying the delegations, whether it's secure, bogus, incur or misconfigured.
But really, the bottom line here is, can you trace, regardless of whether a signature is good or bad, somewhere in the line can you make ?? can you trace from a trusted anchor down to a name? And all the nodes in that path are going to be outlined using one of these three colours, which marks it either as secure, bogus or insecure.
So if we revisit our previous example of medicare.gov, you may not be able to read all of this, but the point it's anchored up here at the ISC DLV and if you follow this down ?? sorry that is DNS SEC look aside validation, you can see that there is actually DS record that does not correspond to a DNSKEY down here in medicare.gov and that makes these three orphaned, so even though the signatures are correct these three are now bogus which is why we were getting the error. Now, within the tool itself, on?line, there are actually some options that can be configured. You probably can't read this so I will tell what you this is here: These are resolvers options, essentially that, show supported algorithms, so if we were to select only the first two algorithms, for example, and exclude algorithm 7, 8 and 10 here, then now, we have no link to the parent, which is using algorithm 7, and so everything turns insecure as opposed to bogus, which it was before. Just one example of how this can be configureable. Here is another example. If we wanted to change the scenario again, we might undo the Trust Anchor at the ISC DLV using this right here and put in our own Trust Anchor, you can put in arbitrary Trust Anchors here by pasting the trusting keys in bind format, and then we see that these are now trusted because we are anchoring right here.
So I would like to go through a few examples here in some of the remaining time. Here is an example of a ccTLD that has just a single key that represents both ZSK, KSK and also provides a SEP. Here is an example of a zone that has both a ZSK and a KSK. However, both of those are registered as SEPs with the link to their parent, in this case the ISC DLV. Here is an example, this is something interesting that I tried to find a way to visualise when several servers have different versions of signatures, and in this case, one of the signatures was bad and one of them was good, so if you hit one serve you would be getting a good signature and if you hit the other one you would be getting a bad signature.
AUDIENCE SPEAKER: Oh, God.
SPEAKER: Here is another example, both the signatures are bad in this case, it didn't matter which serveR you got. Here is an example of a revoked KSK using RFC 5011 and the key here is that it's both the revoked bit is set shown by the thick boarder and also self signed which is important. I will show you later. Here is the same zone but when the signature has expired you can see everything below here is now red, and therefore bogus. By the way I didn't mention, we are all still here even though the last route server was signed and this is an example here of the route zone, the deliberately unvalidatable root zone so you will see that in awful the pictures until that goes away. Here is an example of, again, some expired signatures down here but more importantly some extraneous DNS records that don't correspond to ?? so these are non?existent DNSKEYs down here. Note this does not affect validation, these two keys themselves, but maybe something noteworthy for administrators.
Here are some expired signatures in an island of security, so there are no ?? there is no link to the parent so these are just deemed insecure. Here is an interesting example: Where this was a bad KSK roll?over so you can see this particular key which is no longer a signing key, corresponds to these DLV records. Now, note that when a ?? when the revoked key is set for a key that was previously active, the key tag actually changes and so DNSViz does some work to still match these correctly so that an administrator can better troubleshoot. Now also note here that there is no self signing here on this particular key that has been revoked so it's not truly revoked. I believe this has been fixed in this particular implementation but just an example of something that can be visualised. One more example here where the keys are just missing, for some reason, and here is a more complex example where you can see where aliases come into play. This zone over here is ?? has no problems and in fact it's not even linked to its parent but because it aliases another name which does have problems it becomes unresolvable.
Just a couple of other things to note here that are looked at. Service status. I already talked about consistency of signatures in DNSKEYs, it also looks at path MTU. This is in the server tab on the actual page itself. And a look at NSEC 3 awareness. There have been some interesting situations where an NSEC signed zone not all the servers are NSEC compatable.
So just a little bit on future work, look to better server depend an sees, maintain history of a zone for an administrator. English is my native language. I don't know if we have time for questions or not.
CHAIR: We have got time for some questions.
Richard: Richard Barns BBN. I was just wondering as your server is going off and doing all these queries looking for DNSSEC information are you collecting any statistics on where you are seeing DNSSEC and where you are not?
SPEAKER: In terms of where I am seeing it, yes. However, because I am not a registry or anything like that, I don't have comprehensive data, and where I got my initial seed data was from the open directory project, they have a list of URLs that are indexed so I extracted the host names from there to starts and did some dependency crawling from there but it's by far incomplete.
Richard: I am thinking in the sense of crowd sourcing just by virtue of the fact that you have the service that people are using you could do some opportunistic data collection.
SPEAKER: I have gotten some. This has only been up for a month and there is some user?submitted data, actually most of the customers users that have submitted data so far have been looking at unsigned zones. This was posted recently on Comcast's DNSSEC site and so I have a feeling that a lot of their customers or something were looking at it and typing in their zones but really don't have any DNSSEC information and so it's filled with a lot of unsigned zones at the moment. But yes, it's a good point.
AUDIENCE SPEAKER: Stefan, AFNIC. That is a great tool, I recommend it and it's very good with zone of RIPE because you have a good, long chain of keys but now that the route is fully signed I try to use it with the root and I was not able to figure out the syntax to do it, if I type a dot it is confused.
SPEAKER: Yes, I don't include just the root, so because everything includes the root anyway, I didn't feel it was necessary, but part of it, actually the only reason I didn't do that is because I don't have a clean URL for it, so I didn't want to put dot in there because that makes the URL ?? I guess maybe I could put root or something as the URL since there is no longer a dot root as was pointed out on a DNS operations list. I don't know would root be something that would be useable if somebody wanted to type that in.
AUDIENCE SPEAKER: Ask ICANN,.
SPEAKER: OK thank you for the comment.
DANIEL: I realise this is a work in progress but I am wondering whether you have any plans sort of once it ?? once it becomes sort of stable to package this up so people could run it on other websites?
SPEAKER: That is a great question. And in fact, I was talking with some other folks about this fairly recently. There does need to be some work done to make that ?? to make that possible, right now it's kind of a by?product of some other research I was doing and so it wasn't initially intended to do that; however, I think that would be a desirable and viable option in the future.
DANIEL: So if someone offered help with packaging, that would be useful?
SPEAKER: Yes, I think the ?? a more difficult problem at this time is getting the approval to licence it, which isn't impossible, by the way, it's a little bit of a lengthy process.
DANIEL: OK. Thank you.
SPEAKER: But if do you have interest, I welcome any e?mail feedback to me as well, either for future suggestions, bugs or collaboration interest.
CHAIR: OK. Thank you very much. I think we are a little bit over time. I don't think we have got time for your demo.
(Applause)
That leaves us just with any other business. Does anybody have anything that they wanted to bring to the Working Group's attention? No. I think then it only ?? the only thing to do is again thank our speakers for their contributions. I would also, I would like to pay tribute to them, I think this is an example of what we are trying to do with the new charter in the Working Group. We have got evidence of all the aspects that we have got in the charter, we have also some cross?over with the stuff that Emile has done and Casey has talked about with other Working Groups, and I think it's been an excellent session and an example of where we want to go in the future. Thank you very much. See you in Rome.
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE