Subject: Re: [Hipsec] WGLC: HIP-based overlays

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 22 Feb 2010 10:45:15 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Tuesday, January 26, 2010 7:19 AM
> To: HIP
> Subject: [Hipsec] WGLC: HIP-based overlays
>
> Folks,
>
> we would like to WGLC the set of specifications that describe how to
> build HIP-based overlays. The documents under WGLC are the following:
>
> http://tools.ietf.org/html/draft-ietf-hip-bone-04
> http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00
> http://tools.ietf.org/html/draft-ietf-hip-hiccups-01
> http://tools.ietf.org/html/draft-ietf-hip-via-00
>
> This WGLC will end on February 23rd. Please, send your
> comments to this
> list.
>

Gonzalo,
Below are my WGLC comments on this set of drafts.  I will send some detailed comments on each draft in subsequent messages.

Overall, my opinion is that this set of drafts is not yet ready to publish, because there are some missing elements in each draft (see the detailed comments) and also because I think the overall clarity of the specifications could be improved.  In particular, I found several instances where I had a question of how something worked in one draft, and later found the answer somewhere else in another draft.  These types of things could be probably addressed by some reorganization.

Also, I did not have a clear big picture of this type of overlay until I read all of the details of all drafts.  Some type of "Protocol overview" section in the framework draft, with particular attention to interface definitions or modular decomposition, would help.  For example, when I read the RELOAD draft, I found a nice overview section including architectural diagrams in Section 1 of the draft.  Maybe Section 7 of the hip-bone draft could be moved forward to Section 1 and expanded.

I would suggest:

1) merge draft-ietf-hip-bone, draft-ietf-hip-via, and draft-ietf-hip-hiccups into one draft.  Keep the reload instance as a separate draft.  Keep the certificate draft as a separate draft.

2) write a protocol (or framework) overview section in the draft-ietf-hip-bone-04 and place it in Section 1, like was done for RELOAD.

Note that I did not review these drafts from the perspective of whether all of the new crypto defined is correct and consistent with the rest of HIP.

Regards,
Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 22 Feb 2010 10:45:58 -0800

> This WGLC will end on February 23rd. Please, send your

Comments on draft-ietf-hip-via-00:

I recommended in another message that this draft could be merged with the HIP BONE draft, but below are some more specific comments.

>   These two extensions enable multi-hop routing in HIP.  Before these
>   extensions were specified, HIP only supported a single intermediate
>   host (i.e., a rendezvous server [RFC5204]) between the source of a
>   HIP packet and its destination.

I don't see why these extensions are required to perform multi-hop routing in all cases.  I agree that one of them is needed to provide multi-hop source routing, but perhaps not multi-hop destination-based routing.

> 2.2. Definitions
>
>
>   Destination list:  A list of HITs of the hosts that a HIP packet
>      should traverse.
>
>   Via list:  A list of HITs of the hosts that a HIP packet has
>      traversed.
>
>   Symmetric routing:  A response to a message is routed back using the
>      same set of intermediary nodes as the original message used,
>      except in reversed order.

It may help to note that the terminology is borrowed from RELOAD.

> 3.1. Creating and Processing Via Lists
>
>
>    When a host sending a HIP packet needs to record the hosts that are
>    on the path that the HIP packet traverses, it includes an empty
>    ROUTE_VIA parameter to the packet.

Can you clarify the means whereby a HIP host originating a packet knows that it needs to include a ROUTE_VIA?  Especially, the distinction between setting the SYMMETRIC flag or not.

This is an example where I found the rules for setting these flags and parameters in the instance specification (section 7 of the instance draft).  Maybe this draft should clarify that this is discussed in an instance specification.

> 3.3. Processing Destination Lists
>
>
>   When a host receives a HIP packet that contains a ROUTE_DST
>   parameter, it first looks up its own HIT from the route list.  If
>   host's own HIT is not in the list and the host is not the receiver of
>   the packet, the packet was incorrectly forwarded and MUST be dropped.
>   Next hop for the packet is the HIT after host's own HIT in the list.

The above sentence should be expanded and clarified.  Can the forwarding host ignore the specified next hop in any cases (i.e., is this a SHOULD or MUST next hop)?  For instance, the host may "look ahead" in the destination list and find that it already has an active association to a later host-- can it just use that?  Another possibility to discuss is a situation in which the requested next hop is not reachable for some reason.

Or, you may delegate the exact behavior to the instance specification (such as you do in section 7 of hip-reload-instance), in which case this draft should more clearly state that forwarding behavior may be specified elsewhere.

Perhaps the protocol needs a loose source and strict source routing flag of some sort, to control this behavior.

>   If the host's HIT was the last HIT in the list, the next hop is the
>   receiver's HIT in the HIP header.

It seems to me that the above sentence would be clearer if it just stated that there is no next hop in this case.

> 6.1. Forwarding Loops
>
>
>    A malicious host could craft a destination route list that contains
>    the same HIT more than once and thus create a forwarding loop.  Since
>    the IP layer TTL is decremented on each hop, the loop will be
>    eventually broken, but hosts may additionally protect themselves
>    against this attack by checking that their own HIT is in the
>    destination list only once and drop invalid packets.

I don't think that IP layer TTL can provide protection here; it is regenerated at every HIP hop, right?  However, you do introduce an OVERLAY_TTL parameter elsewhere in HIP BONE; can you use that?

>    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

Why is this a normative reference?

Other comments:

- Should there be a NOTIFY parameter for a route failure situation (for ROUTE_DST)?  See for instance Section 5.3.3.1 of RELOAD

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 22 Feb 2010 10:46:45 -0800

> This WGLC will end on February 23rd. Please, send your

comments on draft-ietf-hip-hiccups-01:

Overall, I think that this document mainly makes sense in the context of HIP BONE and should be folded into that specification.  However, if kept stand-alone, it would help to clarify in the introduction that this specifies a data service with the following semantics:  unordered, duplicate free (subject to receiver ACK cache size and lifetime), reliable (up to a retransmission count), authenticated, and encrypted message-based delivery service.  I would also recommend stating that APIs to higher-level protocols that might use this service are outside the scope of this specification.

> 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; probably at the very least it should point to the normative references that define the terminology in use later in the document.

> 3. Background on HIP
>
>
>    The HIP protocol specification [RFC5201] defines a number of messages
>    and parameters.  The parameters are encoded as TLVs, as shown in
>    Section 3.1.2.  Furthermore, the HIP header carries a Next Header
>    field, allowing other arbitrary packets to be carried within HIP
>    packets.

Perhaps this section could go away or be refactored if this draft is merged to hip-bone.

> 4.1. Definition of the PAYLOAD_MAC Parameter
>
>      Length            length in octets, excluding Type, Length, and
>                        Padding

are there any minimum or maximum size limitations for this parameter?  Should the maximum length be tied to the maximum size that the HMAC can handle?

> 5.1. Handling of SEQ_DATA and ACK_DATA
>
>
>    A HIP DATA packet contains zero or one SEQ_DATA parameter.  The
>    presence of a SEQ_DATA parameter indicates that the receiver MUST ACK
>    the HIP DATA packet.  A HIP DATA packet that does not contain a
>    SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and
>    MUST NOT be ACKed.

is it legal to have a HIP DATA with zero SEQ_DATA and zero ACK_DATA?  If not, suggest to say that if SEQ_DATA is missing, ACK_DATA must be present.

Can SEQ_DATA be present with no PAYLOAD_MAC parameter?

>    packet.  A host MAY choose to hold the HIP DATA packet carrying ACK
>    for a short period of time to allow for the possibility of
>    piggybacking the ACK parameter, in a manner similar to TCP delayed
>    acknowledgments.

Should the ACK_DATA format allow for multiple sequence numbers, if so, to avoid carrying a Type and Length field for each one?

>    1.  The host creates a HIP DATA packet that contains a SEQ_DATA
>        parameter.  The host is free to choose any value for the SEQ_DATA
>        parameter in the first HIP DATA packet it sends to a destination.

This section would be clearer if you replaced "SEQ_DATA parameter" and "SEQ_DATA value" with "SEQ_DATA sequence number".

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 22 Feb 2010 10:47:14 -0800

> 3. Peer Protocol
>
>    The peer protocol to be used is RELOAD, which is specified in
>   [I-D.ietf-p2psip-base].  When used with RELOAD, HIP replaces the
>    RELOAD's Forwarding and Link Management Layer (described in Section
>    5.5. of [I-D.ietf-p2psip-base].

RELOAD also has a Topology Plugin module that is responsible for maintaining the routing tables; from the RELOAD draft:
  "   The Topology Plugin is responsible for maintaining the overlay
   algorithm Routing Table, which is consulted by the Forwarding and
   Link Management Layer before routing a message."

can you define how this relates to the HIP-specific implementation?  Does an interface exist between a HIP forwarding process and the topology plugin of RELOAD?

> 4. Peer ID Generation
>
>    In the other Peer ID mode, namely "RELOAD", all 128 bits are
>    generated as defined in [I-D.ietf-p2psip-base] resulting in a larger
>    usable address space.

If the RELOAD node IDs are not HITs (ORCHIDs), then a mapping between the node id and the HITs is necessary.  Section 5.6.1 of RELOAD suggests that certificates are to be used in this case; I expected that this draft would discuss the HIP certificate model for this binding.

> 5. Mapping between Protocol Primitives and HIP Messages
>
>    ...Block are replaced with HIP header, HIP VIA lists [I-D.ietf-hip-via],
>    and CERT [I-D.ietf-hip-cert], TRANSACTION_ID, OVERLAY_ID and
>    OVERLAY_TTL [I-D.ietf-hip-bone] parameters.

TRANSACTION_ID is specified in hiccups, not hip-bone.

> 8. Enrollment and Bootstrapping
>
>    The RELOAD HIP BONE instance uses the enrollment and bootstrap
>    procedure defined by RELOAD [I-D.ietf-p2psip-base] with the
>    exceptions listed below.

It was not clear to me how initial bootstrapping occurred, or whether HIP Relay/Rendezvous servers can be used in the absence of HIP routes being in the node's Topology plugin table.  I am assuming that upon first join, HIP nodes must either use the "well known public IP address" technique of bootstrap nodes to join, and then subsequently they will forward all of their HIP messages over the overlay-- is that correct?   Does the AttachReq have a set of suggested locators for initial contact?

> 9. NAT Traversal
>
>
>    RELOAD relies on the Forwarding and Link Management Layer providing
>    NAT traversal capabilities.  Thus, the RELOAD HIP BONE instance
>    implementations MUST implement some reliable NAT traversal mechanism.
>    To maximize interoperability, all implementations SHOULD implement at
>    least [I-D.ietf-hip-nat-traversal].

RELOAD specifies that nodes MUST implement full ICE.  (Section 5.5.1.3).  Can you clarify whether that MUST should be avoided in this instance (i.e. how to avoid RELOAD ICE layered on top of HIP ICE-like NAT traversal)?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 22 Feb 2010 10:49:02 -0800

> This WGLC will end on February 23rd. Please, send your

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).

>    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.

> 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.

> 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..."

> 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?

>   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.

>    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.

>    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.

> 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.

> 7.  Architectural Considerations

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

>    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?

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.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 23 Feb 2010 13:15:38 +0200

Hi Tom,

my answers inline:

> Gonzalo, Below are my WGLC comments on this set of drafts.  I will
> send some detailed comments on each draft in subsequent messages.

thanks for taking the time to comment on all these drafts.

> Overall, my opinion is that this set of drafts is not yet ready to
> publish, because there are some missing elements in each draft (see
> the detailed comments) and also because I think the overall clarity
> of the specifications could be improved.

You have made a number of good comments. They will absolutely need to be
addressed before we request their publication. In any case, while we
could request the publication of the framework, via, and hiccups drafts
when your comments have been incorporated, we will most likely delay the
publication request of the RELOAD instance draft for a while. The reason
is that the new revision of the main RELOAD spec
(draft-ietf-p2psip-base-07), which was submitted last week, includes a
few changes (some of them fruit of reviews by "HIP people") that require
modifications in the instance spec. Obviously, ee will not request the
publication of the instance spec as long as the main RELOAD spec is a
moving target.

> In particular, I found
> several instances where I had a question of how something worked in
> one draft, and later found the answer somewhere else in another
> draft.  These types of things could be probably addressed by some
> reorganization.

Yes, your comments about reorganizing some sections and introducing more
elaborate overview sections in the drafts make sense to me.

> Also, I did not have a clear big picture of this type of overlay
> until I read all of the details of all drafts.  Some type of
> "Protocol overview" section in the framework draft, with particular
> attention to interface definitions or modular decomposition, would
> help.  For example, when I read the RELOAD draft, I found a nice
> overview section including architectural diagrams in Section 1 of the
> draft.  Maybe Section 7 of the hip-bone draft could be moved forward
> to Section 1 and expanded.

Agreed.

> I would suggest:
> 
> 1) merge draft-ietf-hip-bone, draft-ietf-hip-via, and
> draft-ietf-hip-hiccups into one draft.

The reason why these drafts are kept separate is that while the via and
hiccups mechanisms are needed to build overlays, they are not specific
to overlays and can be used in other contexts. Therefore, from a
documentation perspective, it makes sense to have them in separate
drafts. That much said, I agree that we need to make sure readers get
the complete picture as soon as possible when they start reading the
specifications. Let's work on reorganizing the sections and adding
overview material so that the drafts explain up front what they are about.

> Keep the reload instance as a
> separate draft.  Keep the certificate draft as a separate draft.
> 
> 2) write a protocol (or framework) overview section in the
> draft-ietf-hip-bone-04 and place it in Section 1, like was done for
> RELOAD.

I agree.

Thanks,

Gonzalo

---

From: Ari Keranen <[email-masked]>
Date: Tue, 23 Feb 2010 16:08:13 +0200

Hi Tom,

Thanks for the review and comments; responses inline.

Henderson, Thomas R wrote:
>>  extensions were specified, HIP only supported a single
>> intermediate host (i.e., a rendezvous server [RFC5204]) between the
>> source of a HIP packet and its destination.
> 
> I don't see why these extensions are required to perform multi-hop
> routing in all cases.  I agree that one of them is needed to provide
> multi-hop source routing, but perhaps not multi-hop destination-based
> routing.

Yes, you could have other ways to do that, but since this is, AFAIK, so 
far the only (to-be) standardized way to do this, I think it's fair to 
say that only single intermediary hop is currently supported. And we 
don't rule out other ways to do that either.

But perhaps we could say something like:

    Before these
    extensions were specified, there were standardized ways for
    supporting only a single intermediate host (e.g., a rendezvous server
    [RFC5204]) between the source of a HIP packet and its destination.

>> Symmetric routing:  A response to a message is routed back using
>> the same set of intermediary nodes as the original message used, 

Actually, originally it wasn't, but you're right that it ended up being 
quite similar. Anyway, since this draft is not RELOAD (or even overlay) 
specific, I think having a RELOAD reference here would rather confuse 
the reader than clarify the terminology.

