요약

  • RFC 3318은 정책 역할 조합(role-combination)이*로 시작할 수 있도록 허용했으므로, 하나의 재사용 가능한 규칙이 필수 역할은 공유하면서 임의 개수의 추가 역할을 가진 인터페이스에 일치할 수 있었습니다.
  • 이 압축은 우선순위를 정의하지 않았습니다. 일치하는 여러 정책이 충돌하는 경우 PDP가 이를 해결해야 했고, PEP는 해결되지 않은 충돌에 대해 로컬 정책을 임의로 만드는 대신 거부해야 했습니다.

구성 시스템에서 반복은 눈에 보이지만 모호성은 그렇지 않습니다. 거의 동일한 인터페이스 규칙이 수천 개씩 있으면 비용이 많이 드는 것처럼 보이기 때문에 설계자들은 공통 부분을 한 번만 말해주는 추상화를 찾습니다. RFC 3318은 역할(roles)이라는 추상화를 제공했습니다. 그리고 이 압축의 대가를 이례적으로 정밀하게 기록했습니다. 와일드카드가 하나의 인터페이스를 둘 이상의 정책과 일치시키는 순간, 그 충돌을 책임지는 주체가 여전히 존재해야 했습니다.

이 문서는 COPS-PR 주변에서 사용되는 프레임워크 정책 정보 베이스(Framework Policy Information Base)를 정의했습니다. PDP(Policy Decision Point, 정책 결정 지점)는 프로비저닝 정보를 선택했습니다. PEP(Policy Enforcement Point, 정책 집행 지점)는 그 정보를 수용하고 집행하는 장치를 대표했습니다. SPPI는 프로비저닝 클래스와 인스턴스의 언어를 제공했습니다. RFC 3318은 역할, 역량 집합(capability sets), 상태 화신(state incarnations), 제한 사항 및 오류에 관한 공통 어휘를 추가했습니다.

역할은 단순히 인터페이스에 연결된 문자열이었습니다.finance,manager,Backbone_interface또는 기능을 설명하는 다른 표현일 수 있었습니다. 하나의 인터페이스는 여러 역할을 가질 수 있었습니다. 정책 인스턴스는 역할 조합을 담았고, 적용 가능성은 그 조합을 인터페이스의 역할 집합과 대조하는 데 달려 있었습니다. 이 간접 참조가 유용했던 이유는 중앙 정책이 어느 벤더가 한 포트를Gi0/1이라고 부르고 다른 벤더가 다른 로컬 식별자를 쓰는지 알 필요가 없기 때문이었습니다.

이 표현은 일반적인 태그 목록보다 엄격했습니다. 비교는 대소문자를 구분했습니다. 조합 내의 역할은 ASCII 값 기준으로 사전순으로 정렬되었습니다.a+b는 하나의 집합에 대한 유효한 표현이었고,b+a는 다른 집합의 이름이 아니라 같은 집합의 잘못된 표현이었습니다. 역할이 없는 인터페이스는null조합을 가졌습니다. 이러한 세부 사항은 두 개의 종단점이 집합을 어떻게 출력할지 먼저 협상하지 않고도 비교할 수 있는 정규 형태를 만들었습니다.

그리고 별표가 등장했습니다.install또는install-notify접근 권한을 가진 정책 클래스에서*+a+b와 같은 조합은a와b를 포함하고, 그 외에 0개 이상의 다른 역할을 가진 인터페이스에 일치했습니다. 별표 자체는 인터페이스 역할로 보고될 수 없었고, 이름 내부의 부분 문자열 와일드카드도 아니었습니다. 그 역할은 집합 포함이었습니다. RFC 3318의 예에 따르면*+b+e+g는a+b+c+e+f+g에 일치합니다.

이는 정책 양을 줄였습니다. 세 개의 인터페이스가 모두 역할A와B를 가지면서 각각R1,R2,R3를 추가로 가진다면, 하나의*+A+B정책이 세 인터페이스를 모두 커버할 수 있었습니다. PDP는 추가 역할만 다른 세 개의 복사본을 설치할 필요가 없었습니다. 이 추상화는 구성 바이트를 절약하고 의도를 더 쉽게 표현할 수 있게 했습니다.

그러나 포함은 우선순위가 아닙니다. RFC는 인터페이스가 둘 이상의 와일드카드 역할 조합에 일치할 수 있음을 명시적으로 허용했습니다. 두 일치는 서로 호환될 수도 있지만, 양쪽 모두 상호 호환되지 않는 처리를 지정하려 할 수도 있었습니다. PDP는 정책을 보내기 전에 충돌을 해결해야 했습니다. 컨트롤러 실수나 장치별 제약 때문에 PDP가 충돌하는 여러 정책을 보낸다면, PEP는 설치를 거부하고 오류를 반환해야 했습니다.

