[Hipsec] (not) using HITs as an application identifier

[[e-mail] (marcelo bagnulo braun)]

El 16/07/2004, a las 0:20, Henderson, Thomas R escribi=F3:

>
>
>> -----Original Message-----
>> From: Julien Laganier [mailto:[e-mail]]
>> Sent: Thursday, July 15, 2004 8:06 AM
>> To: marcelo bagnulo braun
>> Cc: Henderson, Thomas R; [e-mail]
>> Subject: Re: [Hipsec] (not) using HITs as an application identifier
>>
>>
>> Hi Marcelo,
>>
>> On Thursday 15 July 2004 16:07, marcelo bagnulo braun wrote:
>>>
>>>
>>>> I think we mostly agree. My main disagreement was on the scope of
>>>> the change. You are proposing a HIP-wide change whereas I propose
>>>> a referral-application-wide change.
>>>
>>> But, how do you know if the app is planning to do a refferal or
>>> not?
>>
>> The administrator knows.
>>
>> For example I know that FTP uses referrals.
>>
>> An heuristic for finding them might be: Does it breaks with NATs?
>>
>
> I don't really know how I would distinguish between referral aps
> and non-referral apps from within the kernel, or how to wrap them
> as you mentioned.  Perhaps I don't fully understand.
>

My understanding is this would work similar to a NAT placed within the=20=

host.
So the wrap would inspect the contents of the packets and if it=20
recognizes one of the apps that the admin has designed as "refferal=20
apps" then it would substitute the AID for routable AIDs

Another possibility is that the resolver is capable of recognizing=20
"refferal apps", so when one of the "refferal  apps" asks the resolver,=20=

the resolver returns a routable AID instead of the HIT.

In any case, this at least requires manual configuration of what are=20
the apps that require refferals are.

There is an additional problem though, with long lived communications=20
(as you explained in your initial email)
Not only the apps that use refferals have problems but also the apps=20
that have long lived communications, with long periods of inactivity=20
also have problems with the garbage collection mechanisms.
I guess that it would also be required that the administrator defines=20
which apps fall in this category, but i am afraid that this will be=20
harder than identifying refferal apps.

Regards, marcelo


> Anyway, for those interested more on this topic, a new I-D was
> just announced to multi6 group and ietf-announce:
>
> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
>
>
> 	Title		: Considerations on HIP based IPv6 multi-homing
> 	Author(s)	: P. Nikander, T. Henderson
> 	Filename	: draft-nikander-multi6-hip-01.txt
> 	Pages		: 30
> 	Date		: 2004-7-15
> =09
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt
>
>
> Changelog:
>
>    Changes between this version (-01) and -00 draft
>
>       - added Section 2.6 comparing HIP with other group F multi6
>       proposals
>
>       - added Section 3.3 describing how HIP could be possibly changed
>       to include routable AIDs
>
>       - updated references to HIP WG and HIP RG (Section 1.2)
>
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>