요약

  • RFC 3437은 L2TP 액세스 컨센트레이터가 원하는 LCP 옵션과 허용되는 LCP 옵션을 원격 네트워크 서버에 보내도록 하고, 협상이 끝난 뒤 서버가 마지막으로 보내고 받은 Configure-Request를 되돌려 보내도록 요구했습니다.
  • 이 네 개의 AVP는 제어가 아니라 로컬 지식과 증거를 전송했습니다. 선호는 허가가 아니었고, 패킷 사본은 서비스 결과가 아니었으며, 필수 지원은 호환성을 가시성과 맞바꿀 수 있었습니다.

회선 옆의 기계가 세션을 소유하지는 않았다

다이얼 또는 액세스 회선에는 터널 반대편 끝에서 보기 어려운 사실들이 있습니다. 특정 최대 수신 단위(MRU)를 요구하거나, 특정 제어 문자를 이스케이프하거나, PPP 필드를 압축하거나, 대체 프레임 검사 시퀀스를 사용할 수도 있습니다. L2TP에서 L2TP 액세스 컨센트레이터(LAC)는 그 물리 매체 바로 옆에 있었습니다. L2TP 네트워크 서버(LNS)는 대개 멀리 떨어져 있으며, 논리적 PPP 세션을 종단하고 링크 제어 프로토콜(LCP)을 수행했습니다.

이 분담은 유용했지만 지식과 권한을 나누어 버렸습니다. 기본L2TP는 동기 또는 비동기, 디지털 또는 아날로그 같은 대략적인 기술만을 제공했습니다. 그것은 로컬 프레이밍 인터페이스에 대한 완전한 설명이 아니었습니다. LNS는 협상을 소유하면서도 LAC가 직접 관찰할 수 있는 세부 사항을 놓칠 수 있었습니다.

2002년 12월에 발표된RFC 3437은 이 간극 위에 좁은 다리를 놓았습니다.본문,RFC 편집기 기록,Datatracker 페이지,문서 이력,참고 문헌,이후 인용,정오표 검색이 문서 기록을 확립합니다. 그러나 어떤 것도 특정 벤더가 이 확장을 구현했거나 가입자 세션이 성공했다는 증거는 되지 못합니다.

프록시 LCP는 유용했지만 불완전했다

PPP는 LCP Configure-Request, 승인, 거부를 사용해 링크 동작을 확립했습니다.HDLC 유사 프레이밍의 PPP는 ACCM, PFC, ACFC, FCS 동작 같은 옵션을 회선 수준에서 구체화했습니다.LCP 확장과CHAP는 링크 협상이 단순한 프레이밍을 넘어설 수 있음을 보여 줍니다.

LAC는 호출을 LNS에 넘기기 전에 프록시 LCP를 수행할 수 있었습니다. 이는 시간을 절약하고 매체에 가장 가까운 장치가 로컬 매개변수를 정하도록 했습니다. 그러나 프록시가 모든 것을 안전하게 결정할 수는 없었습니다. 인증 정책은 LNS의 몫이었고, MRU는 양쪽 끝에서 제약을 받을 수 있었습니다. 더 근본적으로 PPP 피어는 설정 후 LCP를 다시 열 수 있었습니다. 접수 시점에 찍힌 스냅샷은 세션이 살아 있는 동안 낡아질 수 있었습니다.

그래서 RFC 3437은 LAC가 기존 프록시 LCP AVP를 생략하고 LNS가 직접 협상하도록 강제할 수 있도록 허용했습니다. 새 AVP가 프록시 결과와 공존하는 것도 허용했습니다. 이 설계는 어느 워크플로가 보편적으로 우월하다고 선언하지 않았고, 정보 경계를 명시적으로 만들었습니다.

네 개의 기록, 네 가지 의미

LAC는 ICCN 또는 OCCN 메시지에LCP Want Options(속성 49)와LCP Allow Options(속성 50)를 넣을 수 있었습니다. Want는 선호, 즉 접속 측이 LNS가 협상하기를 바라는 옵션이었습니다. Allow는 경계, 즉 물리 인터페이스가 지원할 수 있는 옵션이었습니다. 한 옵션은 원하면서 허용되지 않을 수도, 허용되면서 피어에게 거부될 수도 있었습니다. 둘을 하나의 "기능" 필드로 합치면 이 확장이 도입한 정책 구분 자체가 지워집니다.

LCP가 끝난 뒤 LNS는 Set-Link-Info로LNS Last Sent LCP Confreq(속성 51)와LNS Last Received LCP Confreq(속성 52)를 보냈습니다. 각 AVP는 Code 필드로 시작하는 완전한 LCP 패킷을 담았습니다. 이들은 교환의 양쪽에서 마지막 Configure-Request가 실제로 어떠했는지를 LAC에게 알려 주었습니다.

