[Hipsec] Comments on the HIP-BONE draft

[Gonzalo Camarillo <[e-mail]>]

Hi Tom,

thanks for you comments. Answers inline:

>> http://tools.ietf.org/id/draft-ietf-hip-bone-02.txt
> 
> I remain very uneasy about the above draft, which I think is not very
> clear and skirts over some hard issues.

we have moved a few things to the RELOAD instance draft, which is still 
very much work in progress (as you can see if you read the draft). Some 
issues will be addressed there. Of course, any general issues belonging 
to the framework should be addresses in this document.

> The document tries to provide a generalized framework for HIP-based
> overlays, but it is not clear how it will work when there are multiple
> peer protocols (multiple overlays) and when the peer IDs are not the
> same as the node IDs.  The specific instance draft does not handle these
> issues; it assumes that the peer ID is the ORCHID (which was not
> acceptable to some in the P2PSIP WG due to possible chosen ID attacks),
> and is, of course, only one instance.

The framework does not assume that Peer IDs are used at the HIP level. 
It just tells you that depending on the Peer IDs used in your overlay, 
you need to convert them to something HIP can use. Originally, we 
thought of having a draft that described that conversion in general (you 
yourself was working on a similar draft at some point) but now we tend 
to think that this type of conversion is better defined in the instance 
specs.

Regarding the RELOAD instance draft, this is one of the open issues. 
That is, whether we can use RELOAD peer IDs directly or if we need some 
type of transformation (ORCHIDs have a prefix; therefore, there are less 
than 128 bits available).

> In general, I recommend not trying to complete work on a framework for
> multiple overlays until there is an example of at least how two
> independent overlays (perhaps with different peer protocols and
> different peer ID structures) coexists on some of the same nodes, and
> the peer IDs are not HITs.  

RELOAD has its own way of identifying particular overlays. Other peer 
protocols may have different ways. Therefore, this does not seem to be a 
framework issue. Each instance draft would need to describe it 
separately... in any case, I agree it is worthwhile talking a bit more 
about this in the framework.

> The draft states:
> "Since HIP needs
> ORCHIDs (and not any type of Peer ID) to work, hosts in the overlay
> will transform their Peer IDs into ORCHIDs, for example, by taking a
> hash of the Peer IDs or taking a hash of the Peer ID and the public
> key."
> 
> I don't see how this would work since for an ORCHID to be used as a HIT,
> it must hash a public key.

The text wants to indicate that conversions between Peer IDs and ORCHIDs 
are up to each particular instance specification. I agree removing the 
examples may be a good idea so that they do not mislead readers.

> It is not clear from the document what IDs are being routed if the peer
> ID is not the same as the HIT.  I think the answer is that it is the
> peer IDs that are being routed, and HIP is just providing the links
> between the peer IDs.

Yes, routing tables contain Peer IDs.

> It may be that the peer IDs are the same as HITs
> in some instances, but it should be architecturally clear that transport
> connections are being terminated at each hop in the overlay.

Yes, transport connections are between hops in the overlay, as usual.

> If the document were to describe an overlay architecture where you
> recommend to the peer protocols "Use HITs like you would otherwise use
> IP addresses, and HIP will take care of the rest of the ugly business of
> NAT traversal, mobility, and multihoming," then it would seem to be
> relatively straightforward, so long as HIP took it upon itself with no
> dependency on the peer protocol to do anything for it.
> 
> 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.

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

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

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

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

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

Thanks,

Gonzalo