요약

  • 모바일 노드의 실제 홈 주소가 방문 네트워크의 발신 접두사 검사에 실패할 수 있었다. 주소의 정당성이 그 발신 지점에서의 토폴로지적 적합성을 보장하지는 않았다.
  • 역방향 터널링은 패킷 안에 원래의 통신 종단을 보존하면서 홈 에이전트까지의 경로에 적절한 외부 발신 주소를 부여했다.
  • 직접 전달과 캡슐화 전달은 서로 다른 선택지를 제공했다. 이들의 협상, 지역성 검사 및 바인딩 검사는 암호화, 방화벽 통과, 그리고 성공적인 종단 간 전달과는 별개로 남아 있었다.

그럴듯하지 않은 출구에서의 정직한 주소

패킷은 통신 상대에게 보내지는 것이었고, 발신자의 홈 주소를 담고 있었다. 모바일 노드가 그 주소를 사용할 정당성에 대해서는 아무것도 달라진 것이 없었다. 달라진 것은 패킷이 네트워크에 진입한 지점이었다. 홈에서는 자연스러운 발신 주소가, 누군가의 다른 연결에서 나오는 순간에는 부적절해 보일 수 있었다.

이것은 유용한 분리가 낳은 곤란한 결과였다. 1996년 10월에 발표된RFC 2002는 홈 주소를 유지하면서 서브넷 간의 IPv4 이동성을 기술했다. 홈 에이전트는 해당 주소로 향하는 트래픽을 가로채, 모바일 노드의 현재 전달 지점을 나타내는 케어오브 주소로 터널링할 수 있었다. 통신 상대는 모든 이동을 완전히 새로운 종단으로 취급할 필요가 없었다.

케어오브 주소는 여러 모바일 노드에 서비스하는 외부 에이전트(foreign agent)에 속할 수도 있고, 모바일 노드 자신에 속할 수도 있었다. 첫 번째 방식에서는 외부 에이전트가 터널을 종단하고 로컬로 전달했다. 두 번째 방식에서는 모바일 노드가 터널을 종단했다. 공유 에이전트 방식에서는 각 방문자가 별도의 로컬 IPv4 주소를 받을 필요가 없었다.

따라서 수신 트래픽에는 홈 에이전트를 통과할 이유가 있었다. 그러나 발신 트래픽에 꼭 같은 요구가 적용되는 것은 아니었다. 원래 모델은 목적지 기반 라우팅을 가정했다. 즉, 모바일 노드는 홈 에이전트를 먼저 거치지 않고도 방문 네트워크에서 홈 발신 주소를 그대로 두고 통신 상대 쪽으로 보낼 수 있었다.

이 가정은 포워딩을 설명했지만, 접수 허용 여부는 정하지 않았다. 네트워크는 목적지 경로를 조회하기 전에, 그 발신 주소를 가진 패킷이 그 특정 연결을 통해 도착하는 것이 마땅한지 물을 수 있었다.

필터가 발신자를 도둑으로 몰 필요는 없었다

2000년 5월에 BCP 38로 발행된RFC 2827은 하류 네트워크로부터 수용하는 발신 접두사를 제한할 것을 권고했다. 그 목적은 발신 주소 스푸핑을 줄이는 것이었다. 목적지로 가는 경로를 안다는 것 자체는 임의의 발신 주소를 수용할 근거가 아니었다.

모바일 노드는 자기 주소를 정직하게 사용하면서도 허용 범위 바깥에 놓일 수 있었다. 홈 접두사는 어딘가 다른 곳에 속해 있었다. 필터는 토폴로지적 개연성을 검사할 뿐, 주소의 소유권이나 그 컴퓨터를 운영하는 사람의 품행을 판정하는 것이 아니었다.

이 문서는 Mobile IP의 난점을 명시적으로 인정하고 역방향 터널링을 가리켰다. 방문자가 도착할 때마다 발신 주소 검증을 포기하라는 요구가 아니었고, 애플리케이션이 안정적인 주소 지정을 완전히 버리라는 요구도 아니었다. 문제는 통신 종단과 현재 전송 구간에 각각 별도의 주소 필드를 부여하는 방식으로 접근할 수 있었다.

발신 접두사 필터링에는 반대 방향의 한계도 있었다. 허용된 접두사 안의 주소를 스푸핑하면 그 검사를 통과할 수 있었다. 적합한 접두사가 곧 개별 발신자의 신원 증명은 아니었다. 역방향 터널 설계는 이 구분을 지켜야 했고, 하나의 유용한 검사를 보편적 신뢰로 바꿔서는 안 되었다.

우회가 제공한 서로 다른 겉면

이 확장은 1998년 5월의RFC 2344에 등장했고, 2001년 1월의RFC 3024가 이를 개정했다. '역방향'은 홈 에이전트에서 모바일 노드로 향하는 기존 터널을 기준으로 한 방향을 가리켰다. 이제 발신 트래픽은 먼저 홈 에이전트로 갔다가 통신 상대에게 계속 진행할 수 있었다.

