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

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

Hi Ari, some responses inline below.

> -----Original Message-----
> From: Ari Keranen [mailto:[e-mail]] 
> Sent: Tuesday, July 28, 2009 4:46 AM
> To: Henderson, Thomas R
> Cc: Gonzalo Camarillo; HIP
> Subject: Re: [Hipsec] Comments on the HIP-BONE draft
> 
> 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.

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.

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

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

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

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

Probably not in the media-stream, RELOAD use case.

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

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

Regards,
Tom