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

["wangjun" <[e-mail]>]

 Hi Gonzalo,

About the HIP ID and Peer ID, My understandings:
1) The HIP Bone is a p2p overlay, each other between peers  talk p2p
protocol, HIP can be encapsulated in a p2p payload..
2)Every HIP host is a p2p client or a p2p agnostic terminal, and attach to
arbitrary peer(s) of the overlay; they register their locator-HIP_ID
bindings into the HIP bone.
So the HIP Hosts may be designated  a peer ID, but  it's really not
mandated. 

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表
Gonzalo Camarillo
发送时间: 2009年7月21日 19:04
收件人: Henderson, Thomas R
抄送: HIP
主题: [Hipsec] Comments on the HIP-BONE draft

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

_______________________________________________
Hipsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hipsec