1 / 12

ENUM validation architecture & friends

This document discusses the motivation and goals of ENUM validation, as well as the roles, processes, and trust assumptions involved. It also outlines the validation requirements and distinguishes between initial and recurring validation processes. The document provides a framework for the transport and format of validation data, including an example of an EPP-based validation framework and a validation token.

graciew
Download Presentation

ENUM validation architecture & friends

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ENUM validation architecture & friends Bernie Höneisen SWITCH / 1.4.e164.arpa hoeneisen@switch.ch Alex Mayrhofer enum.at / 3.4.e164.arpa alexander.mayrhofer@enum.at draft-mayrhofer-enum-validation-arch-00 draft-hoeneisen-enum-validation-epp-01 draft-lendl-enum-validation-token-00 IETF63 - enum WG

  2. Motivation & Goals Motivation: • Solving validation is crucial for ENUM deployment • Major reason why trials precede production • Validation is the major difference between ENUM and "ordinary" domain registration • Validation definition and requirements currently vague • Common view considered useful Major Goals: • Common understanding • Terminology, Processes, Roles, … • Keeping entropy low • Minimize number of solutions addressing same problem • Prevent reinventing the wheel – foster deployment instead IETF63 - enum WG

  3. validation draft orientation map Role model Process & trust assumptions validation data transport validation data format Requirements draft-mayrhofer-enum-validation-arch draft-hoeneisen-enum- validation-epp EPP draft-lendl-enum-validation-token SOAP? XML E.115 IRIS? alternative formats? Other? IETF63 - enum WG

  4. Disclaimer • It is out of scope of these documents how an actual validation is performed ("validation method") • The documents just attempt to provide a generic framework to base validation processes and communication on. IETF63 - enum WG

  5. draft-mayrhofer-enum-validation-arch-00 ENUM Provisioning Model & Roles Legend VE: Validation Entity NAE: Number Assignment Entity ENUM Registry trust relation registration VE ENUM Registrar validation E.164 number assignment verification ENUM management Registrant / Assignee NAE number assignment IETF63 - enum WG

  6. draft-mayrhofer-enum-validation-arch-00 Validation Requirements • The ENUM domain name corresponds to an assigned E.164 number • The corresponding E.164 number is within a number area approved to be used with ENUM • The registration of the ENUM domain name isauthorized by the Assignee of the corresponding E.164 number • The Registrant of the ENUM domain name is identical to the Assignee of the corresponding E.164 number IETF63 - enum WG

  7. Initial vs. recurring validation • Initial Validation • Verify requirements before registration of the ENUM Domain takes place • Recurring Validation (Re-Validation) • Verify that requirements are still satisfied • usually making use of data acquired during initial validation • domain is to be removed when corresponding E.164 number is e.g. revoked IETF63 - enum WG

  8. draft-mayrhofer-enum-validation-arch-00 Registration process assumption Legend VE: Validation Entity NAE: Number Assignment Entity ENUM Registry trust relation 5 registration VE ENUM Registrar validation 3 ENUM management 2 E.164 number assignment verification 4 1 Registrant / Assignee NAE number assignment IETF63 - enum WG

  9. existing RFCs policy dependent common (policy independent) example validation token enum.at some other suitable XML transport mechanism (e.g. SOAP) other variant? Draft-hoeneisen-enum-validation-epp-01 / draft-lendl-enum-validation-token-00 Transport / data format extension framework EPP domain EPP validation framework EPP draft-hoeneisen-enum-validation-epp-01 Scott's EPP RFCs draft-lendl-enum-validation-token-00 IETF63 - enum WG

  10. draft-hoeneisen-enum-validation-epp-01 EPP transport • Framework for Transport of validation information along with the EPP Domain object • Elements for validation information itself are out-of-scope of this document • Example for better readability included • enables usage of different locally adjusted validation information elements or "tokens" IETF63 - enum WG

  11. draft-lendl-enum-validation-token-00 Validation Token • Conveys information about a validation • E.164 Number (obviously) • Contact information (in the style of EPP and E.115) • Serial, validation method, validator, expiration … • XML schema • Optional cryptographic signature • Non-repudiation • Authenticity • Supports trust relation between VE and registry • To be embedded in transport protocols • EPP (Bernie's draft, enum.at implementation) • SOAP? Email? HTTPS? • In productive use for 3.4.e164.arpa. • Probably useful for other purposes (number porting?) IETF63 - enum WG

  12. Next steps • How to proceed withdraft-mayrhofer-enum-validation-arch ? • WG item? • Feedback requested on documents – in particular from folks working on ENUM provisioning implementations IETF63 - enum WG

More Related