이렇게 하는 게 다음과 같은 이유로 쉽기 때문이에요:
먼저 이렇게 해야 Tor가 VoIP와 같은 신규 프로토콜을 다루기 더 쉬워집니다.
애플리케이션에 SKCOS를 적용하는 데 필요한 사항이 모두 해결돼요.
출구 접속(exit connection)을 대상으로 출구 중계기에 그렇게 많은 파일 기술자(descriptor)를 할당할 필요가 없어요.
이러한 방향으로 진행하려 해요만, 몇몇 문제가 있어요:
IP 패킷에 운영체제 속성이 드러난다는 거예요.
TCP 핑거프린팅 공격 등을 막으려면, IP 수준의 패킷 정규화가 현 단계에서 여전히 필요해요.
TCP 스택이 지닌 분산성과 복잡성, 그리고 기기 핑거프린팅 공격을 고려했을 때, 사용자 영역(user space)에 Tor만의 TCP 스택을 따로 제공하는 게 가장 나아보여요.
애플리케이션 단 스트림의 정화가 여전히 필요해요.
Tor 프로젝트는 Torbutton과 같은 사용자 측에서의 애플리케이션이 계속 필요해요.
그래서 패킷을 포착하고 IP 계층에서 패킷을 익명화하는 수준의 문제에 머무르진 않을 겁니다.
특정한 프로토콜에서 여전히 정보가 새고 있어요.
Tor 프로젝트는 사용자의 ISP 내의 DNS 서버가 아닌 접속되지 않을 법한 DNS 서버로 전송될 수 있도록 DNS 요청을 다시 작성해요. 따라서 전송되는 프로토콜을 반드시 파악해야 해요.
DTLS (datagram TLS)엔 기본적으로 사용자가 없으며, IPsec은 확실히 큽니다.
Tor 프로젝트에서 전송 메커니즘(transport mechanism)을 선정하면, 그 후엔 tagging 공격과 다른 잠재적 익명성 및 현재 중단, 재전송 등과 같이 일어나고 있는 무결성 이슈에 대응할 수 있는 새로운 종단간 Tor 프로토콜을 설계하는 거예요.
임의의 IP 패킷에 대한 '출구 정책'은 곧 보안 상 안전한 침입 탐지 시스템(Intrusion Detection System, IDS)를 세우는 겁니다.
Tor 노드 운영자 분들의 말씀에 따르면, Tor를 운영하고 싶지 않은 이유 중 하나가 '출구 정책'(exit policies)라고 해요.
IDS를 추가해 출구 정책을 관리한다면 Tor의 보인이 지닌 복잡도를 제고하고, Tor가 작동 불능에 빠질 가능성이 낮아집니다. IDS와 카운터 IDS 관련 논문에서 이 효능이 검증됐어요.
Tor가 (변조된 패킷이나 IP 플러드와 같은 임의의 IP와 달리) 적합한(valid) TCP 스트림(TCP stream)만 전송한다는 사실만 봐도 Tor가 잠재적 남용 문제의 산실이란 의심이 해명돼요.
'출구 정책'은 IP 패킷을 전송할 수 있게 됨에 따라 훨씬 더 중요한 요소로 자리잡았어요.
Tor 디렉터리 내 출구 정책을 요지만 간추려 설명할 필요가 있어요. 그래야 어떤 노드에서 패킷이 나가는 걸 허용할지 클라이언트가 예측할 수 있으니까요.
더욱이 클라이언트는 출구 노드를 선정하기 전에 세션에 보내고자 하는 패킷 모두를 예측해야 해요!
Tor 내부 명 공간(Tor-internal name space)을 재설계 해야 해요.
Tor는 onion 서비스가 Tor 클라이언트로 전송되는 과정에서 이를 가로채는 방식으로 onion 서비스의 '.onion' 주소를 지원하고 있어요.
IP 단에서 행하는 이와 같은 방식은 Tor와 현지 DNS 리졸버 사이의 복잡한 인터페이스가 요구돼요.