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

[Ari Keranen <[e-mail]>]

Hi Tom,

Henderson, Thomas R wrote:
>>> 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

Many of the details depend on the particular instance specification, and 
the RELOAD instance spec is still very much work-in-progress, so how 
things are done is likely to evolve from current situation. Anyway, 
here's how I see these use cases could work.

> 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)?

Especially bootstrapping is a peer protocol dependent feature (as noted 
in Sections 3.1 and 3.4 of the HIP BONE draft), but in general, you need 
at minimum an IP address (+ possibly port) of an overlay node to contact 
and some overlay identifier (not necessary a peer ID) used to tell the 
contacted node which overlay you want to join. Adding also HIT to the 
tuple increases security, but is not mandatory if the overlay uses an 
enrollment server that gives certificates for the HITs and the nodes can 
use the certificates to prove that they truly belong to that overlay.

> 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?

If Peer-IDs are not HITs, the peer protocol uses "Q.com-CID" as the peer 
name for node C. If this is the case, presumably there is a mapping 
(using some transformation) between Peer ID and HIT, so that there is no 
need for any discovery step.

There is no need to query for C-IP in the overlay since the HIP base 
exchange is done via the overlay and the C-IP (or, the "best" C-IP) is 
discovered using ICE as defined in the NAT traversal draft. And the BeX 
is done using existing overlay connections.

I1 (and the rest of the BeX) is routed using the overlay routing table 
constructed by the overlay protocol, so there is no additional (DNS/DHT) 
lookup for this. If there is no mapping from HIT to Peer ID, we may need 
to convey also the Peer IDs in the HIP packets.

The interaction with peer protocol is likely to require more features 
than what the current HIP native socket API can provide, but at least my 
view on this is that the peer protocol and HIP daemon are integrated so 
that they don't need to use the socket API for sharing the routing table 
(e.g., they are run in the same process, or they use IPC).

> 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?

IMO, no. The different overlays likely have different finger tables 
(i.e., peer protocol connections between peers) and thus it would be 
unlikely (at least in a big network) that they would share connections. 
Also, the HITs for different overlays are likely to be different. This 
could be considered as an optimization though.

> 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)?

Whether a HIP association persists, would depend on the implementation 
of the optimization. If the association was created for something else 
than P2P protocol traffic (e.g., SIP call), it should persist as long as 
it is used.

The routing table records would be overlay instance specific (even if 
they use the same protocol) so they would be added and removed by the 
same overlay process.

> 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?

The overlay tries to route I1 to F-HIT but when it fails to do so, the 
node that detects this (i.e., the node that is responsible for the part 
of the overlay where F would be) responds with an error message. The 
MESSAGE_NOT_RELAYED notify packet type could be used for this, but I 
think the behavior is HIP BONE instance specification specific.

>>> 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).

HIP DATA packets could be used for this. Also, it is possible to use a 
TURN server with IPv4-IPv6 translation. If a TURN server implementing 
the turn-ipv6 draft is used, ICE would take care of this.

>>> 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.

The RELOAD HIP BONE instance spec defines OVERLAY_ID attribute for this 
purpose. The (next version of) HIP BONE draft will define a generic 
format for the parameter and instance specs define how it is encoded for 
each specific protocol. All HIP overlay messages should have this 
parameter to indicate which overlay they belong to.

I understand that we want to keep I1 as simple as possible to prevent 
DoS attacks, but this parameter would not create any state in the 
receiving or forwarding node and it would be trivial to process, so I 
don't think it is a problem to have it there.

>>> 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. 

I guess you're referring to the IP addresses of the hosts that you have 
a direct HIP association with (since even without HIP you don't know the 
addresses of the intermediate nodes forwarding the messages in the 
overlay). For such nodes, I assume one can ask the current IP address 
using the native HIP API and SHIM_LOC_PEER_SEND (or SHIM_LOCLIST_PEER?) 
socket option. That said, because of TURN servers and other relays, this 
may not be really a good idea.

>>> 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.

With RELOAD, the enrollment server can generate Peer IDs that have 
ORCHID prefix either by generating the key pair or by generating random 
ID and using certificates.

>>> 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).

This will be addressed with the generic OVERLAY_ID in the framework draft.


Cheers,
Ari