Re: [Hipsec] Comments on the HIP-BONE draft

["Henderson, Thomas R" <[e-mail]>]

 
> > 
> > Where I think it becomes conflated, however, is when you 
> try to use the
> > overlay to forward HIP signaling traffic.   I see why you 
> are trying to
> > do this but it leads to these questions:
> 
> we had a lot of discussions in the past about this. There 
> were different 
> proposals, one of which proposed the simple use you described 
> above. The 
> conclusion was to do what HIP BONE specifies. I do not think 
> it would be 
> productive to go through the same discussions again at this point.

I am not trying to rathole things, I would just like to understand how
it is supposed to work.  Maybe if I sketched out some use cases, you
could suggest how you think it would work.  For instance, consider five
nodes A-E, and two overlays (X.org's overlay, and Q.com's overlay).
Nodes A-D belong to Q.com's overlay, and A and C to X.org's overlay.  

Peer-ID:  X.org-AID             X.org-CID   

Peer-ID:  Q.com-AID  Q.com-BID  Q.com-CID  Q.com-DID

HIT:      A-HIT      B-HIT      C-HIT      D-HIT        E-HIT

IP-addr:  A-IP       B-IP       C-IP       D-IP         E-IP

Case 1:  The overlay process belonging to Q.com on node E wants to join
overlay Q.com.  What assumptions do you make about the bootstrapping
record that Q.com's overlay process must have about well-known, stable
nodes?  Does this bootstrapping record store the tuple {Q.com-AID,
A-HIT, A-IP) or just (Q.com-AID, A-HIT)?

Case 2:  Suppose on node A, the peer protocol on node A for overlay
Q.com decides to initiate a HIP association to node C.  What name does
it use for node C?  Presumably, its peer-id "Q.com-CID".  So, it needs
to discover the C-HIT and ultimately the C-IP.  So, as part of the peer
protocol, it resolves Q.com-CID to C-HIT.  I suppose that it does this
with the existing connections that it has.  Does it also at this time
obtain C-IP?  Next, it issues a connect(HIT) socket call.  What happens
next?  There is an outbound I1 to a HIT.  Does the I1 go to the HIP
routing layer, or does the HIP process try to do a DNS/DHT lookup, or
both?  If there are no such records, how does the I1 propagate through
the Q.com overlay, which is not routing HITs but Peer-IDs?  If you
suggest, as below, that Q.com's overlay name is stored in the I1, how
does this "Q.com" get passed through the socket API so that HIP knows
that the process that used the socket API to connect(HIT) was associated
with Q.com?  Or is the native socket API not involved in this framework?

Suppose a HIP association is built between node A and node C, based on
the Q.com peer protocol.  Is this association exported to overlay X.org?
If so, suppose A later leaves Q.com overlay, but stays on X.org overlay.
Does the HIP association from A to C persist?  Are HIP records inserted
into the HIP routing table by a particular peer protocol "owned" by that
protocol, and must be removed by that protocol (just as IP routes are
tagged by the routing protocols that insert them into the FIB)?

Case 3:  the stack on Node A is asked to open a session to F-HIT.  It
doesn't know this yet, but F-HIT is not a known HIT in any of the
overlays that it belongs to.  What happens?

> 
> > 1) the overlay may stitch together addressing realms that 
> have no hope
> > of supporting end-to-end HIP associations between them.  
> For instance,
> > this simple topology:
> > 
> > node A <--------Ipv4 network -----> node B <--------Ipv6 network
> > ---------> node C
> > 
> > The overlay may route the I1 from node A to node C and R1 
> back, but no
> > HIP association between A and C can actually be formed.
> 
> This is not a problem specific to the use of HIP in the 
> overlay. It is a 
> general problem of the overlay, even if it was not using HIP. If no 
> direct connections can be formed between nodes in an overlay, the 
> overlay will most likely keep on routing stuff through the overlay.

It depends on the type of overlay, whether the overlay allows "cut
through" forwarding like you are proposing or whether data is forwarded
hop-by-hop at the overlay layer.  But HIP requires the end-to-end
association-- you can't just terminate it hop-by-hop (unless perhaps you
are using HIP DATA packets).

> 
> > 2) what if node B above belongs to multiple other HIP-based 
> overlays?
> > How does it know on which overlay to forward the I1?
> 
> This is one of the open issues of the instance draft. RELOAD 
> has its own 
> way to identify different overlays. We need to decide how we want to 
> covey that information in an I1.

If I1s need to be extended, that is an important framework issue.

> 
> > Also, from a performance perspective, I think there may be 
> some danger
> > in abstracting the underlying topology away from a peer 
> protocol.  From
> > the peer protocol layer perspective, HIP makes every node 
> look like it
> > is "on link" whereas in fact, each node is possibly 
> different number of
> > hops away, in different administrative domains of the network, etc.
> 
> Not really. When HIP is not used, the ICE module takes care of 
> establishing those "links". The complexity of connection 
> management is 
> abstracted out even when HIP is not used.

I was thinking that some overlays (such as content delivery networks)
may want to run heuristics on IP addresses to determine network
distances. 

> 
> > To summarize, I think there is some value in defining how 
> P2PSIP-based
> > overlay could use HIP to form its links and deal with NAT, 
> mobility, and
> > multihoming.  However, before allowing RELOAD nodes to 
> perform the HIP
> > distributed rendezvous service, I would first define:
> > 1) how the system works in the case where the enrollment 
> server chooses
> > PeerIds that are not HITs
> 
> The framework already says this is possible... and the instance draft 
> will need to define how that is done for RELOAD, of course.
> 
> > 2) how two such independent overlays (run by different 
> organizations)
> > could operate on the same node, and how the node would ensure that
> > messages got onto the right overlays
> 
> This will also need to be defined by the instance draft... in 
> any case, 
> I agree with you that the framework needs to talk more about this (it 
> does not discuss this issue right now).
> 
> > The above can all be done by assuming that HIP rendezvous 
> is done in the
> > underlay, not overlay.  As a final step, one might consider 
> whether one
> > of these overlays itself could be leveraged to forward HIP 
> traffic.  If
> > all of this holds together, then I think we might have a framework
> > document that completes the charter item.
> 
> You make valid points above. After addressing your points in a new 
> revision of the draft (possibly after more list discussions), I think 
> the best way to proceed will be to progress the framework and the 
> instance draft together so that they can be reviewed at the 
> same time. 
> In that way, it will be clearer for the reviewers.

I agree that it may be better to progress these together.

> 
> > As an editorial note, I also would recommend skipping 
> section 2 because
> > RFC 4423 and other documents are available to provide HIP tutorials.
> 
> This is the typical comment we often get from HIP experts :o)... 
> however, application-layer people really appreciated that part of the 
> draft when they read it. Before writing it, we sent them all types of 
> links to HIP documents and tutorials but they did not find 
> them useful. 
> I actually believe that having that type of tutorial material in the 
> draft makes it much easier for application-layer people to understand 
> the draft (and eventually decide to use it). So, I strongly 
> suggest to 
> keep it in the draft.

OK, as I said, it was just an editorial suggestion.

Regards,
Tom