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

[Ari Keranen <[e-mail]>]

Henderson, Thomas R wrote:
>> -----Original Message-----
>> From: Ari Keranen [mailto:[e-mail]] 
>> Henderson, Thomas R wrote:
>>> 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.
> 
> This is perhaps my main concern.  I do not understand how you can form
> HITs from Peer IDs, in general, unless the Peer IDs are HITs or public
> keys themselves.  I see how you can bind a HIT to a Peer ID using a
> certificate, but that is not the same.
> 

The easiest solution is to require/recommend that Peer IDs are created 
just like HITs. This should be possible, with minor modifications, at 
least with the peer protocols and algorithms we have been looking into 
so far. However, to be future proof, I agree that a general mechanism 
would be useful.

I think we should consider creating "HITs" (or ORCHIDs) that are not 
hashes of cryptographic keys (and maybe call them ORIDs :). Is there 
some technical reason that prevents you from having an arbitrary, but 
random enough, ID after the ORCHID prefix that is not based on a public 
key if you include anyway certificates and host identities as HIP 
parameters in the HIP base exchange?

Another option would be to leave this out of scope of the current 
documents and define such transformation when there is a protocol or 
algorithm that really needs one. And we can fall back to having Peer IDs 
in HIP parameters and route based on those for overlays whose IDs can't 
be transformed into HITs.

>> There is no need to query for C-IP in the overlay since the HIP base 
>> exchange is done via the overlay 
> 
> which overlay?  Are you assuming that the routing table has an explicit
> entry for an overlay next hop for C?  If there is no entry for C-HIT, is
> the I1 sent on both overlays?
> 

Q.com overlay if the node A is (in that context) initiating connection 
to node C at overlay Q.com. The next hop is taken from Q.com overlay's 
routing table so there is no need for explicit entry for C-HIT. Perhaps 
it would be clearer to talk about "application on node A using overlay 
Q.com" instead of "node A". That is, when one initiates a connection 
(BeX), one tells which overlay that connection belongs to.

Once again, it could be possible for the application or node to try to 
contact another node in all the overlays, but this would be an 
additional optimization or a feature. If we want, e.g., legacy 
applications to be able to use just the socket API for initiating 
connections over P2P overlays, one would need to configure to which 
overlay(s) this kind of messages should be sent to.

>> 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 
> 
> Ah, OK, perhaps this suggests a misunderstanding on my part about what
> you are trying to define.  I was not assuming that HIP and peer protocol
> were integrated, but that HIP was providing a service to different peer
> protocols, so that other WGs like P2PSIP could build an overlay on the
> service offered by a HIP BONE.  Maybe this point could be clarified in
> the next draft version.
> 

OK, I agree that it would make sense to clarify this.

>> 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 peer protocol and HIP are integrated, offering a specialized API,
> then I think my questions about how information is shared between
> overlays are not so relevant.

OK.

>>>>> 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. 
> 
> Probably not in the media-stream, RELOAD use case.
> 

Right, the HIP DATA packets are not really suitable for media but should 
be used only/mainly for the signaling. Although I can think of some use 
cases where even some sort of "media" (say, IM if there are no media 
relays and firewalls prevent direct connectivity) could go via an 
overlay, so I would not make this a MUST NOT, but rather a NOT RECOMMENDED.

>> 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.
> 
> OK
> 
>>>>> 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.
> 
> Again, I think my concern here is based on my assumption that HIP is
> offering a service to a peer protocol, and may be abstracting away
> details from it that it may care about.  However, your comments above
> suggest that since the peer protocol and HIP are part of an integrated
> design, so maybe this is less of a concern.  Mainly, the concern I was
> raising was along the same lines of spoofing HITs for IP addresses to
> applications that may really want the IP addresses.
> 

OK. In that sense the design we have in mind should be able to expose 
enough details for the peer protocols.

>>>>> 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.
>>
> 
> OK, I will wait to see that.

The next version should contain that, but at least currently it's just a 
general version (can have any length) of the OVERLAY_ID in the RELOAD 
instance spec.


Cheers,
Ari