요약

  • MPTCP에서MP_JOINSYN은 기존 MPTCP 상태를 찾기 위해 수신측 토큰을 전달하지만, 새로운 TCP 서브플로가 그 연결에 합류할 수 있는지는 이후의 HMAC 교환과 수신측 자체의 정책이 결정합니다.
  • 토큰 일치, 유효한 HMAC, TCP 핸드셰이크, 애플리케이션 결과는 서로 다른 기록입니다. 그 어느 것도 다른 것들을 정직하게 대신할 수 없습니다.

두 번째 SYN은 의도적으로 절제되어 있습니다. 새로운 애플리케이션 세션을 선포하지도 않고, 네트워크에 신비로운 종단 간 경로를 발견해 달라고 요청하지도 않습니다. 한 주소 쌍 사이에 새로운 평범한 TCP 서브플로를 제안하고, 그 서브플로가 기존 MPTCP 연결의 한 가닥이 되어 달라고 요청할 뿐입니다. 이 제안은 서로 다른 네 가지 질문에 답해야 합니다: 어느 오래된 연결을 말하는가; 제안자가 처음 피어와 연속성을 갖는가; 이 호스트가 또 하나의 가닥을 받아들이기를 원하는가; 그리고 새로 수립된 TCP 플로 위의 패킷을 이후 어떻게 디멀티플렉싱할 것인가.

RFC 6182, 즉 2011년의 아키텍처 문서는 회선 포맷이 등장하기 전에 이 구분을 이해 가능하게 만들었습니다. 애플리케이션은 TCP의 신뢰성 있고 순서가 보장된 바이트 스트림을 계속 보게 됩니다. 반면 네트워크는 평범해 보이는 TCP 서브플로를 보게 됩니다. 여러 주소는 경로 다양성을 추구하는 실용적인 방법이었지, 그 경로들이 물리적으로 분리되어 있다는 보장이 아니었습니다. 야망만큼 호환성이 중요했습니다: MPTCP는 평범한 TCP, 미들박스, 공유 병목 지점의 단일 경로 트래픽과 공존해야 했습니다.

이 구도가 중요한 이유는 혁신을 책임을 물을 수 있는 접합부에 놓기 때문입니다. MPTCP는 TCP 상태를 폐지하지 않았습니다. 여러 TCP 기록 위에 연결 수준의 기록을 하나 추가했고, 그러자 편리한 레이블을 아는 패킷 누구나 그 오래된 기록에 합류할 수 있게 허용하지 않으면서 새로운 5-튜플을 그 기록에 붙이는 방법을 설명해야 했습니다.

첫 핸드셰이크가 이력을 만든다

이 이력은 하나의 정상적인 TCP 경로에서 시작됩니다.RFC 8684에서 첫 서브플로는 SYN, SYN/ACK, ACK에MP_CAPABLE을 전달합니다. 이 협상은 두 종단이 이 연결에서 명시된 MPTCP 버전을 사용할 수 있다고 말하고, 이후 서브플로 인증의 근원이 되는 키 재료를 교환합니다. 필요한 옵션이 없다면—피어가 MPTCP를 지원하지 않거나 미들박스가 옵션을 제거했기 때문일 수 있습니다—명시된 결과는 절반만 인식된 멀티패스 연결이 아니라 정상적인 단일 경로 TCP입니다.

이 폴백 규칙은 각주가 아닙니다. 한 시도에서 관측된 TCP 옵션이 모든 경로가 그것을 보존할 것이라는 증거는 아니며, 한 호스트가 여러 경로를 사용하고자 하는 바람은 인터넷의 나머지가 반드시 따라야 하는 지시가 아닙니다. 초기 교환은 첫 서브플로 위에 경계가 분명한 프로토콜 관계를 수립합니다. 사용자 신원도, 애플리케이션 권한도, 어느 IP 주소의 소유권도, 다른 경로의 미래 품질도 수립하지 않습니다.

더 오래된RFC 6824는 이 설계를 2013년 1월에 실험적(Experimental)으로 기록했습니다. 인터넷 표준이 아니라 구현과 평가를 위해 공표된 것입니다.RFC 8041은 이후 미들박스 및 서브플로 관리 교훈을 포함한 시점이 표기된 운영 경험을 수집했습니다. 2020년에 표준 트랙(Standards Track)으로 공표된 RFC 8684는 그 v0 사양을 대체하며, v1의 명확화와 수정이 주로 배포 경험에 의해 이루어졌다고 말합니다. 이 순서는 좁은 역사적 진술을 뒷받침합니다: 구현 경험이 프로토콜 기록을 바꾸었다는 것입니다. 이것이 현재 배포 점유율, 특정 벤더의 구성, 보편적 이익에 대한 주장을 정당화하지는 않습니다.

토큰은 색인이지 허가증이 아니다

초기 연결이 존재하면, 호스트는 서브플로를 추가하려 시도할 수 있습니다. 첫MP_JOINSYN에는 수신 측 호스트의 토큰, 발신자의 새로운 임의 논스, Address ID가 담깁니다. v1의 SHA-256 선택에서 수신측 토큰은 그 수신자의 초기 키에 대한 SHA-256 해시의 상위 32비트입니다. 컴팩트한 이유는 그 즉시의 임무가 컴팩트하기 때문입니다: 이 SYN이 합류한다고 선언하는 로컬 MPTCP 연결이 어느 것인지 수신자가 찾게 해 주는 것입니다.

그것은 디멀티플렉싱입니다. 소유권 증서가 아닙니다.

수신자는 토큰을 연결 상태로, 그리고 그 상태를 통해 키로 사상합니다. RFC 8684는 토큰이 서브플로 SYN의 디멀티플렉싱에 사용되며, 서브플로가 수립된 후에는 평범한 TCP 5-튜플이 그 패킷을 디멀티플렉싱한다고 명시합니다. 따라서 프로토콜은 시간에 따라 선택자를 바꿉니다. 입장 시점에는 새로운 SYN을 기존 서브플로 5-튜플로 구분할 수 없으므로 수신자의 토큰을 제시합니다. 입장 이후에는 패킷이 새로 만들어진 TCP 플로에 속하며, 그것의 통상적인 출발지 주소, 목적지 주소, 출발지 포트, 목적지 포트, 프로토콜 문맥에 따라 구분됩니다.

Address ID는 다른 부기 문제를 해결합니다. NAT가 반대쪽에서 본 IP 헤더를 바꾼 경우에도 발신자가 출발지 주소를 식별할 수 있도록 발신자가 선택합니다. 이를 통해 상대가 회선 주소에 대한 안정적인 시야를 갖고 있다고 가장하지 않고도 주소 제거와 상관이 가능해집니다. Address ID는 라우팅 가능한 주소도 아니고, 이 연결의 프로토콜 상태 밖에서 발신자가 주소를 소유·제어·사용할 권한이 있다는 증거도 아닙니다.

32비트 토큰은 또한 보안 업무 전체를 해낼 수 없습니다. 이 크기의 충돌 저항성 조회 핸들은 명시된 설계에서 수신자가 상태를 고르고 무차별적 상태 고갈 노출을 제한하는 데 도움이 됩니다. 그것이 인간의 비밀이나 애플리케이션 베어러 자격 증명으로 제시되는 것은 아닙니다. 프로토콜은 유용한 색인을 보편적 주장으로 변환하는 것을 거부합니다.

키가 다시 말해야 한다

MP_JOIN은 조회가 갖지 못한 증명을 더합니다. 수신자는 자신의 새로운 논스와 잘라낸(truncated) HMAC으로 응답합니다. 개시자는 자신의 HMAC으로 응답합니다. HMAC 입력은MP_CAPABLE동안 교환된 키와 두 개의 새로운 논스를 사용합니다. 논스는 기록된 과거 교환만으로는 이 특정 합류 시도의 재생이 불가능하게 만듭니다.

결과는 신중하게 범위가 정해집니다. HMAC이 검증되면, RFC 8684에 따르면 두 호스트는 자신들이 연결 시작 시 존재했던 동일한 MPTCP 피어임을 확인했고, 서브플로가 합류할 MPTCP 연결이 어느 것인지 합의했다는 것입니다. 이것은 이 전송 구조 안에서의 피어 연속성입니다. 그것이 가치 있는 이유는 정확히, 사람들이 흔히 인증이라는 말에 붙이는 주장들보다 작기 때문입니다.

