다이어미터 (프로토콜)

다이어미터 프로토콜(영어: diameter protocol)은 컴퓨터 네트워크에서 사용되는 인증(authentication), 인가(authorization) 및 과금(accounting) 프로토콜이다. 다이어미터 프로토콜 보다 앞서 사용된 RADIUS 프로토콜에서 훨씬 더 유용하게 진화되었고 RADIUS 프로토콜을 대체하고 있다.
다이어미터 애플리케이션은 새로운 명령어나 확장 가능 인증 프로토콜(Extensible Authentication Protocol, EAP)과 함께 사용하기 위한 속성 등을 추가하여 확장할 수 있다.

역사

다이어미터 프로토콜은 1998년 RADIUS의 한계를 극복할 수있는 인증, 인가 및 과금(Authentication, Authorization and Accounting, AAA) 용 프래임 웍을 제공할 목적으로 팻 R. 칼호운, 글렌 존 그리고 핑팬에 의해 처음 개발되었다. RADIUS는 신뢰성, 확장성, 보완 및 유연성에 문제를 가지고 있었다. RADIUS는 원격 접속, IP 이동성과 정책 제어를 효과적으로 처리할 수 없다. 다이어미터 프로토콜은 정책, AAA 및 자원 제어를 수행하기 위해 클라이언트에 의해 사용되는 정책 프로토콜을 정의한다. 다이어미터 프로토콜은 정책, AAA 및 자원 제어를 수행하기 위해 클라이언트에 의해 사용되는 정책 프로토콜을 정의한다. 이것은 하나의 서버가 다양한 서비스를 위한 정책들의 처리가 가능하도록 했다.
RADIUS와 마찬가지로 다이어미터는 AAA 기능을 제공하지만 UDP 대신 TCP와 SCTP를 사용한다. 그러므로 통신 장애의 감지를 위한 논리 구조가 다이어미터 자체에 포함되어 있지 않다. 다이어미터 프로토콜은 3세대 파트너쉽 프로젝트(3rd Generation Partnership Project, 3GPP)의 일부인 IP Multimedia Subsystem (IMS)의 발전으로 더 강화되었다. 다이어미터 애플리케이션은 Cx, Dh, Dx, Rf, Ro와 Sh 인터페이스를 지원한다. 다이어미터 프로토콜은 확장 사용을 통해 프록시, 매개자, 강력한 보안, 모바일 IP, 네트워크 접속 서버(Network-Access Server Requirement, NASREQ), 과금 및 자원 관리를 지원할 수 있게 확장되도록 고안되었다.

프로토콜 설명

다이어미터 기본 프로토콜은 RFC 6733 (오래된 버전: RFC 3588)에 정의되어 있고 AAA protocol에 대한 최소 요구사항을 정의한다. Diameter Applications은 새로운 명령, 속성 또는 두 개 모두를 추가함으로써 기본 프로토콜을 확장할 수 있다. 다이어미터의 보안은 IPsec 또는 TLS 통해 이루어진다. IANA는 다이어미터에 TCP와 SCTP 포트 3868을 할당했다.

버전

이 필드는 다이어미터를 기초로한 프로토콜의 버전을 나타낸다. 2014년 부터 지원되는 값은 1 하나 뿐이다.

메시지 길이

메시지 길이 필드는 헤더 필드와 패딩된 AVP를 포함한 다이어미터 메시지의 길이를 나타낸다.

명령 부호

"R" (Request) 비트 – 설정되면, 그 메시지는 요청이다. 해제되면, 그 메시지는 응답이다.
"P" (Proxiable) 비트 – 설정되면, 그 메시지는 프록시, 전달 또는 리다이렉트 될 수 있다.  해제되면, 그 메시지는 로컬로 처리되어야 한다.
"E" (Error) – 설정되면, 메시지는 프로토콜 오류를 포함하고 이 명령을 위해 설명된 ABNF를 따르지 않는다. "E" 비트 집합을 가진 메시지는 일반적으로 에러메시지로 간주된다. 이 비트는 요청 메시지에 설정되어서는 안 된다.
"T" (잠재적 재전송 메시지) 비트 – 이 플래그는 중복 요청을 제거하는데 도움을 주기 위해 연결 복구 과정 이후에 설정된다. 이것은 재전송 요청이 연결 장애 때문에 일어날 수 있는 중복 표시로써 아직 확인되지 않았을 때 설정된다.

