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

From: [email-masked] (Henderson, Thomas R)
Date: Thu Jul 15 22:53:01 2004

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]
> Sent: Thursday, July 15, 2004 8:06 AM
> To: marcelo bagnulo braun
> Cc: Henderson, Thomas R; [email-masked]
> Subject: Re: [Hipsec] (not) using HITs as an application identifier
>=20
>=20
> Hi Marcelo,
>=20
> 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?
>=20
> The administrator knows.=20
>=20
> For example I know that FTP uses referrals.=20
>=20
> An heuristic for finding them might be: Does it breaks with NATs?=20
>=20

I don't really know how I would distinguish between referral aps=20
and non-referral apps from within the kernel, or how to wrap them=20
as you mentioned.  Perhaps I don't fully understand.

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 =
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)

=20

---

From: [email-masked] (marcelo bagnulo braun)
Date: Mon Jul 19 12:11:29 2004

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

>> 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

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

> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories.
>
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>