이것은 인간 사용자를 식별하지 않습니다. 회사를 증명하지 않고, 계약을 수립하지 않고, 바이트 스트림에서 나중에 전달되는 요청을 승인하지 않으며, 애플리케이션 트랜잭션이 커밋되었음을 증명하지 않습니다. 두 주소 쌍이 독립적인 물리 경로를 제공한다는 것도 증명하지 않습니다. 이것이 말하는 것은, 이 특정 합류를 완료하는 당사자가 프로토콜이 요구하는 연결 재료를 보유하고 있으며, 양단이 확장되는 연결 기록에 대해 합의한다는 것입니다.

부정적 사례들이 이 구분을 정직하게 지켜줍니다. 수신자가 토큰을 모르면 시도된 서브플로를 재설정(reset)합니다. 토큰을 알지만 로컬 정책이 새 서브플로를 금지하면 그 시도 역시 재설정합니다. 기대된 HMAC이 없거나 틀리면 해당 종단이 서브플로를 닫습니다. 따라서 일치하는 토큰은 입장에 앞서지만 입장을 강제하지는 않습니다. 올바른 암호학적 응답은 계속 사용에 앞서지만, 애플리케이션이 무엇을 할 수 있는지는 결정하지 않습니다.

새로운 5-튜플에는 로컬 후원자가 있다

이 로컬 거부 지점은 아키텍처 도식에서 가장 쉽게 사라지는 부분입니다. 도식은 주소 A2가 주소 B1에 도달하는 선을 표시하고 그것을 “추가 경로”라고 부를 수 있습니다. RFC 8684는 더 엄격합니다. SYN은 TCP 서브플로를 제안하고; 수신자는 자신의 MPTCP 상태를 선택하고, 요구되는 증명을 검사하고, 그 상태가 서브플로를 하나 더 받아들일지에 대한 정책 결정을 보유합니다. 그 후에야 새 5-튜플이 공유되는 MPTCP 연결이 관리하는 TCP 플로 중 하나가 됩니다.

이 모델은 유용한 비대칭을 보존합니다. 발신자는 주소, 토큰, 이전 연결 키에 묶인 증거를 제공할 수 있습니다. 수신자는 자신의 상태 테이블, 자원 한도, 입장 정책을 통제합니다. 주소 공개나 패킷 도착이 그 통제를 조용히 이전하지는 않습니다. 이것이 내구성 있는 시스템의 평범한 규율입니다: 발견은 장소를 가리키고; 증명은 주장을 이전 상태에 결속시키며; 운영 중인 종단이 여전히 새 작업이 그곳에 속하는지를 결정합니다.

이것은 또한 애플리케이션 작업의 운명을 단일 추적으로 정할 수 없는 이유를 설명합니다. 캡처는MP_CAPABLE, 토큰을 실은MP_JOIN, 완료된 HMAC, 건강한 TCP 서브플로를 보여줄 수 있습니다. 그것들은 강력한 전송 계층 사실입니다. 그러나 그것들은 요청이 애플리케이션에 의해 수락되었는지, 데이터베이스가 그것을 커밋했는지, 원격 서비스가 그것을 수행할 권한이 있었는지, 사용자가 그 효과를 받았는지를 보여주지 않습니다. 바이트 스트림은 연속적일 수 있지만, 의미는 의도적으로 전송 계층의 관할 밖에 있습니다.

기록의 출처와 한계

여기 기술된 아키텍처와 정의된 프로토콜 동작—RFC 6824의 실험적 지위, RFC 8041에 수집된 시점이 표기된 경험, RFC 8684의 규범적 v1 절차—은 RFC 기록이 확립합니다. 그러나 현재 보급 수준, 실제 경로 분리, 이름이 지정된 네트워크에서의 미들박스 동작, 제품 적합성, 성능 결과, 사용자 신원, 애플리케이션 결과는 확립하지 않습니다.