Subject: [Hipsec-rg] HIP and Mobile IP
From: [email-masked] (Morelli Mario)
Date: Thu Mar 31 02:16:01 2005

Hi.

It is first time I write in this Mailing List, so sorry if I missed some
previous email on this topic.

Here in our lab we are starting to compare these solutions to understand
which are the pros and cons and try to understand where we can use them.
No clear idea up to now on a combination of them, but maybe some
discussion could be useful.

Regards.

--Mario

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andrei Gurtov
Sent: Tuesday, March 22, 2005 4:10 PM
To: Joseph
Cc: [email-masked]
Subject: Re: [Hipsec-rg] HIP and Mobile IP

Hi,

Why would you want to combine MIP and HIP? So far the understanding has
been that they are two different solutions to a problem and cannot
really be used together. Can you give some scenarios where a combination
could be useful?

The ID is really only an outline now, the plan is to submit a more
complete version by summer.

Andrei

Joseph wrote:

> Dear All,
> Is there any information about the combinations of HIP and Mobile IP?=20
> In the section 3.2 of ID -- "Generalizing the HIP base protocol", it=20
> mentioned that "HIP/Mobile IP, as presently defined, Mobile IP with=20
> Route Optimization resembles HIP mobility......" Where can I find the=20
> more details of it ?As section 4.2.1 Securing MIPv6 Bidning update=20
> just give a very general information only Thanks.
> Yours,
> Joseph

_______________________________________________
Hipsec-rg mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec-rg

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia =
S.p.A.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: [email-masked] (Pekka Nikander)
Date: Wed Mar 23 05:30:01 2005
Subject: [Hipsec-rg] New Mailing List: IRTF-Announce
Message-ID: <[email-masked]>

On Aaron's behalf:

A new mailing list has been created to inform the Internet community
of activities relating to the Internet Research Task Force. This
broadcast list will receive notices of IRTF Research Group creation
and termination, document publication, invitations for feedback and
participation, and other IRTF activities. Subscription to this list
is list is open to anyone. Posting to this list is at the discretion
of the IRTF Chair.

Subscription URL:
https://www1.ietf.org/mailman/listinfo/irtf-announce

Archive URL:
http://www1.ietf.org/mail-archive/web/irtf-announce/current/index.html

Please forward this notice to Internet research communities who might
find it of interest.

--Aaron
IRTF Chair

From: [email-masked] (Henderson, Thomas R)
Date: Tue Mar 22 12:51:00 2005
Subject: [Hipsec-rg] HIP and Mobile IP
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: Wassim Haddad [mailto:[email-masked]]=20
> Sent: Tuesday, March 22, 2005 9:36 AM
> To: Henderson, Thomas R
> Cc: [email-masked]; Andrei Gurtov; Joseph
> Subject: Re: [Hipsec-rg] HIP and Mobile IP
>=20
> Hello Thomas,
>=20
>=20
> On 22-Mar-05, at 12:23 PM, Henderson, Thomas R wrote:
>=20
> > > -----Original Message-----
> > > From: Andrei Gurtov [mailto:[email-masked]]
> > > Sent: Tuesday, March 22, 2005 7:10 AM
> > > To: Joseph
> > > Cc: [email-masked]
> > > Subject: Re: [Hipsec-rg] HIP and Mobile IP
> > >
> > > Hi,
> > >
> > > Why would you want to combine MIP and HIP? So far the=20
> understanding=20
> > > has been that they are two different solutions to a problem and=20
> > > cannot really be used together. Can you give some=20
> scenarios where a=20
> > > combination could be useful?
> >
> > The point I wanted to make in the draft is that MIP-RO and HIP=20
> > mobility are similar.=A0 The main differences are in the upper layer =

> > identifiers used, and the technique used to authenticate=20
> the binding=20
> > update.=A0 If HIP were generalized to allow home addresses as=20
> the ULIDs=20
> > (instead of HITs), then HIP protocols might be useful as an=20
> > alternative to existing MIP-RO protocols.=A0 Note that I say *might* =

> > since careful analysis of this has not been done-- it is just a=20
> > possibility, and maybe it is a bad idea.
> >
> > Why might one want to do this?
> > - HIP handshake has different security properties than MIP-RO=20
> > handshake (may improve robustness against certain attacks on the=20
> > authentication
> > protocol)
> > - Performance may improve over existing MIP-RO design (avoidance of=20
> > need to send messages through a home agent upon every=20
> address change).=A0=20
> > For example, an initial DH exchange through the home network might=20
> > provide the authentication context for some or all future binding=20
> > updates.
>=20
> =3D> Note that OMIPv6-CGA does not require any signaling=20
> through the HA except for the *first* handover and provides=20
> one long lifetime shared secret (24
> hours) to authenticate
> subsequent BU/BAs.
>=20

Agreed-- there is also the precomputed Kbm draft that could optimize =
this exchange.  Also, there is a MIPv6 draft for mobile node NAI option =
that seems extensible for other identifiers in the future.  There seem =
to be several parallels between emerging MIPv6 designs and some of the =
HIP designs.

Tom

From: [email-masked] (Wassim Haddad)
Date: Tue Mar 22 12:35:01 2005
Subject: [Hipsec-rg] HIP and Mobile IP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello Thomas,

On 22-Mar-05, at 12:23 PM, Henderson, Thomas R wrote:

> > -----Original Message-----
> > From: Andrei Gurtov [mailto:[email-masked]]
> > Sent: Tuesday, March 22, 2005 7:10 AM
> > To: Joseph
> > Cc: [email-masked]
> > Subject: Re: [Hipsec-rg] HIP and Mobile IP
> >
> > Hi,
> >
> > Why would you want to combine MIP and HIP? So far the
> > understanding has been that they are two different solutions
> > to a problem and cannot really be used together. Can you give
> > some scenarios where a combination could be useful?
>
> The point I wanted to make in the draft is that MIP-RO and HIP =
mobility
> are similar.=A0 The main differences are in the upper layer =
identifiers
> used, and the technique used to authenticate the binding update.=A0 =
If=20
> HIP
> were generalized to allow home addresses as the ULIDs (instead of=20
> HITs),
> then HIP protocols might be useful as an alternative to existing =
MIP-RO
> protocols.=A0 Note that I say *might* since careful analysis of this =
has
> not been done-- it is just a possibility, and maybe it is a bad idea.
>
> Why might one want to do this?
> - HIP handshake has different security properties than MIP-RO =
handshake
> (may improve robustness against certain attacks on the authentication
> protocol)
> - Performance may improve over existing MIP-RO design (avoidance of=20
> need
> to send messages through a home agent upon every address change).=A0 =
For
> example, an initial DH exchange through the home network might =
provide
> the authentication context for some or all future binding updates.

=3D> Note that OMIPv6-CGA does not require any signaling through the HA =

except for
the *first* handover and provides one long lifetime shared secret (24=20
hours) to authenticate
subsequent BU/BAs.

Regards,

Wassim H.

From: [email-masked] (Henderson, Thomas R)
Date: Tue Mar 22 12:25:01 2005
Subject: [Hipsec-rg] HIP and Mobile IP
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: Andrei Gurtov [mailto:[email-masked]]=20
> Sent: Tuesday, March 22, 2005 7:10 AM
> To: Joseph
> Cc: [email-masked]
> Subject: Re: [Hipsec-rg] HIP and Mobile IP
>=20
> Hi,
>=20
> Why would you want to combine MIP and HIP? So far the=20
> understanding has been that they are two different solutions=20
> to a problem and cannot really be used together. Can you give=20
> some scenarios where a combination could be useful?

The point I wanted to make in the draft is that MIP-RO and HIP mobility
are similar.  The main differences are in the upper layer identifiers
used, and the technique used to authenticate the binding update.  If HIP
were generalized to allow home addresses as the ULIDs (instead of HITs),
then HIP protocols might be useful as an alternative to existing MIP-RO
protocols.  Note that I say *might* since careful analysis of this has
not been done-- it is just a possibility, and maybe it is a bad idea.

Why might one want to do this?
- HIP handshake has different security properties than MIP-RO handshake
(may improve robustness against certain attacks on the authentication
protocol)
- Performance may improve over existing MIP-RO design (avoidance of need
to send messages through a home agent upon every address change).  For
example, an initial DH exchange through the home network might provide
the authentication context for some or all future binding updates.
- There may be an infrastructure of home agents (or home agent
functionality) deployed already
- Provides a stepping stone to transitioning to the use of key-based
host identities in the future. =20

I do not have a published reference for such combination as described in
my draft-- it has only been subject of some conversations. =20

Tom

From: [email-masked] (Andrei Gurtov)
Date: Tue Mar 22 10:11:01 2005
Subject: [Hipsec-rg] HIP and Mobile IP
In-Reply-To: <012201c52dbb$f8962190$c477aa83@b0870300103>
References: <012201c52dbb$f8962190$c477aa83@b0870300103>
Message-ID: <[email-masked]>

Hi,

Why would you want to combine MIP and HIP? So far the understanding has
been that they are two different solutions to a problem and cannot
really be used together. Can you give some scenarios where a combination
could be useful?

The ID is really only an outline now, the plan is to submit a more
complete version by summer.

Andrei

Joseph wrote:

> Dear All,
> Is there any information about the combinations of HIP and Mobile IP?
> In the section 3.2 of ID -- "Generalizing the HIP base protocol", it
> mentioned that "HIP/Mobile IP, as presently defined, Mobile IP with
> Route Optimization resembles HIP mobility......" Where can I find the
> more details of it ?As section 4.2.1 Securing MIPv6 Bidning update
> just give a very general information only
> Thanks.
> Yours,
> Joseph

From: [email-masked] (Niklas Karlsson)
Date: Tue Mar 22 01:17:01 2005
Subject: [Hipsec-rg] Thesis on Multiple Host Identities
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello,

I'm happy to introduce myself to this list. I am participating in the 
InfraHIP project (http://hipl.hiit.fi/) at Helsinki University of Technology 
and I am currently working on my Master's thesis on multiple Host 
Identities per host.

The main goal of my work is to enable support for multiple HIs in the HIPL
(HIP for Linux) implementation. The work relates closely to the native HIP 
API introduced by Miika Komu. Advanced HIP aware applications should be able 
to bind to any local HI by using the API.

I intend to finish my work this summer.

-- 
Niklas Karlsson           [email-masked]

From: [email-masked] (Greg Perkins)
Date: Mon Mar 21 13:21:01 2005
Subject: [Hipsec-rg] Re: [Hipsec] Session identifiers (was Re: sticking with 128-bit HITs)
References: <[email-masked]> <01c501c52b24$ff6f52f0$ef01a996@gmp> <[email-masked]>
Message-ID: <025201c52e44$e02f0980$ef01a996@gmp>

Pekka,

You are correct.  These belong on HIP-RG.  I'll continue any email discusion
on this there.

Greg

----- Original Message ----- 
From: "Pekka Nikander" <[email-masked]>
To: "Greg Perkins" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, March 21, 2005 8:25 AM
Subject: [Hipsec] Session identifiers (was Re: sticking with 128-bit HITs)

> Greg,
>
> The ideas you have sound interesting and worth investigating,
> but I'm afraid they fall beyond the current WG charter.  Hence,
> maybe this discussion should be moved to the RG side?
>
> In general, I think it would be a good idea if people worked
> out on alternatives to the current HIP protocol.  The questions
> about Service and Session identifiers are important, and IMHO
> not well enough thought out in the current HIP architecture.
>
> --Pekka
>
> On Mar 17, 2005, at 21:10, Greg Perkins wrote:
>
> > I mostly agree with this but there may be an issue with long-term
> > HI/HIT
> > use.  I like the idea of having a long-term HI, one I can hand-out
> > because
> > it will last years.  In such a use-case it would be a pain if someone
> > managed to duplicate my HIT and thus I'd be forced to make a new
> > HI/HIT and
> > hand it out all over again.  I don't consider this critical but it
> > would be
> > nice if a HI could last for a long period of time IMO.
> >
> > Also, I have started to consider whether or not it is a good idea to
> > use an
> > HIT in the HIP exchange/control packets.  The use of a random HIP
> > session
> > identifier (around 64-96 bits in length) might work out better.
> > During the
> > base exchange you'd have to send your HI in the I2 packet.  The R2
> > packet
> > would contain a session key to be used to mask your HIP session
> > identifier.
> > The SPI index is then used to decrypt the encrypted HIP session
> > indentifier,
> > that is included in every HIP packet header.  The HIP session
> > identifier
> > (HSI) can then be used as the pointer to the HI and also as an index
> > for
> > applications.  I am still mulling this over, and am really just being a
> > devil's advocate atm because I like HITs because of their
> > cryptographic link
> > to the HI.  But, a HSI has the following benefits:
> >
> > - an HSI is a temporary value so even if an attacker attains one he
> > can only
> > do harm to the current HIP session
> > - fewer bits needed for identifier.  64 bits would be more than enough
> > because the value is session oriented and thus discarded after use.
> > Therefore, we could use 64 bits of the IPv6 source address space for
> > an HSI
> > and use the other 64 bits for other uses like LSIs.
> > - using an XOR mask is a cheap yet strong method for protecting the
> > HSI.
> > - for legacy applications you could probably make the HSI an IP
> > address,
> > though I don't know how HIP could be signaled so that it does this in
> > an
> > appropriate way (security gets thrown away of course)
> >
> > In this scenario a HIT is used mainly for lookup at the DNS (or
> > wherever)
> > and thus can use 128 or 256 bit hash as needed.
> >
> > I now await a counter-argument in support of HITs.  The crypto-graphic
> > link
> > to an HI is the strong-point IMO but with hashes under heavy attack,
> > such a
> > link may not be all that secure.  Thus, we either need more bits, live
> > with
> > less security or maybe use a different identifier.
> >
> > Greg
> >
> > ----- Original Message -----
> > From: "Tim Shepard" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Thursday, March 17, 2005 11:23 AM
> > Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? )
> >
> >
> >>
> >> I said and have been been quoted as saying:
> >>
> >>>>> Implications for HIP
> >>>>> --------------------
> >>>>>
> >>>>> For HIP I think we need to be able to handle longer HITs, and I
> >>>>> think we need a way of encoding in the HIT itself (in an
> >>>>> unambiguous way) what hash function it is that is supposed to
> >>>>> demonstrate the binding of the HIT to a public key.  (Otherwise, a
> >>>>> weakness in one hash function might allow you to create a public
> >>>>> key which can be "demonstrated" to be bound to a HIT that was
> >>>>> created with a different hash function.)
> >>
> >> After discussing this with a number of people at IETF62 who are
> >> more of a cryptographer than I am, I am now not certain that we
> >> need to make HITs any longer than they are now.  It may be
> >> reasonable to have only around 120 bits of hash function output
> >> incorporated into the HIT.
> >>
> >> If that is secure enough, there may be significant advantages to
> >> keeping HITs at a fixed length of 128 bits.
> >>
> >> My understanding now is that 80 bits of good hash function output is
> >> sufficient today, and with a simpleminded extrapolation of needing
> >> another bit every 18 months (for Moore's law), 120-bits of good hash
> >> function output should be good until around the year 2065.  So
> >> perhaps we can save extending the HIT to be greater than 128 bits
> >> for some future rev of the relevant protocols.  (Or are we trying to
> >> design protocols that will last for a 100 years or more?)
> >>
> >> I do however still believe that we need an unambiguous tag in the
> >> HIT that tells you how it was generated (which hash function was
> >> used, and perhaps how it was used).  IMHO we need at least four
> >> bits of such a tag, and preferably a few more than that.
> >>
> >> And there's also the desire some have to squeeze HITs into the
> >> IPv6 unicast address space somewhere so that they can be passed
> >> across IPv6 related APIs, so that may burn a few top bits of
> >> the HIT.
> >>
> >> -Tim Shepard
> >> [email-masked]
> >> _______________________________________________
> >> Hipsec mailing list
> >> [email-masked]
> >> http://honor.trusecure.com/mailman/listinfo/hipsec
> >>
> >
> > _______________________________________________
> > Hipsec mailing list
> > [email-masked]
> > http://honor.trusecure.com/mailman/listinfo/hipsec
> >
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 21 08:26:00 2005
Subject: [Hipsec-rg] Session identifiers (was Re: sticking with 128-bit HITs)
In-Reply-To: <01c501c52b24$ff6f52f0$ef01a996@gmp>
References: <[email-masked]> <01c501c52b24$ff6f52f0$ef01a996@gmp>
Message-ID: <[email-masked]>

Greg,

The ideas you have sound interesting and worth investigating,
but I'm afraid they fall beyond the current WG charter.  Hence,
maybe this discussion should be moved to the RG side?

In general, I think it would be a good idea if people worked
out on alternatives to the current HIP protocol.  The questions
about Service and Session identifiers are important, and IMHO
not well enough thought out in the current HIP architecture.

--Pekka

On Mar 17, 2005, at 21:10, Greg Perkins wrote:

> I mostly agree with this but there may be an issue with long-term 
> HI/HIT
> use.  I like the idea of having a long-term HI, one I can hand-out 
> because
> it will last years.  In such a use-case it would be a pain if someone
> managed to duplicate my HIT and thus I'd be forced to make a new 
> HI/HIT and
> hand it out all over again.  I don't consider this critical but it 
> would be
> nice if a HI could last for a long period of time IMO.
>
> Also, I have started to consider whether or not it is a good idea to 
> use an
> HIT in the HIP exchange/control packets.  The use of a random HIP 
> session
> identifier (around 64-96 bits in length) might work out better.  
> During the
> base exchange you'd have to send your HI in the I2 packet.  The R2 
> packet
> would contain a session key to be used to mask your HIP session 
> identifier.
> The SPI index is then used to decrypt the encrypted HIP session 
> indentifier,
> that is included in every HIP packet header.  The HIP session 
> identifier
> (HSI) can then be used as the pointer to the HI and also as an index 
> for
> applications.  I am still mulling this over, and am really just being a
> devil's advocate atm because I like HITs because of their 
> cryptographic link
> to the HI.  But, a HSI has the following benefits:
>
> - an HSI is a temporary value so even if an attacker attains one he 
> can only
> do harm to the current HIP session
> - fewer bits needed for identifier.  64 bits would be more than enough
> because the value is session oriented and thus discarded after use.
> Therefore, we could use 64 bits of the IPv6 source address space for 
> an HSI
> and use the other 64 bits for other uses like LSIs.
> - using an XOR mask is a cheap yet strong method for protecting the 
> HSI.
> - for legacy applications you could probably make the HSI an IP 
> address,
> though I don't know how HIP could be signaled so that it does this in 
> an
> appropriate way (security gets thrown away of course)
>
> In this scenario a HIT is used mainly for lookup at the DNS (or 
> wherever)
> and thus can use 128 or 256 bit hash as needed.
>
> I now await a counter-argument in support of HITs.  The crypto-graphic 
> link
> to an HI is the strong-point IMO but with hashes under heavy attack, 
> such a
> link may not be all that secure.  Thus, we either need more bits, live 
> with
> less security or maybe use a different identifier.
>
> Greg
>
> ----- Original Message -----
> From: "Tim Shepard" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 17, 2005 11:23 AM
> Subject: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? )
>
>
>>
>> I said and have been been quoted as saying:
>>
>>>>> Implications for HIP
>>>>> --------------------
>>>>>
>>>>> For HIP I think we need to be able to handle longer HITs, and I
>>>>> think we need a way of encoding in the HIT itself (in an
>>>>> unambiguous way) what hash function it is that is supposed to
>>>>> demonstrate the binding of the HIT to a public key.  (Otherwise, a
>>>>> weakness in one hash function might allow you to create a public
>>>>> key which can be "demonstrated" to be bound to a HIT that was
>>>>> created with a different hash function.)
>>
>> After discussing this with a number of people at IETF62 who are
>> more of a cryptographer than I am, I am now not certain that we
>> need to make HITs any longer than they are now.  It may be
>> reasonable to have only around 120 bits of hash function output
>> incorporated into the HIT.
>>
>> If that is secure enough, there may be significant advantages to
>> keeping HITs at a fixed length of 128 bits.
>>
>> My understanding now is that 80 bits of good hash function output is
>> sufficient today, and with a simpleminded extrapolation of needing
>> another bit every 18 months (for Moore's law), 120-bits of good hash
>> function output should be good until around the year 2065.  So
>> perhaps we can save extending the HIT to be greater than 128 bits
>> for some future rev of the relevant protocols.  (Or are we trying to
>> design protocols that will last for a 100 years or more?)
>>
>> I do however still believe that we need an unambiguous tag in the
>> HIT that tells you how it was generated (which hash function was
>> used, and perhaps how it was used).  IMHO we need at least four
>> bits of such a tag, and preferably a few more than that.
>>
>> And there's also the desire some have to squeeze HITs into the
>> IPv6 unicast address space somewhere so that they can be passed
>> across IPv6 related APIs, so that may burn a few top bits of
>> the HIT.
>>
>> -Tim Shepard
>> [email-masked]
>> _______________________________________________
>> Hipsec mailing list
>> [email-masked]
>> http://honor.trusecure.com/mailman/listinfo/hipsec
>>
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 21 08:13:01 2005
Subject: [Hipsec-rg] Changing HIP RG co-chair
Message-ID: <[email-masked]>

Folks,

Due to my recently increased IETF workload I would like to
step down from co-chairing the HIP RG.  Tom is planning to
continue.  According to RFC2014 Section 4, new Research
Group chairs are chosen by the IRTF Chair in consultation
with the Group.

I have discussed the issue with Tom and Aaron (the new IRTF
chair), and we are proposing to the group that new co-chair,
replacing me, would be Andrei Gurtov from Helsinki Institute
for Information Technology.

What do other people in the RG think?  Feel free to reply
either do the list or privately to Aaron / Tom / me.

--Pekka

From: [email-masked] (Joseph)
Date: Sun Mar 20 21:17:01 2005
Subject: [Hipsec-rg] HIP and Mobile IP
Message-ID: <012201c52dbb$f8962190$c477aa83@b0870300103>

This is a multi-part message in MIME format.

------=_NextPart_000_011F_01C52E18.2BBA4E50
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Dear All,
    Is there any information about the combinations of HIP and Mobile =
IP? In the section 3.2 of ID -- "Generalizing the HIP base protocol", it =
mentioned that "HIP/Mobile IP, as presently defined, Mobile IP with =
Route Optimization resembles HIP mobility......" Where can I find the =
more details of it ?As section 4.2.1 Securing MIPv6 Bidning update just =
give a very general information only
    Thanks.
Yours,
Joseph
------=_NextPart_000_011F_01C52E18.2BBA4E50
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dbig5">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Is there any =
information about=20
the combinations of HIP and Mobile IP? In the section 3.2 of ID -- =
"Generalizing=20
the HIP base protocol", it mentioned that "HIP/Mobile IP, as presently =
defined,=20
Mobile IP with Route Optimization resembles HIP mobility......" Where =
can I find=20
the more details of it ?As section 4.2.1 Securing MIPv6 Bidning update =
just give=20
a very general information only</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Thanks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Yours,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Joseph</FONT></DIV></BODY></HTML>

------=_NextPart_000_011F_01C52E18.2BBA4E50--

From: [email-masked] (Pekka Nikander)
Date: Sun Mar 13 08:17:01 2005
Subject: [Hipsec-rg] Anyone took any notes, please send them to me
Message-ID: <[email-masked]>

I've got some notes (thanks Mika!) from the HIP-RG session on
Friday, but could definitely use more.  So, if you took any notes,
however partial and however badly written or formatted, please
consider sharing them with me.  I will process all notes that
I get and produce the best minutes I can, both using notes and
my own memories.  However, more than one set of written ones
would help a lot.

If you have taken notes and decide to share them with me, you
will be credited with your name in the IETF proceedings (where
the minutes will be included) without any extra work, while you
don't need to be afraid that raw notes would become public.
Nobody else but I will see them.  OTOH, if you want to keep your
name withdrawn that's also fine.

--Pekka

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 11 10:28:01 2005
Subject: [Hipsec-rg] HIP RG today starts at 1230, not 1300 as listed in Agenda
Message-ID: <[email-masked]>

The agenda lists the HIP RG to start at 1300, and lists
last meeting's agenda.  However, we *are* starting
already at 1230, not 1300 as listed.  See the archive
for the proposed agenda:

http://honor.trusecure.com/pipermail/hipsec-rg/2005-February/000146.html

Tom is back home so I will be chairing.

--Pekka

From: [email-masked] (Miika Komu)
Date: Mon Mar  7 12:07:00 2005
Subject: [Hipsec-rg] native HIP API draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I apologize for this late unofficial submission, but here's some material
for my slot in the RG session:

http://www.iki.fi/miika/docs/draft-mkomu-hip-native-api-00-pre1.txt

Basically, the above draft is my thesis converted to draft format, but not
all sections are included. I also applied some fixes based on the RG
feedback. The final version of my thesis (with all sections) can be found
from:

http://infra.hiit.fi/hipl/hip-native-api-final.pdf

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/