참고: 이 문서는 I2P의 현재 tunnel 구현에 대한 대안들과 미래 가능성에 대한 추측을 다루는 오래된 정보를 포함하고 있습니다. 최신 정보는 tunnel 페이지 를 참조하세요.
해당 페이지는 릴리스 0.6.1.10 기준의 현재 tunnel 구축 구현을 문서화합니다. 릴리스 0.6.1.10 이전에 사용된 이전 tunnel 구축 방법은 이전 tunnel 페이지 에서 문서화되어 있습니다.
구성 대안
터널 길이 외에도 각 터널에 사용할 수 있는 추가적인 구성 가능한 매개변수들이 있을 수 있습니다. 예를 들어 전달되는 메시지 빈도에 대한 조절, 패딩 사용 방법, 터널 운영 기간, 더미 메시지 주입 여부, 그리고 배칭 전략 사용 여부 등입니다. 이러한 기능들은 현재 구현되지 않았습니다.
패딩 대안
여러 tunnel 패딩 전략이 가능하며, 각각 고유한 장점이 있습니다:
- 패딩 없음
- 임의 크기로 패딩
- 고정 크기로 패딩
- 가장 가까운 KB로 패딩
- 가장 가까운 지수 크기로 패딩 (2^n 바이트)
이러한 패딩 전략들은 다양한 레벨에서 사용될 수 있으며, 서로 다른 공격자들에게 메시지 크기 정보가 노출되는 것을 해결합니다. 0.4 네트워크에서 일부 통계를 수집하고 검토한 후, 익명성 절충점을 탐색한 결과, 1024바이트의 고정된 tunnel 메시지 크기로 시작하고 있습니다. 하지만 이 안에서 분할된 메시지 자체는 tunnel에 의해 전혀 패딩되지 않습니다 (다만 end-to-end 메시지의 경우, garlic 래핑의 일부로 패딩될 수 있습니다).
단편화 대안
경로상에서 메시지 크기를 조정하여 적대자가 메시지에 태그를 붙이는 것을 방지하기 위해, 모든 tunnel 메시지는 고정된 1024바이트 크기입니다. 더 큰 I2NP 메시지를 수용하고 더 작은 메시지를 더 효율적으로 지원하기 위해, 게이트웨이는 더 큰 I2NP 메시지를 각 tunnel 메시지 내에 포함된 조각들로 분할합니다. 엔드포인트는 짧은 시간 동안 조각들로부터 I2NP 메시지를 재구성하려고 시도하지만, 필요에 따라 이들을 폐기할 것입니다.
Router들은 프래그먼트가 어떻게 배열되는지에 대해 많은 자유재량권을 가지고 있습니다. 프래그먼트를 개별 단위로 비효율적으로 채워넣거나, 1024바이트 tunnel 메시지에 더 많은 페이로드를 맞추기 위해 짧은 기간 동안 일괄 처리하거나, gateway가 보내고자 하는 다른 메시지들로 기회주의적으로 패딩을 추가할 수 있습니다.
더 많은 대안
터널 처리 중간 조정
간단한 터널 라우팅 알고리즘이 대부분의 경우에 충분하지만, 탐색할 수 있는 세 가지 대안이 있습니다:
- endpoint가 아닌 다른 peer가 tunnel의 종료 지점 역할을 임시로 수행하도록 하기 위해 gateway에서 사용되는 암호화를 조정하여 전처리된 I2NP 메시지의 평문을 제공합니다. 각 peer는 평문을 가지고 있는지 확인할 수 있으며, 수신 시 평문을 가진 것처럼 메시지를 처리할 수 있습니다.
- tunnel에 참여하는 router들이 메시지를 전달하기 전에 재구성할 수 있도록 허용합니다 - 해당 peer의 자체 아웃바운드 tunnel 중 하나를 통해 메시지를 반송하여 다음 홉으로의 전달 지시를 포함시킵니다.
- tunnel 생성자가 peer의 tunnel 내 “다음 홉"을 재정의할 수 있는 코드를 구현하여 추가적인 동적 리디렉션을 가능하게 합니다.
양방향 Tunnel 사용
인바운드와 아웃바운드 통신에 별도의 두 tunnel을 사용하는 현재 전략이 유일한 기법은 아니며, 이는 익명성에 영향을 미칩니다. 긍정적인 측면에서는, 별도의 tunnel을 사용함으로써 tunnel 참여자들에게 분석을 위해 노출되는 트래픽 데이터를 줄입니다. 예를 들어, 웹 브라우저에서의 아웃바운드 tunnel 피어들은 HTTP GET 트래픽만 보는 반면, 인바운드 tunnel의 피어들은 tunnel을 통해 전달되는 페이로드를 봅니다. 양방향 tunnel의 경우, 모든 참여자들이 예를 들어 한 방향으로 1KB가 전송되고 다른 방향으로 100KB가 전송된다는 사실에 접근할 수 있습니다. 부정적인 측면에서는, 단방향 tunnel을 사용하는 것은 프로파일링하고 고려해야 할 피어들의 집합이 두 개 있다는 의미이며, predecessor 공격의 증가된 속도에 대처하기 위해 추가적인 주의가 필요합니다. 아래에 설명된 tunnel 풀링과 구축 과정은 predecessor 공격에 대한 우려를 최소화해야 하지만, 원한다면 인바운드와 아웃바운드 tunnel 모두를 같은 피어들을 따라 구축하는 것도 큰 문제가 되지 않을 것입니다.
백채널 통신
현재 사용되는 IV 값들은 무작위 값입니다. 하지만 그 16바이트 값을 게이트웨이에서 엔드포인트로, 또는 아웃바운드 tunnel에서 게이트웨이에서 모든 피어로 제어 메시지를 보내는 데 사용할 수 있습니다. 인바운드 게이트웨이는 IV에 특정 값들을 한 번 인코딩할 수 있으며, 엔드포인트가 이를 복구할 수 있습니다 (엔드포인트가 생성자이기도 하다는 것을 알고 있기 때문입니다). 아웃바운드 tunnel의 경우, 생성자는 tunnel 생성 중에 참가자들에게 특정 값들을 전달할 수 있습니다 (예: “IV로 0x0을 보면 X를 의미함”, “0x1은 Y를 의미함” 등). 아웃바운드 tunnel의 게이트웨이는 생성자이기도 하므로, 모든 피어가 올바른 값을 받도록 IV를 구성할 수 있습니다. tunnel 생성자는 인바운드 tunnel 게이트웨이에게 일련의 IV 값들을 제공할 수도 있으며, 해당 게이트웨이는 이를 사용하여 개별 참가자와 정확히 한 번씩 통신할 수 있습니다 (하지만 이는 담합 탐지와 관련된 문제가 있을 것입니다).
이 기법은 나중에 스트림 중간에 메시지를 전달하거나, 인바운드 게이트웨이가 엔드포인트에게 DoS 공격을 받고 있거나 곧 실패할 예정임을 알리는 데 사용될 수 있습니다. 현재로서는 이 백채널을 활용할 계획은 없습니다.
가변 크기 tunnel 메시지
전송 계층이 자체적인 단편화를 사용하여 고정되거나 가변적인 메시지 크기를 가질 수 있지만, tunnel 계층은 대신 가변 크기의 tunnel 메시지를 사용할 수 있습니다. 이러한 차이는 위협 모델의 문제입니다 - 전송 계층에서의 고정 크기는 외부 공격자에게 노출되는 정보를 줄이는 데 도움이 되지만(전체적인 흐름 분석은 여전히 작동함), 내부 공격자(즉, tunnel 참여자)에게는 메시지 크기가 노출됩니다. 고정 크기 tunnel 메시지는 tunnel 참여자에게 노출되는 정보를 줄이는 데 도움이 되지만, tunnel 끝점과 게이트웨이에 노출되는 정보는 숨기지 않습니다. 고정 크기 종단 간 메시지는 네트워크의 모든 피어에게 노출되는 정보를 숨깁니다.
항상 그렇듯이, I2P가 누구로부터 보호하려고 하는지의 문제입니다. 가변 크기 tunnel 메시지는 위험합니다. 참가자들이 메시지 크기 자체를 다른 참가자들과의 백채널로 사용할 수 있기 때문입니다. 예를 들어, 1337바이트 메시지를 보면, 당신은 다른 공모하는 peer와 같은 tunnel에 있다는 것을 알 수 있습니다. 허용 가능한 크기의 고정 세트(1024, 2048, 4096 등)가 있어도, peer들이 각 크기의 빈도를 전송 매체로 사용할 수 있기 때문에 여전히 백채널이 존재합니다(예: 1024바이트 메시지 두 개 다음에 8192바이트 메시지). 작은 메시지들은 헤더(IV, tunnel ID, 해시 부분 등)의 오버헤드가 발생하지만, 큰 고정 크기 메시지들은 (배칭으로 인한) 지연 시간 증가나 (패딩으로 인한) 극적인 오버헤드 증가를 가져옵니다. 단편화는 손실된 조각들로 인한 잠재적인 메시지 손실의 비용으로 오버헤드를 분산시키는 데 도움이 됩니다.
타이밍 공격은 고정 크기 메시지의 효과를 검토할 때도 관련이 있지만, 효과적이려면 네트워크 활동 패턴에 대한 상당한 관찰이 필요합니다. tunnel 내의 과도한 인위적 지연은 정기적인 테스트로 인해 tunnel 생성자에 의해 감지되어, 해당 tunnel 전체가 폐기되고 그 안에 있는 피어들의 프로파일이 조정됩니다.
빌딩 대안
참고자료: Hashing it out in Public
기존 Tunnel 구축 방법
릴리스 0.6.1.10 이전에 사용된 기존 tunnel 구축 방법은 기존 tunnel 페이지 에 문서화되어 있습니다. 이는 “한 번에 모두” 또는 “병렬” 방식으로, 메시지가 각 참가자에게 병렬로 전송되는 방법이었습니다.
일회성 망원경식 구축
참고: 이것이 현재 방법입니다.
터널 생성 메시지를 송수신하기 위해 탐색 터널을 사용하는 것과 관련하여 제기된 한 가지 질문은 이것이 선임자 공격에 대한 터널의 취약성에 어떤 영향을 미치는지에 관한 것입니다. 이러한 터널의 엔드포인트와 게이트웨이는 네트워크 전체에 무작위로 분산될 것이지만(해당 집합에 터널 생성자가 포함될 수도 있음), 또 다른 대안은 Tor 에서 수행되는 것처럼 터널 경로 자체를 사용하여 요청과 응답을 전달하는 것입니다. 그러나 이는 터널 생성 중에 누출을 초래할 수 있으며, 피어들이 터널이 구축되는 동안 타이밍이나 패킷 수를 모니터링하여 나중에 터널에 얼마나 많은 홉이 있는지 발견할 수 있게 할 수 있습니다.
“대화형” 망원경식 구축
기존 터널 부분을 통해 각각에 대한 메시지로 hop을 하나씩 구축합니다. 피어들이 메시지를 세어 터널에서 자신의 위치를 결정할 수 있기 때문에 주요한 문제가 있습니다.
관리용 비탐색 Tunnel
tunnel 구축 프로세스의 두 번째 대안은 router에게 tunnel 요청과 응답을 위해 사용할 추가적인 비탐색형 인바운드 및 아웃바운드 풀 세트를 제공하는 것입니다. router가 네트워크에 대한 잘 통합된 관점을 가지고 있다고 가정하면 이는 필요하지 않을 것이지만, router가 어떤 방식으로든 분할되어 있다면 tunnel 관리를 위해 비탐색형 풀을 사용하는 것이 해당 router의 파티션에 어떤 피어들이 있는지에 대한 정보 유출을 줄일 것입니다.
탐색 요청 전달
I2P 0.6.1.10까지 사용된 세 번째 대안은 개별 터널 요청 메시지를 garlic encryption으로 암호화하고 각 홉에 개별적으로 전달하며, 탐색용 터널을 통해 전송하고 응답은 별도의 탐색용 터널로 돌아오도록 하는 방식이었습니다. 이 전략은 위에서 설명한 방식을 위해 폐기되었습니다.
더 많은 역사와 논의
Variable Tunnel Build Message가 도입되기 전에는 최소 두 가지 문제가 있었습니다:
- 메시지의 크기 (일반적인 tunnel 길이가 2 또는 3 hop일 때 8-hop 최대값으로 인해 발생하며… 현재 연구에 따르면 3 hop 이상은 익명성을 향상시키지 않음);
- 높은 구축 실패율, 특히 긴 (그리고 탐색적인) tunnel의 경우, 모든 hop이 동의해야 하며 그렇지 않으면 tunnel이 폐기됨.
VTBM이 #1을 수정하고 #2를 개선했습니다.
Welterde는 재구성을 허용하기 위해 병렬 방법에 대한 수정을 제안했습니다. Sponge는 어떤 형태의 ‘토큰’을 사용하는 것을 제안했습니다.
tunnel 구축을 공부하는 학생들은 현재 방법에 이르기까지의 역사적 기록, 특히 다양한 방법에서 존재할 수 있는 여러 익명성 취약점을 연구해야 합니다. 2005년 10월의 메일 아카이브가 특히 도움이 됩니다. tunnel 생성 명세서 에 명시된 바와 같이, 현재 전략은 predecessor attack에 관해 Michael Rogers, Matthew Toseland (toad), 그리고 jrandom 간의 I2P 메일링 리스트 토론 중에 나왔습니다.
피어 순서 지정 대안
덜 엄격한 순서 지정도 가능하며, A 다음의 홉이 B일 수 있지만 B는 절대 A보다 앞에 올 수 없도록 보장합니다. 다른 구성 옵션으로는 인바운드 tunnel 게이트웨이와 아웃바운드 tunnel 엔드포인트만 고정하거나 MTBF 비율에 따라 순환시키는 기능이 있습니다.
혼합/배치
gateway와 각 hop에서 메시지를 지연, 재정렬, 재라우팅 또는 패딩하기 위해 어떤 전략을 사용해야 할까요? 이것이 어느 정도까지 자동으로 수행되어야 하고, tunnel별 또는 hop별 설정으로 얼마나 많이 구성되어야 하며, tunnel의 생성자(그리고 결국 사용자)가 이 작업을 어떻게 제어해야 할까요? 이 모든 것은 미지의 영역으로 남겨져 있으며, 향후 릴리스에서 해결될 예정입니다.