Re: [P2PSIP] New draft: HIP BONE

[Pekka Nikander <[e-mail]>]

>> In general, we tried to clarify the proposed relationship between  
>> HIP and the peer protocols by the architectural analogy [...],  
>> where we state that HIP acts in a role similar to IP [...] and the  
>> peer protocols in a role similar to routing protocols [...].

<snip>

>> A better way to state what we propose might be "Nodes  
>> participating into an overlay forward I1 packets in a hop-by-hop  
>> fashion over the HIP BONE using the  forwarding tables, which in  
>> turn are built based on the routing table constructed by the peer  
>> protocol for the  overlay."

<snip>

>> [...] my understanding is that a forwarding node would look at the  
>> next hop ORCHID based on the forwarding table, and then pass the  
>> packet to the HIP implementation.  The HIP implementation would  
>> then detect if there is an active HIP association towards that  
>> ORCHID.  If there is, the I1 packet is passed over that HIP  
>> association.  If there are not but there is a valid locator  
>> associated with the next hop ORCHID, then the I1 packet is passed  
>> over IP using the locator.

<snip>

>> Further note that there are at least two choices of what to use as  
>> index to the forwarding table look up:
>> 1) one can use the Peer ID, presumably carried in a new HIP  
>> parameter in the I1 packet, or
>> 2) one can use the ORCHID, carried in the source HIT field in the  
>> I1 packet.

<snip>

> If I understand correctly, you are suggesting that there would be  
> HIP forwarding table(s) with next hop ORCHIDs.  There may be next  
> hop IP addresses or active HIP tunnels corresponding to each next  
> hop ORCHID.

Yes, thought I'd prefer to say "next hop locators" instead of "next  
hop IP addresses", since I could imagine such locators also to have  
other forms, such as UDP tunnels for HIP signalling traffic or such.

> There may be multiple peer protocols populating this HIP table.

I didn't really think about that.  Hence, here we go forward from my  
previous thinking.

> Then, it seems to be the case that there must be multiple HIP  
> forwarding tables, one for each overlay.  [...]  Furthermore, nodes  
> in a DHT will be responsible for portions of the space and these  
> portions will overlap from overlay to overlay.

Yes, you are right.  Furthermore, the set of nodes in each overlay  
may be partially disjoint.

> If so, then there is a requirement to be able to look up the right  
> forwarding table from an I1, which I think you are suggesting above  
> in the last paragraph.

Well, as far as I can see, that depends on the assumptions on the  
number of partially overlapping overlays.  If that number is small,  
the I could imagine that instead of picking just one forwarding table  
to use, one could simply replicate the I1 to all overlays in the case  
the right overlay is not know.  However, if replicating an I1, it  
would most probably make sense to tag it with the names of all  
overlays to which it is being sent to, or at least denote the primary  
overlay it was sent to.  But the details depend on detail  
requirements that I don't understand, e.g., what is the exact  
semantics of having multiple overlays.

> So the I1 (and probably all HIP packets) needs to carry some  
> metadata about the ORCHID type in use, either in a new parameter or  
> embedded in a certificate.

Right; that makes sense once a HIP signalling packet is being  
forwarded within an overlay.  I think a new parameter makes more  
sense, as it would most probably be more efficient to handle that.   
For other reasons, I was thinking of a parameter that would carry an  
ORCHID Context ID.

> Basically, there needs to be a new namespace in use at the HIP  
> forwarding layer -- the namespace
> uniquely identifying overlays.  This could perhaps be the ORCHID  
> Context ID.

I concur.

> Another related question I have is whether you think the legacy  
> application API (based on sockets) would work anymore with ORCHIDs,  
> because if you get a raw ORCHID across the sockets API, you can't  
> tell by inspecting the ORCHID which overlay it belongs to, because  
> the context ID is not visible.

Hmm.  The situation may be worse.  The case may well be that the app  
has no information at all about the overlays, so that it may not even  
be possible to tell the right overlay at all.  In such a case my  
suggestion above, i.e., to send the packet to all overlays  
simultaneously, might make sense.

> It seems that you would need to pass metadata about the ORCHID  
> across the sockets API, so that the node knows
> which ORCHID-based overlay that it belongs to, or else you need to  
> use LSIs even in the IPv6 case (as suggested by Philip Matthews at  
> the Vancouver meeting).

As far as I can see, that depends on the requirements.  If the  
requirement is simply create a secured connection to the peer if  
reachable at all, then IMHO it would make sense to try all of the  
overlays at the same time.  As long as the number of overlays is  
relatively small, the amount of additional traffic will be quite  
small, and originate from the source, i.e., is not replicated in the  
network.

--Pekka


_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip