Establishing Host Identity Protocol Opportunistic Mode with TCP Option Janne Lindqvist Helsinki University of Technology (presented by Miika Komu) draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

Motivation for the Approach Fallback mechanism to plain TCP if peer does not support HIP. (TCP piggybacking) According to Medina et al. arbitrary TCP options are wirely accepted in today’s Internet. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

Basic Idea Include the Host Identity Tag as a TCP option to a TCP SYN segment. If peer supports HIP, the peer responses with R1. Thus, the TCP SYN with the Host Identity Tag is equivalent of an opportunistic I1. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

HIP TCP Option Format 8 bits Kind field. Needs IESG Approval to assign an experimental value (RFC 3692). Used to distinguish one option from another. 8 bits Length field. Denotes the lenght of the option data. (Length = 18.) 128 bits for Host Identity Tag. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

Packet Processing without piggybacking Initiator sends TCP SYN with the HIP TCP Option. Responder replies with R1 and does not create neither HIP or TCP state. Responder thus ignores the TCP SYN. Initiator sends I2. Responder replies with R2. Initiator sends a normal TCP SYN to start TCP handshake. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

Packet Processing Motivation We could allow the Responder to send TCP SYN+ACK after the HIP base exchange, but this would mean introducing TCP state before the base exchange is completed. HIP was designed to avoid state creation before verification that the Initiator is sincere. The above approach would hinder the objective. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

Next, we open a can of worms. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

Piggybacking TCP to HIP base exchange One of the original motivators for the draft was the possibility to piggyback TCP handshake to the HIP base exchange. However, currently the approach is NOT RECOMMENDED. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

HIP Piggybacking Initiator: TCP SYN with the HIP TCP OPTION Responder: R1 concatenated with TCP SYN+ACK Initiator: I2 concatenated with TCP ACK. (TCP hanshake done) Responder: R2 and possibly concatenated TCP data. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

HIP Piggybacking Problems: State creation? We do not want to create HIP or TCP state before verification of the puzzle solution in I2. A normal TCP would be vulnerable to TCP ACK flooding if it does not create state while sending TCP SYN+ACK. (And is vulnerable to TCP SYN flooding.) However, the Responder can trust the Initiator to be sincere after the puzzle is verified and we create TCP state after TCP ACK? This should not introduce a new attack? draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

HIP Piggybacking Problems: Data encryption. TCP ACK in the TCP handshake can contain data. This means that with the presented piggybacking, we would need to encrypt the TCP segment concatenated to I2. And we most likely would need to encrypt possible TCP segments concatenated to R2. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

HIP Piggybacking Problems: Data encryption. Instead of catenating a TCP segment to I2 and R2, we could have ESP(TCP). HIP control messages including ESP seems like an overkill. SPI, Sequence Number, The Payload Data, Padding, Pad Length, Next Header, Authentication Data The approach was even removed from the HIP base protocol specification. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

HIP Piggybacking Problems: Processing Alternatives Just a quick mention that the piggybacking possibility introduces interesting processing alternatives and implementation issues depending on the support status. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

Security Considerations Vulnerable to man-in-the-middle attacks because the peer’s HIT is now known before connection establishment. The fallback mechanism provides the possibility to use unencrypted TCP instead of HIP. Applications should notify users about the connection status. draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi

What Next? Currently, it seems that we should rewrite the presented draft to motivate and cover only the non-piggybacking approach and remove the piggybacking stuff. Write a separate draft on piggybacking related issues? draft-lindqvist-hip-opportunistic-00.txt janne.lindqvist@tkk.fi