> Can you clarify the means whereby a HIP host originating a packet
> knows that it needs to include a ROUTE_VIA?  Especially, the
> distinction between setting the SYMMETRIC flag or not.

It's intentional that we don't mandate when to use the VIA parameter or 
the symmetric flag; it's up to implementation, local policy, or another 
protocol taking advantage of this extension to decide that. For example, 
in the RELOAD instance spec we define the MUSTs and SHOULDs in that 
context. Some other usage may have different requirements, so we don't 
want to rule out those possibilities here.

> This is an example where I found the rules for setting these flags
> and parameters in the instance specification (section 7 of the
> instance draft).  Maybe this draft should clarify that this is
> discussed in an instance specification.

As mentioned above, instance specs are only one possible place where 
this could be defined. I'll add an additional paragraph to the beginning 
of the "Protocol Definitions" section clarifying this:

    The multi-hop routing extensions may be used in different contexts
    and whether a new HIP packet should, for example, include a Via list
    or have different options enabled, can depend on the particular use
    case, local policies, and different protocols using the extension.
    This section defines how the new parameters are handled, but when to
    use these extensions is out of scope for this document.

>> host's own HIT is not in the list and the host is not the receiver
>> of the packet, the packet was incorrectly forwarded and MUST be
>> dropped. Next hop for the packet is the HIT after host's own HIT in
>> the list.
> 
> The above sentence should be expanded and clarified.  Can the
> forwarding host ignore the specified next hop in any cases (i.e., is
> this a SHOULD or MUST next hop)?  For instance, the host may "look
> ahead" in the destination list and find that it already has an active
> association to a later host-- can it just use that?  Another
> possibility to discuss is a situation in which the requested next hop
> is not reachable for some reason.

Next hops should not be ignored, so that should be a MUST. I added to 
the end of the paragraph the following:

    If the host has a valid locator
    for the next hop, it MUST forward the HIP packet to the next hop
    host.

(there's also new text after this paragraph about what to do if there is 
no valid locator; see the last comment)

If you think that there are relevant use cases for the "look ahead 
optimization", we could have one flag that signals whether it's OK to do 
that (and have that as a "MAY").

> Or, you may delegate the exact behavior to the instance specification
> (such as you do in section 7 of hip-reload-instance), in which case
> this draft should more clearly state that forwarding behavior may be
> specified elsewhere.
> 
> Perhaps the protocol needs a loose source and strict source routing
> flag of some sort, to control this behavior.

Actually, this loose source routing flag was in one of the early 
pre-release versions of the draft, but it was removed since we didn't 
find really good use cases for it and it is a bit problematic with 
signed ROUTE_DST list.

The problem is that with loose source routing either the VIA list would 
need to be modified (removing the hops that are already used; breaking 
the signature) or one would need a pointer (new parameter in the 
unsigned part) to the "next hop in the list" since you don't necessarily 
anymore implicitly know where in the list you're going.

Moving the ROUTE_DST to the unsigned part would solve the issue, but we 
felt that protecting the list with signature is more important. Of 
course we could have both signed and unsigned versions if there are 
compelling use cases for the loose source routing.

> It seems to me that the above sentence would be clearer if it just
> stated that there is no next hop in this case.

But there is the "next hop" from the last forwarding host to the 
receiver, right? And it's actually easier to refer to "next hop" in both 
cases in the following text. Or can you propose some other wording that 
would make this clearer?

>>  the same HIT more than once and thus create a forwarding loop.
>> Since the IP layer TTL is decremented on each hop, the loop will be
> I don't think that IP layer TTL can provide protection here; it is
> regenerated at every HIP hop, right?  However, you do introduce an
> OVERLAY_TTL parameter elsewhere in HIP BONE; can you use that?

Good point; I was under the impression that the IP layer TTL is 
preserved by what is defined in the current RFCs, but after having a 
closer look at them it turned out they don't require this.

I would not require using the OVERLAY_TTL parameter if not really 
necessary and rather make the checking-your-own HIT a MUST.

> IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
> 

Good catch. Moved it to informative.

> Other comments:
> 
> - Should there be a NOTIFY parameter for a route failure situation
> (for ROUTE_DST)?  See for instance Section 5.3.3.1 of RELOAD 

That could be useful, I'll add it to the draft. Now it says at the end 
of Section 3.3:

    If the host does not have a valid locator for the next hop host, it
    SHOULD drop the packet and SHOULD send back a NOTIFY error packet
    with type UNKNOWN_NEXT_HOP (value [TBD by IANA; 90]).  The
    Notification Data field for the error notifications SHOULD contain
    the HIP header of the rejected packet and the ROUTE_DST parameter.

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Tue, 23 Feb 2010 17:20:35 +0200

Hi Tom,

Once again, thanks for the comments; responses inline.

Henderson, Thomas R wrote:
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>> this document are to be interpreted as described in RFC 2119
>> [RFC2119].
> 
> This section is empty; probably at the very least it should point to
> the normative references that define the terminology in use later in
> the document.

