RE: [bdx] BDX address recipe outline.

[Moberg Dale <dmoberg@axway.com>]

I have gathered my (limited) understanding of SML and SMP from the PEPPOL appendices L and M, with a look at N, where I started googling background CEN BII links and have temporarily suspended following them.

 

I also hope that I benefited from Mike Edwards’s background presentation relating to addressing!

 

The PEPPOL documentation is very detailed and has solutions to many issues, but it is often hard to see what proposals address generic BDX requirements, specific EU concerns, specific EU project concerns, solution provider concerns, and enduser concerns. In other words, the requirements are neither particularly explicit nor separated by stakeholder concerns. I am, like you, trying to pull the solution apart to see what can be “internationalized” and be of general relevance and value in standardization. Perhaps that will be all, perhaps that will be only certain parts.

 

I best not try to explain how DNS is currently used in general by BDX, and I am for the moment separating out SOA (DNS start of authority) management of records from use of DNS information. But here is one thing I think I have understood. For a 4 corner model (and perhaps for a general n-corner, or intermediary cloud model) there can be a need to interconnect clouds (2^nd and 3^rd corners) so as to relay traffic from corner 1 ( a customer of 2) to corner 3 (where corner 4 is a customer of 3, and is also the destination of some business data exchange originating at corner 1.)

 

While CNAME and A type resource records (RRs) are discussed in BDX, and are apparently used in the DNS query process in the standard way (to obtain an address from a fqdn, a fully qualified domain name), there are other DNS capabilities that can be used for quite ingenious and flexible solutions involving RRs. To keep it simple, I have sketched a query process given a dns query string, a resource record type (NAPTR), and described how to use several DNS query results to find address of 3 from 2, for example. NAPTRs can be used in quite flexible (some might say sometimes too flexible ways) as documented in RFCs 3401 to 3404 on Dynamic Delegation Discovery System (DDDS).

 

So here is one _very_ simple approach

 

Initially corner 2 does a DNS NAPTR query for “unreadablehashedvalue.bdx.org” and get back NAPTR records such as

 

IN NAPTR 100 10 "A" "ServiceIdentifier" "!^.*$!nexthop.example.com!i" .

 

This would be followed (or might be included in the first query) by a DNS A/AAAA/A6 RR for nexthop.example.com to get the address.

 

In this example, “bdx.org” is the domain that has naming authority for the bdx.org domain. It might be a top level domain or subordinate; let’s not worry about those political issues now. The NAPTR record(s) for unreadablehashedvalue.bdx.org then provides information for a discovery process. The “A” indicates that no recursive (in the space of NAPTRs) is needed but that an address lookup will be enabled.  The “100” and “10” values indicate priorities which can be used when multiple records are returned, but are ignored here.  The regular _expression_ ("!^.*$!nexthop.example.com!i") takes the DNS query string matched by the regexp |^.*| (any character string matches) and replaces it by the string “nexthop.example.com” This result is the DNS string that is the key for the next query, which will seek an Address RR in which the internet assigned numerical address (v4 or v6) is found. The field for “Service Identifier” allows a two part well service identifier that allows a given query string to have many NAPTR records, each describing something different for that service. If these were used, it would be our job to standardize the service values into two parts “xxx+yyy” where x and y are alphanumerics and 32 characters maximum. Or if that is unsatisfactory, metadata can be hashed up into an opaque identifier, along with the participant recipient identifier.

 

There are a lot of other ways to build up a query system from NAPTR RRs. Instead of pointing to A records, you can point to S records (DNS SRV RRs). Or recursively using “P” to other NAPTRs. URIs can be looked up using “U”. I do not wish to go into the depths until we agree upon requirements. But if the SLM portions of the submission can be salvaged and scrubbed up a bit, I think we can define a quite general lookup approach suitable for international use and perhaps providing a DNS based discovery service for BDX concerns. (Earlier  approaches (UDDI,ebXML RegRep, others?) could find a home within the resulting lookup services. I think BDX is an interesting start but becomes far more interesting if some advanced DNS functionality is added.

 

Hope that provides a start at adding some clarification.

 

From: bdx@lists.oasis-open.org [mailto:bdx@lists.oasis-open.org] On Behalf Of Tim McGrath
Sent: Tuesday, October 25, 2011 9:48 PM
To: bdx@lists.oasis-open.org
Subject: Re: [bdx] BDX address recipe outline.

 

for a laymen, can i get a feel for how this varies from the use of DNS currently proposed by BDX (and implemented in PEPPOL)?

On 26/10/11 1:51 AM, Moberg Dale wrote:

In this message, a way to use IETF DNS functionality for the BDX address resolution is sketched.  The resolution using a canonical concatenated string of bdx metadata that has been made opaque (in whole or part) by using a cryptographic hash. Apparently this masking has been required  to meet some commercial concerns about not disclosing what organizations use which providers).

 

The main point here is to show that BDX address lookup requirements are met by using a known registry (DNS) with known internet scalability and manageability, using already existing approved standards.

 

By analogy with ENUM, (see information box below for an introduction to ENUM from voip-info.org), we can therefore concatenate BDX service metadata identifiers to a string in a canonical way, use sha-256 to produce a resource identifier, introduce a DNS NAPTR record for that identifier in the “peppol.org” domain or whatever , do a DNS query on the resulting value, and  resolve in a standardized way (indicated by the “A” flag of the NAPTR record) to A, AAAA or A6 address records.

 

(For extra spice, add DNSSEC to prevent cache poisoning at the “peppol.org” domain. Use DANE for DNS based PKI if desired for TLS. Many variations are possible for the NAPTR string on  concatenation order, separators, hashing procedures to meet visibility or nondisclosure concerns. Another variation would insert a “S” flag in the NAPTR RR, and then look up SRV records for a domain name key, from which address records would be obtained. This additional step would allow multiple BDX servers to be advertised for a provider, e.g.)

 

IETF has evolved DNS to support many use cases beyond simple FQDN to Inet address lookups. Isn’t it preferable to actually use DNS, its query system, and its zone update management procedures instead of creating a hybrid Web Service and DNS mashup for a use case that is already easily handled by a simple profile of current specifications?

 

 

From http://www.voip-info.org/wiki/view/ENUM

 

You can dial a telephone number and reach a SIP, H.323 or any other Internet Telephony user. This all happens in the background; you do need to do anything special while calling someone.

A server with ENUM support will lookup a dialed telephone number in the ENUM tree of the DNS to see if there's alternate ways to set up the call instead of just calling out on the PSTN telephone line. ENUM may contain a reference to a SIP URI, a telephone number to dial, a web page or an e-mail address.

Enum uses DNS NAPTR resource records.

 

DNS NAPTR resource records are documented in RFC 2915: This document describes a Domain Name System (DNS) resource record which specifies a regular _expression_ based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). […] This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource Discovery Systems to moving out-of-date services to new domains.