Subject: [Ietf-not43] comments on FIRS

From: edlewis at arin.net (Edward Lewis)
Date: Mon Jun 9 23:46:51 2003

Here are some comments based on one reading of the FIRS documents 
(all fit in this: draft-ietf-crisp-firs-*-01.txt).

The context I'm coming from looking at IP network registrations, 
which don't fall neatly into domain names.

Umbrella thoughts -

1) Internet resources are keyed by domain name.  The name space is 
composed of sets (a misnomer as order is important) of 
domainComponents ("dc="'s) "which cumulatively identify a specific 
portion of the global directory tree."

This is a problem.  Network blocks are registered as ranges of 
network addresses and DNS entries only map to class-full boundaries. 
Even if you get into CIDR-ized DNS (RFC 2137), the problem isn't 
solved, e.g.,

% whois -h whois.arin.net NET-631-823-120-0-1
NetRange:631.823.120.0 - 631.823.127.0
CIDR:    631.823.120.0/22, 631.823.124.0/23, 631.823.126.0/24, 631.823.127.0/32

(Obviously, the numbers have been changed to protect the innocent.)

Basically, address ranges can't be cleanly identified by a domain name.

DNS also can't show the hierarchy of the address assignments - you 
can only delegate from the /16 to the /24 once, but the 255 addresses 
can be suballocated from ISP 1 to ISP 2 to ISP 3...

It appears that the issue for ASN's isn't so dire, but the proposed 
solution places a requirement on IANA to run a ldap server answering 
for a domain that has been handed to the IAB (arpa).

2) In this proposal, DNS appears front and center as the glue of the 
ldap servers and as the representation of all things registered. 
This is contrary to the way in which the numbers registries work 
where DNS is a "tail of the dog."  Being allocated number space 
without a DNS presence is of value as the space only needs to appear 
in the routing tables.  This is unlike the name registries, where 
presence in the DNS is akin to presence in the routing tables.

Pretty much that is the most substantive stuff I hit.  Below is a 
recounting of dog eared pages, mostly coming from the above thoughts.

Document by document -

-firs-arch

I agree with the needs - global data-typing and formatting, need to 
infer knowledge of other servers, potentially account for security 
and for privacy.  I'm dubious that there is a need to fit into any 
database schema - just to look like it came from one is the goal.

section 4 namespace - issues already in umbrella section

"    distributed partitions. Furthermore, the SRV resource records
      associated with those DNS domains also provide a useful mechanism
      for locating the authoritative LDAP servers associated with any
      particular resource in the global FIRS directory database.
"

Not so true in the reverse map - e.g., a /17 yields 128@/24 
delegations.  I guess that we could live with 127 SRV's in that 
instance.

section 4.5

"    elements SHOULD provide multiple URLs, each of which identify
"

Already submitted a comment that implementations check all IP's of 
host parts of URLs - suggested to avoid a mistake in DNS resolver 
code.

section 7.2

"     occurred for a particular resource. For example, RIPE and some of
      its member ccTLDs provide WHOIS output which includes a series of
"

ccTLD's aren't (per se) members of RIPE - at least not in an 
operational sense although they maybe sponsorships in there.  Maybe 
this is just a terminology issue.

-firs-core

Section 3.2 - name problem, DNS is a poor representative of network ranges.

Section 3.4 -
"        *  The protocol identifier of a URL MUST specify the LDAP
             service type. Although general-purpose LDAP referrals are
             allowed to specify any kind of protocol, FIRS referrals are
             intended to be used for automated queries, and the use of
             other protocols is forbidden in the default case.
"

Not sold that this restriction makes enough sense.  As in, perhaps, but I
don't see the rationale.

Section 4.1.2

"          inetResources
           ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The
             inetResources container for the FIRS service' SUP top
             STRUCTURAL MUST cn MAY ( o $ ou $ description $
             inetResourceComments $ businessCategory $ telephoneNumber $
             facsimileTelephoneNumber $ labeledURI $
             preferredDeliveryMethod $ physicalDeliveryOfficeName $
             postOfficeBox $ postalAddress $ postalCode $ street $ l $
             st $ c $ inetAbuseContacts $ inetGeneralContacts $
             inetSecurityContacts $ inetTechContacts $
             inetGeneralDisclaimer ) )