Makes sense; added pointers to 5201, HIP BONE and RELOAD.

> RELOAD also has a Topology Plugin module that is responsible for
> maintaining the routing tables; from the RELOAD draft: "   The
> Topology Plugin is responsible for maintaining the overlay algorithm
> Routing Table, which is consulted by the Forwarding and Link
> Management Layer before routing a message."
> 
> can you define how this relates to the HIP-specific implementation?

HIP replaces the Forwarding layer, so it consults the Topology plugin 
module as the Forwarding layer would have done.

> Does an interface exist between a HIP forwarding process and the
> topology plugin of RELOAD?

The details about the interface (if any) between HIP and RELOAD modules 
are left up to implementations. Our goal was not to define APIs in this 
document, but such APIs can be later defined in, e.g., advanced HIP 
native API document.

>> generated as defined in [I-D.ietf-p2psip-base] resulting in a
>> larger usable address space.
> 
> If the RELOAD node IDs are not HITs (ORCHIDs), then a mapping between
> the node id and the HITs is necessary.  Section 5.6.1 of RELOAD
> suggests that certificates are to be used in this case; I expected
> that this draft would discuss the HIP certificate model for this
> binding.

In this case the 128-bit ID would be your "HIT" so there is no need for 
mapping (and in that sense the assumptions in Section 5.6.1.1 of RELOAD 
draft are not really correct).

>> ...Block are replaced with HIP header, HIP VIA lists
>> [I-D.ietf-hip-via], and CERT [I-D.ietf-hip-cert], TRANSACTION_ID,
>> OVERLAY_ID and OVERLAY_TTL [I-D.ietf-hip-bone] parameters.
> 

Good catch; fixed.

> It was not clear to me how initial bootstrapping occurred, or whether
> HIP Relay/Rendezvous servers can be used in the absence of HIP routes
> being in the node's Topology plugin table.  I am assuming that upon
> first join, HIP nodes must either use the "well known public IP
> address" technique of bootstrap nodes to join, and then subsequently
> they will forward all of their HIP messages over the overlay-- is
> that correct?   Does the AttachReq have a set of suggested locators
> for initial contact?

The idea is to re-use the bootsrapping possibilities defined in the 
RELOAD spec; including downloading the config file using HTTP from a 
server discovered using DNS. But perhaps this would need some 
clarification. I'll see what I can do. AttachReqs are not used with the 
instance spec.

>> implementations MUST implement some reliable NAT traversal
>> mechanism. To maximize interoperability, all implementations SHOULD
>> implement at least [I-D.ietf-hip-nat-traversal].
> 
> RELOAD specifies that nodes MUST implement full ICE.  (Section
> 5.5.1.3).  Can you clarify whether that MUST should be avoided in
> this instance (i.e. how to avoid RELOAD ICE layered on top of HIP
> ICE-like NAT traversal)? 

Yes, the whole 5.5. section of RELOAD is replaced by what is defined in 
5 of the instance spec. I'll clarify in that section that this also 
includes all the ICE stuff. Now the section 5 starts with:

    RELOAD HIP BONE replaces the RELOAD protocol primitives taking care
    of connection establishment with the HIP base exchange, where as the
    rest of the RELOAD messages are conveyed within HIP messages.  The
    Forwarding and Link Management Layer functionality of RELOAD defined
    in Section 5.5. of [I-D.ietf-p2psip-base], including all the NAT
    traversal functionality, is replaced by HIP and the extensions
    defined in this document.

Cheers,
Ari

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 23 Feb 2010 09:47:49 -0800

> overview material so that the drafts explain up front what

I agree that the HIP DATA could be used in other contexts; I had another comment against that draft that if you decide to keep this as a separate draft, you could clarify some things in the beginning of the draft regarding the scope of the specification.

Regarding the via draft, it seems to me to be much more coupled with overlay forwarding, so I would suggest that either you describe the other non-overlay use case(s) for these parameters, or else merge it with HIP BONE.  Anyway, if you still feel that it is important to keep the via draft separate, I will not raise this point again.

Regards,
Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 23 Feb 2010 10:11:41 -0800

Hi Ari, some responses to your responses below:

> From: Ari Keranen [mailto:[email-masked]]
> Sent: Tuesday, February 23, 2010 6:08 AM
> To: Henderson, Thomas R
> Cc: 'Gonzalo Camarillo'; HIP
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-via-00
>
> Hi Tom,
>

OK

> the reader than clarify the terminology.

If you end up with the same terms as RELOAD but slightly different meanings, I would recommend that you try to clarify the distinction, so that readers familiar with RELOAD are not confused.  If they end up being the same terms and definitions as in RELOAD, I don't think that it would be confusing to state this, but I'll leave it up to you.

>     use these extensions is out of scope for this document.

OK

> that (and have that as a "MAY").

If I process a destination list, and I have an active HIP association to the destination HIT, why MUST I send it to another host on the destination list?  It seems that MAY should be the default and MUST should be a mode of operation when there is a specific use case that requires that intermediate nodes handle the packet.

> anymore implicitly know where in the list you're going.

