사용 중단됨 - SSU는 SSU2로 교체되었습니다. SSU 지원은 i2pd 릴리스 2.44.0 (API 0.9.56) 2022-11에서 제거되었습니다. SSU 지원은 Java I2P 릴리스 2.4.0 (API 0.9.61) 2023-12에서 제거되었습니다.
SSU(I2P 문서와 사용자 인터페이스에서 “UDP"라고도 불림)는 I2P에서 구현된 두 가지 전송 프로토콜 중 하나였습니다. 다른 하나는 NTCP2 입니다. NTCP 지원은 제거되었습니다.
SSU는 I2P 릴리스 0.6에서 도입되었습니다. 표준 I2P 설치에서 router는 아웃바운드 연결을 위해 NTCP와 SSU를 모두 사용합니다. SSU-over-IPv6는 버전 0.9.8부터 지원됩니다.
SSU는 “반신뢰성"이라고 불리는데, 확인되지 않은 메시지를 반복적으로 재전송하지만 최대 횟수까지만 시도하기 때문입니다. 그 이후에는 메시지가 폐기됩니다.
SSU 서비스
NTCP transport와 마찬가지로, SSU는 안정적이고 암호화된 연결 지향적인 지점 간 데이터 전송을 제공합니다. SSU만의 고유한 기능으로, 다음을 포함한 IP 감지 및 NAT 통과 서비스도 제공합니다:
- introducers 를 사용한 협력적 NAT/방화벽 우회
- 수신 패킷 검사 및 peer testing 을 통한 로컬 IP 탐지
- 방화벽 상태와 로컬 IP, 그리고 이들의 변경 사항을 NTCP에 전달
- 방화벽 상태와 로컬 IP, 그리고 이들의 변경 사항을 router와 사용자 인터페이스에 전달
Router 주소 명세
다음 속성들이 네트워크 데이터베이스에 저장됩니다.
- Transport name: SSU
- caps: [B,C,4,6] 아래 참조 .
- host: IP (IPv4 또는 IPv6). 단축된 IPv6 주소 (”::” 포함)가 허용됩니다. 방화벽이 설정된 경우 존재할 수도 있고 없을 수도 있습니다. 호스트명은 이전에 허용되었지만 릴리스 0.9.32부터 더 이상 권장되지 않습니다. proposal 141 참조.
- iexp[0-2]: 이 introducer의 만료 시간. ASCII 숫자, epoch 이후 초 단위. 방화벽이 설정되고 introducer가 필요한 경우에만 존재합니다. 선택사항 (이 introducer의 다른 속성이 존재하더라도). 릴리스 0.9.30부터, proposal 133.
- ihost[0-2]: Introducer의 IP (IPv4 또는 IPv6). 호스트명은 이전에 허용되었지만 릴리스 0.9.32부터 더 이상 권장되지 않습니다. proposal 141 참조. 단축된 IPv6 주소 ("::" 포함)가 허용됩니다. 방화벽이 설정되고 introducer가 필요한 경우에만 존재합니다. 아래 참조 .
- ikey[0-2]: Introducer의 Base 64 introduction key. 아래 참조 . 방화벽이 설정되고 introducer가 필요한 경우에만 존재합니다. 아래 참조 .
- iport[0-2]: Introducer의 포트 1024 - 65535. 방화벽이 설정되고 introducer가 필요한 경우에만 존재합니다. 아래 참조 .
- itag[0-2]: Introducer의 태그 1 - (2^32 - 1) ASCII 숫자. 방화벽이 설정되고 introducer가 필요한 경우에만 존재합니다. 아래 참조 .
- key: Base 64 introduction key. 아래 참조 .
- mtu: 선택사항. 기본값 및 최대값은 1484. 최소값은 620. IPv6의 경우 반드시 존재해야 하며, 최소값은 1280, 최대값은 1488 (버전 0.9.28 이전에는 최대값이 1472였음). IPv6 MTU는 16의 배수여야 합니다. (IPv4 MTU + 4)는 16의 배수여야 합니다. 아래 참조 .
- port: 1024 - 65535 방화벽이 설정된 경우 존재할 수도 있고 없을 수도 있습니다.
프로토콜 세부사항
혼잡 제어
SSU의 준신뢰적 전송, TCP 친화적 동작, 그리고 높은 처리량 용량에 대한 요구사항은 혼잡 제어에서 상당한 유연성을 허용합니다. 아래에 설명된 혼잡 제어 알고리즘은 대역폭 효율성과 구현 단순성을 모두 고려하여 설계되었습니다.
패킷은 router의 정책에 따라 스케줄링되며, router의 아웃바운드 용량을 초과하지 않거나 원격 피어의 측정된 용량을 초과하지 않도록 주의합니다. 측정된 용량은 TCP의 slow start 및 혼잡 회피와 유사하게 작동하며, 전송 용량에 대한 가산적 증가와 혼잡 상황에서의 승법적 감소를 사용합니다. TCP와 달리, router는 다른 메시지들을 계속 전송하면서 주어진 기간이나 재전송 횟수 이후에는 일부 메시지들을 포기할 수 있습니다.
혼잡 감지 기법도 TCP와는 다릅니다. 각 메시지가 고유하고 비순차적인 식별자를 가지며, 각 메시지의 크기가 제한되어 있기 때문입니다(최대 32KB). 이 피드백을 송신자에게 효율적으로 전송하기 위해, 수신자는 주기적으로 완전히 ACK된 메시지 식별자 목록을 포함시키고, 부분적으로 수신된 메시지에 대한 비트필드도 포함시킬 수 있습니다. 여기서 각 비트는 프래그먼트의 수신을 나타냅니다. 중복된 프래그먼트가 도착하면 메시지를 다시 ACK해야 하고, 메시지가 여전히 완전히 수신되지 않았다면 새로운 업데이트와 함께 비트필드를 재전송해야 합니다.
현재 구현에서는 패킷을 특정 크기로 패딩하지 않고, 대신 단일 메시지 조각을 패킷에 넣고 전송합니다 (MTU를 초과하지 않도록 주의).
MTU
router 버전 0.8.12부터 IPv4에 대해 두 개의 MTU 값이 사용됩니다: 620과 1484. MTU 값은 재전송되는 패킷의 비율에 따라 조정됩니다.
두 MTU 값 모두에서 (MTU % 16) == 12가 되는 것이 바람직합니다. 이는 28바이트 IP/UDP 헤더 이후의 페이로드 부분이 암호화 목적으로 16바이트의 배수가 되도록 하기 위함입니다.
작은 MTU 값의 경우, 2646바이트 Variable Tunnel Build Message를 여러 패킷으로 효율적으로 패킹하는 것이 바람직합니다. 620바이트 MTU를 사용하면 5개 패킷에 깔끔하게 맞출 수 있습니다.
측정 결과에 따르면, 1492는 거의 모든 합리적으로 작은 I2NP 메시지에 적합합니다 (더 큰 I2NP 메시지는 1900에서 4500바이트까지 될 수 있으며, 이는 어차피 실제 네트워크 MTU에 맞지 않습니다).
MTU 값은 릴리스 0.8.9 - 0.8.11에서 608과 1492였습니다. 큰 MTU는 릴리스 0.8.9 이전에 1350이었습니다.
최대 수신 패킷 크기는 릴리즈 0.8.12부터 1571바이트입니다. 릴리즈 0.8.9 - 0.8.11에서는 1535바이트였습니다. 릴리즈 0.8.9 이전에는 2048바이트였습니다.
릴리스 0.9.2부터, router의 네트워크 인터페이스 MTU가 1484보다 작은 경우, 이를 netDb에 게시하며, 연결이 설정될 때 다른 router들이 이를 준수해야 합니다.
IPv6의 경우 최소 MTU는 1280입니다. IPv6 IP/UDP 헤더는 48바이트이므로 (MTU % 16 == 0)인 MTU를 사용하며, 이는 1280에서 참입니다. 최대 IPv6 MTU는 1488입니다. (버전 0.9.28 이전에는 최대값이 1472였습니다).
메시지 크기 제한
최대 메시지 크기가 명목상 32KB이지만, 실제 제한은 다릅니다. 프로토콜은 fragment 수를 7비트 또는 128개로 제한합니다. 그러나 현재 구현에서는 각 메시지를 최대 64개의 fragment로 제한하며, 이는 608 MTU를 사용할 때 64 * 534 = 33.3KB에 충분합니다. 번들된 leaseSet과 세션 키의 오버헤드로 인해 애플리케이션 수준에서의 실제 제한은 약 6KB 낮은 약 26KB입니다. UDP 전송 제한을 32KB 이상으로 높이기 위해서는 추가적인 작업이 필요합니다. 더 큰 MTU를 사용하는 연결의 경우 더 큰 메시지가 가능합니다.
유휴 시간 초과
유휴 타임아웃과 연결 종료는 각 엔드포인트의 재량에 따라 결정되며 달라질 수 있습니다. 현재 구현에서는 연결 수가 설정된 최대값에 접근할수록 타임아웃을 낮추고, 연결 수가 적을 때는 타임아웃을 높입니다. 권장되는 최소 타임아웃은 2분 이상이며, 권장되는 최대 타임아웃은 10분 이상입니다.
키
사용되는 모든 암호화는 32바이트 키와 16바이트 IV를 사용하는 AES256/CBC입니다. Alice가 Bob과 세션을 시작할 때, MAC과 세션 키는 DH 교환의 일부로 협상되며, 이후 각각 HMAC과 암호화에 사용됩니다. DH 교환 중에는 Bob의 공개적으로 알려진 introKey가 MAC과 암호화에 사용됩니다.
초기 메시지와 후속 응답 모두 응답자(Bob)의 introKey를 사용합니다 - 응답자는 요청자(Alice)의 introKey를 알 필요가 없습니다. Bob이 사용하는 DSA 서명 키는 Alice가 그에게 연락할 때 이미 Alice에게 알려져 있어야 하지만, Alice의 DSA 키는 Bob에게 아직 알려져 있지 않을 수 있습니다.
메시지를 받으면, 수신자는 “from” IP 주소와 포트를 모든 설정된 세션과 확인합니다. 일치하는 것이 있으면 해당 세션의 MAC 키가 HMAC에서 테스트됩니다. 이 중 어느 것도 검증되지 않거나 일치하는 IP 주소가 없으면, 수신자는 MAC에서 자신의 introKey를 시도합니다. 그것이 검증되지 않으면 패킷은 폐기됩니다. 검증되면 메시지 유형에 따라 해석되지만, 수신자가 과부하 상태인 경우 어쨌든 폐기될 수 있습니다.
Alice와 Bob이 설정된 세션을 가지고 있지만, Alice가 어떤 이유로 키를 잃어버리고 Bob에게 연락하고 싶다면, 언제든지 SessionRequest와 관련 메시지를 통해 새로운 세션을 설정할 수 있습니다. Bob이 키를 잃어버렸지만 Alice가 이를 모르는 경우, Alice는 먼저 wantReply 플래그가 설정된 DataMessage를 보내어 Bob이 응답하도록 자극을 시도하고, Bob이 계속해서 응답하지 않으면 키가 손실되었다고 가정하고 새로운 키를 재설정합니다.
DH 키 합의를 위해 RFC3526 2048비트 MODP 그룹 (#14)이 사용됩니다:
p = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
g = 2
이들은 I2P의 ElGamal 암호화 에 사용되는 동일한 p와 g입니다.
재생 공격 방지
SSU 계층에서의 재생 공격 방지는 지나치게 오래된 타임스탬프를 가진 패킷이나 IV를 재사용하는 패킷을 거부함으로써 이루어집니다. 중복된 IV를 감지하기 위해 일련의 Bloom 필터가 주기적으로 “소멸"되도록 사용되어 최근에 추가된 IV만 감지됩니다.
DataMessage에서 사용되는 messageId는 SSU transport보다 상위 계층에서 정의되며 투명하게 전달됩니다. 이러한 ID들은 특정한 순서를 갖지 않으며, 실제로는 완전히 무작위일 가능성이 높습니다. SSU 계층은 messageId 재전송 공격 방지를 시도하지 않으므로, 상위 계층에서 이를 고려해야 합니다.
주소 지정
SSU 피어에 연결하려면 두 가지 정보 세트 중 하나가 필요합니다: 피어가 공개적으로 접근 가능한 경우 직접 주소, 또는 제3자를 통해 피어를 소개받기 위한 간접 주소입니다. 피어가 가질 수 있는 주소의 수에는 제한이 없습니다.
Direct: host, port, introKey, options
Indirect: tag, relayhost, port, relayIntroKey, targetIntroKey, options
각 주소는 또한 해당 특정 피어의 특별한 기능인 일련의 옵션을 노출할 수도 있습니다. 사용 가능한 기능 목록은 아래 를 참조하세요.
주소, 옵션 및 기능은 network database 에 게시됩니다.
직접 세션 설정
직접 세션 설정은 NAT 통과에 제3자가 필요하지 않을 때 사용됩니다. 메시지 순서는 다음과 같습니다:
연결 설정 (직접)
Alice가 Bob에게 직접 연결됩니다. IPv6는 버전 0.9.8부터 지원됩니다.
Alice Bob
SessionRequest --------------------->
<--------------------- SessionCreated
SessionConfirmed ------------------->
<--------------------- DeliveryStatusMessage
<--------------------- DatabaseStoreMessage
DatabaseStoreMessage --------------->
Data <--------------------------> Data
SessionConfirmed 메시지를 받은 후, Bob은 확인으로 작은 DeliveryStatus message 를 보냅니다. 이 메시지에서 4바이트 메시지 ID는 임의의 숫자로 설정되고, 8바이트 “도착 시간"은 현재 네트워크 전체 ID인 2(즉, 0x0000000000000002)로 설정됩니다.
상태 메시지가 전송된 후, 피어들은 보통 자신들의 RouterInfo 를 포함하는 DatabaseStore 메시지 를 교환하지만, 이는 필수 사항은 아닙니다.
상태 메시지의 유형이나 내용이 중요하지 않은 것으로 보입니다. 이는 원래 DatabaseStore 메시지가 몇 초 지연되었기 때문에 추가되었습니다. 이제 store가 즉시 전송되므로 상태 메시지는 제거될 수 있을 것입니다.
소개
Introduction key는 외부 채널(네트워크 데이터베이스)을 통해 전달되며, 릴리스 0.9.47까지는 전통적으로 router Hash와 동일했지만, 릴리스 0.9.48부터는 임의의 값일 수 있습니다. 이 키들은 세션 키를 설정할 때 반드시 사용되어야 합니다. 간접 주소의 경우, 피어는 먼저 relayhost에 연락하여 해당 relayhost에서 주어진 태그로 알려진 피어에 대한 소개를 요청해야 합니다. 가능하다면, relayhost는 주소가 지정된 피어에게 요청하는 피어에게 연락하라는 메시지를 보내고, 동시에 요청하는 피어에게 주소가 지정된 피어가 위치한 IP와 포트를 제공합니다. 또한 연결을 설정하는 피어는 연결하려는 피어의 공개 키를 이미 알고 있어야 합니다(하지만 중간 relay 피어의 공개 키는 반드시 알 필요가 없습니다).
제3자 소개를 통한 간접 세션 설정은 효율적인 NAT 통과를 위해 필요합니다. NAT 또는 방화벽 뒤에 있어 요청되지 않은 인바운드 UDP 패킷을 허용하지 않는 router Charlie는 먼저 몇 개의 피어에 연결하여 일부를 소개자 역할로 선택합니다. 이러한 각 피어들(Bob, Bill, Betty 등)은 Charlie에게 소개 태그(4바이트 임의 숫자)를 제공하며, Charlie는 이를 자신에게 연락하는 방법으로 공개합니다. Charlie의 공개된 연락 방법을 가진 router Alice는 먼저 하나 이상의 소개자에게 RelayRequest 패킷을 보내어 각각에게 자신을 Charlie에게 소개해달라고 요청합니다(Charlie를 식별하기 위해 소개 태그를 제공). 그러면 Bob은 Alice의 공개 IP와 포트 번호를 포함한 RelayIntro 패킷을 Charlie에게 전달한 후, Charlie의 공개 IP와 포트 번호를 포함한 RelayResponse 패킷을 Alice에게 보냅니다. Charlie가 RelayIntro 패킷을 받으면 Alice의 IP와 포트로 작은 임의 패킷을 전송하고(NAT/방화벽에 구멍을 뚫음), Alice가 Bob의 RelayResponse 패킷을 받으면 지정된 IP와 포트로 새로운 전체 방향 세션 설정을 시작합니다.
연결 설정 (소개자를 통한 간접 연결)
Alice는 먼저 introducer Bob에 연결하고, Bob이 요청을 Charlie에게 중계합니다.
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch (data ignored)
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
<-------------------------------------------- DeliveryStatusMessage
<-------------------------------------------- DatabaseStoreMessage
DatabaseStoreMessage -------------------------------------->
Data <--------------------------------------------------> Data
hole punch 후에는 직접 연결 설정에서와 같이 Alice와 Charlie 사이에 세션이 설정됩니다.
IPv6 참고사항
IPv6는 버전 0.9.8부터 지원됩니다. 게시된 relay 주소는 IPv4 또는 IPv6일 수 있으며, Alice-Bob 통신은 IPv4 또는 IPv6를 통해 이루어질 수 있습니다. 릴리스 0.9.49까지는 Bob-Charlie 및 Alice-Charlie 통신이 IPv4를 통해서만 가능합니다. IPv6에 대한 릴레이는 릴리스 0.9.50부터 지원됩니다. 자세한 내용은 사양을 참조하세요.
사양은 버전 0.9.8부터 변경되었지만, IPv6를 통한 Alice-Bob 통신은 실제로 버전 0.9.50까지 지원되지 않았습니다. 이전 버전의 Java router들은 실제로는 IPv6를 통해 introducer 역할을 하지 않았음에도 불구하고, IPv6 주소에 대해 ‘C’ capability를 잘못 발행했습니다. 따라서 router들은 router 버전이 0.9.50 이상인 경우에만 IPv6 주소의 ‘C’ capability를 신뢰해야 합니다.
피어 테스팅
피어들을 위한 협력적 도달가능성 테스팅의 자동화는 일련의 PeerTest 메시지에 의해 활성화됩니다. 적절한 실행을 통해 피어는 자신의 도달가능성을 확인할 수 있으며 그에 따라 동작을 업데이트할 수 있습니다. 테스팅 과정은 매우 간단합니다:
Alice Bob Charlie
PeerTest ------------------->
PeerTest-------------------->
<-------------------PeerTest
<-------------------PeerTest
<------------------------------------------PeerTest
PeerTest------------------------------------------>
<------------------------------------------PeerTest
각 PeerTest 메시지는 Alice가 초기화한 테스트 시리즈 자체를 식별하는 nonce를 전달합니다. Alice가 예상하는 특정 메시지를 받지 못하면 그에 따라 재전송하며, 수신된 데이터나 누락된 메시지를 기반으로 자신의 연결 가능성을 알 수 있습니다. 도달할 수 있는 다양한 최종 상태는 다음과 같습니다:
만약 Bob으로부터 응답을 받지 못한다면, 특정 횟수까지 재전송을 시도하지만, 응답이 전혀 도착하지 않으면 자신의 방화벽이나 NAT가 잘못 구성되어 아웃바운드 패킷에 대한 직접적인 응답조차도 모든 인바운드 UDP 패킷을 거부하고 있음을 알게 됩니다. 또는 Bob이 다운되었거나 Charlie로부터 응답을 받을 수 없는 상태일 수도 있습니다.
Alice가 제3자(Charlie)로부터 예상되는 nonce가 포함된 PeerTest 메시지를 받지 못하면, 이미 Bob의 응답을 받았더라도 Bob에게 보낸 초기 요청을 일정 횟수까지 재전송합니다. Charlie의 첫 번째 메시지가 여전히 도달하지 않지만 Bob의 메시지는 도달한다면, Alice는 자신이 원치 않는 연결 시도를 거부하는 NAT 또는 방화벽 뒤에 있으며 포트 포워딩이 제대로 작동하지 않는다는 것을 알 수 있습니다(Bob이 제공한 IP와 포트가 포워딩되어야 합니다).
Alice가 Bob의 PeerTest 메시지와 Charlie의 두 PeerTest 메시지를 모두 받았지만 Bob과 Charlie의 두 번째 메시지에 포함된 IP와 포트 번호가 일치하지 않으면, 그녀는 자신이 대칭 NAT 뒤에 있다는 것을 알 수 있습니다. 이는 접촉하는 각 피어마다 서로 다른 ‘발신’ 포트로 모든 아웃바운드 패킷을 재작성하는 NAT입니다. 그녀는 포트를 명시적으로 포워딩하고 원격 연결을 위해 해당 포트를 항상 노출된 상태로 유지해야 하며, 추가적인 포트 발견은 무시해야 합니다.
Alice가 Charlie의 첫 번째 메시지는 받았지만 두 번째 메시지를 받지 못한 경우, 그녀는 일정 횟수까지 Charlie에게 PeerTest 메시지를 재전송할 것이지만, 응답을 받지 못하면 Charlie가 혼란스러워하거나 더 이상 온라인 상태가 아니라는 것을 알게 됩니다.
Alice는 peer 테스트에 참여할 수 있을 것으로 보이는 알려진 peer들 중에서 Bob을 임의로 선택해야 합니다. Bob은 차례로 자신이 알고 있는 peer들 중에서 peer 테스트에 참여할 수 있을 것으로 보이고 Bob과 Alice 모두와 다른 IP에 있는 Charlie를 임의로 선택해야 합니다. 첫 번째 오류 조건이 발생하면 (Alice가 Bob으로부터 PeerTest 메시지를 받지 못함), Alice는 새로운 peer를 Bob으로 지정하고 다른 nonce로 다시 시도할 수 있습니다.
Alice의 소개 키는 모든 PeerTest 메시지에 포함되어 있어서 Charlie가 추가 정보를 알지 못해도 Alice에게 연락할 수 있습니다. 릴리스 0.9.15부터 Alice는 스푸핑 공격을 방지하기 위해 Bob과 설정된 세션을 가지고 있어야 합니다. 피어 테스트가 유효하려면 Alice는 Charlie와 설정된 세션을 가지지 않아야 합니다. Alice는 계속해서 Charlie와 세션을 설정할 수 있지만 필수는 아닙니다.
IPv6 참고사항
릴리스 0.9.26까지는 IPv4 주소 테스트만 지원됩니다. IPv4 주소 테스트만 지원됩니다. 따라서 모든 Alice-Bob 및 Alice-Charlie 통신은 IPv4를 통해 이루어져야 합니다. 하지만 Bob-Charlie 통신은 IPv4 또는 IPv6를 통해 이루어질 수 있습니다. PeerTest 메시지에서 지정되는 Alice의 주소는 4바이트여야 합니다. 릴리스 0.9.27부터는 IPv6 주소 테스트가 지원되며, Bob과 Charlie가 게시된 IPv6 주소에서 ‘B’ 기능으로 지원을 나타내는 경우 Alice-Bob 및 Alice-Charlie 통신이 IPv6를 통해 이루어질 수 있습니다. 자세한 내용은 Proposal 126 을 참조하세요.
릴리스 0.9.50 이전에는, Alice가 테스트하고자 하는 전송 계층(IPv4 또는 IPv6)을 통한 기존 세션을 사용하여 Bob에게 요청을 보냅니다. Bob이 IPv4를 통해 Alice로부터 요청을 받으면, Bob은 IPv4 주소를 광고하는 Charlie를 선택해야 합니다. Bob이 IPv6을 통해 Alice로부터 요청을 받으면, Bob은 IPv6 주소를 광고하는 Charlie를 선택해야 합니다. 실제 Bob-Charlie 통신은 IPv4 또는 IPv6을 통해 이루어질 수 있습니다(즉, Alice의 주소 유형과는 무관함).
릴리스 0.9.50부터, IPv4 peer test를 위해 메시지가 IPv6를 통해 전송되거나, (릴리스 0.9.50부터) IPv6 peer test를 위해 IPv4를 통해 전송되는 경우, Alice는 자신의 소개 주소와 포트를 포함해야 합니다.
자세한 내용은 Proposal 158 을 참조하세요.
전송 윈도우, ACK 및 재전송
DATA 메시지는 전체 메시지의 ACK와 메시지의 개별 조각에 대한 부분 ACK를 포함할 수 있습니다. 자세한 내용은 프로토콜 사양 페이지 의 데이터 메시지 섹션을 참조하세요.
윈도잉, ACK, 그리고 재전송 전략의 세부사항은 여기에 명시되지 않았습니다. 현재 구현에 대해서는 Java 코드를 참조하십시오. 설정 단계에서, 그리고 피어 테스트를 위해 router들은 재전송에 대해 지수적 백오프를 구현해야 합니다. 설정된 연결의 경우, router들은 TCP 또는 streaming 과 유사한 조정 가능한 전송 윈도우, RTT 추정 및 타임아웃을 구현해야 합니다. 초기, 최소 및 최대 매개변수에 대해서는 코드를 참조하십시오.
보안
UDP 소스 주소는 물론 위조될 수 있습니다. 또한 특정 SSU 메시지(RelayRequest, RelayResponse, RelayIntro, PeerTest) 내에 포함된 IP와 포트는 정당하지 않을 수 있습니다. 또한 특정 작업과 응답에는 속도 제한이 필요할 수 있습니다.
검증의 세부사항은 여기서 명시되지 않습니다. 구현자는 적절한 곳에 방어 기능을 추가해야 합니다.
피어 기능
하나 이상의 기능이 “caps” 옵션에 게시될 수 있습니다. 기능들은 어떤 순서로도 배치될 수 있지만, 구현 간 일관성을 위해 “BC46” 순서가 권장됩니다.
B : 피어 주소에 ‘B’ 기능이 포함되어 있다면, 해당 피어가 피어 테스트에서 ‘Bob’ 또는 ‘Charlie’ 역할로 참여할 의지가 있고 참여할 수 있다는 의미입니다. 0.9.26까지는 IPv6 주소에 대해 피어 테스팅이 지원되지 않았으며, IPv6 주소에 ‘B’ 기능이 있더라도 무시되어야 했습니다. 0.9.27부터는 IPv6 주소에 대해 피어 테스팅이 지원되며, IPv6 주소에서 ‘B’ 기능의 존재 여부는 실제 지원 여부(또는 지원하지 않음)를 나타냅니다.
C : 피어 주소에 ‘C’ capability가 포함되어 있다면, 해당 주소를 통해 introducer 역할을 수행할 의향과 능력이 있다는 의미입니다 - 도달할 수 없는 Charlie를 위해 introducer Bob 역할을 합니다. 0.9.50 릴리스 이전에는 Java router들이 IPv6 introducer가 완전히 구현되지 않았음에도 불구하고 IPv6 주소에 대해 ‘C’ capability를 잘못 게시했습니다. 따라서 router들은 ‘C’ capability가 광고되더라도 0.9.50 이전 버전은 IPv6에서 introducer 역할을 할 수 없다고 가정해야 합니다.
4 : 0.9.50부터 아웃바운드 IPv4 기능을 나타냅니다. IP가 host 필드에 게시된 경우 이 기능은 필요하지 않습니다. IPv4 소개를 위한 introducer가 있는 주소인 경우 ‘4’가 포함되어야 합니다. router가 숨겨진 경우 ‘4’와 ‘6’이 단일 주소에서 결합될 수 있습니다.
6 : 0.9.50부터 아웃바운드 IPv6 기능을 나타냅니다. IP가 host 필드에 게시된 경우 이 기능은 필요하지 않습니다. IPv6 소개를 위한 introducer가 있는 주소인 경우 ‘6’이 포함되어야 합니다(현재 지원되지 않음). router가 숨겨진 경우 ‘4’와 ‘6’이 단일 주소에서 결합될 수 있습니다.
향후 작업
참고: 이러한 문제들은 SSU2 개발 과정에서 해결될 예정입니다.
윈도우 크기 조정 및 기타 매개변수 평가를 포함한 현재 SSU 성능 분석과 성능 향상을 위한 프로토콜 구현 조정은 향후 작업 주제입니다.
현재 구현은 동일한 패킷에 대해 반복적으로 확인 응답을 보내므로 불필요하게 오버헤드를 증가시킵니다.
620의 기본 작은 MTU 값을 분석하고 가능하면 증가시켜야 합니다. 현재 MTU 조정 전략을 평가해야 합니다. 스트리밍 라이브러리 1730바이트 패킷이 3개의 작은 SSU 패킷에 맞을까요? 아마 안 될 것입니다.
프로토콜은 설정 중에 MTU를 교환하도록 확장되어야 합니다.
Rekeying은 현재 구현되지 않았으며 향후에도 구현되지 않을 예정입니다.
RelayIntro와 RelayResponse의 ‘challenge’ 필드의 잠재적 사용과 SessionRequest 및 SessionCreated의 패딩 필드 사용은 문서화되지 않았습니다.
고정된 패킷 크기 세트는 외부 공격자로부터 데이터 단편화를 더욱 숨기는 데 적절할 수 있지만, 그때까지는 대부분의 필요에 대해 tunnel, garlic, 그리고 종단 간 패딩이 충분해야 합니다.
SessionCreated와 SessionConfirmed의 서명 시간은 사용되지 않거나 검증되지 않는 것으로 보입니다.