Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. IESG Note The following issues describe IESG concerns about this document. The IESG expects that these issues will be addressed when future versions of HIP are designed. In case of complex Security Policy Databases (SPDs) and the coexistence of HIP and security-related protocols such as IKE, implementors may encounter conditions that are unspecified in these documents. For example, when the SPD defines an IP address subnet to be protected and a HIP host is residing in that IP address area, there is a possibility that the communication is encrypted multiple times. Readers are advised to pay special attention when running HIP with complex SPD settings. Future specifications should clearly define when multiple encryption is intended, and when it should be avoided.

No abstract

No abstract

No abstract

This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a DiffieHellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-themiddle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upperlayer protocols, such as TCP and UDP.This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.