HIPL generates type 1 locators without SPI

[Miika Komu]

As reported by Jeff Ahrenholz, we should include the SPI in type 1 locators. Please see the discussion thread in:

http://www.freelists.org/post/hipl-dev/interop-with-OpenHIP-failing-due-to-UPDATE-packets

[Miika Komu (miika-iki)]

See also: http://www.freelists.org/post/hipl-dev/hipldev-Digest-V2-12

[Miika Komu (miika-iki)]

Is this resolved?

[Jeff Ahrenholz (siliconja)]

>
> Is this resolved?
>

I haven't tried this in a while. I think we proceeded past the locator format issue.

-Jeff

> --
> You received this bug notification because you are subscribed to the
> bug
> report.
> https://bugs.launchpad.net/bugs/790487
>
> Title:
> HIPL generates type 1 locators without SPI
>
> Status in Host Identity Protocol for Linux:
> Confirmed
>
> Bug description:
> As reported by Jeff Ahrenholz, we should include the SPI in type 1
> locators. Please see the discussion thread in:
>
> http://www.freelists.org/post/hipl-dev/interop-with-OpenHIP-failing-
> due-to-UPDATE-packets
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/hipl/+bug/790487/+subscriptions

[René Hummen (rene-hummen)]

Looking at modules/update/hipd/update_locator.c:hip_build_locators_old(), we still don't add the SPI number in LOCATORs. However, I am wondering which SPI to add there. Right now, HIPL only sets up IPsec SAs for the preferred locator. So, other possible locators announced during updates do not have an associated SPI. Should we still announce these non-reachable SPI/IP combinations?

[Miika Komu (miika-iki)]

Hi,

On 11/06/2011 06:34 PM, René Hummen wrote:
> Looking at
> modules/update/hipd/update_locator.c:hip_build_locators_old(), we still
> don't add the SPI number in LOCATORs.

We should.

> However, I am wondering which SPI to add there.

The one the local host announced to the peer in the base exchange.

> Right now, HIPL only sets up IPsec SAs for the preferred
> locator. So, other possible locators announced during updates do not
> have an associated SPI. Should we still announce these non-reachable
> SPI/IP combinations?

Let's make it simple and just copy the SPI number in the type 1 locator
field. This way, we conform to draft-ietf-hip-rfc5206-bis and have an
easier migration path to draft-ietf-hip-multihoming when multihoming is
more mature. We don't have rekeying support yet so the SPI number is
fixed during the lifetime of the SA in the current implementation.

We have the reachability test to check which locators are non-reachable.
So yes, all locators should be announced. To repeat, we can stick to the
same SPI.

To keep it simple, I suggest to set to the preferred bit to the local
locator that hip_select_source_address() gives you.

[Henrik Ziegeldorf (henrik-ziegeldorf)]

Fixed in rev 6158.

The SPI is included in type 1 locators.
Still, interoperability tests remain to be done.