요약

  • RFC 3145는 L2TP 피어가 Call-Disconnect-Notify 메시지에 PPP 특정 원인을 붙일 수 있게 했지만, 해당 속성이 선택 사항이며 강제성이 없고 정보 제공용으로 남아 있어야 한다고 요구했다.
  • 원인 코드, 프로토콜 번호, 방향을 함께 놓아야 보고의 범위가 식별된다. 이들만으로 물리적 근본 원인, 책임, 사용자 수신 여부 또는 과금 결과를 독립적으로 증명할 수 없다.
  • 이 설계는 권한을 보고 호스트에 넘기거나 자유 텍스트가 보안 오라클이 되게 하지 않으면서 조직 간 진단을 더 이식 가능하게 만들었다.

터널은 호출이 끝났음을 알았지만 PPP가 본 것은 알지 못했다

L2TP(Layer 2 Tunneling Protocol)는 두 종류의 장치를 분리했다. 터널은 액세스 집중 장치인 LAC를 네트워크 서버인 LNS에 연결했다. 그 구성 안에서 PPP는 링크, 인증, 네트워크 계층 상태를 협상했다. 이 분리는 유용했다. 터널은 PPP의 내부 결정을 모두 재현할 필요가 없었다. 동시에 그것은 관측 가능성의 단층선이기도 했다.

L2TP Call-Disconnect-Notify 메시지는 세션을 닫고 L2TP Result 및 Error Codes를 운반할 수 있었다. 그 값들은 터널 제어 트랜잭션에 대해 이야기했다. PPP가 시간 초과되었는지, 모든 네트워크 제어 프로토콜을 거부했는지, 에코 실패를 겪었는지, 아니면 관리적 결정으로 끝났는지를 원격 운영자에게 반드시 알려주지는 않았다. 그 결여된 설명은 LAC와 LNS가 서로 다른 조직에 속할 때 가장 비싸졌다. 한쪽은 사용자 면 엣지를 보았고, 다른 쪽은 종료로 이어진 PPP 상태를 보았다.

RFC 3145는 그 간극에 간결한 영수증을 넣었다. PPP Disconnect Cause Code 속성-값 쌍은 IETF Vendor ID 0과 Attribute Type 46을 사용했다. 이 속성은 연결 해제 알림에서만 유효했으며, 열거된 원인, PPP Control Protocol Number, 방향 바이트, 그리고 선택적으로 UTF-8 설명 텍스트를 운반했다. 이제 먼 피어는 "호출이 사라졌다"는 말보다 더 많은 것을 받을 수 있었다.

이 확장은 자신이 넘은 경계를 지우지 않았다. 새 속성은 L2TP Result 및 Error Code 속성을 대체하는 것이 아니라 곁에 두어야 한다고 명시했다. PPP 원인과 터널 결과는 병렬적인 관측이었다. 하나를 다른 하나의 대용품으로 다루면 그 증거를 해석 가능하게 만든 계층 구조 자체를 버리는 셈이었다.

Mandatory 비트를 0으로 강제한 것은 건축적 선언이었다

새 속성의 Mandatory 비트는 반드시 0이어야 했다. 이 규칙은 자잘한 오탈자가 아니었다. 더 오래되었거나 단순한 피어도 이해하지 못하는 진단을 제어 메시지를 거부하도록 강제받지 않고 무시할 수 있었다. 설명이 고르게 배포되지 않더라도 연결 해제 처리는 상호 운용 가능하게 남았다.

같은 절제가 문서의 효과 규칙에도 나타났다. 원인 속성은 정보와 로깅을 위한 것이었고, 터널이나 PPP 세션의 동작을 바꿔서는 안 되었다. 진단은 이미 일어난 행위를 기술하는 것은 허용되었지만, 그럴듯한 이유를 담고 있다는 이유만으로 두 번째 제어 평면이 되는 것은 허용되지 않았다.

이 선택은 운영 시스템이 자주 뭉개는 세 가지 권력을 분리했다. 세션을 끝내는 권한은 기존 프로토콜 상태 기계에 남았다. 로컬 관측을 보고하는 권한은 어느 쪽 L2TP 호스트든 가질 수 있었다. 사건이 왜 일어났는지 결론짓는 권한은 하나의 보고 바깥에, 다른 기록들이 그것을 검증할 수 있는 곳에 남았다.

선택 사항인 Hidden 비트는 또 하나의 구분을 제공했다. 피어는 L2TP의 하위 메커니즘을 사용해 속성을 숨길 수 있었고, 이후 지침은 L2TP를 IPsec으로 보호하는 방법을 다루었다. 채널 무결성과 기밀성은 보호된 바이트를 누가 교환했는지 확립하고 변경 가능성을 낮출 수 있다. 그러나 송신자의 로컬 해석이 완전하거나 옳다는 것은 확립할 수 없다. 보호된 주장은 여전히 주장이다.