이 메커니즘은RFC 2003이 정한 구분에 의존했다. 안쪽 IP 헤더는 원래 통신을 기술했고, 바깥쪽 헤더는 터널 종단을 기술했다. 외부 에이전트에서 홈 에이전트로 가는 구간에서 바깥쪽 발신 주소는 외부 에이전트의 케어오브 주소였고, 바깥쪽 목적지는 홈 에이전트였다. 모바일 노드의 홈 주소는 안쪽 발신 주소로 남았다.

이렇게 방문 네트워크가 보는 것은 그 출발 지점에 맞는 바깥쪽 발신 주소였다. 원래 종단은 이름이 바뀌지 않았다. 하나의 패킷이 서로 다른 여정 구간에 각각 유용한 두 개의 주소 관계를 담았다.

캡슐화는 내용물을 비밀로 만들지 않았다. 안쪽 종단을 보존한다고 해서 안쪽의 모든 비트가 그대로라는 뜻도 아니었다. 포워딩은 TTL 같은 필드에 영향을 줄 수 있었다. 그리고 양방향의 대응 터널 종단과 캡슐화가 있어도, 패킷이 역순으로 같은 물리 링크를 지나간다는 보장은 없었다.

추가된 껍데기는 특정한 불일치를 해결했다. 그러나 그것이 모든 중간 정책이 결과를 수용하게 만들 수는 없었다. RFC 3024는 방화벽 통과에 대한 일반 해법을 명시적으로 범위에서 제외했다.

패킷을 에이전트에 건네는 두 가지 방식

직접 전달에서는 모바일 노드가 외부 에이전트를 기본 라우터로 사용하고, 추가 로컬 껍데기 없이 원래 패킷을 보낸다. 에이전트가 이를 집으로 보내는 데 필요한 가로채기와 캡슐화를 수행했다. 이 방식은 유니캐스트 역방향 터널링은 지원했지만 선택적 역방향 터널링은 지원하지 않았다.

캡슐화 전달에서는 노드가 첫 껍데기를 직접 씌운다. 그 껍데기는 외부 에이전트를 향하고, 에이전트는 이를 벗겨낸 뒤 홈 에이전트를 향한 새 껍데기를 씌웠다. 이는 두 번의 서로 다른 인계였지, 변경되지 않은 하나의 바깥쪽 헤더가 두 에이전트를 모두 통과하는 것이 아니었다.

첫 껍데기의 발신 주소는 여전히 모바일 노드의 홈 주소였다. 외부 에이전트가 홈 에이전트를 향해 두 번째 껍데기를 보내는 시점에야 바깥쪽 발신 주소가 케어오브 주소가 되었다. 두 단계를 하나로 합쳐버리면, 모바일 노드가 로컬 구간에서 외부 에이전트의 주소를 자기 발신 주소로 쓴 것처럼 잘못 암시하게 된다.

추가 연산은 선택지를 만들었다. 캡슐화 전달이 협상된 후에는, 외부 에이전트가 모바일 노드의 캡슐화되지 않은 패킷을 역방향 터널링해서는 안 된다. 에이전트는 이런 패킷을 일반 포워딩으로 처리했다. 따라서 모바일 노드는 모든 교환을 먼저 홈으로 보내지 않고도, 프린터처럼 로컬에 있는 자원에 접근을 시도할 수 있었다.

일반 포워딩은 여전히 로컬 경로와 정책에 의존했다. 이 사양은 프린터가 도달 가능하거나 요청을 수용할 것이라고 보장하지 않았다. 방문 네트워크의 규칙에서 면제되는 것이 아니라, 처리 방식의 선택만을 보존한 것이다.

캡슐화 전달은 외부 에이전트를 통하는 브로드캐스트 및 멀티캐스트 역방향 터널링에도 필요했다. 따라서 두 방식은 포장뿐 아니라 서비스 범위에서도 달랐다. 에이전트가 인식 가능한 모든 모바일 패킷을 '친절하게' 같은 복귀 경로에 넣음으로써 이 구분을 지울 수는 없었다.

제안, 요청, 그리고 더 좁은 합의

에이전트 광고의 T 비트는 역방향 터널 서비스를 제안했다. 등록 요청의 T 비트는 그 서비스를 사용하고자 요청했다. 광고는 특정 요청의 수락이 아니었고, 수락은 통신 상대에게 데이터가 도착하는 것을 관찰한 것도 아니었다.

캡슐화 전달은 타입 130, 길이 0의 확장을 사용했다. 이 확장이 없으면 요청된 방식은 직접 전달이었다. 이 확장은 T 비트가 지워진 요청과 함께 보내져서는 안 되며, 인증 확장에 대해 정해진 위치가 있었고, 외부 에이전트는 이를 홈 에이전트에 그대로 전달하는 대신 소비했다.

이것은 특정 관계 안에서의 로컬 전달 선택이었다. 모든 하류 네트워크가 결과 트래픽을 이해하거나 수용한다는 선언이 아니었다.

구현 요구 수준도 달라졌다. RFC 2344는 역방향 터널링을 광고하는 외부 에이전트에게 두 전달 방식 모두의 지원을 요구했다. RFC 3024는 직접 전달은 필수로 두었지만 캡슐화 전달은 권고로 바꿨다. 코드 79는 지원되지 않는 전달 방식의 거절을 식별할 수 있었다.