어플리캐이션-ID

애플리케이션-ID는 메시지가 어떤 다이어미터 애플리케이션에 적용가능한지 구별하는데 사용된다. 그 애플리케이션은 인증 애플리케이션이 될 수도 있고 과금 또는 벤더 특화 애플리케이션이 될 수도 있다.
어떤 다이어미터 확장을 따르는 다이어미터 에이전트는 Capabilities-Exchange-Request (CER)와 Capabilities-Exchange-Answer (CEA) 명령의  Auth-Application-Id Attribute에 특정값을 포함함으로써 지원을 공식화한다.
헤더 안에 있는 애플리케이션-ID의 값은 관련된 애플리케이션-ID APV와 같다. 예를 들어, 다이어미터 신용-제어 애플리케이션 용 Credit-Control-Request (CCR) 와 Credit-Control-Answer (CCA) 명령의 애플리케이션-ID 값와 인증-애플리케이션-ID 속성값은 4이다.

Hop-by-Hop 식별자

요청에 대한 응답에 존재하는 Hop-by-Hop 식별자는 같은 값이어야 하기 때문에 이 식별자는 응답과 요청을 일치시키는데 사용되며 부호가 없는 32-비트 정수 필드로 구성된다.(네크워크 바이트 순서)
다이어미터 프로토콜은 장애 조치를 위해 사용되는 트랜잭션 상태를 릴레이와 프록시 에이전트가 유지할 것을 요구한다. 트랜잭션 상태는 요청을 전달할 때, 그 Hop-by-Hop 식별자가 저장된다는 의미를 내포하고 있다; 필드는 대응하는 응답을 수신 할 때 원래의 값으로 복원되는 로컬 고유 식별자로 대체된다. 요청 상태는 응답의 수신시에 해제된다. 수신된 응답이 알고있는 Hop-by-Hop 식별자와 일치하지 않을 때 다이어미터 에이전트는 이 응답을 무시한다.
리다이렉팅 에이전트의 경우에 Hop-by-Hop 식별자는 다이어미터 에이전트가 응답 메시지로 반응을 하기 때문에 헤더에서 관리된다.

End-to-End 식별자

End-to-End 식별자는 Origin-Host AVP 조합과 함께 중복된 메시지를 감지하는데 사용되는 부호없는 32-bit 정수 필드이다.(네트워크 바이트 순서)
요청을 생성했을 때, End-to-End 식별자는 로컬 고유 식별자로 설정된다. End-to-End 식별자는 어떤 종류의 다이어미터 에이전트도 수정할 수 없고, 대응하는 요청에 있는 같은 값이 응답에 사용된다.

상태 관리

RFC 3588은 피어(peer)와 처리중인 메시지 사이에 연결을 유지하기 위한 핵심 상태 관리를 정의한다. 이것은 기본적인 프로토콜 기능 중에 일부분이고 모든 스택은 이것과 그러한 연결 관련 동작 개념을 지원해야 한다.
추가적으로, 애플리케이션 특정 상태 관리는 이후 또는 더 높은 추상 계층에서 소계될 수 있다. RFC 3588은 인증 및 과금 상태 관리를 정의한다.

메시지 흐름

두 다이어미터 피어(peer) 간의 통신은 전송 연결(transport connection)이 이루어지면서 시작된다(TCP 또는 SCTP). 이후 한 쪽에서 Capabilities-Exchange-Answer (CEA)로 응답하는 또 다른 피어로 Capabilities-Exchange-Request (CER)를 보낸다. RFC 3588을 따르는 피어 TLS (Transport Layer Security)는 추가적으로 협상될 수 있다. RFC 6733을 따르는 피어 TLS 협상은 CER/CEA 이전에 추가적으로 이루어질 수 있다.
이후 애플리케이션 메시지 교환을 위한 연결은 준비 완료된다.
이정 시간동안 메시지 교환이 없다면 둘 중에 한 쪽에서 Device-Watchdog-Request (DWR)을 보낼 수 있고 다른 쪽은 Device-Watchdog-Answer로 응답해야한다.
둘 중 한쪽에서 다른 쪽에서 Disconnect-Peer-Answer로 응답해야하는 Disconnect-Peer-Request (DPR)을 보내 통신을 종료할 수 있다. 이후 전송 연결은 종료된다.