In this relatively short Host Identity Protocol (HIP) overview Host Identity Protocol: Identifier/Locator Split for Host Mobility and Multihoming it is stated

Most Internet applications can run unmodified over HIP, although only HIP-aware new applications using the extended socket interface can take better advantage of the new features that HIP provides. As HIP secures application data traffic with IPsec that is located logically “deep” within the networking stack, the challenge is to provide proper and understandable security indicators to the user to convince the user that the connection, for example, to a banking website, is secured. Such indicators can be developed as extensions to applications (for example, a security plug-in to the Firefox browser) or within a hostwide HIP management utility that controls all applications.

the highlighted sentence left me somewhat puzzled as it indirectly states that currently working upper layer protocols such as TLS will not work over HIP. If it would work we would not need another solution, as we allready have server authentication that is highlighted in browsers. So will TLS work over HIP?

Up until now I thought HIP will introduce modifications in TCP (see first cited sentence) but above that everything should work fine as the layered ip stack architecture renders not directly connected layers transparent right?

Or is it that TLS will become a redundant security layer as HIP allready provides host authentication and transport encryption with IPSec, so that TLS over HIP should be avoided (it slows and does not provide additional security if HIP with additional certificate authentication is running ). Therefor we need a new way of highlighting (HIP) authenticated hosts? (or use the old one to not confuse the user)


tl;dr: The latter.

HIP introduces an additional layer between TCP and IP, and TLS works on top of TCP. There's no reason why it shouldn't work, it would be just an additional layer of encryption and authentication.

HIP is a network layer protocol, and its addresses are a special subset of IPv6 addresses. Any communication to those addresses on a host that supports HIP gets secured by HIP. One of the challenges is that currently the applications have no way of knowing whether any seemingly plain text communication towards some IPv6 address gets silently encrypted by the network stack or not, so indicating it on a browser address bar is not possible. Simply checking if the address belongs to that special IPv6 block is not enough, since a host that doesn't support HIP might actually treat those addresses as regular IPv6 addresses and send the plain text packets to the default gateway.

Another challenge is that since Host Identities are self-generated, there is no certificate authority or other trusted third party whom you can ask whether an identity really belongs to a said real-world entity and show it to the users. Some level of trust can be achieved if the identifiers are transferred over DNSSEC.


Cisco says that HIP is an alternate to TLS:

HIP provides a network layer alternative to using Secure Sockets Layer/Transport Layer Security (SSL/TLS) for application security, which has its benefits and drawbacks. HIP is a generic solution that should work for any transport protocol, whereas until recently TLS supported only TCP. HIP enables host mobility and multihoming, which is not supported by TLS. TLS runs on top of TCP, leaving it vulnerable to various TCP attacks; for example, using spoofed reset (RST) packets or DoS attacks with SYNs. Applications must be designed explicitly to use TLS, whereas HIP can provide security as an add-on to existing traditional applications. On the other hand, TLS does not have a problem with traversing traditional middle-boxes such as NATs and firewalls that need special attention for HIP. Both protocols share the characteristic of endorsing host identity. TLS relies on certificates issued by one of the known Certification Authorities, whereas HIP can use Domain Name System Security Extensions (DNSSEC) [18] or a PKI infrastructure.

As for whether it is possible to run TLS over HIPS, it doesn't seem possible. There is great conflict in the layers they interact on.

  • 1
    The given info is interesting but it s not clear why TLS over hip should not be possible. TCP runs on top of hip and TLS runs on top oft TCP. I dont See the conflict yet – jannikb May 26 '15 at 23:14
  • @yyannecc I completely agree, and your question is valid - it looks like TLS should be able to run on top, but from the ietf documents I read to answer your question, it looks like it would be a specialized overlay to make that happen. – schroeder May 26 '15 at 23:18
  • it looks like the 2 technologies are different enough that although it could be technically possible, that it might not practically work in a general sense. I'm curious to learn more, though. – schroeder May 26 '15 at 23:19

Your Answer

