Comments on draft-irtf-nsrg-report-10.txt Last Call

[Dave Crocker <[e-mail]>]

Folks,

As the discussion about identifiers heats up around the IETF, I've been
finding the NSRG draft very helpful. It's journey through the issues makes it
more difficult for the reader to miss concerns that need to be visited along
the way. Given the remarkable number of IETF efforts that currently touch this
topic, it should be no small benefit to have a document like this, to add some
discipline to the discussion.

I think it is just fine that the paper mostly does not propose or "vote for"
specific solutions. However, I suggest that some detail and depth be added to
some of the opinions offered, particularly in light of the recent evolution to
location/identity and multiaddressing (mobility and multihoming) discussions
in the IETF.

In general, anytime the document offers an opinion, it should try to explain
things sufficiently so that _unsympathetic_ readers and readers unfamiliar
with the topic can see the solid basis for the opinion. The extra pedagogy
will be extremely useful.


Specific comments:


        1.1 Security Considerations

        ...because both the DNS entry and the IP address can change.

There is no such thing as permanent. Even things like MAC id's can be soft. By
most Internet measures, DNS entries are very long-lived. So the concern that a
DNS entry can change needs to be discussed in terms of practical alternatives.
(My concern is not a matter of purity.  I truly do not know what the draft
means.)

If the NSRG folks think that something better is possible, their document
should describe that alternative concretely. Personally, I can't guess what
that would be. And since I've become an advocate of using domain names as
identifiers, I'm particularly interested in hearing the details of what the
NSRG has in mind.

Only then can the reader evaluate that broad claim in the document that the
Internet's architecture has a shortcoming by not having "persistent" names.


          ...connection being hijacked...

Pekka Nikander has cited both hijacking and flooding as exposures. My summary
of his point is:

          Hijacking is directing traffic to oneself. Flooding is directing
          traffic to someone else. One is to intercept data and the other is
          to overload a victim. Both problems are created by being able to ...
          redirect traffic to a new address.

It's helpful to make the distinction between the two.


          2. Related Work

Please add discussion about the new alternatives that have popped up. TCP-MH,
MAST and LIN6 are the three I can think of.  DCCP's tentative multihoming
proposal probably qualifies it for consideration, too.

To the extent that the NSRG finds it helpful, they might want to take a look at:

  <http://www.ietf.org/internet-drafts/draft-crocker-mast-analysis-00.txt>

I split it off from the MAST proposal. It discusses all of the alternative
specifications. I am also working on some tables that compare the different
proposals, but progress on it is slow.


           2.3 HIP

           ...reduced administration. A typical access list used on the
           Internet...

The paper is entirely too casual about citing access control list aggregation.
It implies that this is merely an encoding issue that is hurt by HIP's use of
a hash.

However the entire concept of seeking aggregation hinges on the nature of the
string administration. Independent of the "syntactic" issue that is defeated
by something like hashing, it is only useful to aggregate a control list if
the things being aggregated have the right properties in common AND the
properties are reflected in the name. So, for example, aggregating
topologically-related names makes sense, if topology is the concern. For
domain names, the property in common is administrative authority. Is that the
right property for an access list to aggregate on? Of course, the answer is
that it depends. And the paper should cite this.

Also this issue of list aggregation is of general interest and should not be
buried in the discussion of a particular alternative.


           3. Discussion

           ...Examples of an entity include...

How is a "service" different from a "communicating entity"? Perhaps I'm not
understanding what the NSRG means by "service".

In any event, let me suggest that an architectural discussion like this should
not just offer examples, but should explicitly list the full set of
alternatives. This needs to include interfaces, for example. (If the NSRG
meant "stack" to cover interfaces, as well as logical protocol stacks, then
they need to make this clear. However, are should a stack be able to have only
one interface?)

I believe much of the debate on choosing a type of identifier hinges on its
architectural placement. So, it's quite nice that the NSRG paper has this Discussion
section, but I think it needs to be more pedantic -- or, rather, pedagogical --
about listing and considering the choices.


          3.1 Requirements

          "Stack names are defined to be a new naming structure..."

