Question about license and Android

Asked by Lars Laven on 2014-04-22

Hi,

We are working on a solution where we plan to use HIP for P2P-traffic. We have looked at both OpenHIP and HIPL. OpenHIP seems to use a MIT license in their latest release, but I am not sure what kind of license HIPL has. Is it GPLv2 or MIT?

Also, It looks like your Android code is requiring the device to be rooted. What is it in the code that is the cause of that requirement?

Kind regards,
Lars Lavén

Question information

Language:
English Edit question
Status:
Solved
For:
HIPL Edit question
Assignee:
No assignee Edit question
Solved by:
Lars Laven
Solved:
2014-04-23
Last query:
2014-04-23
Last reply:
2014-04-22
Miika Komu (miika-iki) said : #1

HIPL has some minor GPL parts that we haven't ported yet to MIT-compatible code yet, so the license is both GPL + MIT at the moment. You can find the related bug items with keyword "license" from launchpad.

Lars Laven (lars-laven) said : #2

Thanks Miika for the response.

Regarding Android I saw in the INSTALL document that it required root access and that the kernel needed to have IPSec BEET support. For us rooting the devices is not an option so we need to work around it. We already have a working VPN client on Android that uses the built-in TUN adapter so TUN should work. Is there a way around the BEET support requirement in the kernel? Could BEET support be built into user space instead?

rgds,
Lars

Juhani Toivonen (scolphoy) said : #3

I just realised that the mailing list doesn't traverse the responses back to launchpad..

My initial response for the question:
As for the Android rooting requirement; HIPL does exactly the same thing on Android as it does on Linux. It creates a virtual NIC using the dummy network interface driver, assigns the device’s HIT as the IPv6 address of that NIC, and adds routing table rules that make all packets directed toward HITs to go through that NIC etc. So in short, it does things in kernel-space. This stuff is not permitted to non-privileged users on normal Linux hosts either.

If there is a way to run privileged code, preferably as a service that starts at boot, on a non-rooted device, I want to learn about it too. This is one of the key hindrances with the Android port at the moment.

For the follow up:
If the TUN adapter supports IPv6, then it could be possible to support that as well.. As to the BEET mode, https://www.rfc-editor.org/rfc/rfc5202.txt chapter 3.2 contains a sketch of how the communication could be carried out without BEET mode, but I'm not sure if that has been implemented in HIPL.

Lars Laven (lars-laven) said : #4

Hi,

Yes, the creation of the Virtual NIC, the setting of the device's HIT and routing table modifications can be done in user space since the release of Android 4.0 (Ice Cream Sandwich), but it has to be done in Java so you will need a JNI interface to your native code. Please have a look at VPNService http://developer.android.com/reference/android/net/VpnService.html for a description of the Java VPN API.

We have not tested it our VPN client with IPv6, but I am pretty sure that IPv6 works.

Please let me know if you want to have a Skype call to discuss and/or have further questions.

rgds,
Lars

Juhani Toivonen (scolphoy) said : #5

The security limitations described in the overview turned me off form that API previously. If the device could only keep up one connection at a time, and would need to ask the user separately for each time it wants to connect somewhere else, it makes the thing largely unusable.

However, I may have misunderstood that while reading it the first time. If that meant that packets from that interface could be intercepted by only one app at a time (after the user gives permission), and that app could have as many simultaneous tunnels as it likes, this could be usable.

I'll need to look further into this at some point.

Lars Laven (lars-laven) said : #6

The limitation is that you are only allowed one VPN client at one given moment. There is however no limitation how many open sockets you have from the VPN client so it should fulfil the HIP needs. There is only support for one TUN adapter, but that should not in my mind be a problem for a HIP implementation either.

Lars Laven (lars-laven) said : #7

I guess I should mark this as solved as my questions have been answered.

Thanks guys for all your help and your prompt feedback.

Miika Komu (miika-iki) said : #8

FYI, HIPL is not using tun/tap, but "dummy" interface instead.

Juhani Toivonen (scolphoy) said : #9

I believe that was clear, and the question was if support for the TUN/TAP interface could be added, because that comes natively in Android >= 4.0. This does require a bit of time and effort, but I don't see it as being impossible, and it would be a major step away from requiring a rooted device.

And thanks Lars, I'll see if we can do something about that at some point.