Subject: Some Comments on ID/Loc Separation Proposals

From: <[email-masked]>
Date: Wed, 12 Nov 2003 10:24:35 -0500

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.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Nov 2003 15:57:41 +0100 (CET)

> has for ID or Locator selection in ID/Loc separation protocols.

An interface ID makes no sense to me.

The concept of a stack name, where there can be one or more "stacks"
on a given host, provides the right granularity to me.
Each "stack" can presumbly have one or more network interfaces.

   Erik

---

From: Brian Haberman <[email-masked]>
Date: Thu, 13 Nov 2003 10:21:24 -0500

> Each "stack" can presumbly have one or more network interfaces.

I agree with Erik that an "interface ID" doesn't make sense.  The
question I have is a stack ID high enough?  I have been mulling
over the issue of how a security association should work here.  Is
the SA between stacks?  between apps?  between users?

There may be cases where each of the above approach is useful.

Regards,
Brian

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 13 Nov 2003 10:02:57 -0600

> (HIP, NOID and MAST) and I have some comments (attached).
...
>       with anything but simple end-to-end applications.

The earlier versions of the HIP draft contained a mechanism
where a HIT would not be a 128 bit hash of the public key but
consist of a 64-bit, hierarchically assigned prefix and a
64-bit hash.  However, I removed this from the later versions
of drafts for the following reasons:

   - the proposed mechanism was tied to DNS, and we decided
     to move all DNS specific issues into a separate draft

   - we wanted to keep HIP as simple as possible, and having
     different types of HITs seemed unnecessary, especially
     when the mechanism was optioinal

   - ID->Locator mapping is not needed for simple end-to-end
     applications, and the majority of current applications do
     not need referrals

According to the current thinking, there are at least three
different options on how to support referrals in HIP:

   1. Re-introduce some structure to the HITs, and use a
      hierarchical lookup service (e.g. reverse DNS).

   2. Introduce a flat lookup service, e.g., based on DHTs.
      This looks like a researchy issue, which is likely
      to need more research before ready for engineering.

   3. Introduce a "social contract" to HIP where each HIP
      host acts as a temporary rendezvous point for all hosts
      that it has connections with.

While 3) is not a generic ID->locator mapping solution, it
looks like quite interesting anyway.  In particular, it seems
to be able to solve the common referral case where A has
connections with both B and C, and what to give B's ID to C so
that B and  C can start to communicate directly.

Here is a more specific example on how this might work:

    1. A opens a HIP association AB with B.
    2. A opens a HIP association AC with C.

    At this point A knows the locator sets for both B and C,
    but B and C know only the locator set of A.

    3. A sends B's ID to C.
    4. C tries to open a connection to B.

    At this point C has B's id, but it does not have B's locator
    set.  However, it has a HIP association with A, and therefore
    it may try to use A as a rendezvous server for B.

    [There are a number of open problems in the description above,
     I know.  But for the moment I'd like to focus only on the idea,
     hoping that the nasty details can be solved later.]

    4. C constructs an I1 packet and sents it to A, hoping that
       A knows where B is and will forward the packet to B.
    5. A receives the I1, and according to the "social contract"
       it passes the packet to B, whose locators it knows.
    6. B receives the I1, and replies directly back to C, thereby
       initiating the actual negotiation.

I don't think that it would be useful to define such an referral
mechanism quite yet, but it would certainly be interesting to
explore its limitations and implications (given the assumption
that it can be made to work in the first place).

--Pekka Nikander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Nov 2003 21:28:00 +0100

below...

> There may be cases where each of the above approach is useful.

Indeed. And they are not mutually exclusive. However, does multi6
need to consider any SA higher than the network or transport level?

   Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 13 Nov 2003 16:20:27 -0500

> need to consider any SA higher than the network or transport level?

For the purpose of multi6, I agree with Erik that a "stack ID" is
sufficient.

Regards,
Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Nov 2003 17:21:45 -0600

Margaret,

Wnc> The use of the term "Identifier" or "ID" sweeps an important
MWnc> issue under the rug in some cases:  Is this a host ID or an
MWnc> interface ID?

or a 'stack id' or an 'endpoint id'?  and what do these mean,
precisely.

so, yes, we need to be precise and consistent in defining the term.
(Our -analysis- paper has an increasing list of terminology, with a
goal of capturing consensus definitions.  Feedback is eagerly sought.)

MWnc>     - Initial end-to-end connection set-up.
MWnc>     - Referrals.
MWnc>     - What happens when two nodes try to establish connections
MWnc>       to each other "simultaneously"
MWnc>     - How does the mechanism avoid connection hijacking?

These are really good points.  For example, I had frankly been
avoiding trying to handle referrals, but any solution needs to attend
to this requirement explicitly.

MWnc> MAST Feedback:

MWnc> Uses a control protocol between the two end-nodes to 
MWnc> exchange address information.  The current proposal is
MWnc> two sparsely defined to allow a full analysis of its
MWnc> properties.

And, of course, that is intentional.  The intent is to distinguish
between basic approach, versus the essential details of a
specification that permits real implementation.

MWnc> In particular the document does not describe
MWnc> when MAST control messages would be sent, and how the
MWnc> nodes would know when to send them.

Right. Absolutely required -- eventually -- but not the rocket science
of designing an address pool maintenance mechanism.

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

ignoring the heartbeat function that is suggested, why would not the
obvious "when something changes" rule suffice?

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

As one or another of the other wedge proposals suggests, IPSec would
run above the Mast address pool mechanism.  Hence, IPSec would only
see one "address".

MWnc>         - The PROBE message sounds (to me) similar to 
MWnc>           the old proposal to use pings to detect dead
MWnc>           gateways.  What can we learn from the problems
MWnc>           with that model that apply here?

I, too, would greatly like to hear feedback on this construct.  I've
seen a couple of comments that raised no concerns about it, but none
that offered assurance it would work ok.

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