I'm sorry, I do not see the issue.  The via list is not associated with loose source routing; it is just a "Record Route" option that can be turned around and made into a destination list at the receiver (if symmetric flag is set).

The destination list can be signed; it does not have to be modified regardless of whether loose or strict source routing is chosen.  By loose source, I mean that any later HIT or the destination HIT can be chosen instead of the next HIT in the list; this would allow the packet to always make progress to the destination without confusion about where you are at in the list, right?

> cases in the following text. Or can you propose some other

I think I misread this yesterday, and am not sure it needs to be clarified; sorry.

> necessary and rather make the checking-your-own HIT a MUST.

Perhaps checking-your-own-HIT(s) is MUST and OVERLAY_TTL a MAY?

>     the HIP header of the rejected packet and the ROUTE_DST parameter.

Should you say "host cannot determine a valid locator" instead of "host does not have"?  That would give more flexibility to perhaps find this locator on demand if needed.

Regards,
Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 23 Feb 2010 10:22:01 -0800

> Sent: Tuesday, February 23, 2010 7:21 AM
> To: Henderson, Thomas R
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00
>
> Hi Tom,
>

OK, I suggest to add this clarification to the draft.

> draft are not really correct).

My understanding is that there are two main modes of Node ID generation in (non-HIP-based) RELOAD:
1) centralized
2) self-generated, self-signed

When you say "In the other Peer ID mode, namely "RELOAD",..." which case do you mean?  Just the self-generated case?  If it is the centralized case, the Node IDs can't be used as HITs, and then the Node IDs and the HITs are not related to one another and need to be bound by some kind of certificate framework.  This is what I think section 5.6.1.1 of the base draft refers to.  Or am I misunderstanding something?

>     defined in this document.

OK, I'll have a look at the revisions when they are published.

Regards,
Tom

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 24 Feb 2010 15:48:04 +0200

Hi Tom,

> I agree that the HIP DATA could be used in other contexts; I had
> another comment against that draft that if you decide to keep this as
> a separate draft, you could clarify some things in the beginning of
> the draft regarding the scope of the specification.

sure, that will needs to be clarified in that draft.

> Regarding the via draft, it seems to me to be much more coupled with
> overlay forwarding, so I would suggest that either you describe the
> other non-overlay use case(s) for these parameters, or else merge it
> with HIP BONE.  Anyway, if you still feel that it is important to
> keep the via draft separate, I will not raise this point again.

Ari will take care of describing the non-overlay case in the Via draft.

Thanks,

Gonzalo

---

From: Ari Keranen <[email-masked]>
Date: Thu, 25 Feb 2010 14:12:20 +0200

Hi Tom,

Responses to remaining open issues below.

Henderson, Thomas R wrote:
>> -----Original Message----- From: Ari Keranen
>>>> parameter, it first looks up its own HIT from the route list.
>>>> If host's own HIT is not in the list and the host is not the
>>>> receiver of the packet, the packet was incorrectly forwarded
>>>> and MUST be dropped. Next hop for the packet is the HIT after
>>>> host's own HIT in the list.
>>> forwarding host ignore the specified next hop in any cases (i.e.,
>>> is this a SHOULD or MUST next hop)?  For instance, the host may
>>> "look ahead" in the destination list and find that it already has
>>> 
>> an active
>> Next hops should not be ignored, so that should be a MUST. I added
>> to the end of the paragraph the following:
>> 
>> If the host has a valid locator for the next hop, it MUST forward
>> the HIP packet to the next hop host.
>> 
>> (there's also new text after this paragraph about what to do if
>> there is no valid locator; see the last comment)
>> 
>> optimization", we could have one flag that signals whether it's OK
>> to do that (and have that as a "MAY").
> 
> If I process a destination list, and I have an active HIP association
> to the destination HIT, why MUST I send it to another host on the
> destination list?  It seems that MAY should be the default and MUST
> should be a mode of operation when there is a specific use case that
> requires that intermediate nodes handle the packet.

One reason for requiring the message pass all hosts in the list is that 
you could want to keep some HIP host(s) informed about all the signaling 
that is happening between the two hosts (similar to what you can 
accomplish with preloaded route header in SIP). In that case one should 
not skip any of the hosts even if it would be possible.

But this kind of "loose source routing" option does make sense and would 
be easy to implement, so I'll add a flag for it ("MUST_FOLLOW" that says 
one MUST NOT skip any hosts on path).

>>> (such as you do in section 7 of hip-reload-instance), in which
>>> case this draft should more clearly state that forwarding
>>> behavior may be specified elsewhere.
>>> 
>>> Perhaps the protocol needs a loose source and strict source
>>> routing flag of some sort, to control this behavior.
>> pre-release versions of the draft, but it was removed since we
>> didn't find really good use cases for it and it is a bit
>> problematic with signed ROUTE_DST list.
>> 
>> The problem is that with loose source routing either the VIA list
>> would need to be modified (removing the hops that are already used;
>>  breaking the signature) or one would need a pointer (new parameter
>> in the unsigned part) to the "next hop in the list" since you don't
>>  necessarily anymore implicitly know where in the list you're
>> going.
> 
> I'm sorry, I do not see the issue.  The via list is not associated
> with loose source routing; it is just a "Record Route" option that
> can be turned around and made into a destination list at the receiver
> (if symmetric flag is set).

