Some Comments on ID/Loc Separation Proposals

[<Margaret.Wasserman@nokia.com>]

I have been analyzing a few of the proposal for ID/Loc separation
(HIP, NOID and MAST) and I have some comments (attached).  
Unfortunately, I won't be in most of the multi6 meeting today 
(I may pop in and out), but please consider this e-mail as input 
to your discussion.

Sorry for the cryptic nature of some of these comments.  If there
are any questions, let me know.  I may try to write-up something
more detailed later.

Margaret

General Thoughts:

The combination of ID/Loc in IP (v4 and v6) is an architectural
feature with good and bad trade-offs.  It can be viewed as an
ID/Loc system with: (1) Very efficient ID -> Loc mapping (they
are the same), (2) An inflexible association between a single 
ID and a specific Locator (they are the same).  Property #1 
allows convenient, high performance referrals.  Property #2 
causes difficulties for mobility, multihoming, etc.

The use of the term "Identifier" or "ID" sweeps an important
issue under the rug in some cases:  Is this a host ID or an
interface ID?  The current IP (v4 and v6) architecture uses 
interface IDs.  IPv4 implementations are generally constrained 
to one ID per interface, while IPv6 supports multiple IDs per 
interface.  ID selection is linked to outbound interface
selection -- it is still unclear to me what implications this
has for ID or Locator selection in ID/Loc separation protocols.

---

Some things to consider for proposals:

What are the mechanisms to support (and the costs of):

    - Initial end-to-end connection set-up.

    - Referrals.  The question I ask is: Could this mechanism
      support FTP PASV mode -- I know no one uses it, but it is 
      a simple, well-understood referral.  If a mechanism won't
      support FTP PASV, then it won't support any referral-based
      application.

    - What happens when two nodes try to establish connections
      to each other "simultaneously" (where "simultaneously"
      is defined to mean "during each others' connection set-up
      window").

    - How does the mechanism avoid connection hijacking?

Of course, there are many other interesting questions.

---

NOID Feedback:

Interesting proposal that offers at least some support for
referrals and offers a zero-cost mapping from an ID to a 
locator, by using one of the available locators as the ID.
Supports multihoming and planned renumbering, but not 
roaming/mobility.

Specific comments/issues:

    - NOID is not compatible with local addressing or 
      "two-faced" DNS.  Relies on consistent information
      being returned from the DNS at both ends.

    - NOID happens below frag/reassm, but may add 8
      bytes to the packet length.  ??

    - NOID may have issues when two hosts both attempt
      to open a connection to the other within the NOID
      establishment phase (which may last for a while,
      as it involves two DNS lookups, etc.).  If I
      am modeling this correctly, if NodeA is currently
      in the process of establishing a NOID connection
      to Node B (we have the state set-up on NodeA, but
      not on NodeB), NodeB's attempts to open a connection
      to NodeA will be discarded by NodeA because they
      don't contain the correct FlowID.  Am I right?
      If so, is this a problem?

    - If the topological information in an AID is no 
      longer valid to reach the node, a referral will
      require two DNS lookups (reverse lookup, followed
      by forward lookup) before the new connection can
      be established.  This represents a significant 
      change to the speed/performance of referrals.

---

MAST Feedback:

Uses a control protocol between the two end-nodes to 
exchange address information.  The current proposal is
two sparsely defined to allow a full analysis of its
properties.  In particular the document does not describe
when MAST control messages would be sent, and how the
nodes would know when to send them.

Specific Comments/Issues:

    - This proposal seems, to me, to sweep the entire
      problem under the rug of this mostly-unspecified
      control protocol. 

        - How do the end-points know when they need to 
          send SET operations to update the locators 
          being used on the ends of this connection?

        - The draft suggests using IPsec to secure the
          control connection, but IPsec doesn't support
          changing end-point addresses.

        - The PROBE message sounds (to me) similar to 
          the old proposal to use pings to detect dead
          gateways.  What can we learn from the problems
          with that model that apply here?  I have stored
          my knowledge of the issues here in long-term
          storage, and I'm still waiting to retrieve it.
          But, there are some serious issues with active
          keepalive mechanisms that we should probably
          consider here.

---

HIP Feedback

Very well-developed proposal for end-to-end ID/Loc separation.
No ID->Locator mapping mechanism, so no support for referrals.

Specific Feedback:

    - The lack of any ID->Locator mapping mechanism is a 
      blocking problem for using HIP (as currently defined)
      with anything but simple end-to-end applications.