Subject: [hiprg] New ID: draft-wang-hiprg-service-overlay-00

From: [email-masked]
Date: Tue, 2 Mar 2010 10:27:33 +0800

Dear all,

A new Internet Draft entitled "HIP Service Overlay Study" has been 
submitted.  It can be accessed at:
http://www.ietf.org/id/draft-wang-hiprg-service-overlay-00.txt

(filename: draft-wang-hiprg-service-overlay-00)
It is a HIP service overlay study document, it presents several 
disadvantages of current HIP protocol and then takes a brief introduction 
of two existing alternative solutions. Finally, we propose a HIP service 
overlay architecture.
Your comments on the proposed mechanism would be highly appreciated. In 
addition, I would be glad to make a small presentation and discuss it in 
the upcoming IETF 77 meeting.

Regards,
Jiong Shen

IETF I-D Submission Tool <[email-masked]> 
2010-03-01 17:55

收件人
[email-masked]
抄送
[email-masked]
主题
New Version Notification for draft-wang-hiprg-service-overlay-00

A new version of I-D, draft-wang-hiprg-service-overlay-00.txt has been 
successfuly submitted by Jiong Shen and posted to the IETF repository.

Filename:                 draft-wang-hiprg-service-overlay
Revision:                 00
Title:                            HIP Service Overlay Study
Creation_date:            2010-03-01
WG ID:                            Independent Submission
Number_of_pages: 10

Abstract:
This draft is a HIP service overlay study document, it presents
several disadvantages of current HIP protocol and then takes a brief
introduction of two existing alternative solutions.  Finally, the
authors propose a HIP service overlay architecture.

The IETF Secretariat.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Miika Komu <[email-masked]>
Date: Tue, 02 Mar 2010 16:30:04 +0200

On 03/02/2010 04:27 AM, [email-masked] wrote:

Hi,

are you familiar with the latest HIP overlay drafts? At least the first
comment...

#1.  Before one host wants to communicate with another host, it MUST
   initiate a HIP 4-way handshake, and then initiate a TCP handshake and
   other transport or application connections.  It leads to a long
   connection delay and downgrades the user experience.

...does not the take into count the following:

http://tools.ietf.org/html/draft-ietf-hip-hiccups-01

Please see also:

http://tools.ietf.org/html/draft-ietf-hip-reload-instance
http://tools.ietf.org/html/draft-ietf-hip-via

Regarding to the third comment, I thing certificates in SIM or smart
cards would do the trick:

   #3.  End-to-End communication model depends on the PKI
   infrastructure, but existing widely deployed telecomm network employs
   pre-shared key security mechanism rather than PKI.  So if HIP can
   support pre-shared key authentication, the existing infrastructure
   can be reused.

HIP keys can be also disseminated via DNS as described in RFC5205.

The RVS mechanism in RFC5204 with double jump support should cover the
following fourth comment:

 #4.  Since HIP mobility mechanism does not use any anchor point, if a
   HIP host's IP address changed, it must sends an update message to its
   connected peer.  Such design makes the mobility possible even if
   infrastructure does not involved, but it also causes two weaknesses:
   1)If the connection peer resides in a different continent or if the
   HIP host has too many connections, the update may be time-consuming
   and leads to very high handover delay. 2)If two hosts of one
   connection change their IP addresses simultaneously, the update could
   never be successful.

> disadvantages of current HIP protocol and then takes a brief 
> introduction of two existing alternative solutions. Finally, we propose 
> a HIP service overlay architecture.
> *IETF I-D Submission Tool <[email-masked]>*
> 
> 2010-03-01 17:55
> 
> 	
> 收件人
> 	[email-masked]
> 抄送
> 	[email-masked]
> 主题
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 2 Mar 2010 08:38:57 -0800

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 01, 2010 6:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: [hiprg] New ID: draft-wang-hiprg-service-overlay-00

Dear all,

A new Internet Draft entitled "HIP Service Overlay Study" has been submitted.  It can be accessed at:
http://www.ietf.org/id/draft-wang-hiprg-service-overlay-00.txt

(filename: draft-wang-hiprg-service-overlay-00)
It is a HIP service overlay study document, it presents several disadvantages of current HIP protocol and then takes a brief introduction of two existing alternative solutions. Finally, we propose a HIP service overlay architecture.
Your comments on the proposed mechanism would be highly appreciated. In addition, I would be glad to make a small presentation and discuss it in the upcoming IETF 77 meeting.

I added you to the draft agenda:
http://www.ietf.org/proceedings/10mar/agenda/HIPRG.txt

Regards,
Tom