참고: 다음은 I2P 네이밍 시스템의 배경, 일반적인 논의사항 및 가능한 대안에 대한 설명입니다. 현재 문서는 네이밍 페이지 를 참조하세요.
폐기된 대안들
I2P 내에서의 명명(naming)은 처음부터 다양한 가능성의 스펙트럼에 걸친 지지자들과 함께 자주 논의되어 온 주제입니다. 그러나 I2P의 보안 통신과 분산 운영에 대한 본질적인 요구를 고려할 때, 전통적인 DNS 스타일의 명명 시스템은 명백히 배제되며, “다수결” 투표 시스템도 마찬가지입니다.
하지만 I2P는 DNS와 유사한 서비스 사용을 권장하지 않습니다. 사이트 하이재킹으로 인한 피해가 엄청날 수 있고, 안전하지 않은 destination은 가치가 없기 때문입니다. DNSsec 자체도 여전히 등록기관과 인증 기관에 의존하는 반면, I2P에서는 destination으로 전송된 요청이 가로채이거나 응답이 위조될 수 없습니다. 이는 destination의 공개 키로 암호화되며, destination 자체가 단순히 한 쌍의 공개 키와 인증서이기 때문입니다. 반면 DNS 방식의 시스템은 조회 경로상의 모든 네임 서버가 간단한 서비스 거부 공격과 스푸핑 공격을 수행할 수 있도록 허용합니다. 중앙화된 인증 기관에 의해 서명된 응답을 인증하는 인증서를 추가하면 적대적인 네임서버 문제의 대부분을 해결할 수 있지만, 재전송 공격과 적대적인 인증 기관 공격의 여지는 남겨두게 됩니다.
투표 방식 명명은 특히 익명 시스템에서 시빌 공격의 효과를 고려할 때 매우 위험합니다. 공격자는 임의로 많은 수의 피어를 생성하여 각각으로 “투표"함으로써 특정 이름을 탈취할 수 있습니다. 작업 증명 방법을 사용하여 신원 생성에 비용을 부과할 수 있지만, 네트워크가 성장함에 따라 온라인 투표를 위해 모든 참여자에게 연락하는 데 필요한 부하는 비현실적이며, 전체 네트워크를 조회하지 않는다면 서로 다른 답변 세트에 도달할 수 있습니다.
그러나 인터넷과 마찬가지로 I2P는 네이밍 시스템의 설계와 운영을 (IP와 유사한) 통신 레이어에서 분리하고 있습니다. 번들로 제공되는 네이밍 라이브러리는 대체 네이밍 시스템 이 연결할 수 있는 간단한 서비스 제공자 인터페이스를 포함하여, 최종 사용자가 선호하는 네이밍 트레이드오프 유형을 선택할 수 있도록 합니다.
논의
Names: Decentralized, Secure, Human-Meaningful: Choose Two 도 참조하세요.
jrandom의 댓글
(2005년 11월 26일 구 Syndie 게시물에서 각색)
Q: 일부 호스트가 하나의 주소에 대해 동의하지 않고, 일부 주소는 작동하지만 다른 주소는 작동하지 않는 경우 어떻게 해야 하나요? 이름의 올바른 소스는 누구인가요?
A: 할 수 없습니다. 이것이 실제로 I2P의 이름과 DNS 작동 방식 간의 중요한 차이점입니다 - I2P의 이름은 사람이 읽을 수 있고 안전하지만 전역적으로 고유하지 않습니다. 이는 의도적인 설계이며, 보안에 대한 우리의 필요성에 내재된 부분입니다.
만약 내가 어떤 이름과 연결된 목적지를 변경하도록 당신을 설득할 수 있다면, 나는 성공적으로 그 사이트를 “장악"하게 될 것이고, 어떤 상황에서도 이는 받아들일 수 없습니다. 대신, 우리가 하는 것은 이름을 로컬에서 고유하게 만드는 것입니다: 이는 당신이 사이트를 부르는 이름으로, 브라우저 북마크에 추가하거나 IM 클라이언트의 친구 목록에 추가할 때 원하는 대로 이름을 지을 수 있는 것과 같습니다. 당신이 “보스"라고 부르는 사람을 다른 누군가는 “샐리"라고 부를 수 있는 것처럼 말이죠.
이름은 절대로 안전하게 사람이 읽을 수 있으면서 동시에 전역적으로 고유할 수 없습니다.
zzz의 댓글
다음은 zzz가 I2P의 네이밍 시스템에 대한 몇 가지 일반적인 불만사항들을 검토한 내용입니다.
- 비효율성: 전체 hosts.txt가 다운로드됩니다 (변경된 경우, eepget이 etag와 last-modified 헤더를 사용하므로). 현재 약 800개의 호스트에 대해 약 400K입니다.
맞습니다. 하지만 이것은 I2P의 맥락에서는 많은 트래픽이 아닙니다. I2P 자체가 매우 비효율적이기 때문입니다(floodfill 데이터베이스, 막대한 암호화 오버헤드 및 패딩, garlic routing 등). 12시간마다 누군가로부터 hosts.txt 파일을 다운로드한다면 평균적으로 약 10바이트/초 정도입니다.
I2P에서 일반적으로 그렇듯이, 여기서는 익명성과 효율성 사이에 근본적인 트레이드오프가 있습니다. 일부에서는 etag와 last-modified 헤더를 사용하는 것이 마지막으로 데이터를 요청한 시점을 노출하기 때문에 위험하다고 말합니다. 다른 사람들은 (jump 서비스가 하는 것과 유사하지만 더 자동화된 방식으로) 특정 키만 요청하는 것을 제안했는데, 이는 익명성에 추가적인 비용을 수반할 수 있습니다.
가능한 개선 사항으로는 address book을 대체하거나 보완하는 것(i2host.i2p 참조), 또는 http://example.i 2p/hosts.txt 대신 http://example.i 2p/cgi-bin/recenthosts.cgi에 구독하는 것과 같은 간단한 방법이 있을 것입니다. 가상의 recenthosts.cgi가 예를 들어 지난 24시간 동안의 모든 호스트를 배포한다면, 이는 last-modified와 etag가 있는 현재의 hosts.txt보다 더 효율적이고 더 익명성을 제공할 수 있습니다.
샘플 구현은 stats.i2p의 http://stats.i 2p/cgi-bin/newhosts.txt 에서 확인할 수 있습니다. 이 스크립트는 타임스탬프가 포함된 Etag를 반환합니다. If-None-Match etag와 함께 요청이 들어오면, 스크립트는 해당 타임스탬프 이후의 새로운 호스트만 반환하거나, 새로운 호스트가 없을 경우 304 Not Modified를 반환합니다. 이런 방식으로 스크립트는 구독자가 알지 못하는 호스트만 주소록 호환 방식으로 효율적으로 반환합니다.
따라서 비효율성은 큰 문제가 되지 않으며, 급진적인 변화 없이도 상황을 개선할 수 있는 여러 가지 방법이 있습니다.
- 확장성 부족: 400K hosts.txt (선형 검색 방식)는 현재로서는 그리 크지 않으며, 문제가 되기 전까지 10배 또는 100배까지 증가할 수 있을 것으로 보입니다.
네트워크 트래픽에 관해서는 위를 참조하세요. 하지만 키에 대한 느린 실시간 네트워크 쿼리를 수행할 것이 아니라면, 키당 약 500바이트의 비용으로 전체 키 세트를 로컬에 저장해야 합니다.
- 구성 및 “신뢰"가 필요함: 기본 주소록은 http://www.i2p2.i 2p/hosts.txt에만 구독되어 있으며, 이는 거의 업데이트되지 않아 신규 사용자 경험이 좋지 않습니다.
이는 매우 의도적입니다. jrandom은 사용자가 hosts.txt 제공자를 “신뢰"하기를 원하며, 그가 자주 말하듯이 “신뢰는 불리언이 아닙니다”. 구성 단계는 익명 네트워크에서 신뢰 문제에 대해 사용자가 생각하도록 강제하려는 시도입니다.
또 다른 예로, HTTP Proxy의 “I2P Site Unknown” 오류 페이지에는 몇 가지 점프 서비스가 나열되어 있지만, 특정 서비스를 “추천"하지는 않으며 사용자가 선택하도록 (또는 선택하지 않도록) 하고 있습니다. jrandom은 우리가 나열된 제공업체들을 목록에 올릴 만큼은 신뢰하지만 자동으로 키를 가져올 만큼 신뢰하지는 않는다고 말할 것입니다.
이것이 얼마나 성공적일지는 확실하지 않습니다. 하지만 네이밍 시스템에는 어떤 형태의 신뢰 계층이 있어야 합니다. 모든 사람을 동등하게 대우하는 것은 하이재킹의 위험을 증가시킬 수 있습니다.
- DNS가 아닙니다
안타깝게도 I2P를 통한 실시간 조회는 웹 브라우징 속도를 크게 저하시킬 것입니다.
또한 DNS는 제한된 캐싱과 생존 시간을 가진 조회 기반인 반면, I2P 키는 영구적입니다.
물론 작동하게 만들 수는 있지만, 왜 그래야 할까요? 적합하지 않습니다.
- 신뢰할 수 없음: 주소록 구독을 위해 특정 서버에 의존합니다.
네, 이는 여러분이 구성한 몇 개의 서버에 따라 달라집니다. I2P 내에서 서버와 서비스는 계속 생겨나고 사라집니다. 다른 중앙화된 시스템(예: DNS 루트 서버)도 동일한 문제를 가지고 있습니다. 완전히 분산화된 시스템(모든 사람이 권한을 가짐)은 “모든 사람이 루트 DNS 서버” 솔루션을 구현하거나, hosts.txt에 있는 모든 사람을 주소록에 추가하는 스크립트와 같은 더욱 간단한 방법으로 가능합니다.
하지만 모든 권위적 솔루션을 옹호하는 사람들은 일반적으로 충돌과 하이재킹 문제를 제대로 검토하지 않았습니다.
- 어색하고 실시간이 아님: hosts.txt 제공자, 키 추가 웹 폼 제공자, jump 서비스 제공자, I2P 사이트 상태 보고자들의 임시방편적인 조합입니다. Jump 서버와 구독은 번거로우며, DNS처럼 자연스럽게 작동해야 합니다.
신뢰성과 신뢰 섹션을 참조하세요.
요약하자면, 현재 시스템은 심각하게 망가져 있거나 비효율적이거나 확장성이 없는 것은 아니며, “그냥 DNS를 사용하자"는 제안들은 충분히 검토되지 않은 것입니다.
대안
I2P 소스는 여러 플러그인 방식의 네이밍 시스템을 포함하고 있으며, 네이밍 시스템 실험을 가능하게 하는 설정 옵션을 지원합니다.
- Meta - 두 개 이상의 다른 네이밍 시스템을 순서대로 호출합니다. 기본적으로 PetName을 먼저 호출한 다음 HostsTxt를 호출합니다.
- PetName - petnames.txt 파일에서 조회합니다. 이 파일의 형식은 hosts.txt와 동일하지 않습니다.
- HostsTxt - 다음 파일들을 순서대로 조회합니다:
- privatehosts.txt
- userhosts.txt
- hosts.txt
- AddressDB - 각 호스트가 addressDb/ 디렉토리의 별도 파일에 나열됩니다.
- Eepget - 외부 서버로부터 HTTP 조회 요청을 수행합니다 - Meta와 함께 HostsTxt 조회 후에 스택되어야 합니다. 이는 점프 시스템을 보강하거나 대체할 수 있습니다. 인메모리 캐싱을 포함합니다.
- Exec - 조회를 위해 외부 프로그램을 호출하며, 자바와 독립적으로 조회 스키마에 대한 추가적인 실험을 허용합니다. HostsTxt 후에 사용하거나 단독 네이밍 시스템으로 사용할 수 있습니다. 인메모리 캐싱을 포함합니다.
- Dummy - Base64 이름에 대한 폴백으로 사용되며, 그렇지 않으면 실패합니다.
현재 이름 체계는 고급 설정 옵션 i2p.naming.impl로 변경할 수 있습니다 (재시작 필요). 자세한 내용은 core/java/src/net/i2p/client/naming을 참조하세요.
새로운 시스템은 HostsTxt와 함께 스택되어야 하거나, 로컬 저장소 및/또는 주소록 구독 기능을 구현해야 합니다. 주소록은 hosts.txt 파일과 형식에 대해서만 알고 있기 때문입니다.
인증서
I2P destination에는 인증서가 포함되어 있지만, 현재로서는 해당 인증서가 항상 null입니다. null 인증서를 사용할 경우, base64 destination은 항상 516바이트이며 “AAAA"로 끝나고, 이는 주소록 병합 메커니즘과 기타 다른 곳에서 확인됩니다. 또한 인증서를 생성하거나 destination에 추가할 수 있는 방법이 없습니다. 따라서 인증서를 구현하기 위해서는 이러한 부분들을 업데이트해야 합니다.
인증서의 한 가지 가능한 용도는 작업 증명 입니다.
다른 하나는 “서브도메인”(실제로는 그런 것이 존재하지 않기 때문에 따옴표를 사용합니다. I2P는 평면 명명 시스템을 사용합니다)이 2차 레벨 도메인의 키로 서명되는 것입니다.
모든 인증서 구현에는 인증서를 검증하는 방법이 함께 제공되어야 합니다. 아마도 이는 주소록 병합 코드에서 발생할 것으로 예상됩니다. 여러 유형의 인증서나 여러 인증서를 처리하는 방법이 있나요?
일부 중앙화된 인증 기관에서 서명한 응답을 인증하는 인증서를 추가하면 적대적인 네임서버 문제 중 많은 부분을 해결할 수 있지만, 재생 공격과 적대적인 인증 기관 공격에는 여전히 취약점이 남을 것입니다.