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

From: Ari Keranen <[email-masked]>
Date: Tue, 06 Apr 2010 15:30:45 +0300

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?

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?

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

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.

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?

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.

8.  References

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

Cheers,
Ari

---

From: [email-masked]
Date: Thu, 8 Apr 2010 16:04:49 +0800

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

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

> the host is multihoming? Or do you mean that if the *all* links are 
broken?

[wang]All the link of one host
> 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?
> 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.
> So is the TCP SYN carried in a HIP (DATA?) packet over the overlay?
[wang]yes
> 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.

> _______________________________________________
> hiprg mailing list
> [email-masked]
> 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.

---

From: Ari Keranen <[email-masked]>
Date: Mon, 12 Apr 2010 18:13:28 +0300

Hi,

Responses to both mails inline.

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

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

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

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

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

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

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

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

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

> Will supplement this part.

That would be good.

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

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

> 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