요약

  • PPP의 매직 넘버(Magic-Number)는 반사된 링크 제어 트래픽을 감지하기 위한 엔드포인트가 선택한 마커였으며, 전역적으로 할당되는 장치 식별자도 암호학적 자격 증명도 아니었다.
  • 동일성은 Configure-Request와 Configure-Ack에서 서로 다른 의미를 가졌다. 충돌 처리에는 올바른 패킷 유형, 로컬 이력, 충분히 독립적인 번호 선택이 필요했다.
  • 공유된 절차는 협상을 제약하면서 복구 정책은 구현에 맡겼다. 온전한 프레임, 독립적인 피어, 인증된 피어는 별개의 판단 사항으로 남았다.

패킷 코드를 바꾸면 결론도 바뀐다

PPP 엔드포인트가 매직 넘버를 제안했다고 하자. 정확히 그 번호를 담은 확인 응답이 도착한다. 이것이 링크가 단지 엔드포인트 자신의 트래픽을 되돌려주고 있다는 증거는 아니다. 유효한 Configure-Ack이 반드시 해야 하는 일은 제안된 옵션을 값과 순서를 바꾸지 않고, 일치하는 Identifier와 함께 재현하는 것이다.

이제 들어오는 패킷을 확인 응답에서 Configure-Request로 바꿔 보자. 상대방이 로컬 엔드포인트가 가장 최근에 보낸 요청과 같은 번호를 제안하고 있는 것이다. 이 동일성은 조사를 요구한다. 두 개의 독립적인 선택 사이의 우연한 일치일 수도 있고, 로컬 요청이 루프된 링크를 통해 되돌아온 것일 수도 있다.

이 규칙들은 1994년 7월에 발행된RFC 1661의 서로 다른 부분에 등장한다. 함께 읽으면 프로토콜 증거에 관한 유용한 경고가 된다. 정수 하나는 판결이 아니다. 그 의미는 누가 행동해야 하는지, 그 행동이 무엇인지, 그리고 그것이 어떤 이전 행동을 참조하는지에 달려 있다.

따라서 '매직'은 모든 기계가 인식할 수 있는 특별한 상수가 아니었다. 독립적인 피어의 부재를 더 잘 드러내기 위한 절차였다.

온전한 프레임이 오히려 잘못된 답일 수 있다

점대점 링크는 혼란의 여지가 거의 없어 보인다. 두 개의 끝단이 있고, 한쪽은 전송하고 다른쪽은 수신한다. 그러나 회선이 전송자의 출력을 자기 자신의 수신기로 되돌려줄 수 있다. 그렇다면 형식이 올바른 트래픽을 수신했다는 사실은 겉보기보다 적은 것을 증명한다.

프레임 검사는 이 문제를 해결해 주지 못한다. 1994년 7월 발행된 PPP의 HDLC 유사 프레이밍 사양인RFC 1662는 기본값이 2옥텟이고 4옥텟 대안이 있는 프레임 검사 시퀀스를 정의한다. 그 계산은 지정된 프레임 필드들을 다룬다. 출발지로 되돌아온 변경되지 않은 프레임도 여전히 유효한 검사값을 가질 수 있다.

이것은 검사의 실패가 아니다. 다른 질문이다. 비트 무결성은 수신된 프레임이 검사값과 일치하는지 묻는다. 루프 감지는 링크 제어 트래픽이 독립적인 엔드포인트의 상태를 반영하는지, 아니면 단순히 송신자 자신의 출력인지 묻는다.

이 둘을 혼동하면 특히 설득력 있는 거짓 신호가 만들어진다. 되돌아온 프레임이 깨끗할수록 안심이 된다. PPP는 손상되지 않은 복사본의 증거가 아니라 별개의 선택에 대한 증거를 필요로 했다.

공간은 전체 절차보다 먼저 존재했다

역사적 순서는 1994년 문서 이전부터 시작된다. 1989년 11월RFC 1134는 PPP를 캡슐화 방법, 확장 가능한 링크 제어 프로토콜(LCP), 그리고 네트워크 제어 프로토콜(NCP) 계열로 기술했다. LCP는 링크를 수립하고 시험하며, NCP들은 링크를 사용할 네트워크 계층 프로토콜을 구성한다.

그 Echo와 Discard 포맷에는 이미 4옥텟 매직 넘버 필드가 포함되어 있었다. 구성 옵션으로 변경되지 않는 한 이 번호는 0으로 전송되고 수신 시 무시되었다. 추가 사용은 그 논의의 범위 밖에 남았다. 이 필드는 확장 가능한 설계 안의 자리였으며, 아직 수신되는 모든 값이 협상된 의미를 가진다는 주장은 아니었다.

1990년 7월 D. Perkins와 R. Hobby의RFC 1172는 초기 구성 옵션을 제시했다. 매직 넘버에는 이미 이후 절차의 알아볼 수 있는 요소들이 있었다. 로컬 선택, 충돌 처리, 충분한 고유성 요구, 상호적 동작, 구현에 따른 복구 등이다.

