1. 14.7.2006janne.lindqvist@tml.hut.fi Establishing Host Identity Protocol Opportunistic Mode with TCP Option draft-lindqvist-hip-opportunistic-01.txt Janne Lindqvist Helsinki University of Technology (TKK)

2. 14.7.2006janne.lindqvist@tml.hut.fi 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.

3. 14.7.2006janne.lindqvist@tml.hut.fi 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.

4. 14.7.2006janne.lindqvist@tml.hut.fi Piggybacking TCP to Host Identity Protocol draft-lindqvist-hip-tcp-piggybacking-00.txt

5. 14.7.2006janne.lindqvist@tml.hut.fi Piggybacking TCP to HIP The idea is to (partly) concatenate TCP handshake to the HIP base exchange. Benefit: saves one round trip.

6. 14.7.2006janne.lindqvist@tml.hut.fi 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.

7. 14.7.2006janne.lindqvist@tml.hut.fi 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.

8. 14.7.2006janne.lindqvist@tml.hut.fi Piggybacking

9. 14.7.2006janne.lindqvist@tml.hut.fi 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.

10. 14.7.2006janne.lindqvist@tml.hut.fi 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.

11. 14.7.2006janne.lindqvist@tml.hut.fi 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.

12. 14.7.2006janne.lindqvist@tml.hut.fi 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.

13. 14.7.2006janne.lindqvist@tml.hut.fi Conclusion After the hallway discussions, it is not clear what would the most beneficial design alternative.