Re: [Hipsec] WGLC: draft-ietf-hip-via-00

[Ari Keranen <[e-mail]>]

Hi Tom,

Thanks for the review and comments; responses inline.

Henderson, Thomas R wrote:
>> 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.

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.

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

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.

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

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.

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

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.

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

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?

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

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.

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

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