1992년 5월 발행된RFC 1331은 이 메커니즘을 유지했다. RFC 1661은 이후 이를 6.4절에 배치했다. 이는 연속된 사양을 통한 지속이지 1994년의 갑작스러운 발명이 아니었다. 더 명확한 규칙을 발표하는 것은 구현들의 실제 동작이 그 규칙이 필요로 하는 전제를 제공할 때만 구현 상호운용성을 만들 수 있었다.

협상은 동점을 깨려고 시도한다

옵션을 제안하기 전에 엔드포인트는 자신의 번호를 선택한다. 원하는 속성은 이 링크 반대편 끝의 번호와 높은 확률로 구별되는 것이다. 인터넷 전체에서 고유한 번호는 필요하지 않다.

들어오는 Configure-Request가 옵션을 담고 있으면 엔드포인트는 그 값을 자신이 마지막으로 보낸 Configure-Request의 값과 비교한다. 값이 다르면 지정된 모델 아래에서 단순 반사는 배제된다. 값이 같으면 두 가지 설명이 열려 있는 채로 남는다. 반사와 우연한 충돌이다.

동일성에 대한 요구되는 응답은 다른 번호를 제안하는 Configure-Nak이다. 엔드포인트는 정상 처리 외에 즉시 추가 Configure-Request를 보내서는 안 된다. 수신한 Nak 또는 재시작 타이머가 다음 요청을 보낼 일반적인 이유를 제공한다.

그다음에는 서로 다른 참조점을 가진 두 번째 비교가 이루어진다. 들어오는 Configure-Nak의 번호가 마지막으로 로컬에서 전송한 Nak의 번호와 비교된다. 두 값이 일치하면 반사 의심이 커지며 새 번호를 선택해야 한다. 값이 다르면 절차는 별개의 선택에 대한 증거를 얻은 것이다. 새 Configure-Request는 새 번호를 담아야 한다.

실제로 루프된 링크에서는 요청과 Nak이 작성자에게 계속 되돌아올 수 있다. 독립적으로 선택하는 피어들 사이에서는 번호가 곧 갈라지게 된다. 이 절차는 극적인 결과를 가진 단일 동일성 검사가 아니다. 처음에 구별할 수 없는 두 설명이 서로 다르게 행동하도록 만들려는 조직적인 시도이다.

이 구별은 패킷 이력이 왜 중요한지도 설명해 준다. 모든 들어오는 값을 하나의 구별 없는 '현재 번호'와 비교하면 이 검사가 의존하는 Request 대 Request, Nak 대 Nak 관계를 버리게 된다.

무작위성은 구현의 책임이다

역사적 사양들은 균일한 32비트 선택에 대한 이상화된 충돌 추정치를 제공한다. 단일 동일성에 대해 약 2.3 × 10^-10이다. 이것은 측정된 거짓 경보율이 아니라 하나의 모델을 기술한다.

같은 상태에서 초기화되어 같은 결정론적 시퀀스를 따르는 두 장치는 독립적인 추첨처럼 동작하지 않는다. 같은 요청을 여러 번 수신하는 것도 여러 개의 독립적인 시행을 만들지 않는다. 선택 공간 자체도 주의가 필요하다. 0은 제안되는 매직 넘버로서 불법이므로, 합법적인 비영값으로 제한된 균일 선택기는 발표된 32비트 이상화와 약간 다른 공간을 가진다.

중요한 운영상의 요점은 그 작은 산술적 차이에 의존하지 않는다. 양 끝이 진정으로 구별되는 선택을 만들어낼 수 있는지에 달려 있다. 프로토콜은 필드를 무작위라고 부르는 것만으로 그 속성을 공급할 수 없다.

따라서 RFC 1172와 그 후속 문서들은 좋은 고유성 또는 무작위성 공급원이 없을 때는 옵션을 제안하지 말 것을 권고한다. 그런 구현은 피어의 제안을 승인하거나 거부할 수 있지만, 불량한 생성기로부터 신뢰할 수 있는 로컬 루프 감지를 주장할 수는 없다. 피어는 여전히 자체 감지 능력을 가질 수 있다.

이것은 절제된 형태의 선택성이다. 구현이 어떤 능력을 갖지 않는 것은 허용된다. 그러나 약한 증거를 강한 증거로 광고할 권리는 없다.

거부는 다른 주체를 드러낼 수 있다

이 옵션은 상호적 의무도 부과한다. 매직 넘버를 제안하는 구현은 피어가 같은 옵션을 제안할 때 그것을 거부해서는 안 된다.

이 규칙 덕분에 수신한 Configure-Reject는 이례적으로 많은 정보를 담는다. 옵션을 제안하는 규격 준수 구현은 자신의 반사된 제안에 응답하여 그런 거부를 생성하지 않는다. 따라서 들어오는 거부는 같은 로컬 동작이 되돌아온 것이 아니라 다른 규격 준수 주체가 있음을 가리킨다.