finance와 manager 예제는 권한의 위치를 더욱 명확하게 보여줍니다. 처음에 두 인터페이스는 하나는finance를, 다른 하나는manager를 가질 수 있었습니다. 어느 한 finance 사용자가 manager가 되면, 해당 인터페이스는 새 조합finance+manager를 보고했습니다. PDP는 manager 정책이 우선한다고 결정하거나, finance 관리자를 위한 별도의 DSCP 마킹 같은 세 번째 정책을 만들 수 있었습니다. 하지만 그럴 수 없던 것은, 두 오래된 정책을 병합하여 PEP가 스스로 답을 만들어내도록 방치하는 것이었습니다. RFC 3318은 PEP가 새 조합에 대한 정책을 구성하도록 요구되지도, 허용되지도 않는다고 명시했습니다.

이 문장은 유혹적이지만 위험한 지름길을 차단합니다. 패킷에 가까운 장치는 모든 입력을 갖고 있어 규칙을 결합하기에 가장 적합한 위치처럼 보일 수 있습니다. 그러나 로컬 합성은 집행을 의사 결정으로 바꿔버립니다. 서로 다른 벤더가 같은 입력을 다르게 병합할 수 있고, 중앙 컨트롤러는 더 이상 어느 정책이 결과를 승인했는지 설명할 수 없게 됩니다. 거부는 경계를 지켜주었습니다. 실패한 결정은 가시적으로 보였지만, 임의로 만든 결정은 성공처럼 보일 수 있었습니다.

역할 변경에도 순서가 있었습니다. PEP는 전체 요청 상태(full request state)에서 역할 조합과 인터페이스 연관 정보를 보고했습니다. PDP는 이후 요청되지 않은(unsolicited) 결정으로 새 연관 정보를 보낼 수 있었습니다. PEP가 이를 처리하면 먼저 성공을 반환한 다음, 열린 컨텍스트에 대해 갱신된 전체 상태 요청을 보냈습니다. PDP는 그 성공 이전에 새 상태를 가정해서는 안 되었습니다. 전환 기간 동안 다른 결정들은 여전히 이전 역할을 반영할 수 있었습니다.

따라서 역할의 이름이 바뀌었다는 사실만으로 모든 의존 정책이 같은 순간에 변경되었다고 증명할 수는 없었습니다. 별개의 사실들이 있었습니다. 의도된 역할 할당, 장치가 그 할당을 수용했다는 사실, 갱신된 요청 상태, PDP의 대체 결정, 그리고 PEP의 보고가 그것입니다. RFC 3084는 더 넓은 요청·결정·보고 메커니즘을 제공했고, RFC 3159는 PIB 모델링 규칙을 제공했습니다. 역할 레이블은 정책에 대한 입력이지, 결과적인 패킷 처리에 대한 영수증이 아니었기 때문에 이 연쇄가 중요했습니다.

보안은 이 교환을 보호했지만 없는 우선순위 규칙을 대신할 수는 없었습니다. RFC 3318은 구성 가능한 정보가 치명적으로 잘못 구성될 수 있다고 경고하고 PDP와 PEP 사이의 보호를 지시했습니다. 인증은 두 개의 일치하는 정책을 누가 보냈는지 보여줄 수 있었습니다. 암호화는 전송 중에 그것들을 숨길 수 있었습니다. 그러나 어느 쪽도finance와manager중 어느 것이 이겨야 하는지, 또는 그 조합이 특정 장치에서 안전한지를 결정할 수는 없었습니다.

이 아키텍처는 나중에 형식적인 의미에서도 역사적(Historic)이 되었습니다. 2016년 IESG는 RFC 3318, COPS-PR, SPPI를 Historic으로 이동시키며 배포가 제한적이었고 네트워크 관리 작업이 NETCONF와 YANG으로 이동했다고 밝혔습니다. 이 기록은 역할 메커니즘이 일반적인 실무가 되었다는 주장을 제한합니다. 그러나 충돌 문제를 쓸모없게 만들지는 않습니다.

여기서 지속되는 핵심은*+a+b의 문법이 아닙니다. 압축과 권한의 분리입니다. 와일드카드는 규칙 수를 줄일 수 있지만, 겹치는 규칙의 의미를 결정할 수는 없습니다. RFC 3318은 그 결정의 위치를 컨트롤러로 지정했고, 결정이 불완전할 때 장치의 안전한 답으로 거부를 지정했습니다. 이는 별표가 정책을 단순하게 만들었다는 주장보다 훨씬 유용한 역사적 영수증입니다.

출처:RFC 3318,RFC 3084,RFC 3159, 그리고2016년 IESG 상태 변경 기록.