참고: 이 문서는 원래 2003년에 jrandom이 작성했습니다. 최신 상태로 유지하기 위해 노력하고 있지만, 일부 정보는 구식이거나 불완전할 수 있습니다. 전송 및 암호화 섹션은 2025년 1월 기준으로 최신입니다.
소개
I2P는 확장 가능하고 자체 조직화되며 탄력적인 패킷 교환 익명 네트워크 계층으로, 그 위에서 익명성이나 보안을 중시하는 다양한 애플리케이션들이 운영될 수 있습니다. 이러한 각 애플리케이션은 자유 경로 mixnet(믹스넷)의 적절한 구현에 대해 걱정할 필요 없이 고유한 익명성, 지연시간, 처리량 트레이드오프를 설정할 수 있으며, 이미 I2P 위에서 실행되고 있는 더 큰 사용자 익명성 집합과 자신의 활동을 혼합할 수 있습니다.
이미 사용 가능한 애플리케이션들은 일반적인 인터넷 활동의 전체 범위를 제공합니다 — 익명 웹 브라우징, 웹 호스팅, 채팅, 파일 공유, 이메일, 블로깅 및 콘텐츠 신디케이션, 그리고 현재 개발 중인 여러 다른 애플리케이션들까지 포함합니다.
- 웹 브라우징: 프록시 사용을 지원하는 기존 브라우저 사용.
- 채팅: IRC 및 기타 프로토콜
- 파일 공유: I2PSnark 및 기타 애플리케이션
- 이메일: susimail 및 기타 애플리케이션
- 블로그: 로컬 웹 서버 또는 사용 가능한 플러그인 사용
Freenet 이나 GNUnet 과 같은 콘텐츠 배포 네트워크에서 호스팅되는 웹사이트와 달리, I2P에서 호스팅되는 서비스들은 완전히 상호작용적입니다 — 전통적인 웹 스타일의 검색 엔진, 게시판, 댓글을 달 수 있는 블로그, 데이터베이스 기반 사이트, 그리고 로컬에 설치하지 않고도 Freenet과 같은 정적 시스템을 조회할 수 있는 브리지들이 있습니다.
이러한 모든 익명성 지원 애플리케이션들과 함께, I2P는 메시지 지향 미들웨어의 역할을 담당합니다. 애플리케이션들은 암호화 식별자(“destination”)로 일부 데이터를 보내고 싶다고 말하면, I2P가 해당 데이터가 안전하고 익명으로 전달되도록 처리합니다. I2P는 또한 I2P의 익명 최선 노력 메시지들을 신뢰할 수 있는 순서대로 정렬된 스트림으로 전송할 수 있도록 하는 간단한 streaming 라이브러리를 번들로 제공하며, 네트워크의 높은 대역폭 지연 곱에 맞춰 조정된 TCP 기반 혼잡 제어 알고리즘을 투명하게 제공합니다. 기존 애플리케이션을 네트워크에 연결하기 위해 여러 간단한 SOCKS 프록시들이 사용 가능했지만, 거의 모든 애플리케이션이 익명 상황에서는 민감한 정보를 일상적으로 노출하기 때문에 그 가치는 제한적이었습니다. 안전한 방법은 애플리케이션을 완전히 감사하여 적절한 작동을 보장하는 것이며, 이를 지원하기 위해 네트워크를 최대한 활용할 수 있는 다양한 언어의 일련의 API를 제공합니다.
I2P는 학술적, 상업적 또는 정부 연구 프로젝트가 아니라, 익명성이 필요한 사람들에게 충분한 수준의 익명성을 제공하기 위해 필요한 모든 것을 수행하는 것을 목표로 하는 엔지니어링 노력입니다. 2003년 초부터 한 명의 풀타임 개발자와 전 세계의 헌신적인 파트타임 기여자 그룹과 함께 활발히 개발되어 왔습니다. I2P에서 수행되는 모든 작업은 오픈 소스이며 웹사이트 에서 자유롭게 이용할 수 있으며, 대부분의 코드는 완전히 퍼블릭 도메인으로 공개되었지만, BSD 스타일 라이선스 하에서 몇 가지 암호화 루틴을 사용하고 있습니다. I2P 작업을 하는 사람들은 사람들이 클라이언트 애플리케이션을 어떤 라이선스로 출시하는지 통제하지 않으며, 여러 GPL 애플리케이션들이 이용 가능합니다(I2PTunnel , susimail , I2PSnark , I2P-Bote, I2Phex 등). I2P의 자금 조달은 전적으로 기부에 의존하며, 현재 어떤 관할권에서도 세제 혜택을 받지 않고 있습니다. 이는 많은 개발자들이 스스로 익명이기 때문입니다.
작동
개요
I2P의 작동 방식을 이해하려면 몇 가지 핵심 개념을 파악하는 것이 필수적입니다. 첫째, I2P는 네트워크에 참여하는 소프트웨어(router)와 개별 애플리케이션과 연관된 익명 엔드포인트(destination)를 엄격히 구분합니다. 누군가가 I2P를 실행하고 있다는 사실은 보통 비밀이 아닙니다. 숨겨지는 것은 사용자가 무엇을 하고 있는지(만약 뭔가를 한다면), 그리고 특정 destination이 어떤 router에 연결되어 있는지에 대한 정보입니다. 최종 사용자는 일반적으로 자신의 router에 여러 개의 로컬 destination을 가지게 됩니다. 예를 들어, 하나는 IRC 서버로의 프록시 역할을, 다른 하나는 사용자의 익명 웹서버(“I2P Site”)를 지원하고, 또 다른 하나는 I2Phex 인스턴스를 위해, 또 다른 하나는 torrent를 위해 사용됩니다.
이해해야 할 또 다른 핵심 개념은 “tunnel"입니다. tunnel은 명시적으로 선택된 router 목록을 통과하는 방향성 경로입니다. 계층 암호화가 사용되므로 각 router는 단일 계층만 복호화할 수 있습니다. 복호화된 정보에는 다음 router의 IP와 함께 전달될 암호화된 정보가 포함됩니다. 각 tunnel에는 시작점(첫 번째 router, “gateway"라고도 함)과 종료점이 있습니다. 메시지는 한 방향으로만 전송할 수 있습니다. 메시지를 다시 보내려면 다른 tunnel이 필요합니다.
두 가지 유형의 tunnel이 존재합니다: “outbound” tunnel은 tunnel 생성자로부터 메시지를 보내고, “inbound” tunnel은 tunnel 생성자에게 메시지를 가져옵니다. 이 두 tunnel을 결합하면 사용자들이 서로 메시지를 주고받을 수 있습니다. 발신자(위 이미지의 “Alice”)는 outbound tunnel을 설정하고, 수신자(위 이미지의 “Bob”)는 inbound tunnel을 생성합니다. Inbound tunnel의 게이트웨이는 다른 모든 사용자로부터 메시지를 받을 수 있으며, 이를 종단점(“Bob”)까지 전달합니다. Outbound tunnel의 종단점은 메시지를 inbound tunnel의 게이트웨이로 전달해야 합니다. 이를 위해 발신자(“Alice”)는 암호화된 메시지에 지시사항을 추가합니다. Outbound tunnel의 종단점이 메시지를 복호화하면, 올바른 inbound 게이트웨이(“Bob"으로 가는 게이트웨이)로 메시지를 전달하라는 지시사항을 갖게 됩니다.
이해해야 할 세 번째 핵심 개념은 I2P의 “network database” (또는 “netDb”)입니다 — 네트워크 메타데이터를 공유하는 데 사용되는 한 쌍의 알고리즘입니다. 전달되는 메타데이터의 두 가지 유형은 **“routerInfo”**와 **“leaseSet”**입니다 — routerInfo는 특정 router에 연결하는 데 필요한 데이터(공개 키, 전송 주소 등)를 router들에게 제공하는 반면, leaseSet은 특정 목적지에 연결하는 데 필요한 정보를 router들에게 제공합니다. leaseSet은 여러 개의 “lease"를 포함합니다. 각각의 lease는 tunnel gateway를 지정하여 특정 목적지에 도달할 수 있도록 합니다. lease에 포함된 전체 정보는 다음과 같습니다:
- 특정 목적지에 도달할 수 있게 해주는 tunnel의 인바운드 게이트웨이.
- tunnel이 만료되는 시간.
- 메시지를 암호화할 수 있는 공개 키 쌍 (tunnel을 통해 전송하여 목적지에 도달하기 위해).
Router들은 자신의 routerInfo를 netDb에 직접 전송하는 반면, leaseSet들은 아웃바운드 tunnel을 통해 전송됩니다 (leaseSet들은 router와 해당 leaseSet들 간의 연관성을 피하기 위해 익명으로 전송되어야 합니다).
위의 개념들을 결합하여 네트워크에서 성공적인 연결을 구축할 수 있습니다.
자신의 인바운드 및 아웃바운드 tunnel을 구축하기 위해 Alice는 netDb에서 조회를 수행하여 routerInfo를 수집합니다. 이를 통해 그녀는 자신의 tunnel에서 홉으로 사용할 수 있는 피어 목록을 수집합니다. 그런 다음 그녀는 첫 번째 홉에 빌드 메시지를 보내어 tunnel 구축을 요청하고, 해당 router가 tunnel이 구축될 때까지 구축 메시지를 계속 전달하도록 요청할 수 있습니다.
Alice가 Bob에게 메시지를 보내려고 할 때, 먼저 netDb에서 Bob의 leaseSet을 조회하여 그의 현재 인바운드 tunnel 게이트웨이들을 찾습니다. 그런 다음 자신의 아웃바운드 tunnel 중 하나를 선택하고, 아웃바운드 tunnel의 엔드포인트가 Bob의 인바운드 tunnel 게이트웨이 중 하나로 메시지를 전달하도록 하는 지시사항과 함께 메시지를 보냅니다. 아웃바운드 tunnel 엔드포인트가 이러한 지시사항을 받으면, 요청된 대로 메시지를 전달하고, Bob의 인바운드 tunnel 게이트웨이가 이를 받으면 tunnel을 통해 Bob의 router로 전달됩니다. Alice가 Bob이 메시지에 응답할 수 있기를 원한다면, 메시지 자체의 일부로 자신의 목적지를 명시적으로 전송해야 합니다. 이는 streaming 라이브러리에서 수행되는 상위 레벨 계층을 도입함으로써 가능합니다. Alice는 또한 자신의 최신 LeaseSet을 메시지와 함께 번들로 제공하여 Bob이 응답할 때 netDb 조회를 할 필요가 없도록 함으로써 응답 시간을 단축할 수도 있지만, 이는 선택사항입니다.
tunnel 자체는 네트워크 내부의 피어들로부터 무단 공개를 방지하기 위한 계층화된 암호화를 가지고 있지만(전송 계층 자체가 네트워크 외부의 피어들로부터 무단 공개를 방지하는 것처럼), 아웃바운드 tunnel 엔드포인트와 인바운드 tunnel 게이트웨이로부터 메시지를 숨기기 위해 추가적인 종단 간 암호화 계층을 추가하는 것이 필요합니다. 이 “garlic encryption “은 Alice의 router가 여러 메시지를 단일 “garlic message"로 묶어서, 특정 공개키로 암호화하여 중간 피어들이 garlic 내에 몇 개의 메시지가 있는지, 그 메시지들이 무엇을 말하는지, 또는 개별 clove들이 어디로 향하는지를 알 수 없도록 합니다. Alice와 Bob 간의 일반적인 종단 간 통신에서, garlic은 Bob의 leaseSet에 게시된 공개키로 암호화되어, Bob 자신의 router에게 공개키를 노출하지 않고도 메시지를 암호화할 수 있게 합니다.
염두에 둬야 할 또 다른 중요한 사실은 I2P가 완전히 메시지 기반이며 일부 메시지가 전송 과정에서 손실될 수 있다는 것입니다. I2P를 사용하는 애플리케이션은 메시지 지향 인터페이스를 사용하고 자체적으로 혼잡 제어 및 신뢰성 요구사항을 처리할 수 있지만, 대부분의 경우 제공된 streaming 라이브러리를 재사용하여 I2P를 스트림 기반 네트워크로 보는 것이 가장 좋습니다.
터널
인바운드와 아웃바운드 tunnel 모두 비슷한 원리로 작동합니다. tunnel gateway는 여러 tunnel 메시지를 축적한 후, 결국 이를 tunnel 전달을 위한 형태로 전처리합니다. 다음으로, gateway는 전처리된 데이터를 암호화하고 첫 번째 홉으로 전달합니다. 해당 피어와 후속 tunnel 참가자들은 중복이 아닌지 확인한 후 다음 피어로 전달하기 전에 암호화 계층을 추가합니다. 결국 메시지는 엔드포인트에 도착하여 다시 분리되고 요청에 따라 전달됩니다. 차이점은 tunnel의 생성자가 하는 일에서 발생합니다 — 인바운드 tunnel의 경우 생성자가 엔드포인트이며 추가된 모든 계층을 단순히 복호화하는 반면, 아웃바운드 tunnel의 경우 생성자가 gateway이며 홉별 암호화의 모든 계층이 추가된 후 메시지가 tunnel 엔드포인트에서 평문으로 도착하도록 모든 계층을 미리 복호화합니다.
메시지를 전달할 특정 피어들의 선택과 그들의 특별한 순서는 I2P의 익명성과 성능 특성을 이해하는 데 중요합니다. 네트워크 데이터베이스(아래에서 설명)는 쿼리할 피어들과 항목을 저장할 위치를 선택하는 자체 기준을 가지고 있지만, tunnel 생성자는 단일 tunnel에서 네트워크의 모든 피어를 임의의 순서로 (그리고 심지어 임의의 횟수로) 사용할 수 있습니다. 완벽한 지연시간과 용량 데이터가 전역적으로 알려져 있다면, 선택과 순서는 클라이언트의 위협 모델과 함께 그들의 특정한 요구사항에 의해 결정될 것입니다. 불행히도 지연시간과 용량 데이터를 익명으로 수집하는 것은 쉽지 않으며, 이 정보를 제공하기 위해 신뢰할 수 없는 피어들에 의존하는 것은 그 자체로 심각한 익명성 문제를 야기합니다.
익명성 관점에서 가장 간단한 기법은 전체 네트워크에서 피어를 무작위로 선택하고, 무작위로 순서를 정한 다음 그 순서대로 영원히 사용하는 것입니다. 성능 관점에서 가장 간단한 기법은 필요한 여유 용량을 가진 가장 빠른 피어를 선택하고, 투명한 장애 조치를 처리하기 위해 다양한 피어에 부하를 분산시키며, 용량 정보가 변경될 때마다 tunnel을 재구축하는 것입니다. 전자는 취약하고 비효율적이며, 후자는 접근할 수 없는 정보를 요구하고 충분하지 않은 익명성을 제공합니다. I2P는 대신 다양한 피어 선택 전략을 제공하고, 익명성을 인식하는 측정 코드와 결합하여 피어들을 그들의 프로파일에 따라 조직화하는 작업을 진행하고 있습니다.
기본적으로 I2P는 상호작용하는 피어들의 간접적인 행동을 측정하여 지속적으로 프로파일링합니다. 예를 들어, 피어가 netDb 조회에 1.3초 만에 응답할 때, 이 왕복 지연 시간은 요청과 응답이 통과한 두 터널(인바운드와 아웃바운드)에 관련된 모든 router들의 프로파일과 조회된 피어의 프로파일에 기록됩니다. 전송 계층 지연이나 혼잡과 같은 직접적인 측정은 프로파일의 일부로 사용되지 않습니다. 이는 조작될 수 있고 측정하는 router와 연관될 수 있어 간단한 공격에 노출시킬 수 있기 때문입니다. 이러한 프로파일을 수집하면서 각각에 대해 일련의 계산이 실행되어 성능을 요약합니다 — 지연 시간, 많은 활동을 처리할 수 있는 용량, 현재 과부하 상태인지 여부, 그리고 네트워크에 얼마나 잘 통합되어 있는지를 평가합니다. 이러한 계산 결과는 활성 피어들과 비교되어 router를 네 개 계층으로 구성합니다 — 빠르고 높은 용량, 높은 용량, 실패하지 않음, 그리고 실패함. 이러한 계층의 임계값은 동적으로 결정되며, 현재는 상당히 간단한 알고리즘을 사용하지만 대안들이 존재합니다.
이 프로필 데이터를 사용하여, 가장 간단하고 합리적인 피어 선택 전략은 최상위 계층(빠르고 높은 용량)에서 피어를 무작위로 선택하는 것이며, 이는 현재 클라이언트 tunnel에 배포되어 있습니다. 탐색 tunnel(netDb 및 tunnel 관리에 사용)은 “실패하지 않는” 계층(더 나은 계층의 router도 포함)에서 피어를 무작위로 선택하여, 피어가 router를 더 광범위하게 샘플링할 수 있게 하고, 실제로는 무작위 언덕 오르기 를 통해 피어 선택을 최적화합니다. 그러나 이러한 전략만으로는 전임자 공격과 netDb 수집 공격을 통해 router의 최상위 계층에 있는 피어에 대한 정보가 누설됩니다. 이에 따라 부하를 균등하게 분산시키지는 못하지만, 특정 부류의 공격자가 수행하는 공격을 해결할 수 있는 여러 대안이 존재합니다.
임의의 키를 선택하고 그 키로부터의 XOR 거리에 따라 피어들을 정렬함으로써, predecessor 및 harvesting 공격에서 유출되는 정보가 피어들의 실패율과 계층의 이탈률에 따라 감소됩니다. netDb harvesting 공격을 처리하는 또 다른 간단한 전략은 인바운드 tunnel 게이트웨이를 고정하면서 tunnel 내부의 더 깊은 피어들을 무작위화하는 것입니다. 클라이언트가 접촉하는 적대자들에 대한 predecessor 공격을 처리하기 위해서는 아웃바운드 tunnel 엔드포인트들도 고정된 상태로 유지될 것입니다. 가장 노출된 지점에서 고정할 피어의 선택은 모든 피어가 결국 실패하므로 지속 시간에 제한이 있어야 하며, 다른 router들의 측정된 평균 장애 간격을 모방하기 위해 반응적으로 조정하거나 사전에 회피할 수 있습니다. 이 두 전략은 차례로 결합될 수 있으며, 고정된 노출 피어와 tunnel 자체 내에서의 XOR 기반 순서를 사용합니다. 더 엄격한 전략은 잠재적 tunnel의 정확한 피어들과 순서를 고정하여, 모든 피어가 매번 같은 방식으로 참여하는데 동의하는 경우에만 개별 피어들을 사용하는 것입니다. 이는 각 피어의 predecessor와 successor가 항상 동일한 XOR 기반 순서와 다르며, XOR은 단지 그들의 순서가 변경되지 않도록 보장합니다.
앞서 언급했듯이, I2P는 현재(릴리스 0.8) XOR 기반 정렬과 함께 위의 계층화된 랜덤 전략을 포함하고 있습니다. tunnel 운영, 관리 및 피어 선택에 관련된 메커니즘에 대한 더 자세한 논의는 tunnel spec 에서 찾을 수 있습니다.
Network Database (netDb)
앞서 언급했듯이, I2P의 netDb는 네트워크의 메타데이터를 공유하는 역할을 합니다. 이에 대한 자세한 내용은 network database 페이지에 나와 있지만, 기본적인 설명은 아래에서 확인할 수 있습니다.
모든 I2P router는 로컬 netDb를 포함하지만, 모든 router가 DHT에 참여하거나 leaseSet 조회에 응답하는 것은 아닙니다. DHT에 참여하고 leaseSet 조회에 응답하는 router들을 ‘floodfill’이라고 합니다. Router는 수동으로 floodfill로 구성되거나, 충분한 용량을 갖고 신뢰할 수 있는 운영을 위한 기타 기준을 충족할 경우 자동으로 floodfill이 될 수 있습니다.
다른 I2P router들은 floodfill에 간단한 ‘store’와 ’lookup’ 쿼리를 보내서 데이터를 저장하고 조회합니다. floodfill router가 ‘store’ 쿼리를 받으면, Kademlia 알고리즘 을 사용하여 다른 floodfill router들에게 정보를 전파합니다. ’lookup’ 쿼리는 현재 중요한 보안 문제를 피하기 위해 다르게 동작합니다. lookup이 수행될 때, floodfill router는 lookup을 다른 피어에게 전달하지 않고, (요청된 데이터가 있다면) 항상 스스로 응답합니다.
네트워크 데이터베이스에는 두 가지 유형의 정보가 저장됩니다.
- RouterInfo는 특정 I2P router에 대한 정보와 연결 방법을 저장합니다
- LeaseSet은 특정 목적지(예: I2P 웹사이트, 이메일 서버…)에 대한 정보를 저장합니다
이 모든 정보는 게시 당사자에 의해 서명되고 해당 정보를 사용하거나 저장하는 모든 I2P router에 의해 검증됩니다. 또한 데이터에는 오래된 항목의 저장과 가능한 공격을 방지하기 위한 타이밍 정보가 포함되어 있습니다. 이것이 I2P가 정확한 시간을 유지하기 위한 필요한 코드를 번들로 포함하여 가끔 SNTP 서버들(pool.ntp.org 라운드 로빈이 기본값)을 조회하고 전송 계층에서 router들 간의 시간 차이를 감지하는 이유이기도 합니다.
몇 가지 추가적인 주의사항들도 중요합니다.
게시되지 않고 암호화된 leaseSet: 특정 사람들만이 목적지에 도달할 수 있기를 원할 수 있습니다. 이는 목적지를 netDb에 게시하지 않음으로써 가능합니다. 하지만 다른 수단을 통해 목적지를 전송해야 합니다. 이는 ‘암호화된 leaseSet’에 의해 지원됩니다. 이러한 leaseSet은 복호화 키에 접근 권한이 있는 사람들만이 해독할 수 있습니다.
부트스트래핑: netDb 부트스트래핑은 매우 간단합니다. router가 도달 가능한 피어의 routerInfo를 하나라도 받을 수 있게 되면, 해당 router에게 네트워크의 다른 router들에 대한 참조를 요청할 수 있습니다. 현재 많은 사용자들이 이러한 정보를 제공하기 위해 자신의 routerInfo 파일을 웹사이트에 게시하고 있습니다. I2P는 자동으로 이러한 웹사이트 중 하나에 연결하여 routerInfo 파일을 수집하고 부트스트래핑을 수행합니다. I2P는 이 부트스트랩 과정을 “리시딩"이라고 부릅니다.
조회 확장성: I2P 네트워크에서의 조회는 반복적이며, 재귀적이지 않습니다. floodfill로부터의 조회가 실패하면, 다음으로 가장 가까운 floodfill에 대해 조회가 반복됩니다. floodfill은 데이터를 위해 다른 floodfill에게 재귀적으로 요청하지 않습니다. 반복적 조회는 대규모 DHT 네트워크로 확장 가능합니다.
전송 프로토콜
router 간 통신은 외부 공격자에 대해 기밀성과 무결성을 제공하면서, 연락한 router가 주어진 메시지를 수신해야 하는 올바른 대상임을 인증해야 합니다. router가 다른 router와 통신하는 구체적인 방법은 중요하지 않습니다 — 이러한 기본 필수 조건들을 제공하기 위해 서로 다른 시점에서 세 가지 별도의 프로토콜이 사용되었습니다.
I2P는 현재 TCP 기반의 NTCP2 와 UDP 기반의 SSU2 두 가지 전송 프로토콜을 지원합니다. 이들은 이전 버전인 NTCP 와 SSU 프로토콜을 대체했으며, 기존 프로토콜들은 현재 더 이상 사용되지 않습니다. 두 프로토콜 모두 IPv4와 IPv6를 지원합니다. TCP와 UDP 전송을 모두 지원함으로써 I2P는 제한적인 검열 체제에서 트래픽을 차단하려는 방화벽을 포함한 대부분의 방화벽을 효과적으로 통과할 수 있습니다. NTCP2와 SSU2는 현대적인 암호화 표준을 사용하고, 트래픽 식별 저항성을 개선하며, 효율성과 보안을 증대하고, NAT 통과를 더욱 견고하게 만들도록 설계되었습니다. Router들은 지원하는 각 전송 방식과 IP 주소를 netDb에 게시합니다. 공용 IPv4와 IPv6 네트워크에 접근할 수 있는 router들은 일반적으로 NTCP2/SSU2와 IPv4/IPv6의 각 조합별로 하나씩 총 네 개의 주소를 게시합니다.
SSU2 는 SSU의 목표를 지원하고 확장합니다. SSU2는 Wireguard 및 QUIC과 같은 다른 현대적인 UDP 기반 프로토콜과 많은 유사점을 가지고 있습니다. UDP를 통한 네트워크 메시지의 안정적인 전송에 더하여, SSU2는 peer-to-peer, 협력적 IP 주소 감지, 방화벽 감지, 그리고 NAT traversal을 위한 특화된 기능을 제공합니다. SSU 사양 에서 설명된 바와 같이:
이 프로토콜의 목표는 제3자가 쉽게 식별할 수 있는 데이터를 최소한으로만 노출하면서 안전하고 인증된, 준신뢰성 있는 비순차적 메시지 전달을 제공하는 것입니다. 고도의 통신뿐만 아니라 TCP 친화적인 혼잡 제어를 지원해야 하며 PMTU 탐지를 포함할 수 있습니다. 일반 사용자에게 충분한 속도로 대용량 데이터를 효율적으로 전송할 수 있어야 합니다. 또한 대부분의 NAT나 방화벽과 같은 네트워크 장애물을 해결하기 위한 기술을 지원해야 합니다.
NTCP2 는 NTCP의 목표를 지원하고 확장합니다. 현대적인 암호화 표준을 사용하여 TCP를 통한 효율적이고 완전히 암호화된 네트워크 메시지 전송과 트래픽 식별에 대한 저항성을 제공합니다.
I2P는 여러 전송 방식을 동시에 지원합니다. 아웃바운드 연결을 위한 특정 전송 방식은 “입찰"로 선택됩니다. 각 전송 방식이 연결에 대해 입찰하고 이러한 입찰의 상대적 가치가 우선순위를 할당합니다. 전송 방식들은 피어에 대한 기존 연결이 이미 설정되어 있는지 여부에 따라 다른 입찰로 응답할 수 있습니다.
bid (우선순위) 값은 구현에 따라 달라지며 트래픽 조건, 연결 수 및 기타 요인에 따라 변할 수 있습니다. Router들은 또한 각 전송 방식과 주소에 대한 전송 “비용"으로 netDb에 인바운드 연결에 대한 전송 선호도를 게시합니다.
암호화
I2P는 암호화, 인증, 검증을 위해 여러 프로토콜 계층에서 암호학을 사용합니다. 주요 프로토콜 계층은 다음과 같습니다: 전송, tunnel 구축 메시지, tunnel 계층 암호화, 네트워크 데이터베이스 메시지, 그리고 종단간(garlic) 메시지입니다. I2P의 원래 설계는 당시 안전하다고 여겨지던 소규모 암호화 기본 요소 집합을 사용했습니다. 여기에는 ElGamal 비대칭 암호화, DSA-SHA1 서명, AES256/CBC 대칭 암호화, SHA-256 해시가 포함되었습니다. 사용 가능한 컴퓨팅 성능이 증가하고 암호학 연구가 수년에 걸쳐 크게 발전함에 따라, I2P는 기본 요소와 프로토콜을 업그레이드해야 했습니다. 따라서 우리는 “암호화 유형"과 “서명 유형"의 개념을 추가하고, 이러한 식별자를 포함하고 지원을 나타내도록 프로토콜을 확장했습니다. 이를 통해 우리는 하위 호환성을 깨뜨리거나 네트워크 업데이트를 위한 “플래그 데이"를 요구하지 않으면서도, 현대 암호학에 대한 네트워크 지원을 주기적으로 업데이트하고 확장하며 새로운 기본 요소에 대해 네트워크를 미래 대비할 수 있습니다. 일부 서명 및 암호화 유형은 실험적 사용을 위해 예약되어 있기도 합니다.
현재 대부분의 프로토콜 계층에서 사용되는 기본 암호화 방식은 X25519 키 교환, EdDSA 서명, ChaCha20/Poly1305 인증 대칭 암호화, 그리고 SHA-256 해시입니다. AES256은 여전히 tunnel 계층 암호화에 사용됩니다. 이러한 현대적인 프로토콜들은 네트워크 통신의 대부분에 사용됩니다. ElGamal, ECDSA, DSA-SHA1을 포함한 기존 암호화 방식들은 구형 router들과의 통신 시 하위 호환성을 위해 대부분의 구현에서 계속 지원됩니다. 일부 오래된 프로토콜들은 더 이상 사용되지 않거나 완전히 제거되었습니다. 가까운 미래에는 강력한 보안 표준을 유지하기 위해 포스트 양자(PQ) 또는 하이브리드-PQ 암호화 및 서명으로의 마이그레이션에 대한 연구를 시작할 예정입니다.
이러한 암호화 기본 요소들이 결합되어 다양한 공격자에 대한 I2P의 계층화된 방어 체계를 제공합니다. 가장 낮은 수준에서는 router 간 통신이 전송 계층 보안으로 보호됩니다. 전송 계층을 통해 전달되는 터널 메시지들은 자체적인 계층화된 암호화를 가지고 있습니다. 다양한 다른 메시지들은 “garlic message” 내부에서 전달되며, 이것들 또한 암호화됩니다.
Garlic Messages
Garlic 메시지는 “onion” 계층 암호화의 확장으로, 단일 메시지의 내용이 여러 개의 “cloves"를 포함할 수 있게 해줍니다. 여기서 cloves는 각각의 전달 지시사항과 함께 완전히 형성된 메시지들입니다. 메시지는 정보에 접근해서는 안 되는 peer를 통해 평문으로 전달될 경우 garlic 메시지로 래핑됩니다. 예를 들어, router가 다른 router에게 tunnel 참여를 요청하고 싶을 때, 요청을 garlic 안에 래핑하고, 그 garlic을 수신 router의 공개키로 암호화한 후 tunnel을 통해 전달합니다. 또 다른 예로는 클라이언트가 목적지로 메시지를 보내고 싶을 때입니다. 발신자의 router는 해당 데이터 메시지를 (다른 메시지들과 함께) garlic으로 래핑하고, 그 garlic을 수신자의 leaseSet에 게시된 공개키로 암호화한 후 적절한 tunnel들을 통해 전달합니다.
암호화 계층 내부의 각 클로브에 첨부된 “지침"에는 클로브를 로컬로, 원격 라우터로, 또는 원격 라우터의 원격 터널로 전달하도록 요청하는 기능이 포함되어 있습니다. 이러한 지침에는 피어가 특정 시간이나 조건이 충족될 때까지 배송을 지연하도록 요청할 수 있는 필드가 있지만, 중요한 지연 이 배포될 때까지는 이행되지 않습니다. tunnel을 구축하지 않고도 garlic 메시지를 명시적으로 여러 홉으로 라우팅하거나, garlic 메시지로 감싸서 tunnel의 다음 홉으로 전달하기 전에 여러 홉을 거쳐 전달함으로써 tunnel 메시지를 재라우팅하는 것도 가능하지만, 이러한 기법들은 현재 기존 구현에서는 사용되지 않습니다.
세션 태그
신뢰할 수 없고 순서가 보장되지 않는 메시지 기반 시스템인 I2P는 비대칭 및 대칭 암호화 알고리즘의 간단한 조합을 사용하여 garlic 메시지에 데이터 기밀성과 무결성을 제공합니다. 원래 조합은 ElGamal/AES+SessionTags로 불렸지만, 이는 2048bit ElGamal, AES256, SHA256 및 32바이트 nonce의 간단한 사용을 설명하기에는 지나치게 장황한 방식입니다. 이 프로토콜은 여전히 지원되지만, 네트워크의 대부분은 새로운 프로토콜인 ECIES-X25519-AEAD-Ratchet으로 마이그레이션했습니다. 이 프로토콜은 X25519, ChaCha20/Poly1305, 그리고 32바이트 nonce를 생성하는 동기화된 PRNG를 결합합니다. 두 프로토콜 모두 아래에서 간략히 설명됩니다.
ElGamal/AES+SessionTags
router가 다른 router에게 garlic 메시지를 처음 암호화하려고 할 때, AES256 세션 키에 대한 키 자료를 ElGamal로 암호화하고 암호화된 ElGamal 블록 뒤에 AES256/CBC 암호화된 페이로드를 추가합니다. 암호화된 페이로드 외에도, AES 암호화된 섹션에는 페이로드 길이, 암호화되지 않은 페이로드의 SHA256 해시, 그리고 여러 개의 “session tags” — 무작위 32바이트 nonce들이 포함됩니다. 송신자가 다음에 다른 router에게 garlic 메시지를 암호화하려고 할 때, 새로운 세션 키를 ElGamal 암호화하는 대신 이전에 전달된 session tag 중 하나를 단순히 선택하고 해당 session tag와 함께 사용된 세션 키를 사용하여 이전과 같이 페이로드를 AES 암호화하며, session tag 자체를 앞에 붙입니다. router가 garlic 암호화된 메시지를 수신하면, 처음 32바이트가 사용 가능한 session tag와 일치하는지 확인합니다 — 일치하면 단순히 메시지를 AES 복호화하지만, 일치하지 않으면 첫 번째 블록을 ElGamal 복호화합니다.
각 세션 태그는 내부 적대자가 서로 다른 메시지를 동일한 router 간의 통신으로 불필요하게 연관시키는 것을 방지하기 위해 단 한 번만 사용할 수 있습니다. ElGamal/AES+SessionTag 암호화 메시지의 발신자는 언제 얼마나 많은 태그를 전달할지 선택하여, 수신자에게 일련의 메시지를 처리할 수 있을 만큼 충분한 태그를 미리 제공합니다. Garlic 메시지는 작은 추가 메시지를 clove로 묶어서(“delivery status message”) 성공적인 태그 전달을 감지할 수 있습니다. garlic 메시지가 의도된 수신자에게 도착하여 성공적으로 해독되면, 이 작은 delivery status message가 노출된 clove 중 하나가 되고, 수신자에게 해당 clove를 원래 발신자에게 (물론 inbound tunnel을 통해) 다시 보내라는 지시를 포함합니다. 원래 발신자가 이 delivery status message를 받으면, garlic 메시지에 포함된 세션 태그가 성공적으로 전달되었음을 알 수 있습니다.
세션 태그 자체는 매우 짧은 수명을 가지며, 사용되지 않으면 폐기됩니다. 또한 각 키에 대해 저장되는 수량과 키 자체의 수도 제한되어 있습니다. 너무 많이 도착하면 새로운 메시지나 오래된 메시지가 삭제될 수 있습니다. 발신자는 세션 태그를 사용하는 메시지가 제대로 전달되고 있는지 추적하며, 충분한 통신이 이루어지지 않으면 이전에 제대로 전달되었다고 가정했던 메시지들을 삭제하고 완전한 고비용 ElGamal 암호화로 되돌아갈 수 있습니다.
ECIES-X25519-AEAD-Ratchet
ElGamal/AES+SessionTags는 여러 측면에서 상당한 오버헤드가 필요했습니다. ElGamal이 상당히 느리기 때문에 CPU 사용량이 높았습니다. 대량의 session tag들을 미리 전달해야 하고 ElGamal 공개키가 매우 크기 때문에 대역폭이 과도했습니다. 대량의 session tag를 저장해야 하는 요구사항으로 인해 메모리 사용량이 높았습니다. session tag 전달 손실로 인해 신뢰성이 저하되었습니다.
ECIES-X25519-AEAD-Ratchet은 이러한 문제들을 해결하기 위해 설계되었습니다. X25519가 키 교환에 사용됩니다. ChaCha20/Poly1305가 인증된 대칭 암호화에 사용됩니다. 암호화 키는 “이중 래칫” 방식으로 주기적으로 순환됩니다. 세션 태그는 32바이트에서 8바이트로 줄어들고 PRNG로 생성됩니다. 이 프로토콜은 Signal과 WhatsApp에서 사용되는 signal 프로토콜과 많은 유사점을 가지고 있습니다. 이 프로토콜은 CPU, RAM, 대역폭에서 상당히 낮은 오버헤드를 제공합니다.
세션 태그는 세션 태그와 세션 키를 생성하기 위해 세션의 양쪽 끝에서 실행되는 결정론적 동기화된 PRNG에서 생성됩니다. PRNG는 SHA-256 HMAC을 사용하는 HKDF이며, X25519 DH 결과에서 시드됩니다. 세션 태그는 미리 전송되지 않으며, 메시지와 함께만 포함됩니다. 수신자는 세션 태그로 인덱싱된 제한된 수의 세션 키를 저장합니다. 송신자는 미리 전송되지 않기 때문에 세션 태그나 키를 저장할 필요가 없으며, 필요시 생성할 수 있습니다. 송신자와 수신자 간에 이 PRNG를 대략적으로 동기화하여 유지함으로써 (수신자가 다음 예를 들어 50개의 태그 윈도우를 사전 계산함), 주기적으로 많은 수의 태그를 묶어서 전송하는 오버헤드가 제거됩니다.
미래
I2P의 프로토콜은 휴대폰을 포함한 대부분의 플랫폼에서 효율적이며, 대부분의 위협 모델에 대해 안전합니다. 그러나 강력한 국가 지원 적대자들에 직면한 이들의 요구를 충족하고, 지속적인 암호학적 발전과 끊임없이 증가하는 컴퓨팅 파워의 위협에 대응하기 위해서는 추가적인 개선이 필요한 몇 가지 영역이 있습니다. 제한된 경로(restricted routes)와 가변 지연 시간(variable latency)이라는 두 가지 가능한 기능이 2003년 jrandom에 의해 제안되었습니다. 더 이상 이러한 기능들을 구현할 계획은 없지만, 아래에 설명되어 있습니다.
제한된 경로 운영
I2P는 기능적인 패킷 스위칭 네트워크 위에서 실행되도록 설계된 오버레이 네트워크로, 종단간 원리를 활용하여 익명성과 보안을 제공합니다. 인터넷이 더 이상 종단간 원리를 완전히 수용하지 않지만(NAT 사용으로 인해), I2P는 네트워크의 상당 부분이 접근 가능해야 합니다 — 제한된 경로를 사용하여 실행되는 여러 피어들이 가장자리에 있을 수 있지만, I2P는 대부분의 피어들이 접근 불가능한 극단적인 경우에 대한 적절한 라우팅 알고리즘을 포함하지 않습니다. 그러나 그러한 알고리즘을 사용하는 네트워크 위에서는 작동할 것입니다.
제한된 경로 운영은 직접 도달할 수 있는 피어에 제한이 있는 경우로, 제한된 경로가 어떻게 처리되는지에 따라 여러 가지 다른 기능적 및 익명성 영향을 미칩니다. 가장 기본적인 수준에서 제한된 경로는 피어가 인바운드 연결을 허용하지 않는 NAT 또는 방화벽 뒤에 있을 때 존재합니다. 이는 분산 홀 펀칭을 전송 계층에 통합하여 대부분 해결되었으며, 이를 통해 대부분의 NAT 및 방화벽 뒤에 있는 사람들이 별도 구성 없이 요청되지 않은 연결을 수신할 수 있게 되었습니다. 그러나 이것이 네트워크 내부의 router들에게 피어의 IP 주소 노출을 제한하지는 않습니다. 이들은 게시된 introducer를 통해 피어에게 소개받을 수 있기 때문입니다.
제한된 경로의 기능적 처리를 넘어서, IP 주소 노출을 제한하는 데 사용할 수 있는 두 가지 수준의 제한된 작동이 있습니다 — 통신을 위한 router별 tunnel 사용과 ‘client router’ 제공입니다. 전자의 경우, router들은 새로운 tunnel 풀을 구축하거나 탐색 풀을 재사용할 수 있으며, 전송 주소 대신 routerInfo의 일부로 일부 tunnel의 인바운드 게이트웨이를 게시할 수 있습니다. 피어가 해당 router와 연결하려고 할 때, netDb에서 해당 tunnel 게이트웨이를 확인하고 게시된 tunnel 중 하나를 통해 관련 메시지를 간단히 전송합니다. 제한된 경로 뒤의 피어가 응답하려는 경우, 직접적으로(피어에게 IP를 노출할 의향이 있는 경우) 또는 아웃바운드 tunnel을 통해 간접적으로 응답할 수 있습니다. 피어가 직접 연결된 router들이 해당 피어에게 도달하려고 할 때(예: tunnel 메시지를 전달하기 위해), 게시된 tunnel 게이트웨이보다 직접 연결을 우선시합니다. ‘client router’의 개념은 단순히 어떤 router 주소도 게시하지 않음으로써 제한된 경로를 확장합니다. 이러한 router는 netDb에 routerInfo를 게시할 필요조차 없으며, 단순히 연결하는 피어들에게 자체 서명된 routerInfo를 제공하기만 하면 됩니다(router의 공개 키를 전달하는 데 필요함).
제한된 라우트 뒤에 있는 사용자들에게는 트레이드오프가 있습니다. 이들은 다른 사람들의 tunnel에 덜 빈번하게 참여하게 될 가능성이 높고, 연결된 router들이 그렇지 않았다면 노출되지 않았을 트래픽 패턴을 추론할 수 있게 됩니다. 반면, 그러한 노출 비용이 IP가 사용 가능하게 되는 비용보다 낮다면, 그만한 가치가 있을 수 있습니다. 물론 이는 제한된 라우트 뒤에 있는 router가 접촉하는 피어들이 적대적이지 않다는 가정 하에서입니다 — 즉, 네트워크가 충분히 커서 연결을 위해 적대적인 피어를 사용할 확률이 충분히 작거나, 신뢰할 수 있는 (그리고 아마도 임시적인) 피어들이 대신 사용되는 경우입니다.
제한된 경로는 복잡하며, 전반적인 목표는 대부분 포기되었습니다. 여러 관련 개선사항들이 제한된 경로의 필요성을 크게 줄였습니다. 이제 방화벽 포트를 자동으로 열기 위해 UPnP를 지원합니다. IPv4와 IPv6를 모두 지원합니다. SSU2는 주소 탐지, 방화벽 상태 결정, 협력적 NAT hole punching을 개선했습니다. SSU2, NTCP2, 그리고 주소 호환성 검사는 tunnel이 구축되기 전에 tunnel hop들이 연결될 수 있음을 보장합니다. GeoIP와 국가 식별을 통해 제한적인 방화벽을 가진 국가의 peer들을 피할 수 있습니다. 그러한 방화벽 뒤에 숨겨진 router들에 대한 지원이 향상되었습니다. 일부 구현체들은 Yggdrasil과 같은 오버레이 네트워크의 peer들에 대한 연결도 지원합니다.
가변 지연시간
I2P의 초기 노력 대부분이 저지연 통신에 집중되어 있었지만, 처음부터 가변 지연 서비스를 염두에 두고 설계되었습니다. 가장 기본적인 수준에서, I2P 위에서 실행되는 애플리케이션들은 중간 및 고지연 통신의 익명성을 제공하면서도 여전히 그들의 트래픽 패턴을 저지연 트래픽과 혼합시킬 수 있습니다. 그러나 내부적으로 I2P는 garlic encryption을 통해 자체적인 중간 및 고지연 통신을 제공할 수 있습니다. 이는 메시지가 특정 지연 후, 특정 시간에, 특정 수의 메시지가 전달된 후, 또는 다른 믹싱 전략에 따라 전송되어야 한다고 명시합니다. 계층화된 암호화를 통해, clove가 지연 요청을 노출시킨 router만이 해당 메시지가 고지연을 필요로 한다는 것을 알게 되어, 트래픽이 저지연 트래픽과 더욱 잘 혼합될 수 있게 합니다. 전송 전제조건이 충족되면, clove를 보유하고 있던 router(그 자체도 garlic 메시지일 가능성이 높음)는 요청에 따라 단순히 이를 전달합니다 — router로, tunnel로, 또는 가장 가능성 있게는 원격 클라이언트 목적지로.
가변 지연 서비스의 목표는 이를 지원하기 위한 store-and-forward 메커니즘에 상당한 자원이 필요합니다. 이러한 메커니즘은 i2p-bote와 같은 다양한 메시징 애플리케이션에서 지원될 수 있고 실제로 지원되고 있습니다. 네트워크 수준에서는 Freenet과 같은 대체 네트워크가 이러한 서비스를 제공합니다. 우리는 I2P router 수준에서 이 목표를 추구하지 않기로 결정했습니다.
유사한 시스템
I2P의 아키텍처는 메시지 지향 미들웨어의 개념, DHT의 토폴로지, 자유 라우트 믹스넷의 익명성과 암호화, 그리고 패킷 스위칭 네트워킹의 적응성을 기반으로 구축됩니다. 하지만 그 가치는 새로운 개념이나 알고리즘에서 나오는 것이 아니라, 기존 시스템과 논문의 연구 결과를 신중하게 결합한 엔지니어링에서 나옵니다. 기술적, 기능적 비교를 위해 검토할 가치가 있는 유사한 노력들이 몇 가지 있지만, 특히 두 가지를 여기에서 언급하겠습니다 — Tor와 Freenet입니다.
네트워크 비교 페이지 도 참조하세요. 이 설명들은 2003년에 jrandom이 작성한 것으로 현재는 정확하지 않을 수 있습니다.
Tor
언뜻 보기에 Tor와 I2P는 기능적으로나 익명성 측면에서 많은 유사점을 가지고 있습니다. I2P의 개발은 Tor의 초기 단계 노력을 알기 전에 시작되었지만, 원래의 onion routing과 ZKS 노력의 많은 교훈들이 I2P의 설계에 통합되었습니다. 디렉토리 서버를 통한 본질적으로 신뢰할 수 있고 중앙집중화된 시스템을 구축하는 대신, I2P는 각 피어가 사용 가능한 자원을 최적으로 활용하는 방법을 결정하기 위해 다른 router들을 프로파일링하는 책임을 맡는 자체 조직화 네트워크 데이터베이스를 가지고 있습니다. 또 다른 주요 차이점은 I2P와 Tor 모두 계층화되고 순서가 정해진 경로(tunnel과 circuits/streams)를 사용하지만, I2P는 근본적으로 패킷 교환 네트워크인 반면 Tor는 근본적으로 회선 교환 네트워크라는 것입니다. 이를 통해 I2P는 혼잡이나 기타 네트워크 장애를 투명하게 우회하고, 중복 경로를 운영하며, 사용 가능한 자원에 걸쳐 데이터의 부하를 분산시킬 수 있습니다. Tor는 통합된 outproxy 발견 및 선택을 제공함으로써 유용한 outproxy 기능을 제공하는 반면, I2P는 그러한 애플리케이션 계층 결정을 I2P 위에서 실행되는 애플리케이션에게 맡깁니다. 실제로 I2P는 TCP와 같은 스트리밍 라이브러리 자체도 애플리케이션 계층으로 외부화하여 개발자들이 다양한 전략을 실험하고 그들의 도메인별 지식을 활용하여 더 나은 성능을 제공할 수 있도록 했습니다.
익명성 관점에서 보면, 핵심 네트워크들을 비교했을 때 많은 유사점이 있습니다. 그러나 몇 가지 핵심적인 차이점들이 있습니다. 내부 공격자나 대부분의 외부 공격자를 다룰 때, I2P의 단방향 tunnel은 단순히 플로우 자체를 살펴보는 것만으로도 Tor의 양방향 회로에서 노출되는 것보다 절반의 트래픽 데이터만 노출합니다 — HTTP 요청과 응답은 Tor에서는 동일한 경로를 따르지만, I2P에서는 요청을 구성하는 패킷들은 하나 이상의 아웃바운드 tunnel을 통해 나가고, 응답을 구성하는 패킷들은 하나 이상의 다른 인바운드 tunnel을 통해 돌아옵니다. I2P의 피어 선택 및 순서 전략이 전임자 공격(predecessor attack)을 충분히 해결해야 하지만, 양방향 tunnel로의 전환이 필요할 경우, 동일한 router들을 따라 인바운드와 아웃바운드 tunnel을 구축할 수 있습니다.
Tor의 망원경식 tunnel 생성 사용에서 또 다른 익명성 문제가 발생하는데, 회로의 셀이 적대자의 노드를 통과할 때 단순한 패킷 계수 및 타이밍 측정을 통해 적대자가 회로 내 어디에 위치하는지에 대한 통계적 정보가 노출됩니다. I2P는 단일 메시지로 단방향 tunnel 생성을 사용하여 이러한 데이터가 노출되지 않도록 합니다. tunnel 내 위치를 보호하는 것은 중요한데, 그렇지 않으면 적대자가 강력한 전임자, 교차점, 트래픽 확인 공격을 일련으로 수행할 수 있기 때문입니다.
전반적으로 Tor와 I2P는 각각의 초점에서 서로를 보완합니다 — Tor는 고속 익명 인터넷 outproxy 제공에 중점을 두는 반면, I2P는 그 자체로 분산화된 복원력 있는 네트워크 제공에 중점을 둡니다. 이론적으로는 둘 다 두 가지 목적을 모두 달성하는 데 사용될 수 있지만, 제한된 개발 자원을 고려할 때 각각 고유한 장단점을 가지고 있습니다. I2P 개발자들은 I2P의 설계를 활용하기 위해 Tor를 수정하는 데 필요한 단계들을 고려해왔지만, 자원 부족 상황에서 Tor의 실행 가능성에 대한 우려는 I2P의 패킷 스위칭 아키텍처가 희소한 자원을 더 효과적으로 활용할 수 있을 것임을 시사합니다.
Freenet
Freenet은 I2P 설계의 초기 단계에서 큰 역할을 했습니다 — 네트워크 내에 완전히 포함된 활기찬 가명 커뮤니티의 실행 가능성을 입증하고, outproxy에 내재된 위험을 피할 수 있음을 보여주었습니다. I2P의 첫 번째 씨앗은 Freenet의 대체 통신 계층으로 시작되었으며, 확장 가능하고 익명이며 안전한 점대점 통신의 복잡성을 검열 저항적 분산 데이터 저장소의 복잡성에서 분리하려고 시도했습니다. 그러나 시간이 지나면서 Freenet의 알고리즘에 내재된 일부 익명성과 확장성 문제로 인해 I2P의 초점은 Freenet의 구성 요소가 아닌 일반적인 익명 통신 계층 제공에 엄격히 머물러야 함이 분명해졌습니다. 수년에 걸쳐 Freenet 개발자들은 기존 설계의 약점을 인식하게 되었고, 실질적인 익명성을 제공하기 위해 “premix” 계층이 필요할 것이라고 제안하게 되었습니다. 즉, Freenet은 I2P나 Tor와 같은 믹스넷 위에서 실행되어야 하며, “클라이언트 노드"가 믹스넷을 통해 “서버 노드"에 데이터를 요청하고 게시하면, 서버 노드가 Freenet의 휴리스틱 분산 데이터 저장 알고리즘에 따라 데이터를 가져오고 저장하는 방식입니다.
Freenet의 기능은 I2P와 매우 상호 보완적입니다. Freenet은 중간 및 고지연 시스템 운영을 위한 많은 도구들을 기본적으로 제공하는 반면, I2P는 적절한 익명성을 제공하기에 적합한 저지연 mix network를 기본적으로 제공합니다. mixnet을 검열 저항성 분산 데이터 저장소로부터 분리하는 논리는 여전히 엔지니어링, 익명성, 보안, 그리고 리소스 할당 관점에서 자명해 보이므로, Freenet 팀이 그 방향으로 노력을 추구하기를 바랍니다. 만약 I2P나 Tor와 같은 기존 mixnet을 단순히 재사용하거나 (필요에 따라 개선하는 데 도움을 주는) 것이 아니라면 말입니다.
부록 A: 애플리케이션 계층
I2P 자체는 실제로 많은 일을 하지 않습니다 — 단순히 원격 목적지로 메시지를 보내고 로컬 목적지를 대상으로 하는 메시지를 받을 뿐입니다 — 흥미로운 작업의 대부분은 그 위의 계층에서 이루어집니다. 그 자체로 I2P는 익명이고 안전한 IP 계층으로 볼 수 있으며, 번들로 제공되는 streaming library 는 그 위에 구축된 익명이고 안전한 TCP 계층의 구현으로 볼 수 있습니다. 그 외에도 I2PTunnel 은 I2P 네트워크로 들어가거나 나가기 위한 범용 TCP 프록시 시스템을 제공하며, 다양한 네트워크 애플리케이션들이 최종 사용자를 위한 추가 기능을 제공합니다.
스트리밍 라이브러리
I2P streaming 라이브러리는 일반적인 streaming 인터페이스(TCP 소켓을 모방)로 볼 수 있으며, 구현체는 I2P의 높은 지연 시간을 고려한 여러 최적화와 함께 sliding window protocol 을 지원합니다. 개별 스트림은 최대 패킷 크기와 기타 옵션을 조정할 수 있지만, 4KB 압축 기본값은 손실된 메시지 재전송의 대역폭 비용과 여러 메시지의 지연 시간 사이에서 합리적인 절충안인 것으로 보입니다.
또한, 후속 메시지의 상대적으로 높은 비용을 고려하여, streaming 라이브러리의 메시지 스케줄링 및 전달 프로토콜은 전달되는 개별 메시지가 가능한 한 많은 정보를 포함할 수 있도록 최적화되었습니다. 예를 들어, streaming 라이브러리를 통해 프록시되는 작은 HTTP 트랜잭션은 단일 라운드 트립으로 완료될 수 있습니다 — 첫 번째 메시지는 SYN, FIN 및 작은 페이로드(일반적으로 HTTP 요청이 맞음)를 번들로 묶고, 응답은 SYN, FIN, ACK 및 작은 페이로드(많은 HTTP 응답이 맞음)를 번들로 묶습니다. SYN/FIN/ACK가 수신되었음을 HTTP 서버에 알리기 위해 추가 ACK가 전송되어야 하지만, 로컬 HTTP 프록시는 전체 응답을 브라우저에 즉시 전달할 수 있습니다.
그러나 전반적으로 streaming 라이브러리는 슬라이딩 윈도우, 혼잡 제어 알고리즘(slow start와 congestion avoidance 모두), 그리고 일반적인 패킷 동작(ACK, SYN, FIN, RST 등)을 갖춘 TCP의 추상화와 매우 유사합니다.
Naming Library 및 주소록
자세한 정보는 이름 지정 및 주소록 페이지를 참조하세요.
개발자: mihi, Ragnarok
I2P 내에서의 명명은 가능성의 스펙트럼 전반에 걸친 지지자들과 함께 처음부터 자주 논의되어온 주제입니다. 그러나 안전한 통신과 분산 운영에 대한 I2P의 본질적인 요구사항을 고려할 때, 전통적인 DNS 스타일의 명명 시스템은 명백히 배제되며, “다수결” 투표 시스템도 마찬가지입니다. 대신 I2P는 일반적인 명명 라이브러리와 로컬 이름에서 destination 매핑으로 작동하도록 설계된 기본 구현체를 제공하며, “Address Book"이라는 선택적 애드온 애플리케이션도 함께 제공합니다. address book은 web-of-trust 기반의 안전하고 분산된 인간 친화적 명명 시스템으로, 모든 인간 친화적 이름이 전역적으로 고유해야 한다는 요구사항만을 포기하고 로컬 고유성만을 요구합니다. I2P의 모든 메시지는 destination에 의해 암호화적으로 주소가 지정되지만, 다른 사람들은 서로 다른 destination을 참조하는 “Alice"에 대한 로컬 address book 항목을 가질 수 있습니다. 사람들은 web of trust에서 지정된 피어들의 공개된 address book을 가져오거나, 제3자를 통해 제공된 항목들을 추가하거나, (일부 사람들이 선착순 등록 시스템을 사용하여 일련의 공개된 address book을 구성하는 경우) 이러한 address book을 네임 서버로 취급하여 전통적인 DNS를 모방하는 방식으로 새로운 이름을 발견할 수 있습니다.
I2P는 DNS 형태의 서비스 사용을 권장하지 않는데, 이는 사이트가 탈취당할 경우 발생하는 피해가 엄청날 수 있기 때문입니다 — 그리고 안전하지 않은 destination은 가치가 없습니다. DNSsec 자체도 여전히 등록기관과 인증 기관에 의존하는 반면, I2P에서는 destination으로 보내진 요청이 차단되거나 응답이 위조될 수 없습니다. 요청들이 destination의 공개 키로 암호화되고, destination 자체가 단순히 공개 키 한 쌍과 인증서이기 때문입니다. 반면 DNS 형태의 시스템은 조회 경로상의 어떤 네임 서버든 간단한 서비스 거부 공격과 스푸핑 공격을 수행할 수 있습니다. 중앙화된 인증 기관이 서명한 응답을 인증하는 인증서를 추가하면 악의적인 네임서버 문제 대부분을 해결할 수 있지만, 재전송 공격과 악의적인 인증 기관 공격의 여지는 여전히 남아있을 것입니다.
투표 방식의 명명법도 위험한데, 특히 익명 시스템에서 Sybil 공격의 효과를 고려할 때 더욱 그렇습니다. 공격자는 임의로 많은 수의 peer를 생성하고 각각으로 “투표"하여 특정 이름을 장악할 수 있습니다. 작업 증명 방법을 사용하여 신원을 무료가 아니게 만들 수 있지만, 네트워크가 성장함에 따라 온라인 투표를 수행하기 위해 모든 사람에게 연락해야 하는 부하는 현실적이지 않으며, 전체 네트워크를 조회하지 않으면 서로 다른 답변 집합에 도달할 수 있습니다.
그러나 인터넷과 마찬가지로, I2P는 명명 시스템의 설계와 운영을 (IP와 유사한) 통신 계층에서 분리하고 있습니다. 번들로 제공되는 명명 라이브러리에는 대체 명명 시스템이 연결될 수 있는 간단한 서비스 제공자 인터페이스가 포함되어 있어, 최종 사용자가 선호하는 명명 트레이드오프를 결정할 수 있습니다.
I2PTunnel
개발자: mihi
I2PTunnel은 아마도 I2P의 가장 인기 있고 다용도적인 클라이언트 애플리케이션으로, I2P 네트워크 안팎으로의 일반적인 프록시 기능을 제공합니다. I2PTunnel은 네 개의 별도 프록시 애플리케이션으로 볼 수 있습니다 — 인바운드 TCP 연결을 수신하여 지정된 I2P destination으로 전달하는 “client”, HTTP 프록시처럼 작동하여 요청을 적절한 I2P destination으로 전달하는 “httpclient” (일명 “eepproxy”, 필요시 네이밍 서비스에 쿼리 후), destination에서 인바운드 I2P 스트리밍 연결을 수신하여 지정된 TCP 호스트+포트로 전달하는 “server”, 그리고 HTTP 요청과 응답을 파싱하여 더 안전한 작동을 가능하게 하는 “server"의 확장인 “httpserver"입니다. 추가적으로 “socksclient” 애플리케이션도 있지만, 앞서 언급한 이유로 사용을 권장하지 않습니다.
I2P 자체는 outproxy 네트워크가 아닙니다 — 믹스 네트워크에서 데이터를 믹스 안팎으로 전달하는 것에 내재된 익명성과 보안 문제로 인해 I2P의 설계는 외부 리소스를 필요로 하지 않으면서 사용자의 요구를 충족할 수 있는 익명 네트워크 제공에 집중되어 있습니다. 그러나 I2PTunnel “httpclient” 애플리케이션은 outproxy를 위한 훅을 제공합니다 — 요청된 호스트명이 “.i2p"로 끝나지 않으면, 사용자가 제공한 outproxy 세트에서 무작위 목적지를 선택하고 요청을 해당 목적지로 전달합니다. 이러한 목적지들은 단순히 outproxy 실행을 명시적으로 선택한 자원봉사자들이 운영하는 I2PTunnel “server” 인스턴스입니다 — 기본적으로 outproxy인 사람은 없으며, outproxy를 실행한다고 해서 자동으로 다른 사람들이 당신을 통해 프록시하라고 알리는 것은 아닙니다. outproxy는 내재적인 약점을 가지고 있지만, I2P 사용에 대한 간단한 개념 증명을 제공하고 일부 사용자에게는 충분할 수 있는 위협 모델 하에서 일부 기능을 제공합니다.
I2PTunnel은 사용 중인 대부분의 애플리케이션을 가능하게 합니다. 웹서버를 가리키는 “httpserver"를 통해 누구나 자신만의 익명 웹사이트(또는 “I2P Site”)를 운영할 수 있습니다 — 이 목적을 위해 웹서버가 I2P와 함께 번들로 제공되지만, 어떤 웹서버든 사용할 수 있습니다. 누구나 익명으로 호스팅되는 IRC 서버 중 하나를 가리키는 “client"를 실행할 수 있으며, 각 IRC 서버는 로컬 IRCd를 가리키는 “server"를 실행하고 자체 “client” tunnel을 통해 IRCd 간 통신을 수행합니다. 최종 사용자들은 또한 I2Pmail의 POP3 및 SMTP 목적지를 가리키는 “client” tunnel을 가지고 있으며(이는 단순히 POP3 및 SMTP 서버를 가리키는 “server” 인스턴스입니다), I2P의 CVS 서버를 가리키는 “client” tunnel을 통해 익명 개발이 가능합니다. 때로는 사람들이 NNTP 서버를 가리키는 “server” 인스턴스에 접근하기 위해 “client” 프록시를 실행하기도 했습니다.
I2PSnark
I2PSnark 개발자: jrandom 외, mjw 의 Snark 클라이언트에서 포팅
I2P 설치와 함께 번들로 제공되는 I2PSnark는 멀티토렌트 기능을 갖춘 간단한 익명 BitTorrent 클라이언트로, 모든 기능을 일반 HTML 웹 인터페이스를 통해 제공합니다.
I2Pmail / Susimail
개발자: postman, susi23, mastiejaner
I2Pmail은 애플리케이션이라기보다는 서비스입니다. postman은 mastiejaner와 함께 개발된 일련의 구성 요소에 액세스하는 I2PTunnel 인스턴스를 통해 POP3 및 SMTP 서비스로 내부 및 외부 이메일을 모두 제공하여, 사람들이 선호하는 메일 클라이언트를 사용해 익명으로 메일을 보내고 받을 수 있게 합니다. 하지만 대부분의 메일 클라이언트가 상당한 식별 정보를 노출하기 때문에, I2P는 I2P의 익명성 요구사항을 염두에 두고 특별히 구축된 susi23의 웹 기반 susimail 클라이언트를 번들로 제공합니다. I2Pmail/mail.i2p 서비스는 투명한 바이러스 필터링뿐만 아니라 hashcash 강화 할당량을 통한 서비스 거부 공격 방지를 제공합니다. 또한 각 사용자는 mail.i2p outproxy를 통해 전달하기 전에 자신의 배치 전략을 제어할 수 있습니다. 이 outproxy는 mail.i2p SMTP 및 POP3 서버와 분리되어 있으며, outproxy와 inproxy 모두 I2P 자체를 통해 mail.i2p SMTP 및 POP3 서버와 통신하므로, 이러한 비익명 위치가 손상되더라도 사용자의 메일 계정이나 활동 패턴에 접근할 수 없습니다.