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

[Ari Keranen <[e-mail]>]

Hi Tom,

Responses to remaining open issues below.

Henderson, Thomas R wrote:
>> -----Original Message----- From: Ari Keranen
>> Henderson, Thomas R wrote:
>>>> 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.

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

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

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

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

Makes sense; fixed this too.


Cheers,
Ari