개요
본 제안서는 단일 Destination 을 투명하게 호스팅하는 여러 라우터를 I2P 클라이언트, 서비스 또는 외부 로드 밸런서 프로세스가 관리할 수 있도록 하는 프로토콜 설계를 제시한다.
현재 이 제안서는 구체적인 구현을 명시하지 않는다. I2CP 의 확장으로 구현되거나, 새로운 프로토콜로 구현될 수 있다.
동기
멀티홈(Multihoming)이란 동일한 Destination을 여러 라우터가 호스팅하는 것을 의미한다. 현재 I2P에서 멀티홈을 수행하는 방법은 각 라우터에서 독립적으로 동일한 Destination을 실행하는 것이다. 클라이언트가 특정 시점에 사용하는 라우터는 LeaseSet을 가장 최근에 게시한 라우터이다.
이 방법은 일종의 해킹이며, 대규모 웹사이트에서는 제대로 작동하지 않을 가능성이 높다. 예를 들어 100개의 멀티홈 라우터가 각각 16개의 터널을 가지고 있다고 가정하자. 그러면 10분마다 1600개의 LeaseSet이 게시되며, 이는 초당 거의 3건에 해당한다. 플러드필(Floodfill) 노드는 이를 감당할 수 없게 되고, 제한(throttle)이 작동하게 된다. 게다가 아직 조회(lookup) 트래픽에 대해서는 언급조차 하지 않았다.
제안서 123은 메타-LeaseSet을 사용하여 이 문제를 해결한다. 메타-LeaseSet은 100개의 실제 LeaseSet 해시를 나열한다. 조회는 두 단계로 이루어진다: 먼저 메타-LeaseSet을 조회하고, 그 다음 명시된 LeaseSet 중 하나를 조회한다. 이는 조회 트래픽 문제에 대한 좋은 해결책이지만, 단독으로는 상당한 프라이버시 누출을 초래한다. 각 실제 LeaseSet이 단일 라우터에 대응하기 때문에, 게시된 메타-LeaseSet을 모니터링함으로써 어떤 멀티홈 라우터가 온라인 상태인지 파악할 수 있다.
I2P 클라이언트 또는 서비스가 단일 Destination을 여러 라우터에 분산시키되, LeaseSet 관점에서 단일 라우터를 사용하는 것과 구별할 수 없도록 하는 방법이 필요하다.
설계
정의
사용자 (User)
자신의 Destination을 멀티홈하고자 하는 개인 또는 조직. 일반성을 잃지 않고 단일 Destination을 고려한다 (WLOG).
클라이언트 (Client)
Destination 뒤에서 실행되는 애플리케이션 또는 서비스. 클라이언트 측, 서버 측 또는 피어 투 피어 애플리케이션일 수 있으며, I2P 라우터에 연결한다는 의미에서 클라이언트라 칭한다.
클라이언트는 세 부분으로 구성되며, 모두 동일한 프로세스 내에 있을 수도 있고, 여러 프로세스 또는 머신에 분산될 수도 있다 (멀티 클라이언트 구성):
밸런서 (Balancer)
피어 선택 및 터널 생성을 관리하는 클라이언트의 구성 요소. 한 번에 하나의 밸런서만 존재하며, 모든 I2P 라우터와 통신한다. 장애 대비 밸런서가 존재할 수 있다.
프론트엔드 (Frontend)
병렬로 운영될 수 있는 클라이언트의 구성 요소. 각 프론트엔드는 단일 I2P 라우터와 통신한다.
백엔드 (Backend)
모든 프론트엔드 간에 공유되는 클라이언트의 구성 요소. 어떤 I2P 라우터와도 직접 통신하지 않는다.
라우터 (Router)
사용자가 운영하는 I2P 라우터로, I2P 네트워크와 사용자의 네트워크 사이의 경계에 위치한다 (기업 네트워크의 엣지 장치와 유사). 밸런서의 명령에 따라 터널을 생성하고, 클라이언트 또는 프론트엔드를 위해 패킷을 라우팅한다.
고수준 개요
다음과 같은 구성이 요구된다고 가정하자:
- 하나의 Destination을 가진 클라이언트 애플리케이션.
- 각각 3개의 인바운드 터널을 관리하는 4개의 라우터.
- 12개의 터널 모두가 단일 LeaseSet에 게시되어야 한다.
싱글 클라이언트
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]-----
|-{ [Tunnel 3]===/ \
| \
|-{ [Tunnel 4]===\ \
[Destination] |-{ [Tunnel 5]====[Router 2]----- \
\ |-{ [Tunnel 6]===/ \ \
[LeaseSet]--| [Client]
|-{ [Tunnel 7]===\ / /
|-{ [Tunnel 8]====[Router 3]----- /
|-{ [Tunnel 9]===/ /
| /
|-{ [Tunnel 10]==\ /
|-{ [Tunnel 11]===[Router 4]-----
-{ [Tunnel 12]==/
멀티 클라이언트
-{ [Tunnel 1]===\
|-{ [Tunnel 2]====[Router 1]---------[Frontend 1]
|-{ [Tunnel 3]===/ \ \
| \ \
|-{ [Tunnel 4]===\ \ \
[Destination] |-{ [Tunnel 5]====[Router 2]---\-----[Frontend 2] \
\ |-{ [Tunnel 6]===/ \ \ \ \
[LeaseSet]--| [Balancer] [Backend]
|-{ [Tunnel 7]===\ / / / /
|-{ [Tunnel 8]====[Router 3]---/-----[Frontend 3] /
|-{ [Tunnel 9]===/ / /
| / /
|-{ [Tunnel 10]==\ / /
|-{ [Tunnel 11]===[Router 4]---------[Frontend 4]
-{ [Tunnel 12]==/
일반 클라이언트 프로세스
Destination을 로드하거나 생성한다.
각 라우터와 세션을 열고, 이를 Destination에 연결한다.
주기적으로 (약 10분마다, 터널 생존 상태에 따라 더 자주 또는 덜 자주):
각 라우터로부터 빠른 티어(fast tier)를 가져온다.
피어의 상위 집합(superset)을 사용하여 각 라우터로/에서 터널을 생성한다.
- 기본적으로 특정 라우터로/에서의 터널은 해당 라우터의 빠른 티어에 있는 피어를 사용하지만, 프로토콜에서 이를 강제하지는 않는다.
모든 활성 라우터로부터 활성 인바운드 터널 집합을 수집하고, LeaseSet을 생성한다.
하나 이상의 라우터를 통해 LeaseSet을 게시한다.
I2CP와의 차이점
이 구성을 생성하고 관리하기 위해 클라이언트는 현재 I2CP 에서 제공하는 기능 외에 다음의 새로운 기능이 필요하다:
- LeaseSet을 생성하지 않고 라우터에 터널 생성을 지시.
- 인바운드 풀의 현재 터널 목록을 가져오기.
또한 다음 기능은 클라이언트가 터널을 관리하는 방식에서 상당한 유연성을 제공한다:
- 라우터의 빠른 티어 내용 가져오기.
- 주어진 피어 목록을 사용하여 라우터에 인바운드 또는 아웃바운드 터널 생성 지시.
프로토콜 개요
Client Router
---------------------> Create Session
Session Status <---------------------
---------------------> Get Fast Tier
Peer List <---------------------
---------------------> Create Tunnel
Tunnel Status <---------------------
---------------------> Get Tunnel Pool
Tunnel List <---------------------
---------------------> Publish LeaseSet
---------------------> Send Packet
Send Status <---------------------
Packet Received <---------------------
메시지
Create Session
- 주어진 Destination에 대한 세션을 생성한다.
Session Status
- 세션이 설정되었음을 확인하며, 클라이언트가 이제 터널 생성을 시작할 수 있음을 알린다.
Get Fast Tier
- 라우터가 현재 터널을 생성할 때 고려할 피어 목록을 요청한다.
Peer List
- 라우터가 알고 있는 피어 목록.
Create Tunnel
- 지정된 피어들을 통해 새로운 터널을 생성하도록 라우터에 요청한다.
Tunnel Status
- 특정 터널 생성의 결과를 제공하며, 생성 완료 후에 전달된다.
Get Tunnel Pool
- Destination에 대한 인바운드 또는 아웃바운드 풀의 현재 터널 목록을 요청한다.
Tunnel List
- 요청된 풀에 대한 터널 목록.
Publish LeaseSet
- 제공된 LeaseSet을 Destination의 아웃바운드 터널 중 하나를 통해 게시하도록 라우터에 요청한다. 응답 상태는 필요 없으며, 라우터는 LeaseSet이 게시되었다고 판단할 때까지 계속 재시도해야 한다.
Send Packet
- 클라이언트에서 보내는 아웃고잉 패킷. 선택적으로 패킷을 반드시(또는 가능하면) 전송해야 할 아웃바운드 터널을 지정할 수 있다.
Send Status
- 패킷 전송 성공 또는 실패 여부를 클라이언트에 알린다.
Packet Received
- 클라이언트를 위한 인고잉 패킷. 선택적으로 패킷을 수신한 인바운드 터널을 지정할 수 있다(?)
보안 영향
라우터 관점에서 이 설계는 기존 상태와 기능적으로 동일하다. 라우터는 여전히 모든 터널을 생성하고, 자체 피어 프로파일을 유지하며, 라우터와 클라이언트 작업 간의 분리를 강제한다. 기본 구성에서는 완전히 동일한데, 해당 라우터의 터널이 라우터 자신의 빠른 티어에서 생성되기 때문이다.
netDB 관점에서 이 프로토콜을 통해 생성된 단일 LeaseSet은 기존 기능을 활용하기 때문에 기존 상태와 동일하다. 그러나 16개의 Lease에 가까운 큰 LeaseSet의 경우, 관찰자가 LeaseSet이 멀티홈임을 파악할 수 있을 수 있다:
현재 빠른 티어의 최대 크기는 75개의 피어이다. 인바운드 게이트웨이(IBGW, Lease에 게시된 노드)는 티어의 일부에서 선택된다 (해시에 따라 터널 풀별로 무작위 분할, 개수 기준 아님):
1 홉 전체 빠른 티어 2 홉 빠른 티어의 절반 (2014년 중반까지 기본값) 3+ 홉 빠른 티어의 1/4 (현재 기본값은 3)즉, 평균적으로 IBGW는 20~30개 피어 집합에서 선택된다.
싱글홈 구성에서, 16개 터널의 LeaseSet은 최대 20개 피어 집합에서 무작위로 선택된 16개의 IBGW를 가진다.
기본 구성에서 4개 라우터를 사용하는 멀티홈 구성에서, 16개 터널의 LeaseSet은 최대 80개 피어 집합에서 무작위로 선택된 16개의 IBGW를 가진다. 다만 라우터 간에 일부 공통 피어가 존재할 가능성이 있다.
따라서 기본 구성에서는 통계적 분석을 통해 LeaseSet이 이 프로토콜로 생성되었음을 파악할 수 있을 수 있다. 또한 라우터의 수를 추정할 수도 있지만, 빠른 티어의 피어 변동(churn)이 이러한 분석의 정확도를 낮출 것이다.
클라이언트가 선택하는 피어를 완전히 제어할 수 있기 때문에, IBGW를 제한된 피어 집합에서 선택함으로써 이러한 정보 유출을 줄이거나 제거할 수 있다.
호환성
LeaseSet 형식에 변경이 없기 때문에 이 설계는 네트워크와 완전히 하위 호환된다. 모든 라우터는 새로운 프로토콜을 인식해야 하지만, 모두 동일한 실체에 의해 제어되기 때문에 이는 문제가 되지 않는다.
성능 및 확장성 참고 사항
이 제안서는 LeaseSet 당 최대 16개 Lease라는 상한선을 변경하지 않는다. 이보다 더 많은 터널이 필요한 Destination의 경우, 두 가지 가능한 네트워크 수정이 있다:
LeaseSet 크기의 상한을 늘린다. 구현하기 가장 간단하지만, 널리 사용되기 전에 네트워크 전반의 지원이 필요하며, 더 큰 패킷 크기로 인해 조회 속도가 느려질 수 있다. LeaseSet의 최대 실용 크기는 기본 전송 계층의 MTU에 의해 결정되며, 약 16kB 정도이다.
계층화된 LeaseSet을 위한 제안서 123을 구현한다. 이 제안서와 함께 사용하면, 서브-LeaseSet의 Destination을 여러 라우터에 분산시켜 클리어넷 서비스의 여러 IP 주소처럼 작동할 수 있다.
감사의 말
이 제안서의 논의를 가능하게 해준 psi에게 감사한다.