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.
1.1 Security Considerations
...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.
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.
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.
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?
This one point has massive impact on the design choice, of course.
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.
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.
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