Re: [hiprg] hiprg Digest, Vol 10, Issue 2

[[e-mail]]

Hi Ari,

Thanks for the review and comments. Responses inline.

Thanks,
Jiong


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

Message: 1
Date: Tue, 06 Apr 2010 15:30:45 +0300
From: Ari Keranen <[e-mail]>
Subject: [hiprg] Comments on draft-wang-hiprg-service-overlay-00
To: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

> Hi,

> Here are some comments on the HIP service overlay draft. Overall, the 
> draft's idea is somewhat interesting, but there are some issues I would 
> not fully agree on (or that I may not have understood correctly).


> 1.  Introduction

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

> You can piggyback the TCP handshake or any other transport stuff to the
> I2/R2 exchange if you really wish to mitigate this issue, but due to DoS
> resistance it may not be a good idea. Anyway, the analyzed indirection
> solutions (sending packets via overlays) would likely create more delay
> than the basic 4-way handshake, right?

Yes, you can do some optimize for the handshake, but anyway, you need do 
handshake with any new host you want to communicate. In HIP service 
overlay,
device only need handshake with the HAP(HIP Access Peer) once. 
And the security is established between the device and access peer.

For the performance of indirection solutions, we are evaluating and doing 
prototyping. 


> Also, I'd say "host can" instead of "host wants to".

Makes sense.

>     #2.  When the underlying link broken, the initiator doesn't know the
>     link had broken until it has gotten O(n^2) fail attempts, in which
>     the n is the number of one multihoming host's locators.

> If only one link is broken, wouldn't the other links still work if
> the host is multihoming? Or do you mean that if the *all* links are 
broken?

Here, means all links are broken.

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

> Self generated identities are quite standard with HIP, so I wouldn't
> agree with depending on a PKI. And you can use certificates to sign the
> self-generated keys and the certificates can be obtained using a
> pre-shared key (say, one logins to a web page that authenticates the
> user) to accomplish the same functionality but in a cleaner way. That
> said, also I have earlier proposed a pre-shared key (password) based
> authentication in the draft-keranen-hip-native-nat-traversal-00, before
> concluding that it may not be that good idea (the next version will use
> certificates instead).

Yes, but anyway, we need expand base protocol to support other method 
except PKI.

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

> I'm not sure if I fully understand this. Wouldn't RVS or a HIP relay
> server work as an "anchor point"? This should solve your 2nd point. And
> regarding the first point, I assume you are referring to a high RTT when
> you talk about peers in different continent?

Here, for first point, yes, it means high RTT.
For the RVS mechanism, as it only relay I1, so for point 2, the update 
will fail 
and use RVS to reestablish the HIP contection. It still could cause 
considerable delay. 


> 3.1.  i3

>     For the four issues listed
>     in introduction part, as i3 does not need HIP handshake, the issue 
#1
>     goes away; and as hosts always send packages to i3 infrastructure,
>     and update i3 infrastructure about it's IP address changes, so issue
>     #2, #3 and #4 also can be resolved.

> I'm not sure if the comparison between i3 and HIP is really a meaningful
> one. For example, sure you don't need PKI with i3, but you don't need
> one with HIP either to get the same level of security. Also, making a
> 4-way hand shake is probably most of the time faster than going via i3
> overlay, so I would not agree that #1 is better with i3.

As one client need HIP 4-way handshake with every new host everytime, it 
may cause delay and need more resources. Using HIP service overlay, client
only need connect to HAP(HIP Access Peer) once, and need not do handshake 
with every new host. For the forwording performance is under evaluation.

> 3.2.  Hi3

>     Hi3 uses i3 as control plane for forwarding HIP handshake packages
>     I1, I2, R1 and R2, but still uses end to end PKI infrastructure and
>     end to end HIP connection as data plane, so the issues #1, #2, #3 
and
>     #4(1) listed in introduction part still exist.

> Actually, using direct HIP connection on the data plane makes this much
> more efficient than routing all the data via an overlay (as in i3). And
> you really don't need the PKI with Hi3 either.

Yes, using direct HIP connection on the data plane makes this much
more efficient than routing all the data via an overlay (as in i3), but
the connection is based on end to end, so the four issues still exist.

> 4.2.  Registration procedure

> Probably intentionally (being -00 version), there are a lot of details
> missing on how the registration is actually done, so it's hard to
> evaluate it.

Will supplement this part.

> 4.3.  Initiating a communication

>     When a HIP client initiates a connection to a new peer, e.g. sends a
>     TCP SYN packet to a new host, the client's HIP stack inserts a proxy
>     address, which is gotten from registration procedure, into the HIP
>     packet and routing the packet to the HAP which has the proxy 
address.

> So is the TCP SYN carried in a HIP (DATA?) packet over the overlay?

TCP SYN will be carried in a HIP packet, it can be treated as HIP data,
the client's HIP stack will add the destination address into the HIP 
destination 
address field and send it to it's HAP(HIP Access Peer). HAP will forward 
this 
package by the destination address.


> 4.4.  Updating location

>     In this specification, the HIP host does not need to notify the
>     location change to the communicating hosts directly, thus reducing
>     the extra connection delay.

> I think you could accomplish the same with a HIP data relay (see
> draft-keranen-hip-native-nat-traversal) but without the overlay 
overhead.

We use HIP overlay for load balance and local access, because we consider 
the huge client connections.

> 8.  References

> You should add the reference pointers to appropriate places in the text;
> now you have none.

Good point, will follow.

> Cheers,
> Ari


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

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


End of hiprg Digest, Vol 10, Issue 2
************************************




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