"

I think more flexibility is needed in the names of the contacts - 
maybe have a structure called contact and inside have a "kind" - 
Admin, Tech, Abuse, Notify, etc.  Also, we tag contacts as persons or 
roles.

We also have a "Public comments" field in the ARIN database, probably 
close to "General Disclaimer"

Section 4.2.3 (Example)

I'd like to see this for a true net range, not just a class-full CIDR notation.

Section 5 - reference to a "Section 0" (Nit.)

Section 5.2.1 - "query fails" - returns no data?  Failure modes will 
need better treatment, failure cases are traditionally poorly defined 
and become the Achilles heal of specs.

Section 5.2.2.
"     The top-down model is primarily suited for locating Internet
      resources which are centrally managed and delegated, and where
      information about the delegation is desired. In particular, this
      includes resources such as DNS domain names, IP address blocks,
      and AS numbers.
"

Okay for following database but not in DNS.  Addresses can be sub-allocated.

Step a.1 - what if the IP address isn't on a class-full boundary?

-firs-asn

inetAsnRegistrar - not applicable
inetAsnRoutingContacts - number registries may not have access to any 
routing policy, in any shape or form.

"         inetAsnContacts
           ( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAsnContacts' DESC
              'Contacts for general administrative issues concerning
              this ASN.' EQUALITY caseIgnoreMatch SYNTAX
              inetContactSyntax )
"

Need more flexibility to identify the contacts for the ASN, and 
whether the ASN is role/individual.

"                0   Reserved delegation (permanently inactive)
                  1   Assigned and active (normal state)
                  2   Assigned but not yet active (new delegation)
                  3   Assigned but on hold (disputed)
                  4   Assignment revoked (database purge pending)
"

Not sure if these apply, maybe they do...  (ASN's aren't delegated.)

"          cn=65535,cn=inetResources,dc=arin,dc=net
...
           +-attribute: inetAssociatedIpv4Networks
           | value: "192.0.2.0/24"
"

ARIN doesn't associate ASN's with prefixes - that's an operational 
decision.  (We register ASNs and prefixes to organizations, not each 
other.)

Section 5.1

This sounds like it's creating a ASN swamp - ARIN doesn't give out 
all AS's, each registry would have to run it's own ldap server for 
it's component.  I.e., IANA is the root of this.

-firs-ipv4

"     An augmented BNF for this syntax is as follows:

           inetIpv4NetworkSyntax = inetIpv4Octet "." inetIpv4Octet "."
             inetIpv4Octet "." inetIpv4Octet "/" inetIpv4Prefix
"

Doesn't capture ranges accurately enough.

inetIpv4Registrar, Routing contacts - same as for Asn above, and same 
for Ipv6 in the -firs-ipv6 document.

Section 5.1

" Finally, a
      classless IPv4 address block of "192.0.2.0/20" would be mapped to
      the reverse-lookup DNS domain name of "0/14.2.0.192.in-addr.arpa"
      which would in turn be mapped to the fully-qualified distinguished
      name of "dc=0/14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa".
"

I don't follow that.

-firs-ipv6

Nothing new (comment wise) that wasn't in -ipv4.

-firs-dns and -firs-dnsrr didn't seem to be of interest to my 
context, I can't figure out the latter anyway.

-firs-contacts

Problems in here have already been mentioned...

We have a generic contact with "subtypes" and the role/individual 
thing.  Issues here aren't hard to hammer out....
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Digital cameras are to film cameras as Etch-A-Sketches are to canvases.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jun 10 13:55:50 2003

[general comments here, and some detailed comments below]

Thanks for the input. I've made the changes and corrections I could, based
on errors and comments below. We need to discuss some of the general
concerns you raised in more detail to see where there are real issues or
just poor wording on my part.

