Re: [hiprg] Comments on draft-wang-hiprg-service-overlay-00

[[e-mail]]

Thanks a lot for the comments, base on Jiong's previous mail, 
complementary answers following inline


[e-mail] 写于 2010-04-06 20:30:45:

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

[Wang]Yes, you're right, but not always the case. When the transport delay 
is not negligible, that means the distance between two hosts is far 
enough, the overlay overhead maybe less than 4-way handshake.
 

> Also, I'd say "host can" instead of "host wants to".
> 
> 
>     #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?

[wang]All the link of one host
> 
>     #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).
> 
> 
>     #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?

[wang]RVS is being used to find the correct destionation host location, 
the actual traffic doesn't anchor on RVS. 
      The first point caused by not only  the long distance but also the 
per-connection updating behavior
 
       Where is the 'HIP relay' related document?
> 
> 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.
> 
> 
> 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.

[wang]Fully agree that direct HIP connection is more efficient, but how 
much we are willing to pay depends on the benefit.
      we'll provide some additional use cases about the hip service 
overlay.
> 
> 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.
> 
> 
> 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?
>
[wang]yes
> 
> 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.

[wang]what we are taking in consideration is a full mobile enviroment, 
where the host may change IP address and anchor point, The HAP should 
perform additional handover task to make the delay reduction possible.I 
think this kind of function haven't been included in hip relay.

> 
> 8.  References
> 
> You should add the reference pointers to appropriate places in the text;
> now you have none.
> 
> 
> Cheers,
> Ari
> _______________________________________________
> hiprg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hiprg
> 



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