요약

  • RFC 3518은 PPP BCP에 협상 가능한 Bridge-Control-Packet-Indicator를 추가했다. 활성화하면 송신 측이 인식된 BPDU 및 GARP 계열 프레임을 표시하여 링크가 이를 폐기하거나 심각하게 지연시키지 않도록 했다.
  • C 비트는 로컬 분류를 증명했을 뿐, BPDU의 진위성, 수신 측 수용, 스패닝 트리 수렴 또는 루프 없음을 증명하지 못했다. RFC 자체가 악의적인 피어가 격리되어야 할 루프를 닫을 수 있다고 경고했다.

브리지 제어 프레임은 특이한 영향력을 지닌다. 일반 데이터는 이미 존재하는 포워딩 상태를 따른다. 스패닝 트리 BPDU는 그 상태를 바꿀 수 있다. 어느 브리지가 루트인지, 어느 포트가 포워딩하고 어느 이중 경로가 차단된 채로 남는지. 따라서 제어 트래픽의 지연은 위상에 대한 낡은 인식을 실질적으로 영향을 줄 만큼 오래 유지할 수 있다.

PPP 브리징은 이미 지점 간 링크를 통해 LAN 프레임을 전송하는 방법을 학습한 바 있었다. RFC 1638이 이전 메커니즘을 정의했고, RFC 2878이 브리징 제어 프로토콜(BCP)을 개정했다. 양단의 브리지는 프레이밍과 브리징 특성을 협상한 뒤 PPP를 통해 브리지드 트래픽을 전송할 수 있었다. 2003년 4월에 발표된 RFC 3518은 RFC 2878을 폐기하면서 놀랍도록 협소한 개선만을 더했다.

그 변경 목록은 두 항목을 명시했다. Bridge Control Packet Indicator를 구성 옵션으로 추가하고, 플래그 필드의 이전에 예약되어 있던 한 비트에 새 의미를 부여하는 것. 이러한 절약이 역사적 요점이다. 이 표준은 새로운 스패닝 트리 알고리즘을 발명하지 않았다. 기존 전송 메커니즘 내부에서 제어 프레임을 구별하는 방법을 추가했을 뿐이다.

BCP 옵션 유형 10이 이 인디케이터의 지원을 알렸다. 지원은 기본적으로 비활성화되어 있었다. 피어들이 옵션을 협상하면, 송신 측은 나가는 프레임이 브리지 제어 프레임인 경우에만, 그리고 정확히 그 경우에만 C 비트를 1로 설정해야 했다. 협상하지 않으면 비트는 0으로 유지되어야 했고, 협상하지 않는 시스템은 비트가 설정된 프레임을 송수신할 수 없었다. 이 규칙은 구형 RFC 2878 피어와의 상호운용성을 유지했다.

분류는 프레임 내용에 근거했다. RFC 3518은 스패닝 트리 BPDU와 GARP PDU를 식별하고, IEEE가 할당한 목적지 MAC 주소를 통한 인식을 요구했다. 여기에는 브리지 그룹, 브리지 관리, GMRP 및 GVRP에서 사용하는 주소가 포함되었다. 일단 인식되면, 제어 프레임은 PPP 브리지드 프레임 헤더에 명시적인 신호를 받았다.

운영상의 약속은 처리 방식에 관한 것이었다. 브리지 제어 트래픽은 폐기되거나 유의미하게 지연되어서는 안 된다. RFC 3518은 이 아이디어를 라우팅 업데이트에 높은 IP 우선순위를 부여하는 것에 비유하며, RFC 2474의 차등화 서비스 어휘를 활용했다. 표시된 프레임은 대량 데이터와 맹목적으로 경쟁하는 대신 우선 로컬 큐에 들어갈 수 있었다.

이것은 실제 제어였지만, 로컬 제어였다. 송신 측 분류기가 프레임이 어떤 클래스에 속한다고 판정했다. 협상은 인접 PPP 피어가 플래그를 이해한다는 것을 확립했다. 스케줄러는 그때 링크에서 그 프레임에 유리한 처리를 줄 수 있었다. 이 중 어느 사실도 내용을 인증된 주장으로 검사하거나, 송신 측이 스패닝 트리 도메인에 대한 권한을 가졌음을 확립하거나, 모든 브리지가 일관된 결과에 도달했는지 관찰하지 않았다.

근거를 따라가면 이 구별이 더 명확해진다. IANA 레지스트리 항목은 옵션 번호 10이 할당되었음을 증명한다. 성공적인 옵션 교환은 두 피어 간의 공유 능력을 증명한다. C 비트는 송신 구현이 무엇을 분류했는지 증명한다. 도착은 인접 피어까지의 전송을 증명한다. BPDU를 어떻게 사용할지는 수신 브리지의 제어 프로세스만이 결정할 수 있고, 수렴과 차단된 이중 경로에 대한 주장은 도메인 전반에 걸친 관찰만이 뒷받침할 수 있다.