Sorry, I meant ROUTE_DST list.

> The destination list can be signed; it does not have to be modified
> regardless of whether loose or strict source routing is chosen.  By
> loose source, I mean that any later HIT or the destination HIT can be
> chosen instead of the next HIT in the list; this would allow the
> packet to always make progress to the destination without confusion
> about where you are at in the list, right?

OK, I was talking about different kind of loose source routing where 
there could be HIP hosts in between which are not part of the list. The 
kind of LSR you propose sounds reasonable and I added the MUST_FOLLOW 
flag for this.

  >>>> 6.1. Forwarding Loops
>>>> 
>>>> 
>>>> A malicious host could craft a destination route list that
>>>> contains the same HIT more than once and thus create a
>>>> forwarding loop. Since the IP layer TTL is decremented on each
>>>> hop, the loop will be eventually broken, but hosts may
>>>> additionally protect themselves against this attack by checking
>>>> that their own HIT is in the destination list only once and
>>>> drop invalid packets.
>>> I don't think that IP layer TTL can provide protection here; it
>>> is regenerated at every HIP hop, right?  However, you do
>>> introduce an OVERLAY_TTL parameter elsewhere in HIP BONE; can you
>>> use that?
>> preserved by what is defined in the current RFCs, but after having
>> a closer look at them it turned out they don't require this.
>> 

Yeah, makes sense. But for this to work, the OVERLAY_TTL must be made 
critical; and this in turn requires that the parameter is removed before 
forwarding a HIP packet from an overlay to a host that does not 
understand the parameter (in case you have a "gateway host" to/from the 
overlay).

I made increase the OVERLAY_TTL parameter's type value by one and added 
the following text to HIP-BONE draft:

      Type        [ TBD by IANA; 64011 ]
[...]
    The type of the OVERLAY_TTL parameter is critical (as defined in
    Section 5.2.1 of [RFC5201]) and therefore the final recipient of the
    packet, and all HIP hosts on the path, MUST support it.  If the
    parameter is used in a scenario where the final recipient does not
    support the parameter, the parameter SHOULD be removed before
    forwarding the packet to the final recipient.

>>> Other comments:
>>> 
>>> - Should there be a NOTIFY parameter for a route failure
>>> situation (for ROUTE_DST)?  See for instance Section 5.3.3.1 of
>>> RELOAD
>> That could be useful, I'll add it to the draft. Now it says at the
>> end of Section 3.3:
>> 
> Should you say "host cannot determine a valid locator" instead of
> "host does not have"?  That would give more flexibility to perhaps
> find this locator on demand if needed.

Makes sense; fixed this too.

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Thu, 25 Feb 2010 16:31:12 +0200

Henderson, Thomas R wrote:
>> [mailto:[email-masked]]
>>>> 3. Peer Protocol
>>>> 
>>>> [I-D.ietf-p2psip-base].  When used with RELOAD, HIP replaces
>>>> the RELOAD's Forwarding and Link Management Layer (described in
>>>> Section 5.5. of [I-D.ietf-p2psip-base].
>>> Topology Plugin is responsible for maintaining the overlay
>> HIP replaces the Forwarding layer, so it consults the Topology
>> plugin module as the Forwarding layer would have done.
>> 
>> The details about the interface (if any) between HIP and RELOAD
>> modules are left up to implementations. Our goal was not to define 
>> APIs in this document, but such APIs can be later defined in, e.g.,
>> advanced HIP native API document.
> 

OK. I thought that would be implicitly clear. But I can add the 
following to the end of the intro section:

    [...] The
    details on how different RELOAD modules would be integrated to a HIP
    implementation and what kind of APIs are used between them are left
    as implementation details or to be defined by other documents.

>>> suggests that certificates are to be used in this case; I
>>> expected that this draft would discuss the HIP certificate model
>>> for this binding.
>> In this case the 128-bit ID would be your "HIT" so there is no need
>> for mapping (and in that sense the assumptions in Section 5.6.1.1 
>> of RELOAD draft are not really correct).
> 
> My understanding is that there are two main modes of Node ID
> generation in (non-HIP-based) RELOAD: 1) centralized 2)
> self-generated, self-signed
> 
> When you say "In the other Peer ID mode, namely "RELOAD",..." which
> case do you mean?  Just the self-generated case?  If it is the
> centralized case, the Node IDs can't be used as HITs, and then the
> Node IDs and the HITs are not related to one another and need to be
> bound by some kind of certificate framework.  This is what I think
> section 5.6.1.1 of the base draft refers to.  Or am I
> misunderstanding something?

We mean both cases.  I'm sorry but I don't follow why couldn't the 
non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA 
lists and certificates) in the centralized case?

The CERT parameter used to prove that a host can use certain Node ID 
contains the hosts real HIT (i.e., hash of the host ID) which binds the 
Host ID to the Node ID.

