GDOI: 키 서버가 데이터 경로에 없는 이유

그룹 키 서버는 정책과 키를 구성원에게 배포하고, 구성원이 직접 트래픽을 보호한다. 이 문장은 설계가 컨트롤러를 모든 보호 패킷의 중계 장치로 취급할 때까지는 형식적인 말처럼 들리지만, 그렇게 되면 토폴로지에 필요 없던 홉이 하나 늘고 트래픽 경로는 상태만 배포하도록 만들어진 장치에 의존하게 된다. 키 서버가 어디에 있고 데이터가 어디로 흐르는지를 말하는 것은 서로 다른 두 그림이며, GDOI는 바로 그 차이를 중심으로 만들어졌다. 이를 거꾸로 이해하면 무엇을 감시하고 무엇을 확장하는지가 달라지므로 작은 모델링 오류가 아니다. 아래 절들은 프로토콜 자체의 구분을 따른다.

두 가지 보안 상태

RFC 6407는 구성원이 정책과 키 자료를 요청하는 풀 교환과, 승인된 구성원에게 정책과 키 갱신을 배포하는 푸시 교환을 정의한다. 둘 다 보안 연계를 관리한다. 어느 것도 애플리케이션의 데이터 스트림이 아니므로, 성공한 교환은 제어 채널이 동작했다는 것만 증명한다. 구성원은 깨끗하게 등록하고 유효한 키를 보유해도 데이터 정책이 틀리면 트래픽을 보호하거나 전달하지 못할 수 있다. 어느 교환이 무엇을 나르는지 알면 이 두 실패는 전혀 다르게 보인다.

표준은 또한 키 갱신 메시지를 보호하는 재키 보안 연계를, 구성원이 트래픽을 어떻게 보호하는지 설명하는 데이터 보안 연계와 별도로 명명한다.

그림이 아니라 교환을 따라가라

각 메시지가 무엇을 위한 것인지 보라. 등록은 어느 구성원이 묻는지 컨트롤러에 알리고 상태를 세우며, 재키는 정책이나 키가 바뀌었음을 구성원에게 알리고, 그다음 보호된 애플리케이션 트래픽이 설치된 데이터 보안 연계를 사용해 구성원 사이를 흐른다. 컨트롤러 주소는 처음 두 교환에 나타나며 세 번째에는 전혀 나타날 필요가 없다.

그래서 물리적 인접성으로 그린 인터페이스 그림은 여기서 오해를 부른다. 컨트롤러의 인터페이스는 제어 원천이며, 모든 암호화 패킷의 다음 홉이 자동으로 되는 것은 아니다.

남겨 둘 가치가 있는 세 가지 기록

구성원의 인증된 등록과 도달할 수 있는 제어 원천, 이후 키 갱신을 전달하는 경로, 보호된 애플리케이션 트래픽을 나르는 경로와 연결을 적어 둔다. 세 기록, 세 소유자이며 어느 하나가 고장 나도 증상은 다르다. 두 기록이 모두 없으면, 등록한 뒤 갱신을 한 번도 받지 못한 구성원은 오래된 정책으로 등록한 구성원과 구별되지 않는다.

이것들은 누군가의 기억이 아니라 구성 옆에 둔다. 구성원 변경은 드물어서 필요할 때쯤이면 근거는 늘 사라져 있다.

인터페이스, 서비스 연결, 처리 경로

서비스 기반 게이트웨이에는, 물리 언더레이 주소가 로컬 서비스 연결과 같지 않고 트래픽이 IPsec 처리 경로에 어떻게 도달하는지를 플랫폼 구현이 결정한다는 차이가 하나 더 있다. 오류 메시지가 서비스 인터페이스 규칙을 언급했다고 서비스를 물리 인터페이스로 옮기거나 무관한 변환을 추가하는 것은 수리의 옷을 입은 추측이다.

서비스 연결이 트래픽을 어떻게 받는지는 플랫폼 자체 문서를 읽어라. 프로토콜이 표준이어도 메커니즘은 공급업체별이다.

표준화된 프로토콜 메시지도 공급업체 간 호환성을 확립하지 않는다. 두 구현이 상호 운용된다고 가정하기 전에 필요한 기능, 정책과 연계 속성, 인증 방법, 정확한 플랫폼과 릴리스를 비교하라.

제어 가용성과 데이터 포워딩은 별개의 점검

일상 운영, 구성원 변경, 키 갱신을 위해 컨트롤러 도달성을 계획하라. 이미 설치된 상태에서 성공하는 애플리케이션 교환은 다음 등록이나 재키가 구성원에게 도달할 수 있음을 증명하지 않으며, 그 격차는 보통 몇 시간 뒤 새 구성원을 받지 않는 터널로 나타난다. 동작하는 세션만이 아니라 새 등록을 시험하라.

그다음 컨트롤러를 배제한 채 포워딩을 따로 시험하라. 두 점검, 두 결과, 그리고 어느 절반이 고장 났는지에 대한 훨씬 짧은 논쟁.