이유에는 좌표가 필요했다

RFC 3145는 벗겨낸 숫자만을 정의하지 않았다. Disconnect Code를 제어 프로토콜과 방향과 짝지었다. 그 튜플이 필요했던 까닭은 "인증 실패"나 "매개변수 거부"는 관점 없이는 무의미하기 때문이다.

방향 0은 전역 오류를 의미했다. 방향 1은 피어 측, 방향 2는 로컬 호스트 측을 의미했다. 정상적인 LCP 종료에서 방향은 어느 쪽이 Terminate-Request를 보냈는지 식별한다. 강제 암호화나 콜백에서는 기능을 요구한 쪽과 거부한 쪽을 구분한다. 인증 협상에서는 피어가 거부한 프로토콜과, 피어가 요청했으나 로컬에서 수용 불가능한 프로토콜을 구분한다.

로컬과피어라는 말은 보고서를 작성하는 호스트에 고정되어 있다. 수집기가 이를 조용히 "고객"과 "공급자"로 바꿔 쓰면, 회선이 운반하지 않은 주장이 만들어진다. 방향을 고장으로 바꾸는 대시보드도 마찬가지다. 요청된 메커니즘을 거부하는 것이 올바른 정책 결정일 수 있다. 마지막 패킷을 보냈다고 해서 그 앞의 모든 일에 대한 책임이 증명되는 것은 아니다.

Control Protocol Number는 두 번째 좌표를 더한다. 전역 원인은 0을 쓴다. 링크 제어 실패는 LCP를, 인증 실패는 해당 인증 프로토콜을, 네트워크 제어 실패는 보통 관련 NCP를 가리킨다. 여러 NCP가 실패하면 속성의 여러 복사본이 전송될 수 있다. 단일 복사본은 가장 최근에 실패한 NCP를 식별해야 한다. "가장 최근"은 선택 규칙이지, 이전 실패들이 중요하지 않았다는 선언이 아니다.

이것이 정규화된 이벤트가 원래 튜플을 보존해야 하는 이유다. "원인 16"만으로는, 특정 피어가 특정 인증 프로토콜에 대해 특정 방향으로, 특정 CDN 안에서, 알려진 전송 보호 맥락 아래 보고한 코드 16보다 약하다. 좌표가 하나 제거될 때마다 숫자를 과잉 해석하려는 유혹이 커진다.

목록은 상태를 다루었지 법정 판정을 다루지 않았다

초기 레지스트리는 0부터 20까지였다. 정보 없음, 관리적 연결 해제, 정상 LCP 종료, 협상 시간 초과, 인식 가능한 LCP 패킷 없음, Magic Number 오류로 신호된 가능한 루프백, 에코 시간 초과, 멀티링크 불일치, 콜백 또는 암호화 거부, 인증 실패, 사용 가능한 네트워크 제어 프로토콜 부재, 수용 가능한 주소에 대한 수렴 실패가 포함되었다.

이 라벨들은 두 제품이 같은 관측 등급을 부호화할 수 있게 해 주었기 때문에 가치가 있었다. 그러나 관측 등급은 완전한 인과 사슬이 아니기 때문에 한계도 있었다. 에코 시간 초과는 한 지점에서 기대한 응답이 관측되지 않았다는 것만 증명한다. 손실, 혼잡, 죽은 피어, 막힌 반환 경로, 실패한 로컬 프로세스 중 무엇인지는 선택해 주지 않는다. "인증 실패"는 프로토콜 결과를 기록할 뿐, 이름이 유효하고 비밀번호만 틀렸는지를 공개할 권한을 주지 않는다.

RFC 3145는 마지막 한계를 명시했다. 미래의 확장은 공격자에게 진단을 사용자명 오라클로 바꾸는 구분을 주어서는 안 된다. 더 많은 세부 정보가 곧 더 많은 진실은 아니다. 세부 정보는 유인을 바꾸고, 비밀을 노출하고, 반복된 탐색으로 경계를 넘을 의도가 없던 상태를 발견하게 할 수 있다.

선택 사항인 UTF-8 메시지는 산문에서도 같은 규율을 만든다. 이식 가능한 문자는 설명을 표시 가능하게 만든다. 그러나 정본으로 만들지 않고, 모든 독자에게 안전하게 만들지 않고, 사용자에게 도달했음을 보장하지도 않는다. 자유 텍스트는 정확한 출처와 개인정보 처리 방식이 보존된 채 구조화된 튜플 곁에 있어야 한다. 텍스트가 코드를 덮어써서는 안 되고, 코드가 산문을 인증해서도 안 된다.

두 주인은 공유된 영수증이 필요했다