But I guess this needs some further clarification in the draft; I'll add 
some text about this.

>>> being in the node's Topology plugin table.  I am assuming that
>>> upon first join, HIP nodes must either use the "well known public
>>> IP address" technique of bootstrap nodes to join, and then
>>> subsequently they will forward all of their HIP messages over the
>>> overlay-- is that correct?   Does the AttachReq have a set of
>>> suggested locators for initial contact?
>>  RELOAD spec; including downloading the config file using HTTP from
>> a server discovered using DNS. But perhaps this would need some 
>> clarification. I'll see what I can do. AttachReqs are not used with
>> the instance spec.
>> 
>>>> 9. NAT Traversal
>>>> 
>>>> 
>>>> RELOAD relies on the Forwarding and Link Management Layer
>>>> providing NAT traversal capabilities.  Thus, the RELOAD HIP
>>>> BONE instance implementations MUST implement some reliable NAT
>>>> traversal mechanism. To maximize interoperability, all
>>>> implementations SHOULD implement at least
>>>> [I-D.ietf-hip-nat-traversal].
>>>  this instance (i.e. how to avoid RELOAD ICE layered on top of
>>> HIP ICE-like NAT traversal)?
>> Yes, the whole 5.5. section of RELOAD is replaced by what is 
>> defined in 5 of the instance spec. I'll clarify in that section
>> that this also includes all the ICE stuff. Now the section 5 starts
>> with:
>> 
>>  of connection establishment with the HIP base exchange, where as
>> the rest of the RELOAD messages are conveyed within HIP messages.
>> The Forwarding and Link Management Layer functionality of RELOAD
>> defined in Section 5.5. of [I-D.ietf-p2psip-base], including all
>> the NAT traversal functionality, is replaced by HIP and the
>> extensions defined in this document.
>> 
> 

OK, thanks. We'll make a new revision before the cut-off date.

Cheers,
Ari

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 25 Feb 2010 08:48:16 -0800

> lists and certificates) in the centralized case?

Let's say that the enrollment server allocates the first node the Node ID of "0", the second node a Node ID of "1" etc.  Are you suggesting that these values are used as HITs?

I raised this issue in another thread yesterday, but it seems to me that a central idea in the HIP architecture is that the HIT is the hash of the public key of a public/private key pair and that the host holds the private key.  I don't believe we've talked before about the possibility that the HI and HIT are not related cryptographically.

- Tom

---

From: Ari Keranen <[email-masked]>
Date: Fri, 26 Feb 2010 08:59:31 +0200

Henderson, Thomas R wrote:
>>> When you say "In the other Peer ID mode, namely "RELOAD",..."
>>> which case do you mean?  Just the self-generated case?  If it is
>>> the centralized case, the Node IDs can't be used as HITs, and
>>> then the Node IDs and the HITs are not related to one another and
>>> need to be bound by some kind of certificate framework.  This is
>>> what I think section 5.6.1.1 of the base draft refers to.  Or am
>>> I misunderstanding something?
> Let's say that the enrollment server allocates the first node the
> Node ID of "0", the second node a Node ID of "1" etc.  Are you
> suggesting that these values are used as HITs?

Yes. Although the enrollment server would not really give IDs like that 
but rather make them cryptographically random, but the point remains the 
same: the IDs in the RELOAD mode are not (necessarily) hashes of public 
keys.

> I raised this issue in another thread yesterday, but it seems to me
> that a central idea in the HIP architecture is that the HIT is the
> hash of the public key of a public/private key pair and that the host
> holds the private key.  I don't believe we've talked before about the
> possibility that the HI and HIT are not related cryptographically.

Yeah, we had a thread on the HIP list about this some half a year ago 
but it died away. I admit that the HIT being a hash of a public key is 
somewhat central idea in HIP, but is it really necessary if you have a 
certificate that can provide the same binding between the non-HIT-ID and 
Host ID?

AFAIK, you only lose the property that for someone else it's really hard 
to generate the same identity, but with an enrollment server that would 
not be a problem thanks to the certificates. Without an enrollment 
server one could fake the ID in the RELOAD mode, but then you can still 
use the ORCHID mode and real HITs or generate IDs as digests (SHA-1 or 
SHA-256) of the public key as the RELOAD draft proposes.

Cheers,
Ari

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 26 Feb 2010 09:29:26 -0800

> Sent: Thursday, February 25, 2010 11:00 PM
> To: Henderson, Thomas R

I think we should really explore this idea more but let's do so in the more RFC4423bis context as discussed in the other thread.  I wasn't objecting to the idea per se, but just that we should not slip it into this draft if it is not really recognized as a part of HIP today.

I see pros and cons to non-ORCHID HITs:
- pro:  can be designed to be hierarchical or formatted as needed.  Can they even be IPv6 addresses?
- con:  HITs are no longer unique.  It is really the certificate which is the unique identifier.
It does seem more flexible and may have deployment advantages.  Does it solve the ACL problem with current HITs (that they are non-aggregatable)?  It could lead to aggregatable HITs but then the ACL will need to know the authorizing enrollment server for those HITs, and check CERTs.

- Tom