CRISP BOF Ted Hardie, Chair 53rd IETF, March 18, 2002 Minutes taken by Lisa Dusseault (lisa@xythos.com) Edited by Ted Hardie (Ted.Hardie@nominum.com) Summary: The BoF session discussed the audience and requirements for a cross-registry information service protocol.. The consensus of the room was that the overlap in requirements among the identified audiences was not clear enough to warrant the scope proposed by the BoF organizers. As a first step towards clarifying the requirements, it was agreed that a set of use cases would be supplied to the mailing list; a requirements list or document prepared from the use cases would then be the basis for further discussion. BoF presentations and discussion: Why registries need a new solution Presentation by Stig Venaas of Uninett Why are Norwegian registries interested in alternatives to WHOIS? * The main problem is no authentication. The registry should be able to provide almost no information to anonymous users, and by contrast provide full information to registrars. * Another problem is the need to limit query responses according to the IP address requesting, or even better, by authenticated ID. * Need a standardized query language to allow the same tools to query multiple registries * Need a standardized structured output to allow the same tools to parse responses from multiple registries Storage of registry information is in a SQL database, but LDAP access to that database would involve slow responses because of the different structures required. Currently the Norwegian registries are using LDAP, but that involves replicating data from the SQL server to LDAP in order to get fast queries. EU Privacy rules Issue about European protection and privacy issues and how they related to this. Answer: registries have to use different rules, depending on whether the records are describing individuals or organizations. The rules in Sweden, according to Patrik Falstrom, is that the registry may not publish information about private persons (name, telephone number, postal address). This is interesting information, in so far as it produces requirements for the system. The requirement for the system is that the registry records must be taggable with policy such as this. Decisions may be related to the entry type. Performance of LDAP compared to WHOIS Using an oracle database and constrained query sets, Network Solutions tests have shown that LDAP can sustain the same query rates as WHOIS. Whois-like information is getting more and more fragmented. This is another opportunity to try and fix it. Unified Front-end problems Demonstration of Geektools retrieval of whois information by Ted. A unified front end has been built but it is difficult to do anything useful with the unstructured data from various back-ends. The kind of tagging on the data from the Australian registry is much more extensive than that available from the American registry. Processing is difficult. Anything that would be logical to prevent data mining by spammers also prevents legitimate use. Servers should be able to reference each other, perhaps in chains, so that front ends don't have to do so much work RIR Input Regarding WHOIS deficiencies Presentation by Cathy Murphy, on behalf of ARIN (not the RIRs) * Need a one-stop lookup service This would only be needed to handle IP address space and AS (Aut-num) queries. Data mirroring is a possibility. Perhaps a set of limited- function servers could know what RIR to query? Then the appropriate RIR could actually respond to the query. ARIN membership specifically requested the RWhois model. * Data accuracy concerns * Misuse of contact information: Currently all information is public, and sources of that information must know that. We're thinking of doing a private service in the future. Currently ARIN does make data available in bulk, subject to an acceptable use policy. * Increased server load: Better software and hardware and architectures are needed to handle 2-6 x load increases in past year. What are we not doing: Ted Hardie Note that the word WHOIS is not in the name of the BOF. It is specifically not supposed to be backward compatible with WHOIS. Requirements Draft Requirements have already been discussed at several venues so could be pretty mature. Users and Scope Some different communities of users have been identified, but the scope of the problem has been narrowed to those that administer the Internet: * Address registry operators: RIR, NIR, LIR. * Domain registry operators * Law enforcement and intellectual property enforcers This is about accessing data, not provisioning. The focus is on interaction between registry and end-user. Requirements Standard requirements apply: standard, extensible, decentralized, use existing solutions. More particular requirements: * Access control: level of access, techniques to prevent anonymous data miners * DNS referencing: use DNS to locate appropriate servers. E.g. using SRV records. * Must be able to lookup specific information given a key. * Must be able to search * Standard formats must be produced. Address, domain and routing registries share most of these requirements. In addition, routing registries require mirroring. In addition, domain registries need escrow support. Discussion on identification of users: Are these the right users to select? Do they really share the same needs? In some address applications, multiple registries might be involved in producing a single answer. That creates some difficulties. Cathy noted that any distributed system has that. In RWhois, referral provides the way to get additional information. Rick pointed out that this same discussion has happened before in the IETF. Are the users really ready for it, this time? Will they stand up and help work with us to do this? We can write this stuff and agree to it within the IETF. Let's hear that Verisign wants this. They're not here? That's a problem. Ted notes that it's not just the United States registries that are concerned. We have here a broad population of people who are somewhat content to keep doing the same thing they're doing. To attract those people, we need to have a concrete proposal, with a concrete set of advantages, to present to them. We don't have that yet. But does it mean we give up now? Should we eliminate some of the user communities we've already identified? E.g. forget about the routing registries for now, and perhaps expand later? Dave Crocker suggested we need several concrete usage scenarios to drive design. Questioning the Need Is there a really serious user requirement that isn't being satisfied? Well, the registrars have a real need for a standard representation because of how transfers occur. Now they do compete against each other, and it's difficult at times to get to provide resources. There are certain user communities that need certain parts of what's currently provided by WHOIS. What they do does not work very well. For example, the incident report CERT equivalent folks. They need to track down in near real-time, who claims responsibility for a net block or domain. Right now, its very difficult or time-consuming for them to track this information through the layers where it is now: NIR to RIR to LIR. Alexander French, speaking as an operator, says yes we want solutions to the requirements outlined. However, we're not the ones who need to implement solutions. Goals: Is this meant to supplement WHOIS, replace WHOIS, or be redundant with WHOIS? IF the aim is to replace, then uptake will be slow. CRISP is not to change the interior workings of registries business, nor how they store their information. Without changing either of these, it should be possible to provide query capability and structure for responses. Scope and Complexity Is this too much work to try to solve? Crocker seemed to think so. Jaap Akkerhuis repeated that specificity and narrow scope is good, that there are even other kinds of registries, not covered here. Response was general agreement that of course we're not considering user groups not considered here. Rick suggested that when a service has been abused, and you're trying to find all the entities that must be contacted about that abuse, this work would really make that task easier. Specifically on Routing registries If RPSL solves this problem, we should use it. One of the problems we see today is that data is separated, and you can't get good authentication unless you combine the data in the same store. Since the routing registration data necessary falls out of the address data, it's not as crazy as it sounds. Proposal Overview Leslie Daigle Two proposals have been put forward: ldap-whois and iris. Neither of these was written by Leslie, but this is just intended to be an overview. Both proposals stay focused on the intended audience (IRRs, RIRs, domain registries, network operators). Clients can be written to any server software; the bigger issue is the care and feeding of servers. LDAP-WHOIS This proposal leverages LDAP for the query response model, and has a data model that spans all the applications identified in the requirements. See the draft for details. Performance of LDAP in this space? Issues were raised about whether LDAP was sufficiently extensible to match this space well. Reassurances were given from some people who have actually tried, that it does. IRIS This proposal uses XML schema based query and responses. The data model is inferred. HTTP has been proposed for a transport. Currently IRIS is for individual servers. No way to get references to other authorities. See the draft for details. IRIS vs. LDAP Global Service Either IRIS or LDAP-WHOIS could be a front-end to existing registry databases, instead of completely replacing them. Missing pieces Neither proposal addresses cross-registry searches. Cannot aggregate: If you are thinking of a service that will take others' whois information and store it in a 3rd party location, that is doomed to fail for numerous reasons. Some entities are prevented from allowing their information to be aggregated in this manner. Problems solved by FreeBSD client: To a certain extent, the FreeBSD project has solved a lot of these problems with a smart WHOIS client. It parses the user's request and attempts to look up, through a DNS query with the TLD, who is the appropriate WHOIS server to ask. It's not perfect, and later versions are better than earlier versions. Some of the work that you're suggesting has therefore already been done. However, no work has been done to parse the response or do anything with it. Note that the output they get is limited. You're left with a situation where a human can parse the information that is returned and do something with it. Also note that the client implementation community is always chasing an increasing number of servers with different formats etc. This is at least a point to start from. Privacy again: Opposition to queries that go to all the registries that are out there, collating information about an individual. It may be inevitable but must be opposed. However, are there some kinds of things we should be able to search across all registries? E.g. the existence of a particular domain name across all TLDs? So what is the requirement for a protocol? Is there a new technical requirement in addition to the requirements we've already presented for authentication and policy? Apparently not. Data accuracy: George Michaelson suggested that data accuracy must be out of scope. Of course data must be as accurate as possible, but that's a matter of human process, not something that can be standardized. Of course we can't guarantee quality of data. However, we can Different schemas There are commonalities among the information presented, but they are not the same. Different people present different information. If we chose RPSL as a schema language, or some other, and the schema elements for an RIR are different from those for a different registry, but they use the same protocol, is that a problem? There may also be a common way to do referrals Some records will always be so advanced that they are unparsable. User groups are or are not interested in standardization Somebody stated that many of the supposed end users of this solution don't want a standard solution. RIPE NCC doesn't want this. We are convinced we have a system that works. It took a while to develop and make work. It has been extensively tuned. You mentioned incident response teams? We rolled out a system to support European incident response teams. If you are going to throw out everything we have for a utopic system that is going to cause more trouble than it is going to remove Another (12) RIPE NCC member(s) said that they would love to see this. There's been a big effort to remove DNS information from the RIPE database, and that's a fine thing. However it doesn't mean that we can't access that information with the same mechanisms. A draft that we could hit people with and ask them to implement it now, please. You would then see registries, registrars and RIRs coming around. Existing solutions RIPE 81 is an existing solution. When we did RPSL we looked around to see what was out there. We started from something without that. If we are going to change that standard, let's do it for a good reason, not just XML. The requirements that I'm hearing have more to do with domain registries. Is there a requirement that the two registries have to be the same? What ties domain name registries with routing registries? Answers: Perhaps it's that they share the same end users, that the same customers go to each of these registries looking for information. There was some discussion about specific scenarios where the end user would actually want to pull information from various different registries and collate it. Work Plan Ted Hardie [NOTE: See charter for specific work plan proposal] RIPE will not have an implementation of the proposal by Feb 2003 (the suggested Proposed Standard date) Rick noted that the iris draft looks easily as complex as implementing a LDAP server. A requirements document can either be agreed upon quickly, or never. The difference between the two is whether you can get agreement on what it is you're intending to do. The presentation earlier is helpful in that regard though still hand-waving. Resources are there for writing the necessary documents as evidenced by the two proposals and requirements draft are already written. The question is rather whether there is agreement what this is about. Statement: Usage scenarios will be written, that will feed into the requirements document. Agreement that this is useful? Significant hum for yes, none for no.