RFC에서 이 간극이 왜 중요한지 드러내는 가장 계몽적인 문장은 액세스 집중 장치와 네트워크 서버가 같은 소유자나 관리자를 두지 않을 수 있다는 점이다. 한 팀 안에서는 엔지니어가 관행적으로 내부 로그를 상관 분석할 수 있을 때가 있다. 조직 경계를 넘으면 관행은 약하다. 각 당사자는 상대가 무엇을 관측했는지 말해 주는 안정적인 영수증이 필요하되, 양측이 하나의 상태 기계나 하나의 유인 구조를 공유한다고 가장하지 않아야 한다.

RFC는 이 확장이 강제 터널링에서 LNS에서 LAC로 보낼 때 특히 유용할 것으로 예상하면서도 어느 쪽이든 보낼 수 있게 했다. 그 비대칭은 영구적 권한이 아니라 있기 쉬운 지식을 기술한다. LNS는 자신의 PPP 협상이 왜 끝났는지 알 수 있고, LAC는 액세스 링크에서 무슨 일이 있었는지 알 수 있다. 완전한 조사에는 둘 다 필요할 수 있다.

초안 역사는 또 하나의 유용한 이음새를 남겼다. 이전 형식은 3Com Vendor ID 43을 사용했다. RFC 3145는 수신자가 그 형식을 동등한 것으로 받아들이는 것을 허용하되 구현이 이를 전송하지는 말라고 했다. 호환성은 오래된 증거를 보존했고, IETF 배정이 앞으로의 회선 계약이 되었다. 레지스트리는 필드를 어떻게 읽을지 확립했지만, 누가 배포했는지, 어떤 개별 보고가 정확한지는 증명하지 않는다.

과금에는 또 하나의 영수증이 필요했다

초록은 이 원인이 과금과 디버깅에 도움될 수 있다고 말했다. 조심스러운 동사가 중요하다. RADIUS 터널 과금 속성은 터널을 식별하고, 과금 입력을 기록하고, 세션을 상관시킬 수 있다. 이 기록들은 연결 해제 원인이 답하지 않는 질문에 답한다. 어느 과금 세션이 시작되었는지, 중간 업데이트가 언제 도착했는지, 정지(stop) 기록이 수신되었는지, 시스템이 그것을 어떻게 적용했는지.

원인 코드는 정지가 발생했을 이유를 설명할 수 있다. 그러나 정지 기록이 정산되었는지, 사용량 카운터가 완전했는지, 청구서가 옳았는지는 증명할 수 없다. 반대로 깨끗한 과금 정지가 PPP 진단이 옳았다는 것을 증명하지도 않는다. 두 기록은 어느 한 필드를 우월하다고 선언하는 방식이 아니라 안정적인 식별자와 타임스탬프를 통해 만나야 한다.

데이터 평면도 마찬가지다. 에코 시간 초과 코드는 패킷 카운터, 도달 가능성 검사, 링크 알람과 비교되어야 한다. 인증 원인은 자격 증명과 민감한 텍스트를 넓은 로그에서 벗어나게 유지하면서 상태 전이와 비교되어야 한다. 정상 종료는 실제 LCP 교환과 비교되어야 한다. 원인은 조사의 색인이지 조사의 마지막 페이지가 아니다.

실행 중인 코드가 최종 항소를 제공했다

RFC 3145는 내구 있는 인터넷 패턴의 작은 예시다. 상호 운용을 위해 필요한 최소한의 메시지를 표준화한 다음, 운영에서 나온 증거로 기관이 그것에 대해 무엇을 주장할 수 있는지 제약하게 한다. 숫자 배정은 상징적 권위다. 보호된 CDN은 기록된 행위다. PPP 상태와 패킷은 운영 현실이다. 과금과 사용자 경험은 결과다. 어느 것도 다른 것을 흉내낼 수 없다.

이 위계는 유용한 진단이 정치화되는 것도 막는다. 수신 조직이 피어의 코드를 최종 진실로 받아들이거나 신뢰할 수 없는 것으로 버리는 양자택일에 놓이면 협력은 취약해진다. 더 나은 규칙은 더 좁다. 주장을 그대로 보존하고, 누가 만들었는지 보존하고, 독립적인 영수증과 대조하고, 불확실성을 보이게 유지하라. 보고서는 경계가 있기 때문에 가치가 남는다.

25년이 지난 지금도 관측 가능성 시스템은 이 이음새에서 실패한다. 한 구성 요소가 공급한 이유를 수집하되 보고자와 방향을 제거하고, 친절한 문장으로 번역한 뒤 전역 인시던트 라벨로 승격시킨다. RFC 3145는 이미 더 안전한 구조를 보여 주었다. 코드는 터널을 건널 수 있다. 그러나 현실에 대한 권한은 코드와 함께 이동하지 않는다.

출처