이 글은 HIP 프로토콜 작동에 대한 간략한 개요입니다.
HIP Payload header는 모든 IP datagram(IP 패킷)에 포함될 수 있습니다. 그러나 HIP 헤더는 상대적으로 크기 때문에 (40 bytes), HIP 헤더가 HIP 연결 상태를 설정하거나 변경하는 데 사용되는 제어 패킷에서만 발생하도록 압축하는 것이 바람직합니다. 헤더 압축과 데이터 패킷을 기존 HIP 연결과 일치 시키는 방법은 별도의 문서(찾는 중)에 정의되어 있습니다. 모든 HIP 구현은 최소한 HIP의 ESP 전송 형식을 구현해야 합니다 (MUST).
HIP Association 생성
앞선 용어 정의에 따라 HIP BEX(HIP Base Exchange, HIP 기본 교환)을 시작하는 시스템은 개시자(Initiator)이고, 피어는 응답자(Responder)입니다. BEX가 완료되면 이러한 구분은 잊혀지며 향후 어느 쪽이든 통신에서 개시자가 될 수 있습니다.
HIP BEX는 개시자와 응답자 간의 상태 설정을 관리하는 역할을 하며, 첫 번째 패킷인 I1은 교환을 시작하고 마지막 패킷은 R1, I2, R2는 세션 키 생성을 위한 인증된 Diffie-Hellman 키 교환을 구성합니다.
개시자는 먼저 트리거 패킷인 I1을 응답자에게 보냅니다. 이 패킷에는 개시자의 HIT가 포함되어 있으며, 응답자의 HIT를 알고있는 경우에는 응답자의 HIT를 포함합니다. 또한 I1 패킷은 키 자료를 생성하는데 사용되는 D-H 그룹의 협상을 초기화하기 위한 D-H 그룹 ID 목록을 포함합니다.
R1 패킷은 실제 인증된 D-H 교환을 시작합니다. 이 패킷에는 퍼즐(개시자가 교환을 계속하기 전에 풀어야하는 암호학적 도전)과 응답자의 D-H 매개 변수 및 응답자가 지원하는 암호 알고리즘 목록이 포함됩니다.
I2 패킷에서 개시자는 받은 퍼즐의 답과 응답자에게 필요한 정보를 전달하는 D-H 매개변수도 포함되어 있습니다. 만약 퍼즐의 답이 맞지 않으면 I2 메시지는 삭제됩니다 (MUST).
R2 패킷은 I2 패킷의 수신을 확인하고 교환을 완료합니다. 패킷은 응답자에 의해 서명됩니다.
HIP 퍼즐 메커니즘
HIP 퍼즐 메커니즘의 목적은 다양한 서비스 거부 공격으로부터 응답자를 보호하는 것입니다.
응답자는 유효한 I2 패킷을 받을 때까지 상태 생성을 지연할 수 있습니다. 유효한 솔루션이 없는 I2 패킷은 응답자가 확인 후 즉시 거부될 수 있습니다. 해시 함수를 계산하여 솔루션을 확인하고 상태가 생성되기 전, 즉 공개 키 서명 검증 및 D-H 키 생성이 수행되기 전에 잘못된 솔루션을 거부할 수 있으며, 응답자는 퍼즐의 난이도를 변경함으로써 CPU 또는 메모리 대상 DoS 공격을 방해할 수 있습니다.
퍼즐 계산은 개시자의 HIT를 기반으로 하기 때문에 대부분의 위조된 I2 패킷을 상태 없이 거부할 수 있습니다. 응답자는 이미 계산된 다양한 수의 R1 패킷을 가지고 있으며, I1 패킷에 포함된 정보를 기반으로 패킷을 선택합니다. 그 다음 응답자가 I2 패킷을 받으면, 개시자의 HIT를 사용하여 퍼즐이 해결되었는지 확인할 수가 있습니다.
이러한 방식으로 공격자가 하나의 I1, R1 패킷을 교환한 다음 다양한 HIT에서 오는 것으로 대량의 위조된 I2 패킷을 생성하는 것으로부터 방어합니다. 하지만 고정된 HIT를 사용하는 공격자로부터 보호하지는 않습니다. 이러한 공격자에 대해서는 로컬 상태를 생성하고 퍼즐 확인이 이전에 실패했음을 기억하는 식으로 보호할 수 있습니다.
응답자 구현은 알고리즘 복잡성 공격이 불가능 하도록 충분한 무작위성을 포함해야 합니다.
퍼즐 교환 (Puzzle Exchange)
응답자는 I1 패킷을 받으면 퍼즐 교환을 시작합니다. 응답자는 난수 #I를 제공하고 개시자에게 숫자 #J를 찾도록 요구합니다. 개시자가 적절한 #J를 선택하기 위해 #I, 본인의 HIT, #J의 연결을 생성하고, 이 연결을 RHASH 알고리즘을 사용하여 해시를 계산해야 합니다. 결과의 최하위 #K 비트는 반드시 0이어야 합니다. #K는 퍼즐의 난이도를 설정합니다.
적절한 #J를 생성하려면, 개시자는 해시 대상인 0을 생성할 때까지 여러 개의 #J를 생성해야 합니다. 개시자는 퍼즐 매개변수에서 제공하는 퍼즐 수명을 초과하면 포기하고, 응답자는 #I, HIT, #J의 연결을 다시 생성하여 개시자가 할당된 작업을 완료했을음을 증명하기 위해 해시를 다시 계산해야 합니다.
사전 계산 공격을 방지하기 위해 응답자는 개시자가 추측할 수 없는 방법으로 #I를 선택해야 합니다. 또한, #I 값이 개시자가 아닌 응답자가 실제로 선택했는지 확인할 수 있어야 합니다. 이를 구현하는 방법은 부록A를 참고하세요.
응답자는 개시자에게 전송되는 R1 패킷에 몇 가지 데이터를 포함할 수 합니다. 이 데이터는 개시자의 I2 패킷에 변경하지 않고 그대로 복사해야 합니다 (MUST). 응답자는 이 데이터를 생성하기 위해 암호화나 해싱, #I, 로컬 상태 정보 등 다양한 방법을 사용할 수 있습니다. 응답자는 개시자가 보낸 패킷이 이전에 받은 R1에 대한 응답임을 인식하기 위해 사용될 수 있습니다. 응답자는 이러한 비밀을 주기적으로 변경해야 합니다 (MUST).
응답자는 몇 분에 한 번씩 새로운 퍼즐과 새로운 R1을 생성하는 것이 좋습니다 (RECOMMENDED). 또한, 퍼즐이 폐기 된 후에도 유효한 퍼즐 솔루션을 확인할 수 있는 시간(2 * lifetime)을 권장합니다 (RECOMMENDED). 이렇게 함으로써 예전에 해결된 퍼즐이 공격자에게 사용될 가능성을 줄이고, 퍼즐의 유효성 문제를 방지할 수 있습니다.
퍼즐 값 #I와 솔루션 #J는 D-H 키 교환에서 키 자료를 도출하기 위한 입력입니다 (참고). 따라서 응답자는 동일한 개시자에 동일한 DH 키를 가진 동일한 퍼즐 #I를 사용해서는 안됩니다 (SHOULD NOT). 이를 위해 고유한 카운터를 사용하는 것이 좋습니다.
NOTE: 프로토콜 개발자들은 replay attacks으로부터 개시자를 보호하기 위해 R1에 타임스탬프를 포함 할지를 고려하였으나 글로벌 시간 동기화 문제를 피하기 위해 타임스탬프를 포함하지 않기로 결정하였습니다.
NOTE: 프로토콜 개발자들은 퍼즐에 CPU 바운드 함수 대신 메모리 바운드 함수를 사용해야 하는지 여부를 고려하였으나 메모리 바운드 함수를 사용하지 않기로 결정하였습니다.
