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

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

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