참고
이 제안서는 승인되었으며 API 0.9.65부터 Tunnel Creation ECIES specification에 포함되어 있습니다. 아직 구현된 것은 없으며, 구현 날짜/API 버전은 미정입니다.
개요
지난 몇 년간 새로운 프로토콜, 암호화 유형 및 혼잡 제어 개선으로 네트워크의 성능이 향상됨에 따라 비디오 스트리밍과 같은 빠른 애플리케이션이 가능해지고 있습니다. 이러한 애플리케이션은 클라이언트 터널의 각 홉에서 높은 대역폭을 필요로 합니다.
그러나 참여 라우터는 터널 빌드 메시지를 받을 때 터널이 사용할 대역폭에 대한 정보를 가지고 있지 않습니다. 참여 터널에 의해 사용되는 현재 총 대역폭과 참여 터널에 대한 총 대역폭 제한을 기반으로 터널을 수락하거나 거부할 수 있습니다.
요청 라우터 또한 각 홉에서 사용 가능한 대역폭에 대한 정보를 가지고 있지 않습니다.
또한, 라우터는 현재 터널의 인바운드 트래픽을 제한할 방법이 없습니다. 이는 과부하나 서비스의 DDoS 시기에 매우 유용할 것입니다.
이 제안서는 터널 빌드 요청 및 응답 메시지에 대역폭 매개변수를 추가하여 이러한 문제를 해결합니다.
설계
ECIES 터널 빌드 메시지 (참조: Tunnel Creation ECIES specification)의 터널 빌드 옵션 매핑 필드에 대역폭 매개변수를 추가합니다. 옵션 필드의 공간이 제한되어 있기 때문에 짧은 매개변수 이름을 사용하십시오. 터널 빌드 메시지는 고정 크기이므로 메시지의 크기는 증가하지 않습니다.
사양
ECIES 터널 빌드 메시지 사양을 다음과 같이 업데이트합니다:
긴 ECIES 빌드 레코드와 짧은 ECIES 빌드 레코드 모두에 대해:
빌드 요청 옵션
레코드의 터널 빌드 옵션 매핑 필드에 설정될 수 있는 다음의 세 가지 옵션: 요청 라우터는 하나, 전체, 또는 아무 것도 포함할 수 있습니다.
- m := 이 터널에 필요한 최소 대역폭 (KBps 양의 정수 문자열)
- r := 이 터널에 요청된 대역폭 (KBps 양의 정수 문자열)
- l := 이 터널에 대한 대역폭 제한; IBGW에만 전송 (KBps 양의 정수 문자열)
제한: m <= r <= l
참여 라우터는 “m"이 지정되어 있고 최소한 그만큼의 대역폭을 제공할 수 없는 경우 터널을 거부해야 합니다.
요청 옵션은 해당 암호화된 빌드 요청 레코드의 각 참여자에게 전송되며, 다른 참가자에게는 보이지 않습니다.
빌드 응답 옵션
응답이 ACCEPTED일 때, 레코드의 터널 빌드 응답 옵션 매핑 필드에 설정될 수 있는 다음 옵션:
- b := 이 터널에 사용 가능한 대역폭 (KBps 양의 정수 문자열)
참여 라우터는 빌드 요청에 “m” 또는 “r"이 지정된 경우 이를 포함해야 합니다. 지정된 경우 “m” 값 이상이어야 하지만, 지정된 경우 “r” 값보다 적거나 많을 수 있습니다.
참여 라우터는 터널을 위해 최소한 이만큼의 대역폭을 예약하고 제공하려고 시도해야 하지만, 이것은 보장되지 않습니다. 라우터는 10분 후의 상태를 예측할 수 없으며, 참여 트래픽은 라우터 자신의 트래픽 및 터널보다 우선순위가 낮습니다.
라우터는 필요한 경우 사용 가능한 대역폭을 과대 할당할 수도 있으며, 이는 바람직할 수 있습니다. 터널 내의 다른 홉이 이를 거부할 수 있기 때문입니다.
이러한 이유로, 참여 라우터의 응답은 최선을 다한 노력에 대한 약속으로 간주되어야 하며, 보장되지 않습니다.
응답 옵션은 요청 라우터에 해당 암호화된 빌드 응답 레코드에 전송되며, 다른 참가자에게는 보이지 않습니다.
구현 노트
대역폭 매개변수는 터널 레이어에서 참여 라우터에서 본 모습대로이며, 즉 초당 고정 크기 1 KB 터널 메시지의 수입니다. 전송(NTCP2 또는 SSU2) 오버헤드는 포함되지 않습니다.
이 대역폭은 클라이언트에서 보는 대역폭보다 훨씬 크거나 작을 수 있습니다. 터널 메시지는 래칫 및 스트리밍을 포함한 상위 레이어의 상당한 오버헤드를 포함합니다. 스트리밍 acks와 같은 간헐적인 작은 메시지는 각각 1 KB로 확장됩니다. 그러나 I2CP 레이어에서의 gzip 압축은 대역폭을 상당히 줄일 수 있습니다.
요청 라우터에서의 가장 간단한 구현은 현재 풀에서의 터널의 평균, 최소 및/또는 최대 대역폭을 사용하여 요청에 넣을 값을 계산하는 것입니다. 보다 복잡한 알고리즘도 가능하며 구현자에게 달려 있습니다.
클라이언트가 라우터에 필요한 대역폭을 알리기 위한 현재 정의된 I2CP 또는 SAM 옵션은 없으며, 이 제안서에는 새로운 옵션이 제안되지 않았습니다. 필요한 경우 나중에 옵션이 정의될 수 있습니다.
구현은 사용 가능한 대역폭 또는 기타 데이터, 알고리즘, 로컬 정책 또는 로컬 구성을 사용하여 빌드 응답에 반환되는 대역폭 값을 계산할 수 있습니다. 이 제안서에서는 지정되지 않았습니다.
이 제안서는 인바운드 게이트웨이가 “l” 옵션에 의해 요청된 경우 터널 당 조절을 구현해야 함을 요구합니다. 다른 참가 홉이 특정 알고리즘이나 구현을 구현하거나 어떤 형태로든 글로벌 조절을 구현할 필요는 없습니다. 필요하다면 말입니다.
이 제안서는 또한 클라이언트 라우터가 참여 홉에 의해 반환된 “b” 값으로 트래픽을 조절해야 한다고 요구하지 않으며, 애플리케이션에 따라서는 이것이 불가능할 수도 있습니다, 특히 인바운드 터널의 경우.
이 제안서는 오직 생성자가 만든 터널에만 영향을 미칩니다. 엔드 투 엔드 연결의 다른 쪽 끝의 소유자가 만든 “far-end” 터널을 요청하거나 대역폭을 할당하기 위한 방법은 정의되어 있지 않습니다.
보안 분석
클라이언트 지문 분석 또는 상관관계가 요청을 기반으로 가능할 수 있습니다. 클라이언트(기원) 라우터는 각 홉에 동일한 값을 보내는 대신 “m” 및 “r” 값을 랜덤화하거나, 대역폭 “버킷"을 나타내는 제한된 값을 보내거나, 또는 이 둘의 조합을 사용할 수 있습니다.
과도한 할당 DDoS: 현재 많은 수의 터널을 통과시키고 사용하여 라우터를 DDoS할 수 있는 반면, 이 제안서는 여러 큰 대역폭 요청으로 하나 이상의 터널을 요청하여 훨씬 쉽게 만들 수 있습니다.
이 위험을 완화하기 위해 구현은 다음 전략 중 하나 이상을 사용할 수 있어야 합니다:
- 사용 가능한 대역폭의 과도한 할당
- 일부 사용 가능한 대역폭의 비율에 대한 터널 당 할당 제한
- 할당된 대역폭의 증가율 제한
- 사용된 대역폭 증가율 제한
- 터널의 수명 초기에 사용되지 않은 경우 할당된 대역폭 제한 (사용하지 않으면 잃음)
- 터널 당 평균 대역폭 추적
- 요청된 대역폭과 터널 당 실제 사용된 대역폭의 추적
호환성
문제 없음. 현재 모든 구현은 빌드 메시지의 매핑 필드를 무시하며, 비어 있지 않은 옵션 필드를 올바르게 건너뜁니다.
마이그레이션
구현은 언제든지 지원을 추가할 수 있으며, 조정이 필요하지 않습니다.
현재 이 제안서 지원이 요구되는 API 버전은 정의되어 있지 않으므로, 라우터는 지원 확인을 위해 “b” 응답을 확인해야 합니다.