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

From: [email-masked]
Date: Wed, 3 Mar 2010 16:55:20 +0800

Hi Miika,

Thanks for the comments. Our draft is for constructing a overlay 
infrastructure, 
and this overlay provides ID and IP mapping and forwards 
packages to right targets.

Normally, the user equipments are not part of the overlay, they use HIP to 
connect
to the overlay for the mobility and multihoming supporting.

As the peers of overlay infrastructure are stable and not always moving, 
so the overlay
itself may not use HIP.

Please see detail answer embeded. 

Thanks,
Jiong

------------------------------
Date: Tue, 02 Mar 2010 16:30:04 +0200
From: Miika Komu <[email-masked]>
Subject: Re: [hiprg] New ID: draft-wang-hiprg-service-overlay-00
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=GB2312

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

<Jiong> For hiccups, by my understanding, it should be designed for 
control messages 
and it can be used only for exchanging few packets between the peers for 
security purpose.
So in normal data communication, two hosts still need use HIP
4-way handshake. 
For our draft, we think user equipments are not necessary as a part of 
overlay, and they don't need know that the infrastructure is a overlay.

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.

<Jiong> Consider of compatible with previous user equipments and the truth 

that PKI is not widely used in telcomm system, the purpose here is to 
separate
the end to end authentication based on PKI and the 3.5 layer HIP protocol 
itself.
For the authentication method that can be decided by the system. 

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.

<Jiong> The RVS mechanism can not resolve issue 1). And for issue 2), by 
my
understanding, the update will fail and use RVS to reestablish the HIP 
contection.
It still could cause considerable delay.

> 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.
> 
> 
> 
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg

------------------------------

Message: 3
Date: Tue, 2 Mar 2010 08:38:57 -0800
From: "Henderson, Thomas R" <[email-masked]>
Subject: Re: [hiprg] New ID: draft-wang-hiprg-service-overlay-00
To: "[email-masked]'" <[email-masked]>,
                 "[email-masked]"                <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID:
 <[email-masked]>
 
Content-Type: text/plain; charset="us-ascii"

________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://www.irtf.org/mail-archive/web/hiprg/attachments/20100302/f1d6b945/attachment.htm

------------------------------

Message: 4
Date: Tue, 2 Mar 2010 08:42:46 -0800
From: "Henderson, Thomas R" <[email-masked]>
Subject: [hiprg] agenda requests
To: "[email-masked]" <[email-masked]>
Message-ID:
 <[email-masked]>
 
Content-Type: text/plain; charset="us-ascii"

We have a 2-hour slot at the next IETF, on Monday March 22, 1740-1940. 
Both Andrei and I plan to be at the meeting.

I've started to put together an agenda which will be maintained here:
http://www.ietf.org/proceedings/10mar/agenda/HIPRG.txt

Please send any additional agenda requests to us prior to the meeting.

- Tom

------------------------------

Message: 5
Date: Tue, 2 Mar 2010 20:07:49 +0100
From: Pascal Urien <[email-masked]>
Subject: Re: [hiprg] agenda requests
To: "Henderson, Thomas R" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID:
 <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Hi Thomas

I request a short slot for

http://tools.ietf.org/html/draft-urien-hip-tag-03

and Iot issues

Best Regards

Pascal Urien

2010/3/2 Henderson, Thomas R <[email-masked]>

> We have a 2-hour slot at the next IETF, on Monday March 22, 1740-1940.
>  Both Andrei and I plan to be at the meeting.
>
> I've started to put together an agenda which will be maintained here:
> http://www.ietf.org/proceedings/10mar/agenda/HIPRG.txt
>
> Please send any additional agenda requests to us prior to the meeting.
>
> - Tom
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://www.irtf.org/mail-archive/web/hiprg/attachments/20100302/aa071ad0/attachment.htm

------------------------------

_______________________________________________
hiprg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/hiprg

End of hiprg Digest, Vol 9, Issue 1
***********************************

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