It is a bit strange to have the term "stack" defined considerably after it has
been used.

More importantly, it calls for a new string and automatically excludes any
existing choices. If that's not what the NSRG meant, they might want to use phrasing
different from "new naming structure". Perhaps "new naming construct" with an
explicit note that it includes existing names, such as IP addresses and domain
names? Existing choices might well be sufficient, if they cover the right
place in the stack and have the necessary other properties. So the text should
not imply that a new string is required.

If, on the other hand, the NSRG really did mean to insist that a new string is
required, then the paper is taking a position for which there is insufficient
requirements support. At the least, the NSRG needs to do a much more thorough
job of explaining why existing choices are absolutely unacceptable.

My own efforts to get just this sort of explanation, on several mailing lists,
has been oddly unproductive, although some offline discussions are making
progress. I get the sense of underlying religion driving things more than
functional requirements, or at least of functional requirements that are so
abstract, folks do not have a sufficiently concrete sense of usage. So my
request to for these enhancements to the NSRG paper really is a plea.

By the way, the bulleted list at the end of the section is a good summary of
the conceptual concerns.


           3.2.2 Statistical

This section 3.2 is an excellent guide to name architects.


           ...such delegation introduces overhead...

This section applies to IP addresses, as well as domain names, so the
discussion needs to be much more constrained in listing problems. For example,
solutions that have no linguistic/semantic quality to them are not likely to
run into serious trademark concerns.

Frankly I think the reference to domain squatting is bogus.  Domain squatting
is a hassle, but does not seem to be a major issue in the use of domain names,
these days.


          3.2.3 Mapping

          A name on its own is of very limited value.

On the contrary, the simple fact of a string's uniqueness can be extremely
helpful, in a sufficiently constrained context, even when there is no mapping.
The context nonce labels that are used in PPK, SCTP and MAST do not really
have any "mapping" other than being unique.


          Usage

This is a discussion that seems to be missing from the section, yet everything
hinges on it. How will a name get used? For example as the paper notes, one
important question is whether the name needs to be in every packet?

This one point has massive impact on the design choice, of course.

I believe a failing in the community discussion about identifiers is that it
is conducted too much in the abstract with too little consideration of the
actual usage requirements. Consequently people are not thinking very hard
about trade-offs among the alternatives.

The paper presents issues in terms of a kind of taxonomy. This is quite
useful, but only after there is a broader context for discussing usage, since
it is the usage that drives the requirements. Only when the requirements are
more clear can the design choices be made from the taxonomic menu that you
present.


        Infrastructure

This is another discussion that would be helpful to add. The paper touches on
it in many places, and certainly the paper implies its importance, but I think
that it is not presented as a coherent design point.

The question is what administrative and operational infrastructures are needed
for the identifier? (And, of course, why?) Again, my sensitivity about this
comes from seeing a lack of consideration for it in the community discussions.


        3.5 Is an architectural change needed

        ... Mobile IP will cover any perceived need...

This statement is a good example of missing the infrastructure factor. Mobile
IP takes a significant infrastructure hit. Note, for example that the MIP
effort has been underway for a very long time and has, so far, achieved
essentially no market penetration.

Further, approaches like TCP-MH and SCTP show that similar functionality can
be achieved through a very different approach that has no infrastructure
overhead. No, not the same as MIP. Target (ie, Server) Mobility requires some
sort of 3rd party reference service. However Initiator (ie, Client) Mobility
does not.

I strongly encourage that the paper avoid taking MIP as a given.

To conclude, I'll repeat my thanks for the NSRG paper. Although I have my own
biases about the right choices for this topic, I am more concerned that
discussion about choices be carefully reasoned and appropriately concrete.
From what I have seen, this has not been happening. the NSRG paper can be
extremely helpful in focusing discussion to be less religious and more
functional.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:[phone]>