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

[Ari Keranen <[e-mail]>]

[e-mail] wrote:
>    That means every HIP Host must be a p2p peer, and the deployment 
> model is same  as the P2P applications such as skype? In such a 
> scenario,only HIP hosts can communicate each other, so what about the 
> interworking solution between HIP and non-HIP host?

Every HIP host that is part of the overlay (i.e., routing messages and 
storing data there) would be a peer. Interworking with non-HIP hosts has 
not been in the scope of HIP-BONE so far.

>   I prefer that HIP bone acts as a distributed service system and every 
> ordinary HIP host is just a p2p client, and combining with the mechnisms 
> described in draft-melen-hip-proxy, the generic interworking solution 
> can be provided to any hip and non-hip hosts.

That's an interesting idea. What kind of interworking did you have in mind?


Cheers,
Ari


> [e-mail] 写于 2009-07-28 13:53:39:
> 
>  > Hi,
>  >
>  > wangjun wrote:
>  > > 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..
>  >
>  > Actually, the current idea is that peer protocol messages would be
>  > encapsulated in HIP messages to keep the protocol layering consistent.
>  >
>  > > 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.
>  >
>  > The HIP hosts don't actually need to register locators to the overlay
>  > since the HIP base exchange is done via the overlay and the (best)
>  > locator is discovered using ICE (see [1] but replace HIP relay server
>  > with a HIP BONE overlay).
>  >
>  > > So the HIP Hosts may be designated  a peer ID, but  it's really not
>  > > mandated.
>  >
>  > HIP hosts have peer IDs when they are part of a HIP BONE overlay, but
>  > preferably the peer ID is a one of the HITs of the host.
>  >
>  >
>  > Cheers,
>  > Ari
>  >
>  > [1] http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-08
>  >
>  > > -----邮件原件-----
>  > > 发件人: [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 
> thinkthat 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 
> needsome 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 
> overlaywill 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
>  > >
>  > > _______________________________________________
>  > > Hipsec mailing list
>  > > [e-mail]
>  > > https://www.ietf.org/mailman/listinfo/hipsec
>  >
>  > _______________________________________________
>  > Hipsec mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/hipsec
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.