[Battlemesh] Host Identity Protocol, any experience?

[willi uebelherr]

Dear Tom,

we have to separate something in this discussion in the architectural space.

1) Under some conditions, mobile devices change her AP space. And this 
means, it can be possible to use an open session with his move.

This is mostly not necessary for laptops or notebooks. This can be 
necessary for handheld, small mobile device.

And this mechanism is only necessary to continue an open session. If we 
create a new session, we work with this new AP space.

2) Under such specific conditions it is not necessary to inflate more 
and more this confusion in the IP stack.

3) This living sessions (TCP, UDP) was started from a specific AP with 
the communication partner inside or outside of this AP space. And this 
specific mobile device change the AP space. Therefore for me, it will be 
much clearer and simpler, to conentrate to this temporal action, the 
forwarding. Based on this focus to the AP's, a device with much more 
resources, mostly, it will be much easier to organise the following of 
the pakets.

And this is the basic architectural goal of the Mobil-IP. The 
implementation maybe can be the same nonsense like in the HIP area.

many greetings, willi
Asuncion, Paraguay


On 28/11/2016 14:19, Tom Henderson wrote:
> On 11/28/2016 05:05 AM, Linus Lüssing wrote:
>> Hi,
>>
>> Just read about this protocol a few days ago:
>>
>> https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-43/121-host.html
>>
>> https://en.wikipedia.org/wiki/Host_Identity_Protocol
>> https://tools.ietf.org/html/rfc7401
>>
>> Has anyone had the pleasure to play with it yet?
>>
>> Seems like it might be a necessity to support truely decentral,
>> distributed, dynamic internet uplinks in a public mesh network?
>>
>> (otherwise, everytime a node with a direct uplink vanishes, TCP
>> connections would break or would need some tunneling)
>>
>>
>> The idea of HIP to strip the identity part from IP addresses and
>> replacing it with a layer in between, which cryptographically
>> generates identities, sounds ingenious!
>
> I've been involved with HIP for a long time.  There have been several
> variations on the basic architecture, but the main idea is to allow
> transport sessions and applications to bind to a stable identifier which
> is a) 128 bits long so that it can be used in place of an IPv6 address
> in protocols and code, and b) the hash of a public key, with enough
> strength to prevent brute force attacks. Think of Mobile IPv6, but with
> the home address being this other IPv6-address-like identifier that is
> bound to a public key.  In mobility and multihoming situations, where IP
> addresses change, a peer host can directly verify that it is indeed
> talking to the same host on different addresses, without checks such as
> return routability.  The network stack is responsible for managing the
> binding of real IP addresses to this HIP identifier, and performing a
> "host NAT" operation on incoming and outgoing datagrams.
>
> One variation for small networks or overlays is to route directly on
> these identifiers:
> https://tools.ietf.org/html/rfc6079
>
> Possible drawbacks to HIP are the cost of managing this layer of
> indirection in the stack (including support for NAT traversal, DNS
> extensions, address discovery of mobile hosts, key revocation), and the
> inability to aggregate these identifiers in access control lists.
> However, it has found application in some environments for which
> security is critical (e.g. SCADA networks, some IoT applications).
>
> - Tom
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>