Before we get into that, let me make a disclaimer, which is that the IP
addressing and ASN specifications were really intended to serve as
placeholders until somebody from that area expressed sufficient interest
in working on the subject (tag, you're it). Also, the WG charter doesn't
cover those areas, although my understanding of the situation is that
we're probably going to flip back to include them at some point. For those
reasons, I specificallly labelled the IP specifications as "Experimental"
(and had meant to do the same with the ASN specification but forgot to
change the template apparently). The specifications in their current form
really only represent my best-guess at the subject, and I want/need your
help to make them useful.

You're correct in your observation that ASN entries are served from a
swamp namespace. That's because ASNs do not have any hierarchy, and are
not mapped to the DNS hierarchical namespace. Since there's no hierarchy
or namespace, a "default" authoritative partition has to be used to
initiate the query-resolution process. However, my expectation is that the
entries in the default partition will *only* exist as referral sources,
with queries for each entry being immediately referred to canonical
entries at RIR-specific partitions. For example, a query for ASN 65535
would be mapped to the default partition and get sent to the swamp server,
which would immediately return a referral to the RIR-specific partition.
If you have any ideas on how we could impose ASN-to-partition mapping at a
higher layer using some kind of DNS mapping, it would lighten the overall
burden on the servers somewhat (moving it to the clients), but that's
really our only other alternative to using a swamp referral system.
Alternatively, I can put the above text into the ASN specification and
tell folks what's actually going on.

IP addresses do have hierarchy, and can be mapped to DNS domains in order
to construct the authoritative partition element of a fully-qualified
distinguished name for a particular resource. However, the default query
process does not use the authoritative partition, but instead uses dc=arpa
as the default partition. As with ASN entries, queries are sent to the
swamp server by default, and referrals take over from there. The reason
for specifying how to build the fully-qualified distinguished name is so
that the other bootstrapping models *can* be used if necessary or
desirable. But by default, it is not used. Whereas ASNs can *only* use the
top-down model (since there is no delegation hierarchy to map against),
address blocks can use any of them, but by default use the top-down model.

Judging from your comments, you are saying that there some of the
centrally delegated address blocks don't align with mappings in the
IN-ADDR.ARPA hierarchy. I'd like to talk to you off-list about these to
see what we can do to make the full syntax predictable, or if the errors
in my text are the actual problem (the example you cited was malformed and
has been corrected, and there is a missing recursion for parent octets).
Let's talk about this off-list.

Specific responses below.

> this is just a terminology issue.

reworded as "RIPE and some ccTLDS"

> Not sold that this restriction makes enough sense.  As in, perhaps, but I

FIRS is an application service which is specifically intended to provide
automated retrieval. The application service is expected to be integrated
into a variety of user applications, such as ~"click on a traceroute entry
and fetch information about the network resource". In order for this work
as expected, the referrals have to be constrained to predictable and
defined mechanisms, and allowing unstructured and/or undefined services
breaks the usage models. For example, a traceroute client that calls of
FIRS should be able to expect that the data will always be provided as
LDAP attributes; if the answer data is a generic web page or a gopher menu
or some other unstructured and/or undefined URL/service, the application
wouldn't be able to use the information. I reworded the text to try and
clarify that the restriction is due to the application limitations.

> Admin, Tech, Abuse, Notify, etc.  Also, we tag contacts as persons or 

We should probably talk more about the kinds of contact types/roles you
need to support. I'm not going to be excited about putting them into a
structured ASN.1 attribute (if that's your suggestion) since that makes
searching by value much harder (eg, ~find all resources with this contact
address). I've no problems with moving the generic contact attributes into
an auxiliary object class, and almost did that on the last edit. We should
talk about the types/roles that need to be supported and then we can
figure out the best way to go from here.

> Section 4.2.3 (Example)
> 
> I'd like to see this for a true net range

That's just an example of the associated resources. I don't want to
introduce complications, since that would unnecessarily obfuscate the
canonical purpose of the example (associated resources).

> Section 5 - reference to a "Section 0" (Nit.)

Fixed, thanks

> and become the Achilles heal of specs.

I tried to clarify that there is no recovery in this model (directed
queries), and that the search has to exit if the "known" server or "known"
resource do not exist at the expected locations.

> Not sure if these apply, maybe they do...  (ASN's aren't delegated.)

That's all stuff we should talk about.

> decision.  (We register ASNs and prefixes to organizations, not each 

The "associated" entries are mostly for operator use, not for use by the
registrars or delegation bodies. There are some instances where it would
be useful for a delegation body to provide some of this data, but it is
mostly provided as a way for people to say "this domain is associated with
this netblock" for internal linkage purposes. You can ignore it.

>       name of "dc=0/14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa".

There was an error in the example, sorry. It's been fixed. New text is:

  For example, a host-specific IPv4 address block of "192.0.2.14/32"
  would be mapped to the reverse-lookup DNS domain name of
  "14.2.0.192.in-addr.arpa." which would in turn be mapped to
  "dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Meanwhile, the "Class
  C" block of "192.0.2.0/24" would be mapped to the reverse-lookup
  DNS domain name of "2.0.192.in-addr.arpa." which would in turn be
  mapped to "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Finally, a
  classless IPv4 address block of "192.0.2.0/20" would be mapped to
  the reverse-lookup domain name of "0/20.14.2.0.192.in-addr.arpa"
  which would in turn be mapped to the fully-qualified distinguished
  name of "dc=0/20,dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa".

See the intro text at the top of this message. The purpose is to provide a
fully-qualified DN which *can* be used for non-default queries.

> context, I can't figure out the latter anyway.

-firs-dnsrr is intended to provide a way to store raw DNS resource records
with a specific entry. This is primarily intended to provide structured
nameserver data (host:address pairs) with domain name entries and for
storing address data associated with a known nameserver entry (I need to
better explain this). It is generalized to allow both of these uses and to
also allow any kind of raw RRs to be associated with any domain name
entry, for any other purpose. For example, some DNS servers allow
LDAP-storage of zone data, and this accomodates that usage in an
interoperable way. Those other uses aren't the stated goal because they
aren't part of the charter but they are well-served by a generalized RR
storage schema which is needed anyway.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: ggm at apnic.net (George Michaelson)
Date: Sun Jun 15 22:41:56 2003

Eric, I think you are making a mistake arguing that the DNS is the vehicle to
control the mapping of Internet Addresses back to their parent allocation blocks
(which is how i read part of your response to Ed.)

Reverse-DNS domain registration is a disjoint set from Allocation space records.
While ARIN may use mechanisms in their 'inetnum' object to manage default DNS
servers, there is no obligation to maintain a reverse-DNS entry, and in fact we
are considering mechanisms to de-list people from the DNS who are lame, to try
and improve global services (impact on the root for lame DNS is large)

I think all not43 candidates trying to del with addresses have to face up
to address behaviour as allocation behaviour as a 'first class' data type with
certain behaviours, not as a side-effect of DNS/domain behaviours:

	allocations are integer ranges

	not all allocations are CiDR aligned (but usually can be broken down
	into CiDR equivalents)

	allocations nest.
	
	requests to look up allocations include

		find immediate parent
			ie find the nearest thing 'above' this entry, containing
			this entry.

		find maximal (largest) parent
			ie find the largest thing 'above' this entry, which may
			contain sub-entries which themselves nest, to this entry

		find all children

cheers
	-george

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Sun Jun 15 23:52:33 2003

on 6/15/2003 9:41 PM George Michaelson wrote:
> Eric, I think you are making a mistake arguing that the DNS is the
> vehicle to control the mapping of Internet Addresses back to their
> parent allocation blocks (which is how i read part of your response
> to Ed.)

By default, queries would be sent to the servers responsible for the top
of the delegation hierarchy (in-addr.arpa., etc). Those queries would
follow LDAP referrals to registry-specific servers for the range that was
queried, possibly following LDAP referrals to operator-specific servers.

The use of full-reverse maps are only intended to be used in those cases
where the user wants to *start* the process at the servers belonging to
the operator of a particular block, and where starting at the top of the
delegation tree would be a waste of time for the user and an unnecessary
burden on the top-level delegation servers. There are going to be some
applications which need to communicate directly with leaf-nodes -- one
possible example might be a reverse-route analyser, where the client wants
to ask a remote operator's server for its view of a route -- and there
needs to be a mechanism for performing leaf-node bootstrapping to support
these kinds of applications. In the typical case, however, clients will
usually start at the top, as described in the preceding paragraph.

[btw, the use of in-addr.arpa is a change from what is in the -01 specs
right now, which just uses the arpa TLD, but which has been changed in the
pending -02 specs after discussions with Edward].

> Reverse-DNS domain registration is a disjoint set from Allocation space
> records. While ARIN may use mechanisms in their 'inetnum' object to
> manage default DNS servers, there is no obligation to maintain a
> reverse-DNS entry, and in fact we are considering mechanisms to de-list
> people from the DNS who are lame, to try and improve global services
> (impact on the root for lame DNS is large)

That's understood and perfectly okay; it's not mutually exclusive with the
intended usage. If somebody wants to provide data on their leaf-node
server, their DNS mapping has to work in order for the server to be
located. Removing broken delegations from the parent domain would not
affect anything that wasn't broken already (this is equally true for SRV
RRs as it is for PTR RRs).

> I think all not43 candidates trying to del with addresses have to face
> up to address behaviour as allocation behaviour as a 'first class'
> data type with certain behaviours, not as a side-effect of
> DNS/domain behaviours:
> 
> 	not all allocations are CiDR aligned (but usually can be broken
>       down into CiDR equivalents)

Allocations that don't fall on CIDR boundaries are a problem for ARIN too,
and we're bouncing a couple of ideas around on this now. The problem from
my perspective is that hierarchical, non-indexed distributed partitions
have to store the lookup key in the entry name in order for them to be
locatable in the global database, and the CIDR allocations are the best
key value (and thus the best naming value for entries) for a variety of
different reasons.

The best solution to this dilemma for me personally would be to generate
your LDIF dumps to use the known CIDR allocations, regardless of how the
allocations are stored in the canonical database. Using the example that
Edward gave, that would mean creating multiple LDIF entries from the
single "NET-631-823-120-0-1" entry in the canonical database, with the
resulting ["cn=631.823.120.0/22"|"cn=631.823.124.0/23"|etc] LDIF entries
with data from the canonical entry.

While it's possible to use some kind of centralized delegation data for
some of this (such as keeping it within LDAP), that goes against the
federated approach the WG has explicitly favored, and causes unnecessary
burden for applications that want to locate a leaf-node server without
having to ask the delegation root for the information. This is especially
true for leaf-nodes that may be several delegations removed from the
top-level (eg, a server on a /29 subnet, delegated from an ISP, who
delegated from a provider, who delegated from a registry,...).

> 	allocations nest.

Nested allocations can be accomodated either directly (if they fall on
CIDR boundaries) or indirectly (as above).

> 			ie find the nearest thing 'above' this entry,
> 			containing this entry.
>
> 			ie find the largest thing 'above' this entry,
>			which may contain sub-entries which themselves
> 			nest, to this entry

Those scenarios are handled in the default case already. The matching
rules in the specs say that all entries that are superior to the address
in the assertion value must be returned. So, you could return the /8 top
allocation, a /16 sub allocation, all the way down to a /32 allocation if
you have those allocations stored in your server (and you can generaate
referrals to the operator's server if you don't have them stored).

The requirement here is that the LDAP server will need to have specific
entries for each of these address blocks (note that this may just be a
result of how you spit out LDIF files nightly or whatnot, not necessarily
how your internal database is structured).

> 		find all children

Today that could be handled with an inetAssociatedIpv[4|6]Network
attribute in the parent entry. If we we need something more robust than
that, we can define an additional matching filter that specifically
requests all of the subordinate allocations on the queried server. The
downside to that approach is more complexity at the client, in that it's
another radio button the user has to navigate. How common would this be?

It seems from the above that you have pretty much the same issues as
Edward is raising in our off-list discussion. We should bring you into the
discussion once we get a little further into it.