요약

  • RFC 2516은 지점 간 PPP 세션 앞에 상태 없는 디스커버리 단계를 두었습니다. 양단은 세션이 성립된 이후에만 가상 인터페이스 자원을 할당했습니다.
  • 선택 사항인 AC-Cookie는 컨센트레이터가 자신이 보낸 값을 소스 주소가 그대로 돌려줄 수 있는지 확인하는 데 쓸 수 있었고,Host-Uniq와Relay-Session-Id는 각각 호스트 소유 및 릴레이 소유의 상관 관계 역할을 담당했습니다.
  • 이 토큰들은 유한한 패킷 맥락만을 담았습니다. 그 어느 것도 사람을 인증하거나 이후의 PPP 구성, 트래픽, 상용 서비스의 존재를 입증하지 않았습니다.

세션 테이블이 없는 브로드캐스트

1999년 2월, RFC 2516은 다대다 접속을 위해 만들어진 이더넷을 PPP가 어떻게 통과할 수 있는지를 기술했습니다. 호스트는 PADI를 브로드캐스트로 보내고, 이를 서비스할 수 있는 컨센트레이터들은 PADO로 응답할 수 있었습니다. 호스트는 하나의 제안을 선택해 해당 컨센트레이터로 하나의 유니캐스트 PADR을 보냈습니다. 이어서 PADS가 수락된 서비스를 확인하고 세션 식별자를 제공했습니다. RFC는 이 단계들을 디스커버리(Discovery)와 PPP 세션(PPP Session)으로 부르며 그 경계를 특히 명확히 했습니다. 디스커버리는 PPP 세션이 성립되기 전까지는 상태를 갖지 않습니다. 그 시점에 호스트와 액세스 컨센트레이터 모두 PPP 가상 인터페이스를 위한 자원을 할당해야 했습니다.

이 절차는 단순히 더 예쁜 핸드셰이크가 아니었습니다. 공유 이더넷은 하나의 요청을 여러 장비에 전달할 수 있는 반면, 지점 간 PPP 종단은 선택된 하나의 피어에 귀속되는 상태가 필요했습니다. 가상 인터페이스 할당을 미룬다는 것은 브로드캐스트 요청이나 제안 자체로는 컨센트레이터가 세션 자원을 약속할 필요가 없다는 뜻이었습니다. 이 프로토콜은 디스커버리가 어떤 처리도 소비하지 않는다고 주장하지 않았습니다. 다만 더 오래 지속되는 PPP 세션 상태 주변에 선을 그은 것입니다.

값은 반드시 되돌아와야 했다

RFC 2516은 액세스 컨센트레이터에 선택 사항인 AC-Cookie 태그를 제공했습니다. 컨센트레이터가 PADO에 이 태그를 담아 보냈다면, 호스트는 PADR에서 그 값을 변경 없이 돌려보내야 했습니다. 호스트는 이 바이트를 불투명한 것으로 취급했습니다. RFC는 컨센트레이터가 PADR의 소스 주소를 이용해 그 값을 다시 생성할 수 있도록 권고했습니다. 이를 통해 해당 주소가 되돌아오는 방향으로 도달 가능함을 보여주고, 컨센트레이터가 그 주소에 대한 동시 세션 수를 제한하는 데 도움을 얻을 수 있었습니다.

표준은 호스트 MAC에 대해 컨센트레이터만 아는 키로 HMAC을 적용하는 것을 예시로 들었습니다. 그러나 그 알고리즘이나 보편적인 보호를 요구하지는 않았고, 쿠키가 모든 서비스 거부 공격을 막을 수 없음을 명시적으로 경고했습니다. 이 메커니즘은 제안을 받은 쪽이 그 제안을 되돌려 보낼 수 있음을 확인할 때까지 세션별 자원 할당을 미루는 방법이었지, 어떤 가구나 계정을 누가 통제하는지에 대한 암호학적 단정이 아니었습니다.

다른 태그들은 소유권의 경계를 더 분명하게 했습니다.Host-Uniq는 호스트가 선택한 것으로, 도착하는 PADO나 PADS를 자신의 요청과 연관시키게 해 주었고, 컨센트레이터는 그 의미를 해석하지 않고 바이트를 그대로 반사했습니다.Relay-Session-Id는 중간 릴레이가 추가할 수 있으며 양단에 불투명했고, 양단은 이를 수정 없이 돌려보냈습니다. 각 토큰은 만든 쪽이 경로를 연관 짓는 데 도움이 되었습니다. 그러나 성공적으로 회신되었다고 해서 서로 호환되는 신원이 되는 것은 아니었습니다.

확인 단계가 자원 상태를 바꿨다

수락된 PADS는 0이 아닌 세션 ID와 컨센트레이터가 수락한 서비스 이름을 전달했습니다. 거부된 서비스 이름에는 ID 0과 오류 태그를 담은 PADS가 사용되었습니다. 세션이 성립되면 그 식별자는 고정되지만, RFC는 세션을 튜플로 정의했습니다. 즉, 소스 MAC, 목적지 MAC, SESSION_ID의 조합입니다. 16비트 숫자만 남겨두는 대시보드는 프로토콜 범위의 일부를 버리는 셈입니다.

PADS는 디스커버리를 PPP 세션 단계로 옮겼습니다. 그러나 PADS가 PPP의 이후 링크 제어 프로토콜(LCP) 협상, 선택적 인증, 네트워크 제어 프로토콜 구성을 수행하지는 않았습니다. RFC 1661은 이 단계들을 별도로 기술합니다. 이 글은 페이로드 크기와 RFC 4638의 1492바이트 경계를 다룬 기존 PPPoE 보도를 반복하지 않습니다. 이 글의 주제는 자원 전환과 세 가지 회신 태그의 서로 다른 범위이며, 하류 서비스 전달에 대한 주장이 아닙니다.

쿠키는 되돌아오는 경로의 증거였다

RFC 2516의 설계는 작지만 중요한 구분을 담고 있습니다. 제안은 저비용이고 넓게 노출될 수 있지만, 세션은 특정한 쌍방 자원 약속입니다. 컨센트레이터 소유의 쿠키는 그 약속에 앞서 되돌아오는 경로의 도달 가능성을 시험하는 데 도움을 주었고, 호스트와 릴레이의 토큰은 각자의 상관 관계 맥락을 보존했습니다. 같은 바이트가 패킷 교환을 연관 짓는 데 유용할 수 있지만, 여전히 사람의 신원이나 권한에 대해서는 아무것도 말해주지 않습니다.

이것이 바로 이 표준이 뒷받침하는 역사적 서술입니다. 이 표준은 자원 보호 설계와 그 명시된 한계를 문서화합니다. 그러나 절약된 메모리를 정량화하거나, HMAC 예시를 사용한 특정 구현을 이름으로 밝히거나, 현재의 배포를 입증하거나, 어떤 세션이 인증을 완료했는지 트래픽을 전송했는지 보여주지는 않습니다.

출처:RFC 2516;RFC 1661;RFC 2104;RFC 4638(인접한 페이로드 크기 주제는 여기서 제외).