방향이 중요했습니다. Want와 Allow는 물리 에지의 지식을 세션 제어자 쪽으로 옮겼고, 두 Confreq 기록은 협상 증거를 되돌려 보냈습니다. LAC가 어느 한쪽의 전방 AVP를 보낸다면 역방향 AVP를 받아 처리할 수 있어야 했습니다. 이는 상호 대조 루프였지, 서로 바꿔 쓸 수 있는 네 개의 플래그가 아니었습니다.

돌아온 패킷은 그래도 인증, 네트워크 계층 구성, 계정 처리, 도달 가능성, 애플리케이션 성공을 증명하지 못했습니다. 원하는 옵션 목록보다는 강한 증거였고, 완성된 사용자 결과보다는 약한 증거였습니다.

선택적 호환성이 증거를 숨길 수 있었다

네 AVP는 기본적으로 모두 비필수였습니다. 오래된 피어는 지원하지 않는 선택적 AVP를 무시하고 계속할 수 있었습니다. 대신 M 비트를 설정하면 피어가 확장을 이해하지 못할 경우 세션을 종료하도록 요구할 수 있었습니다. RFC 3437은 확장 없이 운영하는 것이 완전히 허용될 수 없는 경우가 아니라면 그 선택을 권하지 않았습니다.

이 경고는 운영상의 타협을 드러냅니다. 선택 가능성은 가용성을 보호했지만 접속 에지가 원하는 증거를 놓치게 만들 수 있었습니다. 필수 지원은 지원 부재를 치명적으로 만드는 방식으로만 강제력을 높였습니다. 운영자는 구성된 AVP가 도착했다고 가정하는 대신 협상된 지원을 관찰해야 했습니다.

저자들은 또한 프록시 LCP 값을 재사용하는 대신 새 속성 번호를 배정했습니다. 오래된 구현은 기존 AVP를 인식하면서도 구 규격이 허용하지 않는 메시지 유형에 나타나면 거부할 수 있었습니다. 새 번호는 호환성 장치였습니다. 알 수 없는 선택적 데이터가, 명목상 있을 수 없는 자리의 익숙한 데이터보다 안전했습니다.IANA L2TP 레지스트리가 이 배정을 기록하고,PPP Numbers 레지스트리가 더 넓은 협상 어휘를 기록합니다. 레지스트리 항목은 조정의 증거이지 배포의 증거가 아닙니다.

정보 전송은 정보를 노출했다

보안 절은 짧았지만 솔직했습니다. 원하는, 허용되는, 협상된 링크 매개변수는 인터페이스 특성을 드러내어 관찰자가 토폴로지를 추론하도록 도울 수 있었습니다. 저자들은 유사한 사실이 이미 터널을 통해 전달되는 LCP 패킷에서 보일 수 있음을 지적했습니다. RFC 3437은 정보가 나타나는 형식과 지점을 바꿨을 뿐, 근본 사실 자체를 만들어 낸 것은 아니었습니다.

관련 문서들은 경계가 어디에 있었는지 보여 줍니다.RFC 3145는 L2TP 연결 해제 사유 정보를 다루며, 분리된 종단들 사이에서 의미를 보존하려는 또 하나의 시도였습니다.RFC 3193은 IPsec 위의 L2TP를 규정하고 서로 다른 상태 및 MTU 문제를 노출했습니다.RFC 3438은 MPLS 위의 PPP 터널링을 다루었고,RFC 3931은 이후 L2TP 버전 3를 PPP 너머로 일반화했습니다. 어느 것도 RFC 3437의 AVP를 기밀성이나 서비스 제공의 증명으로 바꾸지 못합니다.

분리된 제어 표면을 위한 작은 프로토콜

Lu Heng의현실 계층논의는 수신 사슬을 명확히 합니다. Want는 선언된 의도이고, Allow는 진술된 제약이며, Configure-Request는 관찰된 프로토콜 메시지입니다. 완료된 LCP는 링크 상태이고, 인증과 유용한 트래픽은 그 이후의 사건입니다. 각각은 자신만의 기록을 마땅히 가져야 합니다.

이 사례는 또한구현 코드 우선원칙을 뒷받침합니다. 종단이 알 수 없는 AVP, 다시 열린 LCP, 오류 경로에서 살아남는지는 구현 증거만이 보여 줄 수 있습니다.최소 초기 사양관점은 네 AVP의 절약을 설명합니다. 이 프로토콜은 필요한 최소한의 지식만 터널을 넘겼고, 로컬 정책과 도입은 자발적으로 남겨 두었습니다. 이들은 사후의 편집적 독해이며, 저자들의 동기에 대한 주장이 아닙니다.

RFC 3437의 오래가는 교훈은 원격 제어가 틀렸다는 것이 아닙니다. 원격 제어는 로컬 제약과 반환된 증거가 구별 가능하게 남아 있을 때에만 신뢰할 수 있다는 것입니다. 물리 링크는 터널 종단이 볼 수 없는 것을 알고 있었습니다. 표준은 그렇지 않은 척하는 대신, 각 측에 자신이 아는 것을 정확히 말할 방법을 주었습니다.

출처