[hipl-users] Re: LSI functionality in HIPL
- From: Stephen Herborn <stephen.herborn@xxxxxxxxxxxx>
- To: hipl-users@xxxxxxxxxxxxx
- Date: Tue, 23 May 2006 00:26:50 +1000
Would you be interested in making the LSIs work in the HIP daemon and
contributing the code?
Sounds like fun, maybe will have a go over the (european) winter if its
not done (and still necessary) by then.
* Most commonly used applications already seem to support IPv6
addressing
True. However we were looking at trying to use tcpcp (tcp connection
passing) in combination with HIPL to implement a simple tcp session
mobility scheme, problem is tcpcp is ipv4 only. Someone has recently
ported tcpcp to ipv6 but not released it yet, so it would be a waste of
time to port it ourselves.
* We have been investigating if we can do some socket wrapping in the
userspace, similarly as in TESLA [1]
A potential really-bad-hack to let ipv4 applications use HIP might be to
create a null encrypted (local) tunnel mode IPSec session between the
application and the hip daemon at both ends, with the 'inner' addresses
as the ipv4 address of the respective src and dst and the 'outer'
addresses as the respective src and dst HITs. This assumes (most
probably incorrectly) that it is possible to have the 'inner' src-dst
address pair as a different protocol from the 'outer' src-dst pair.
Apart from the need for explicit static configuration of ipv4 addresses,
and the possibility that available IPsec tools may not support 'inner'
and 'outer' tunnel addresses of different protocols, is there any reason
that *something like this* should not work in theory? Hope I'm not
displaying total ignorance of the basics here.
E.g. what I have in mind:
1. IPv4 Application --> IPv4(src=ipv4_oops, dst=ipv4_crash) --> IPSec tunnel
2. IPSec tunnel --> IPv6(src=hit_oops, dst=hit_crash, {IPv4(...)}) -->
IPSec beet mode (HIP)
3. IPsec beet mode (HIP) --> IPv6(src=ipv6_oops, dst=ipv6_crash,
{IPv4(...)}) --> eth0
{...} denotes encrypted payload
\steve
Other related posts:
