Re: [Hipsec] WGLC: draft-ietf-hip-bone-04

[Ari Keranen <[e-mail]>]

Hi Tom,

Thanks for the comments! Responses inline.

Henderson, Thomas R wrote:
> comments on draft-ietf-hip-bone-04:
> 
> (please see my other post suggesting that this draft include the via
> and hiccups drafts and that it add a better protocol overview
> section).

OK, we'll add some overview text to the next version.

>> 2. Terminology
>> 
>> 
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>> this document are to be interpreted as described in RFC 2119
>> [RFC2119].
> 
> This section is empty; I think that since this is intended as a
> framework document, a good terminology section is needed.

OK. I added the following:

    Overlay network:  A network built on top of another network.  In case
       of HIP BONEs, the underlaying network is an IP network and the
       overlay can be, e.g., a peer-to-peer (P2P) network.

    Peer protocol:  A protocol used by nodes in an overlay network for
       performing, e.g., data storage and retrieval or overlay
       maintenance.  HIP is used for conveying the peer protocol messages
       between the nodes in the overlay network.

    Node ID:  A value that uniquely identifies a node in an overlay
       network.  The value is not usually human-friendly, but for example
       a hash of a public key.

    Valid locator:  A Locator (as defined in [RFC5206]; usually an IP
       address or an address and a port number) that a host is known to
       be reachable at, for example, because there is an active HIP
       association with the host.

Did you have something else specific in mind that should be added here?

>> 3. Background on HIP
>> 
> 
> I previously commented (earlier version of this draft) that it might
> be easier to refer readers to the HIP arch or base RFCs, but if you
> want to keep it here, suggest to move it to an appendix since it is
> not normative material.

I think it's good to have this early in the document since it provides 
the needed background for P2P (and other non-HIP) people about HIP. If 
it were in the appendix, or just references, likely it would be never 
actually read and there would be plenty of misconceptions about the rest 
of the document.

>> 4. The HIP BONE Framework
>> 
>> 
>> An overlay typically requires three types of operations:
>> 
>> o  overlay maintenance. o  data storage and retrieval. o
>> connection management.
> 
> Not all overlays (e.g. pure routing overlays) require data storage
> and retrieval.  Suggest to say that "Many overlays typically
> require..."

Makes sense; fixed this.

>> 4.1. Peer ID Assignment and Bootstrap
>> 
>> Nodes in an overlay are primarily identified by their Peer IDs.
> 
> This terminology "Peer ID" seems very RELOAD-centric.  How about the
> more general "Node ID", or talk about the distinction between peers
> and clients, such as in RELOAD?

Good point. Changed all the occurrences of Peer ID into Node ID.

>> If the overlay network or peer protocol has more specific 
>> requirements for the Peer ID value that prevent using HITs derived 
>> from public keys, each host will need a certificate (e.g., in their
>>  HIP base exchanges) provided by the enrollment server to prove
>> that they are authorized to use a particular identifier in the
>> overlay.
> 
> Note:  this is what I thought was missing in the instance
> specification.

This will be clarified in the RELOAD instance spec.

>> Bootstrap issues such as how to locate an enrollment or a bootstrap
>>  server belong to the peer protocol.
> 
> This seems to be a placeholder sentence for future text.  At the very
> least, this framework draft should deal with the bootstrap issue of
> how to forward I1s along the HIP BONE when a node first joins the
> overlay.

I think this is really an instance specific issue and there's not much 
one can say in the architecture document.

>> Note that the border between HIP BONE instance specification and a 
>> peer protocol specifications is blurry.
> 
> I agree with this observation; the current drafts are basically
> written from the standpoint of RELOAD and details about e.g.
> interaction between HIP and topology plugin are fuzzy.  However, it
> seems to me that to be useful as a general purpose framework for
> arbitrary peer protocols, crisper APIs would need to be specified.

I think that how, e.g., the topology plugin and HIP daemon actually 
interact are implementation details, and as discussed in the instance 
spec thread, I think these documents are not the right place for 
defining APIs or implementation details.

>> 5. Advantages of Using HIP BONE
>> 
>> Using HIP BONE, as opposed to a peer protocol, to perform
>> connection management in an overlay has a set of advantages.  HIP
>> BONE can be used by any peer protocol.  This keeps each peer
>> protocol from defining primitives needed for connection management
>> (e.g., primitives to establish connections and to tunnel messages
>> through the overlay) and NAT traversal.  Having this functionality
>> at a lower layer allows multiple upper-layer protocols to take
>> advantage of it.
> 
> This section probably could be moved to an introduction, explaining
> why we are going through all of the trouble to support these
> overlays.

Makes sense. I moved this to be part of the intro section.

>> 7.  Architectural Considerations
> 
> Note, Section 7 is probably more important as a first section, not
> the last in the draft.

I'll see what we can do with this.

>> Architecturally, routing tables are located between the peer
>> protocol and HIP, as shown in Figure 7.
> 
> This is important architectural discussion.  I had a few questions
> here:
> 
> 1) can a HIP packet from one overlay consult the routing table built
> in another overlay?

I'd say that, by default, no. HIP BONE packets are overlay network 
specific (identified with the OVERLAY_ID), so they should not cross 
overlay borders. However, I think we shouldn't forbid that either if 
someone want to specify something for this.

> 2) if HIP receives a locally originated packet with no OVERLAY_ID,
> and it has one or more peer protocols running, how does it decide
> where to route the packet?  I assume that all locally originated
> packets will somehow have their overlay identifier specified, but it
> would be helpful to state this somewhere.  For example, if it were
> RELOAD, RELOAD may have special APIs allowing it to identify the
> overlay ID that all locally originated packets from the RELOAD
> instance should use.  In addition, if HIP on that node was providing
> traditional HIP services to legacy applications, such (legacy
> applications) outbound packets would use rendezvous/relay servers as
> usual.

This is mostly an API issue, but one could configure his HIP 
implementation so that if there is no locator for a HIT, it is 
automatically sent to a certain overlay. Actually, we could define a 
"rendezvous usage" using RELOAD for this in the RELOAD instance spec.


Cheers,
Ari