Presentation on theme: "Establishing Host Identity Protocol Opportunistic Mode with TCP Option draft-lindqvist-hip-opportunistic-01.txt Janne."— Presentation transcript:
email@example.com Establishing Host Identity Protocol Opportunistic Mode with TCP Option draft-lindqvist-hip-opportunistic-01.txt Janne Lindqvist Helsinki University of Technology (TKK)
firstname.lastname@example.org Motivation for the Approach Fallback mechanism to plain TCP if peer does not support HIP. According to Medina et al. arbitrary TCP options are widely accepted in today’s Internet. (Ref. SIGCOMM CCR April 2005) Arbitrary IP options are not that accepted.
email@example.com Basic Idea Include the Host Identity Tag as a TCP option to a TCP SYN segment. If the peer supports HIP, the peer responses with R1. Thus, the TCP SYN with the Host Identity Tag is equivalent of an opportunistic I1. If the peer does not support HIP, it ignores the option and responses with TCP SYN+ACK.
firstname.lastname@example.org Piggybacking TCP to Host Identity Protocol draft-lindqvist-hip-tcp-piggybacking-00.txt
email@example.com Piggybacking TCP to HIP The idea is to (partly) concatenate TCP handshake to the HIP base exchange. Benefit: saves one round trip.
firstname.lastname@example.org Design Choices We do not want to create TCP state before creating HIP state. –We want to check the puzzle before creating TCP state. TCP ACKs may contain data and thus need to be encrypted. The approach is designed to work normal and opportunistic base exchange and with the TCP Option initiated opportunistic mode.
email@example.com Piggybacking We send the TCP SYN concatenated to I2, we do not need encryption for the TCP segment, since it does not contain payload data. Only optionally a signature can be added for integrity protection. This way, the Responder can verify the puzzle first and then create TCP state when sending R2 and TCP SYN+ACK. TCP ACK is then in the ESP protected flow.
firstname.lastname@example.org Integrity Protection It is not clear how to do the integrity protection with this concatenation approach. We could do it perhaps by adding a IP option after the TCP segment which contains a signature? –Seems to be kind of a stretch.
email@example.com Relation to Opportunistic HIP with TCP Option draft-lindqvist-hip-opportunistic-01 establishes opportunistic mode by sending a TCP Option with HIT instead of I1. The Initiator just resends the TCP SYN segment in I2.
firstname.lastname@example.org Security Considerations If we do not encrypt the TCP segments, TCP port numbers are revealed which would otherwise be protected by ESP. –This can be privacy issue.
email@example.com Alternatives for the Approach Just send the TCP SYN at the same time and forget the concatenation? Define a HIP parameter that can contain TCP segments? This would establish encryption and integrity protection. These are not mentioned in the draft, but came to mind after hallway discussions.
firstname.lastname@example.org Conclusion After the hallway discussions, it is not clear what would the most beneficial design alternative.