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

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

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] 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.
>

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