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

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Oct 2003 15:27:13 -0700

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:+1.408.246.8253>

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 10 Oct 2003 15:24:08 +0300

Dave and others,

Thanks for these your valuable comments, Dave.  As I mentioned in
my other message wrt. the draft, I have also some concerns.
Since they mostly align with your concerns, it looks best
to use your message as a starting point, and mostly add to it.
On the other hand, in a couple of points I do disagree with you,
or just have a different point-of-view.  I also indicate these
below.

Before going to the specifics, I also want to express my please
on the draft.  I think that it is very important that the IETF
conveys this kind of discussion, and that the draft is published
in a timely manner as an RFC.  I also hope that the IAB soon
will create the architectural discussion mailing list that they
promised at the IAB open meeting in Vienna.

I am only referring to those sections of your (Dave's) comments
that are relevant to my concerns or where I clearly disagree.

> Pekka Nikander has cited both hijacking and flooding as exposures. My
> summary of his point is:
> 
> 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 ... 

I completely agree and second this comment.  As far as I know,
still today the best document explaining the attacks is the Mobile
IPv6 Route Optimization background document,
draft-nikander-mobileip-v6-ro-sec-01.txt.  The document is somewhat
lengthy and MIPv6 specific, but it does explain the dangers.
The current intention is to publish the document as an informational
RFC.  Gabriel Montenegro is the document editor.

> 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.
...
> Also this issue of list aggregation is of general interest and should
> not be buried in the discussion of a particular alternative.

I concur.  Especially now when HIP is more similar to PBK in the
sense that HIP keys are mostly created by the hosts themselves
and not administratively assigned in any way, I would suggest
moving this discussion to a completely separate section.  On the
other hand, we have to remember that HIP is still very much a moving
target, and may change considerably in the future.

The issue of using HIP Host Identifiers in firewalls and ACLs is more
complicated that the text suggests.  While it is true that managing
strings that do not have any aggretable structure may be harder, it
is also true that the public key nature of the HIP host identifiers
make it possible to build much stronger firewalls and ACL protection
than the current IP address based mechanisms allow.

> Usage  [of names]
> 
> 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?
> 

I think that it is very important to try to clarify the role of
any potential new identifiers or stack names.

The off-line discussions that Dave, me and a few other folks have
been having seem to indicate towards a direction where we have at
least two very different design choices:

   1. The new names could be used mostly for (combound) connection
      identifiers, allowing end-points involved in connections
      to change their IP addresses during the lifetime of the
      connections.  At the same time, IP addresses would continue
      to be used for opening new connections.  There are many
      subtleties in this design, especially security wise, but I do
      not want to use excess space to explain them here.

   2. The new names could be used more like genuine end-point
      identifiers, both naming existing connections and being used
      as contact points for new connections.

While this usage semantics dimension definitely needs to be
explored much more, I don't know whether the NSRG draft is the
right place to do so.  Maybe the NSRG draft could merely
explicitly mention the problem relate to usage semantics, and
the deep relations to any future design and architecture.

> 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.

I pretty much agree.

> Infrastructure
> 
> 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.

I tend to believe that it is too early to discuss the question of
required infrastructure in detail.  Only when we have some kind
of understanding of the usage scenarios can we do so.  From my
point of view, the current touches on infrastructure are quite
enough for the NSRG report.

> 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.
> 

Dave, with all respect, I think that you are partially missing the
context here.  My reading of the draft here is that it simply tries
to explain the two schools of thought.  From my perspective, many
people seem to believe (or at least hope) that Mobile IP will solve
the problems, and that it provides a reasonable bases for much
future functionality, multi-address based multi-homing included.
Quite a few people seem to share that point-of-view.  Whether that
point-of-view is foolish or technically unsound is a completely
separate question.

My suggestion is to simply make the section more clear in presenting
the two different schools of thought.  At minimum, I think that the
first paragraph needs to be split before the words "Here there are ...".

----

Most probably I don't share many of the larger concerns that Dave
has, given his much longer experience at the IETF and in the industry
than I have.  However, I do believe that this question of name spaces
is of immerce importance to the future of the Internet.

I do believe that the NSRG report contains many pieces of good
information and advice, and that it should be published as soon
as possible.  On the other hand, I also think that is is just yet
another starting point for a discussion.  As of today, we still lack
the proper forum for that discussion.  Therefore I urge the IESG and
the IAB to make sure that the forum will be formed in a timely fashion.

--Pekka Nikander