RFC 1661은 제안자가 협상이 성공한 것처럼 진행하되, 피어가 매직 넘버를 사용하지 않을 것임을 인식해야 한다고 말한다. 이것은 양 끝이 동일한 능력을 협상했다는 선언이 아니다. 상대가 옵션을 거부하더라도 유용한 결과를 보존하기 위한 방법이다.

이 추론은 그 모델에 의해 한정된다. 거부는 서명이 아니며, 공격자는 상태 기계가 상상한 규격 준수 피어처럼 행동할 의무가 없다. 이 결과는 구별 가능한 프로토콜 행동에 관한 것이며, 검증된 조직적 신원에 관한 것이 아니다.

응답은 응답 송신자의 번호를 담는다

협상이 완료되면 로컬 매직 넘버는 엔드포인트의 LCP Echo-Request, Echo-Reply 및 Discard-Request 패킷에 나타난다. 각 송신자는 자신의 마커를 공급한다.

Echo-Reply는 교환을 연관 짓기 위해 요청의 Identifier를 복사한다. 그렇다고 요청자의 매직 넘버까지 복사한다는 뜻은 아니다. 두 필드는 서로 다른 역할을 한다. 하나는 응답을 요청과 연관 짓고, 다른 하나는 송신 엔드포인트의 협상된 상태를 반영한다.

이 구별은 '에코'라는 단어가 모든 것이 그대로 되돌아와야 한다는 직관을 유도하기 때문에 특히 중요하다. 여기서 관련된 수신 진단 트래픽에서 로컬 마커가 그대로 있는 것은 바로 반사를 가리킬 수 있는 것이다.

이 메시지들에는 상태 경계도 있다. Echo 요청과 응답은 LCP Opened 상태에서만 전송되며, 그 상태에서 수신된 Echo-Request는 응답을 요구한다. 이들은 협상 전에 임의로 사용할 수 있는 프로브가 아니다. Discard-Request는 싱크 연산이며 어떤 응답도 만들지 않는다.

매직 넘버 협상이 성공할 때까지는 해당 진단 필드가 0으로 전송된다. 이 합법적인 기본값은 구성 옵션 안에서 제안되는 불법적인 0과 혼동되어서는 안 된다. 운영 중에는 피어의 기대 값, 또는 그 유효한 미협상 0은 로컬 엔드포인트 자신의 값과 다른 증거이다. 무관한 값은 다른 피어와 통신하고 있음을 시사한다.

이 분류들 중 어느 것도 IP 경로가 동작한다는 것, 서비스가 건강하다는 것, 또는 물리적 고장의 특정 위치를 증명하지 않는다. 이들은 링크 제어 관찰이다.

번호는 자격 증명이 아니다

IANA PPP 레지스트리는 매직 넘버를 LCP 구성 옵션 유형 5로 식별한다. 이 옵션은 유형과 길이를 포함해 6옥텟을 차지하며, 선택된 값에 4옥텟이 남는다. Authentication-Protocol은 별개의 옵션으로 유형 3이다.

레지스트리는 옵션 유형에 공유된 의미를 할당한다. 각 엔드포인트의 매직 넘버를 할당하지는 않는다. 운영자는 새로운 로컬 마커를 선택하기 전에 전역 예약을 구할 필요가 없으며, 레지스트리 항목은 특정 링크가 이 옵션을 지원한다는 증거를 제공하지 않는다.

인증에는 다른 기반이 필요하다. 1996년 8월의 CHAP을 기술한RFC 1994는 챌린지와 공유 비밀을 계산된 응답에 사용한다. 이 역사적 대비는 책임의 분리를 보여주며, 오늘날 레거시 인증 알고리즘을 배포하라는 권고가 아니다.

매직 넘버는 비밀에 의존하는 증명이 아니라 가시적인 상태이다. 프레임 검사, 로컬적으로 구별되는 마커, 인증된 피어는 결코 하나의 안심되는 '링크 양호' 라벨로 합쳐져서는 안 된다.

감지는 정책보다 먼저 끝난다

RFC 1661은 복구 절차를 특정하지 않고 남겨둔다. 링크를 Down으로 취급하고 다시 여는 것, 또는 상태가 허용하는 곳에서 Echo 트래픽으로 반사의 끝을 관찰하는 것 같은 가능성을 기술한다. 하나의 재시작 횟수나 하나의 보편적 타임아웃을 강제하지 않는다.

이 경계는 그 설계의 경제성의 일부이다. 두 엔드포인트는 협상을 해석하기 위한 공통 규칙이 필요하다. 그러나 반드시 동일한 운영 비용이나 이상 징후에 대한 동일한 응답이 필요하지는 않다.

작은 번호는 엔드포인트들이 절제된 질문을 던지도록 도왔다. 이것이 다른 주체의 선택에 대한 증가인가, 아니면 내 자신의 귀환인가? 그 유용성은 여러 더 큰 질문에 함축으로 답하기를 거부하는 데 의존했다.