BCP의Opened상태도 같은 원칙에 속한다. PPP의 RFC 1661 상태 머신은 관련 Configure-Ack 교환 이후에Opened를 사용한다. RFC 3518은 또한 특정 호환 불가능한 선택, 즉 해결되지 않은 스패닝 트리 프로토콜 불일치를 포함하는 경우 BCP가 그 상태에 들어가지 못하도록 했다. 그런 협상을 통과한다는 것은 양단이 수용 가능한 구성 교집합을 찾았다는 뜻이다. 그들의 뒤에 있는 모든 브리지와 링크가 검토되었다는 뜻은 아니다.

RFC의 보안 절은 그 비약을 거부한다. 악의적인 피어와 함께 올라오는 브리지드 링크는 포워딩된 멀티캐스트 트래픽을 통해 네트워크 정보를 유출할 수 있다. 더 나쁘게는, 그 피어가 감지되어 격리되었어야 할 루프를 닫거나 악의적인 부하를 제공함으로써 서비스 거부를 일으킬 수 있다. 협상되고 표시된 제어 경로 자체가 위상 안전을 증명한다면, 이 경고는 말이 되지 않았을 것이다.

RFC 3518은 외부 기기나 침해된 기기가 나타날 수 있는 경우 LCP 시작 시 PPP 인증을 권고했다. RFC 1994에 명시된 CHAP는 재사용 가능한 암호를 반복 전송하지 않으면서 피어를 챌린지할 수 있다. 인증은 "이 지점 간 링크에 어떤 피어가 있는가?"라는 질문에 대한 답을 개선한다. 그래도 "알려진 모든 브리지 사실이 정확한가?" 또는 "전체 위상이 루프 없이 수렴했는가?"에는 답할 수 없다. 신원은 신뢰를 좁힌다. 운영 증거를 대체하지는 않는다.

다른 PPP 메커니즘도 같은 경계를 지킨다. RFC 1990의 멀티링크 PPP는 여러 구성 링크에 걸쳐 트래픽을 분할하고 순서를 매길 수 있다. RFC 2686의 멀티클래스 멀티링크 PPP는 선택된 클래스의 지연을 줄일 수 있다. 이러한 기능들은 표시된 제어 프레임이 얼마나 신속하게 이동하는지에 영향을 준다. 신속한 전송이 제어 알고리즘이 프레임을 수용했거나 안전한 데이터 플레인을 만들었다는 증명으로 변하지는 않는다.

구형 형식 예외조차 유익하다. RFC 3518은 구형 BCP 브리지를 위해 하위 호환되는 BPDU 형식을 유지하면서, 일반적으로 브리지 및 GARP PDU를 공유 브리지드 프레임 형식으로 전송했다. 상호운용성은 피어가 파싱할 수 있는 것을 인식하는 것을 요구했다. 하나의 프레이밍 선택이 전체 스패닝 트리 도메인의 상태를 서술한다고 가장하는 것을 요구하지는 않았다.

RFC 7042는 이후 IETF와 IEEE 802 매개변수 사이의 행정 경계를 문서화했고, PPP Numbers 레지스트리는 BCP 옵션 10을 계속 기록한다. 이것들은 권한 기록이다. 구현들이 만날 수 있도록 이름과 번호를 안정화한다. 특정 프레임이 진짜인지, 제때 도착했는지, 수용되었는지, 효과적이었는지는 보고할 수 없다.

RFC 3518이 중요한 이유는 그 소박한 비트가 사소하지도 마법적이지도 않았기 때문이다. 차등 처리가 도움이 될 수 있는 정확한 인터페이스에서 제어 클래스를 노출하면서, 브리지 알고리즘과 위상 증거는 그 인터페이스 바깥에 남겨두었다. 표준은 권한을 국지화했다. 여기서 분류하고, 여기서 우선순위를 두고, 이 피어와 협상하라.

역사적 오류는 그 표시를 판정으로 읽는 것이다. 제어 프레임은 올바르게 인식되고 신속하게 전송되면서도 낡은 정보를 실어 나를 수 있고, 침해된 피어에서 올 수 있고, 잘못된 행정 도메인에 도달할 수 있으며, 아직 수렴하지 않은 위상 속에 도착할 수 있다. C 비트는 프레임의 용도를 말한다. 프레임이 서술하는 세계가 안전하다는 말은 하지 않는다.

출처