IANA Mobile IP 레지스트리가 이 할당을 확인해 준다. RFC 3024에는 79가 아직 할당되지 않았다고 말하는 낡은 괄호가 남아 있는데, 같은 문서의 할당 섹션과 변경 부록은 이 할당을 기록하고 있다. 그 낡은 괄호만 읽으면 레지스트리에 대한 거짓 서술이 나온다. 역사적 사양은 개정판 간 비교뿐 아니라 때로 문서 내부의 대조도 필요하다.

성공적인 등록에도 쓸모 있는 출구가 없을 수 있었다

역방향 터널 요청이 실패하면 노드는 T 비트를 지우고 다시 시도해 등록을 얻을 수 있었다. RFC 3024는 이것이 데이터 전송에는 무용지물일 수 있다고 경고했다. 발신 필터링 때문에 역방향 터널이 필요한 상황에서, 성공한 재시도는 패킷을 밖으로 꺼내는 데 필요한 바로 그 기능을 제거해 버린 것이었다.

응답은 거짓말이 아니었다. 더 적은 요구의 배열을 수락했을 뿐이다. 실수는 그 수락을 전체 데이터 경로에 대한 약속으로 취급한 데 있었다. 호환성 재시도는 정밀한 거절을, 원인이 덜 드러나는 이후의 실패로 바꿔놓을 수 있었다.

등록에는 지역성 검사도 있었다. 요청은 TTL 255로 보내야 했고, 외부 에이전트는 그 값을 검사했다. IP 라우터를 통과할 때마다 TTL은 줄어든다. 이는 특정한 형태의, 로컬 링크 밖에서의 등록 탈취 시도를 제한했지만, 이미 그 링크에 있는 적대적 이웃을 인증해 주지는 않았다.

홈 에이전트 쪽에서는 디캡슐화 바인딩 검사의 구현이 요구되었고 기본적으로 활성화하는 것이 권고되었다. 바깥쪽 발신 주소는 등록된 케어오브 주소와, 안쪽 발신 주소는 모바일 홈 주소와, 캡슐화는 협상된 방식과 일치해야 했다. 바인딩이 없거나 캡슐화가 틀리면 패킷을 폐기해야 했다.

이것은 전송 서비스를 구속했지만, 모든 패킷의 내용을 암호학적으로 인증해 주지는 않았다. 문서는 무관한 터널을 종단하는 에이전트에 대한 예외를 '권장하지 않는' 형태로 허용했으므로, 기본 권고를 '이 검사가 어디서나 무조건 활성화된다'는 주장으로 다시 쓰면 안 된다.

바인딩을 갱신하는 메시지의 방향조차 중요하다.RFC 3024의 검증된 기술적 정오표는 해당 문단에서 등록 응답을 등록 요청으로 바로잡았다. 수정되지 않은 문장을 그대로 옮기면 상태를 바꾸는 입력에 대한 잘못된 서술이 된다.

사설 주소에도 의미를 발휘할 자리가 필요했다

RFC 3024의 본문 논의는 공통의 주소 공간을 가정했다. 부록은 서로 다른 공간을 다루는 제한적인 배열을 다룰 뿐, 일반적인 NAT 통과나 임의의 사설 주소 중복에 대한 해법을 약속하지 않았다.

외부 에이전트와 홈 에이전트는 여전히 바깥쪽 주소 공간에서 서로 도달해야 했다. 안쪽 주소는 각자의 통신 도메인 안에서 적절한 의미를 지녀야 했다. 서로 다른 홈 에이전트 뒤에서 반복되는 사설 홈 주소는 필요한 맥락이 있어야만 구분될 수 있었다.

로컬 전달에서 이 맥락에는 링크 계층에서 그 모바일 노드와의 보안 연관이 포함되었다. 관련 보안 섹션은 이 배열에 보안 링크 계층 신원을 요구했으며, 인증되지 않은 공유 이더넷을 권고하지 않았다. 추가 헤더가 맥락을 담을 수는 있지만, 그것 자체로 신뢰할 수 있는 로컬 신원을 만들어 낼 수는 없었다.

2010년 11월의RFC 5944도 인그레스 필터링을 논하면서 역방향 터널링을 언급했다. 이는 이 아키텍처적 문제의 지속성을 문서화한 것이지, 배포 규모를 세거나 모든 모바일 네트워킹이 이 모델을 따랐다고 주장한 것이 아니다.

먼저 홈으로 간 패킷은, 자신을 실어 나르는 네트워크가 여정의 한 부분을 이해할 수 있도록 하기 위해 그렇게 했다. 홈 주소는 안정적으로 남을 수 있었고, 바깥쪽 발신 주소는 현재 출발 지점에 맞을 수 있었으며, 로컬 트래픽은 때로 로컬에 머물 수 있었다. 그 어느 성취도 모든 경계를 넘을 권한을 부여하지는 않았다. 이 설계는 서로 다른 질문을 서로 다른 검사에 배정함으로써 동작했지, 하나의 성공한 검사가 전부를 대답하게 두지 않았다.