hipl-core team mailing list archive

[Tobias Heer <619332@xxxxxxxxxxxxxxxxxx>]

I think reducing the failure probability during BEX is a really good thing but I also think that we should have some specification and documentation in the form of a draft to back up the experimentation.
I also think shotgun goes into an interesting direction but I think there is some more research and coding necessary before it evolves into a feature with long-term support.

I did express my interest and doubts about shotgun on the hipsec list
before. You may want to read the conversation for more reasoning.

http://www.ietf.org/mail-archive/web/hipsec/current/msg02837.html
http://www.ietf.org/mail-archive/web/hipsec/current/msg02839.html

I am not sure if I should lean towards keeping or abandoning it, though.
I guess my recommendation strongly depends on whether it is still
actively developed and maintained or if it is "just there". If it is
maintained and will serve as input for the IETF or IRTF I think it
should definitely stay (but possibly in a feature branch until the
experimentation is completed). If it is not maintained anymore not, we
will have some optimization without proper documentation (in the form of
specification and research papers) that is only supported by HIPL and it
will decay because of lacking support.

Some general questions that may make the decision to keep or discard it easier:
* Is the concept well understood? Are its side effects (e.g., interactions with middleboxes) understood and documented?
* Is it well tested? Do we know exactly when it works and when it doesn't?
* Does shotgun solve an real problem that people notice?
* Does it solve the problem well?
* Is it complete or does it need more work?
* Who will maintain and develop it?

-- 
Broadcast as fall-back mechanism when no HIT->IP
https://bugs.launchpad.net/bugs/619332
You received this bug notification because you are a member of HIPL core
team, which is subscribed to HIPL.

Status in Host Identity Protocol for Linux: New

Bug description:
If the hip daemon can't resolve an address with hip_map_id_to_addr, it tries to broadcast an I1 message using standard interfaces.

This fallback mechanism is in my and Renes opinion useless and should be stripped out.

The cause of failing in my particular case was that I mounted /etc/hip/hosts with fuse and the fopen function failed to open it, even though hipd had root rights.