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

[Ari Keranen <[e-mail]>]

Hi,

Responses to both mails inline.

On 04/07/2010 12:56 PM, [e-mail] wrote:
On 04/08/2010 11:04 AM, [e-mail] wrote:
> 
> 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?
> 
> 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.

OK, but doing the 4-way handshake and then a TCP handshake directly is 
probably faster than doing just a TCP handshake via the overlay, so at 
least in a big overlay the long connection delay point may not apply.

What order of magnitude you assume the TTL for packets sent over the 
overlay to be? If there are, e.g., 4 overlay hops, and average 100ms RTT 
between two nodes, that's already 400ms of RTT just for the overlay 
part. And if the RTT to both HAPs is in the same order of magnitude, 
that would be in total 600ms RTT, i.e., 900ms for TCP 3-way handshake. 
You could do a HIP 4-way handshake and a TCP handshake directly in 3,5 
RTTs, i.e., 350ms (assuming the same average RTT).

I think you need to assume the overlay nodes to have quite small RTTs in 
order to be even as efficient as the regular HIP.

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

This sounds good.

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

Perhaps you would need to elaborate on what cases this does apply.

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

Could clarify this in the text, too. But if one is multihoming, probably 
it would make sense to use more than one link for communicating with the 
HAP, and thus one would need to check all of them in case of failure anyway?

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

Well, leap-of-faith is already supported, and certificates enable 
already other models too as I explained above. And I'm not opposing 
adding some pre-shared key authentication, but I think the comment that 
HIP *depends* on PKI is incorrect.

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

I think stating this explicitly would be a good idea.

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

HIP relay could be used for relaying also UPDATEs in this kind of 
situation.

> [wang]RVS is being used to find the correct destionation host location, 
> the actual traffic doesn't anchor on RVS.

OK, so by "anchor point" you don't mean only HIP signaling. I'm still a 
bit skeptical whether using an overlay is more efficient, but probably 
your evaluation efforts will clarify this.

>       The first point caused by not only  the long distance but also the 
> per-connection updating behavior

True. Although, using a HIP relay could be even more efficient.

>        Where is the 'HIP relay' related document?

See draft-ietf-hip-nat-traversal.

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

OK, but the PKI point (3) is not really valid, right? The results of the 
performance evaluation would be indeed interesting.

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

I think whether the issues are valid depends much on the overlay, and 
especially on RTTs and whether a HIP relay can be used, as I explained 
above.

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

This would be interesting. Especially I think it would be good to 
explain the scenarios where the service overlay is more efficient, and 
where it isn't.

I would assume that the biggest benefit of using an overlay is not the 
connection setup latency, but e.g., fault tolerance, scaling properties, 
and possibly anonymity.

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

That would be good.

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

OK, I would suggest clarifying this in the text too.

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

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

OK, I missed that in the draft. Perhaps it would be good to clarify why 
the overlay is better than using multiple HIP relays.

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

True, data relaying is not part of the services provided by a HIP relay. 
Instead, one could use the HIP data relay (see 
draft-keranen-hip-native-nat-traversal) or a TURN server for that.


Cheers,
Ari