[hipl-users] Re: HIP update packages
- From: KKloe Kaishoto <kaishos@xxxxxxxxx>
- To: hipl-users@xxxxxxxxxxxxx
- Date: Fri, 26 Feb 2010 00:10:10 +0100
yeah I know about the relay, the thing is that they want to avoid any kind
of pre-registration to a middlebox(at most the middlebox should be able to
do its own dns query for mutiple hops between middleboxes) otherwise I would
just have presented the relay for them :)
On Thu, Feb 25, 2010 at 5:26 PM, Miika Komu <miika.komu@xxxxxxx> wrote:
> On 25/02/10 18:01, KKloe Kaishoto wrote:
>
> Hi,
>
> I forgot to mention explicitly that the Relay defined in the NAT traversal
> draft requires registration using a base exchange before it is willing to
> relay any traffic. This is required only to the Responder side. It increases
> security because the Responder can be authenticated with its public key (or
> HIT).
>
> Hallo.
>>
>> Ok thanks, was just wondering about question 2 mostly, we have done the
>> middlebox as far as our coding goes and are just writting now the paper
>> only and one of the questions were how secure the support of mobility in
>> the gateway/middlebox were. Can now write about rfc5206 for future works.
>> As we were working with HIPL code version 1.0.4 release 42 and have done
>> a simple relay in theory for update packages as it wasnt implemented by
>> that time.
>> Can say that our gateway/middlebox support the handshake and esp relaying.
>>
>> On Thu, Feb 25, 2010 at 3:51 PM, Miika Komu <miika.komu@xxxxxxx
>> <mailto:miika.komu@xxxxxxx>> wrote:
>>
>> On 02/25/2010 03:00 PM, KKloe Kaishoto wrote:
>>
>> Hi,
>>
>>
>> Hi.
>>
>> I got a questions about HIP and updates.
>>
>> I can start with that me and a friend have done thesis work for a
>> company here to implement a gateway so that a IPv4 only host can
>> communicate with a IPv6 only host using HIP, we are using
>> parameters we
>> have defined ourself and by people here.
>> In the gateway there will be an association between the hosts
>> that looks
>> like this:
>> Say we have hosts A and B and in the databse of the gateway
>> there will
>> be this connection.
>>
>> (A) IPv4 adress + ESP spi <--> (B) IPv6 adresss + ESP spi
>>
>> (there is for now only one unique SPI in the database so
>> collsions may
>> occour).
>>
>>
>> please have a look at the SPINAT paper for SPI collisions:
>>
>> http://lib.tkk.fi/Diss/2008/isbn9789512295319/article7.pdf
>>
>> In my opinion, SPINAT is a bit overkill if you use UDP encapsulation
>> for IPv4 traffic and make sure that the gateway tracks also the UDP
>> port numbers.
>>
>>
>> Thus if a A send a ESP packet to B, the gateway will match the
>> IP and
>> SPI and know where to send it.
>>
>>
>> Abstractly speaking, this sounds a bit like the combination of these:
>>
>> http://tools.ietf.org/html/draft-ietf-hip-nat-traversal
>> http://tools.ietf.org/html/draft-ietf-behave-turn
>>
>> Teredo [RFC4380] also supports commercial relays that can achieve
>> the same functionality. Teredo is protocol independent. Linux has
>> also a Teredo implementation called Miredo.
>>
>> We gave up maintaining the NAT traversal code based on
>> draft-ietf-hip-nat-traversal. However, the HIP relay code is still
>> in HIPL code and we actually hacked hipfw to support also ESP
>> relaying. The code is nearly completed (see bug id 871). This
>> actually sounds even at a technical level very similar what you're
>> doing. If this is interesting, I can give you more information.
>>
>>
>> Now when a UPDATE comes from let say host B and host B has
>> changed the
>> IP address, the package will be relayed but host A in this case
>> will see
>> that it got an update package with the same IP adress in the IP
>> header
>> i.e. the IP in the IP header to A will be the one of the gateway.
>> My questions are:
>> 1. How will host A behave?
>>
>>
>> You can dig up the standards-compliant answer from RFC5206. Tom
>> Henderson is lurking on this mailing list and perhaps he can give
>> you a direct answer?
>>
>> AFAIK, current HIPL code will just reply to the UPDATE. Right, Baris?
>>
>>
>> 2. The change will have to be in the gateway, but as the gateway
>> doesnt
>> have any idea on how to do any verification of packages, should
>> it set
>> up a new associtaion based on the third update package(that is
>> sent from
>> the host B in this, i.e. the one containing an ack)?, if so, how
>> would
>> it impact on security?
>>
>> Couldnt find any answer to question 1 when trying to search for it.
>>
>>
>> If the gateway tracks the UPDATE packets and verifies the
>> signatures, it can authenticate the mobile node in a secure way. The
>> hipfw module in HIPL supports also tracking of connections like this.
>>
>> If you want to achieve more robust middlebox security, I recommend
>> having a look at:
>>
>>
>> http://www.ds-group.info/members/heer/publications-tobias-heer/pdfs/end-host-authentication-and-authorization-for-middleboxes-based-on-a-cryptographic-namespace.pdf
>> http://tools.ietf.org/html/draft-heer-hip-middle-auth
>>
>>
>>
>
>
Other related posts:
