Subject: [Hipsec-rg] hiprg meeting Nov. 12
From: [email-masked] (Henderson, Thomas R)
Date: Fri Oct 29 16:42:06 2004

We received confirmation today on our requested Nov. 12=20
slot for the HIP RG meeting:

FRIDAY, November 12, 2004
1300-1530 Afternoon Session
	IRTF 	hiprg 	Host Identity Protocol RG

We are presently finalizing the agenda and will post it ASAP.

Tom

From: [email-masked] (Jari Arkko)
Date: Fri Oct 29 02:31:00 2004
Subject: [Hipsec-rg] Ask for comment about handoff analysis
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I believe you need to take into account a number
of factors. Packet lengths and crypto time are
(IMHO) not the most important things. Probably
latency issues are priority 1 for most people,
but you mileage may vary. And there components
in the latency and other characteristics of
handoffs that are common to HIP and other
approaches. See

   http://www.ietf.org/internet-drafts/draft-arkko-mip6-ro-enhancements-00.txt

for a discussion of handoff related performance
goals, as well as some breakdown of issues affecting
this and solution components for improvements, from
the Mobile IPv6 point of view.

Joseph So wrote:
> Dear All,
>   I'm trying to do the analysis of HIP with other protocol and prove that
> HIP can do better handoff. If by analysis and compare with other protocols,
> what is the packet length I should choose, with or without HIP_Signature and
> HIMAC? (Without: 40 , with 40+20+40). I found some paper just choose part of
> the packet to compare (like SIP, they will use only 140bytes (SDP message)
> to compare with other protocol to prove they are better)
>   Can anyone give me some suggestion? Because HIMAC and HIP_Signature will
> be the analysis completely different. 
>   Thanks a lot
> Yours,
> Joseph
> 

From: [email-masked] (Joseph So)
Date: Fri Oct 29 00:52:00 2004
Subject: [Hipsec-rg] Ask for comment about handoff analysis
Message-ID: <[email-masked]>

Dear All,
  I'm trying to do the analysis of HIP with other protocol and prove that
HIP can do better handoff. If by analysis and compare with other protocols,
what is the packet length I should choose, with or without HIP_Signature and
HIMAC? (Without: 40 , with 40+20+40). I found some paper just choose part of
the packet to compare (like SIP, they will use only 140bytes (SDP message)
to compare with other protocol to prove they are better)
  Can anyone give me some suggestion? Because HIMAC and HIP_Signature will
be the analysis completely different. 
  Thanks a lot
Yours,
Joseph

-- 
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!

From: [email-masked] (Mika Kousa)
Date: Tue Oct 26 04:05:00 2004
Subject: [Hipsec-rg] About the Update REA package
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 26 Oct 2004, Joseph So wrote:

-> Dear All,
->   I'm trying to analysis about handoff in HIP. I'm calcualte the package
-> length. In the draft-ietf-hip-mm-00,it mentioned that "Any UPDATE packet
-> that includes a REA parameter SHOULD include both an HMAC and a
-> HIP_SIGNATURE. What is a typical lenght of HIP_SIGNATURE, in the
-> draft-ietf-hip-base-00, it said that it is variable.

At least in the packets I see my packet captures, the length of the 
HIP_SIGNATURE parameter seems to be 48 bytes using DSA.

->   Futhermore, can anyone give the comment on this? 
->   REA Update package length (Figure 3 in draft-ietf-hip-mm-00, readdress
-> without rekeying, but with address check)=  REA parameter  + HMAC +
-> HIP_SIGNATURE = 32 + 20 + HIP_SIGNATURE

Add SEQ, 8 bytes.

-> min REA parameter = TYPE + Length + SPI + Address Lifetim + Reservered +
-> Address = 2 + 2 + 4 + 4 + 4 + 16 = 32. Is my understanding about the packet
-> of HIP update packet correct? I am trying to compare with other protocols.

Looks like it is right.

From: [email-masked] (Joseph So)
Date: Tue Oct 26 00:45:01 2004
Subject: [Hipsec-rg] About the Update REA package
Message-ID: <[email-masked]>

Dear All,
  I'm trying to analysis about handoff in HIP. I'm calcualte the package
length. In the draft-ietf-hip-mm-00,it mentioned that "Any UPDATE packet
that includes a REA parameter SHOULD include both an HMAC and a
HIP_SIGNATURE. What is a typical lenght of HIP_SIGNATURE, in the
draft-ietf-hip-base-00, it said that it is variable.
  Futhermore, can anyone give the comment on this? 
  REA Update package length (Figure 3 in draft-ietf-hip-mm-00, readdress
without rekeying, but with address check)=  REA parameter  + HMAC +
HIP_SIGNATURE = 32 + 20 + HIP_SIGNATURE
min REA parameter = TYPE + Length + SPI + Address Lifetim + Reservered +
Address = 2 + 2 + 4 + 4 + 4 + 16 = 32. Is my understanding about the packet
of HIP update packet correct? I am trying to compare with other protocols.
  Thanks a lot.
Yours,
Joseph

-- 
Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD
++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++

From: [email-masked] (Henderson, Thomas R)
Date: Mon Oct 25 09:43:01 2004
Subject: [Hipsec-rg] About the performace of HIP
Message-ID: <[email-masked]>

Joseph,
One comparison can be found here:
Henderson, TR, " Host Mobility for IP Networks: A Comparison" IEEE =
Network
Magazine, Vol. 17, No. 6, pp. 18-26, November, 2003.

Tom

> -----Original Message-----
> From: Joseph So [mailto:[email-masked]]=20
> Sent: Monday, October 25, 2004 12:04 AM
> To: [email-masked]
> Subject: [Hipsec-rg] About the performace of HIP
>=20
>=20
> Dear All,
>   I'm trying to understand the performance of HIP. I found=20
> serval papers
> mentioned that "HIP is believed to provide a better=20
> performance than Mobile
> IP". Is there any paper or material compared these two=20
> protocols? In the
> mobility view, which one can handle the handoff better? I=20
> know that if HIP
> will provide a better performance in routing a package than=20
> Mobile IPv4 as
> no triangle routing problem, but how about Mobile IPv6 and HIP?
>   Thanks a lot.
> Joseph
>=20
> --=20
> +++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
> Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
>=20
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>=20

From: [email-masked] (Joseph So)
Date: Mon Oct 25 01:54:00 2004
Subject: [Hipsec-rg] About the performace of HIP
Message-ID: <[email-masked]>

Dear All,
  I'm trying to understand the performance of HIP. I found serval papers
mentioned that "HIP is believed to provide a better performance than Mobile
IP". Is there any paper or material compared these two protocols? In the
mobility view, which one can handle the handoff better? I know that if HIP
will provide a better performance in routing a package than Mobile IPv4 as
no triangle routing problem, but how about Mobile IPv6 and HIP?
  Thanks a lot.
Joseph

-- 
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl

From: [email-masked] (Lars Eggert)
Date: Thu Oct 21 02:30:01 2004
Subject: [Hipsec-rg] [Fwd: I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt]
Message-ID: <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms000709030406040300060203
Content-Type: multipart/mixed;
 boundary="------------010006020209020302000407"

This is a multi-part message in MIME format.
--------------010006020209020302000407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Julien and me have a new problem description draft for HIP resolution 
and rendezvous that is loosely based on our workshop abstract.

The idea is that this draft motivates the general problem and describes 
specific issues. Other documents would then describe specific 
resolution/rendezvous proposals and discuss if and how they address the 
issues. (I had chatted with a few people at the last IETF and they 
seemed to agree that splitting the rendezvous work in this manner may be 
useful.)

We'd be happy to receive feedback; specifically, whether the currently 
identified issues are valid and whether we're missing some?

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------010006020209020302000407
Content-Type: message/rfc822;
 name="I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt"

To: [email-masked]
From: [email-masked]
Date: Wed, 20 Oct 2004 10:35:02 -0400
Subject: I-D ACTION:draft-eggert-hiprg-rr-prob-desc-00.txt
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: HIP Resolution and Rendezvous Problem Description
	Author(s)	: L. Eggert, J. Laganier
	Filename	: draft-eggert-hiprg-rr-prob-desc-00.txt
	Pages		: 12
	Date		: 2004-10-19
	
This document investigates the design space for resolution and
   rendezvous mechanisms for the Host Identity Protocol (HIP.) It
   identifies and describes specific issues that HIP resolution and
   rendezvous mechanisms should address.  These issues include
   dependencies on the DNS, lack of support for direct communication
   based on host identities, lack of a reverse lookup mechanism for host
   identities, and DNS and node rendezvous.

   This document does not propose specific resolution and rendezvous
   mechanisms.  Different alternative solutions will be described and
   discussed in companion documents.  These documents should analyze if
   and to what degree the specific proposals they present address the
   issues identified here.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-eggert-hiprg-rr-prob-desc-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-eggert-hiprg-rr-prob-desc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-eggert-hiprg-rr-prob-desc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-eggert-hiprg-rr-prob-desc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-eggert-hiprg-rr-prob-desc-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------010006020209020302000407--

--------------ms000709030406040300060203
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000709030406040300060203--

From: [email-masked] (Miika Komu)
Date: Wed Oct 20 02:27:02 2004
Subject: [Hipsec-rg] Basic Question about HIP Session
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 20 Oct 2004, Joseph So wrote:

>   Thanks for your answering, so that if there is a communication between a
> HTTP server with HIP support and HTTP client with HIP support, is this
> procedure correct?
> 1. 4-way handshake which initalized by the HTTP client.
> 2. HTTP client sends the HTTP request to server
> 3. HTTP server reply

Yes, this is correct. Naturally, there is also a TCP handshake between 1
and 2.

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

From: [email-masked] (Joseph So)
Date: Wed Oct 20 02:09:01 2004
Subject: [Hipsec-rg] Basic Question about HIP Session
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear Pekka,
  Thanks for your answering, so that if there is a communication between a
HTTP server with HIP support and HTTP client with HIP support, is this
procedure correct?
1. 4-way handshake which initalized by the HTTP client.
2. HTTP client sends the HTTP request to server
3. HTTP server reply

or 2, 1 ,3?

(If the HTTP header is using the HIT/LSI instead of IP addresses)

Thanks a lot.
Yours,
Joseph

> >   Is that all connections no matter in which layer above HIP (Such as 
> > HTTp,
> > FTP, UDP, TCP) established after four-way handshake of HIP? So that no
> > communication between nodes can be made before the four-way handshake 
> > if
> > that is base on HI address?
> 
> If I understand your question correctly, the short answer is "yes".
> However, the base exchange is usually triggered by some app sending
> a first packet to an LSI/HIT.
> 
> --Pekka
> 
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
> 

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

From: [email-masked] (Pekka Nikander)
Date: Wed Oct 20 00:50:01 2004
Subject: [Hipsec-rg] Basic Question about HIP Session
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

>   Is that all connections no matter in which layer above HIP (Such as 
> HTTp,
> FTP, UDP, TCP) established after four-way handshake of HIP? So that no
> communication between nodes can be made before the four-way handshake 
> if
> that is base on HI address?

If I understand your question correctly, the short answer is "yes".
However, the base exchange is usually triggered by some app sending
a first packet to an LSI/HIT.

--Pekka

From: [email-masked] (Joseph So)
Date: Tue Oct 19 21:00:00 2004
Subject: [Hipsec-rg] Basic Question about HIP Session
Message-ID: <[email-masked]>

Dear All,
  Is that all connections no matter in which layer above HIP (Such as HTTp,
FTP, UDP, TCP) established after four-way handshake of HIP? So that no
communication between nodes can be made before the four-way handshake if
that is base on HI address?
Yours,
Joseph

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

From: [email-masked] (Henderson, Thomas R)
Date: Wed Oct 13 09:54:01 2004
Subject: [Hipsec-rg] agenda requests for HIP RG meeting
Message-ID: <[email-masked]>

We have put in a request for a HIP-RG meeting on Friday, November 12
in the afternoon (1-3:30 slot).  So far, that request has not shown
up in the IETF agenda, possibly because IRTF slots are handled with
lower scheduling priority.  If our request is not accepted, we'll let
you know ASAP.

Please send any requests for agenda topics to Pekka or me by the
end of next week.

Thanks,
Tom