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

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

Hi Ari, some responses to your responses below:

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

OK

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

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.

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

OK

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

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.

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

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?

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

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

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

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

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

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


>
> Cheers,
> Ari
>