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

[Pekka Nikander <[e-mail]>]

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.

> 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