Re: [Hipsec] Overlay work: status and request for input

[Gonzalo Camarillo <[e-mail]>]

Hi Tom,

thanks for your feedback. I would like to keep this thread focused on 
our milestones. I will answer your questions about the HIP BONE draft in 
a different thread.

Thanks,

Gonzalo

Henderson, Thomas R wrote:
> Gonzalo, below I've expressed my (somewhat negative, sorry) opinions on
> your questions: 
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[e-mail]] 
>> Sent: Monday, July 20, 2009 3:33 AM
>> To: HIP
>> Subject: [Hipsec] Overlay work: status and request for input
>>
>> Folks,
>>
>> here you have a summary of the status of the overlay work.
>> Additionally, we have some questions for the WG related to our
>> milestones and their related charter items. Your input on those
>> questions is very welcome.
>>
>> 1) We have the following milestone:
>>
>> "Specify a framework to build HIP-based overlays. This framework will
>> describe how HIP can perform some of the tasks needed to build an
>> overlay and how technologies developed somewhere else (e.g., a peer
>> protocol developed in the P2PSIP WG) can complement HIP by performing
>> the tasks HIP was not designed to perform."
>>
>> The WG item for this milestone is the following draft, which should be
>> ready for WGLC:
>>
>> 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.
> 
> 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.
> 
> 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.  
> 
> 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.
> 
> 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.  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.
> 
> 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:
> 
> 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.
> 
> 2) what if node B above belongs to multiple other HIP-based overlays?
> How does it know on which overlay to forward the 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.
> 
> 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
> 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
> 
> 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.
> 
> As an editorial note, I also would recommend skipping section 2 because
> RFC 4423 and other documents are available to provide HIP tutorials.
> 
>> This draft defines a high-level framework to build HIP-based overlays.
>> Additionally, its previous version defined how to build a HIP-based
>> overlay using RELOAD. The authors have chosen to move this 
>> definition to
>> a separate document because while the high-level framework is
>> informational in nature, the definition makes use of 
>> normative language.
>> The resulting document is the draft below. We would like to ask the WG
>> if it is OK to split our current milestone in two so that 
>> they cover the
>> high-level framework and the definition in separate documents.
>>
>> http://tools.ietf.org/internet-drafts/draft-keranen-hip-reload
> -instance-00.txt
>> Additionally, we would like to ask the WG if we should take the draft
>> above as the WG item associated to the milestone for the definition.
> 
> I think it is good to split framework from instance documents.  I might
> suggest that Delay Tolerant Networks (DTN) be another instance document.
> 
> 
>> 2) We have the following milestone:
>>
>> "Specify how to carry upper-layer data over specified HIP
>> packets. These include some of the existing HIP packets and possibly
>> new HIP packets (e.g., a HIP packet that occurs outside a HIP base
>> exchange)."
>>
>> We still do not have a WG item for it but the following draft has been
>> around for some time. We would like to ask the WG if we 
>> should adopt the
>> following draft as the WG item for this milestone.
>>
>> http://tools.ietf.org/internet-drafts/draft-nikander-hip-hiccu
> ps-02.txt
>> Revision 02 of the draft above is identical to 01 (the only 
>> changes are
>> the date and the new copyright). The authors intend to address the
>> comments received on the list shortly.
> 
> In January I made a number of comments that the semantics for this new
> service were not very clear.  I still would like to understand the
> service semantics and requirements; could they be stated clearly
> somewhere?  I am not really questioning that such a need for HIP DATA
> might exist, but it seems premature to specify message syntax for these
> packets when there is no implementation that implements it and no API
> for HIP-aware applications to access this service.  How can we build
> interoperable implementations without this?
> 
>> 3) In order to be able to support the functionality provided 
>> by RELOAD,
>> HIP needs to support multi-hop routing. Instead of specifying 
>> it in the
>> HIP BONE draft, having a separate draft seem to make more sense given
>> that this functionality has a more general applicability than 
>> overlays.
>> We would like to ask the WG if we should spin off a new milestone from
>> our original milestone for overlays that covers multihop 
>> routing in HIP.
>>
>> The following draft takes a stab at specifying multihop 
>> routing in HIP.
>> We would like to ask the WG if we should adopt it as a WG item for the
>> milestone above (assuming we decide to create the milestone).
>>
>> http://tools.ietf.org/internet-drafts/draft-camarillo-hip-via-00.txt
> 
> I'm fine with your suggestion. 
> 
>> 4) We have the following milestone:
>>
>> "Specify how to generate ORCHIDs from other node identifiers
>> including both cryptographic ones (leading to cryptographic
>> delegation) and non-cryptographic ones (e.g., identifiers defined by a
>> peer protocol)."
>>
>> When we created that milestone, we expected to have a generic 
>> mechanism
>> to transform node IDs into ORCHIDs. However, at this point, it seems
>> that such transformation will be done in different ways 
>> depending on the
>> peer protocol used in a particular overlay. For example, the instance
>> specification for RELOAD draft defines such transformation for RELOAD
>> peer identifiers. The fact that nobody has submitted a draft for that
>> milestone seems to confirm the previous impression. We would 
>> like to ask
>> the WG if we should remove that milestone from our charter.
>>
> 
> (note:  the charter seems to now be missing from
> http://www.ietf.org/dyn/wg/charter/hip-charter.html)
> 
> RFC4843 already specifies how to generate ORCHIDs from other node
> identifiers.  If they are unique, they can serve as the Input in the
> ORCHID algorithm.  But they cannot be used as HITs.  Was that the intent
> of the charter item, to allow non-HIT ORCHIDs to serve the role as HITs
> in the protocol?  (See above discussion about overlays)
> 
> I think the interesting question is how to bind other node identifiers
> that are not public keys to HIP's public keys.  I have been assuming
> that certificates and HIP-CERT are the answer there.  At least, that has
> been the direction that we have been interested in at Boeing.
> 
> - Tom