요약

  • UDP 기반 CoAP에서 메시지 ID는 중복 감지와 ACK/리셋 상관 관계를 처리하고, 토큰은 엔드포인트 컨텍스트와 함께 응답을 미완료 요청과 매칭합니다. 두 필드는 의도적으로 분리되어 있습니다.
  • 매칭된 토큰은 상관 관계 영수증일 뿐, 사람, 기기 소유자, 인증된 주체, 인가 결정, 현재 리소스 상태 또는 완료된 애플리케이션 동작의 증명이 아닙니다.

클라이언트가 제한된 기기에 요청을 보냅니다. 응답이 돌아오는데, 클라이언트가 토큰 필드에 넣었던 것과 동일한 짧은 바이트 열이 담겨 있습니다. 추적 로그에서 이 매칭은 만족스러워 보입니다. 요청은 여기, 응답은 저기, 그 사이에 동일한 토큰.transaction verified라는 관대한 로그 메시지 하나를 남기고 넘어가고 싶어집니다.

그 문장은 프로토콜이 제공하지 않은 증거를 소비하는 것입니다.

토큰은 클라이언트에게 어떤 미완료 요청에 이 응답이 속하는지 알려줍니다. 엔드포인트의 소유자가 누구인지, 게이트웨이 뒤에 누가 서 있는지, 요청이 인가되었는지, 센서 값이 신선한지, 성공 코드가 함축하는 물리적 동작을 액추에이터가 마쳤는지는 알려주지 않습니다. 위조 방지 역할도 경계가 분명합니다. 무작위화된 토큰은 전송 보안이 없을 때 맹목적 추측을 어렵게 만들 뿐, 자격 증명이 되지는 않습니다.

이 설계에서 Carsten Bormann의 문서화된 위치는 정확합니다. 그는 2014년 CoAP의 Standards Track 정의인 RFC 7252의 세 저자 중 한 명입니다. CoAP를 TCP, TLS, 웹소켓으로 전송하는 RFC 8323의 첫 번째 저자이기도 합니다. 첫 번째 문서는 메시지 ID를 토큰과 분리하고, 두 번째 문서는 드러나는 뺄셈을 수행합니다. 신뢰 가능한 전송 계층이 재전송과 중복 처리를 책임지게 되면, CoAP는 메시지 ID를 제거하되 토큰은 유지합니다.

하나의 숫자는 사라지고, 다른 하나는 남습니다. 각 필드가 실제로 무엇을 하는지 보여주는 매우 깔끔한 실험입니다.

작은 두 필드, 서로 다른 두 시계

CoAP는 모든 바이트가 중요한 노드와 네트워크를 위해 설계되었습니다. UDP에서 고정 헤더는 16비트 메시지 ID를 포함합니다. RFC 7252는 그 값을 메시지 계층에 할당합니다. 이 값은 중복 메시지 감지에 도움이 되며, 확인 응답(ACK)이나 리셋을 그것을 유발한 Confirmable 또는 Non-confirmable 메시지와 매칭합니다. 매칭 규칙에는 대응하는 엔드포인트가 포함되며, 교환 수명 동안 동일한 메시지 ID를 그 엔드포인트와 함께 재사용할 수 없습니다.

이 상태는 짧은 운영 시계를 가집니다. 확인 응답이 유실되면 Confirmable 메시지는 재전송될 수 있습니다. 수신자는 같은 소스 엔드포인트에서 같은 메시지 ID를 두 번 이상 볼 수 있습니다. 각 사본은 확인 응답하되, 그 안에 담긴 요청이나 응답은 정상적으로 한 번만 처리해야 합니다. 따라서 메시지 ID는 한정된 질문에 답하는 데 도움이 됩니다. 이 메시지 교환을 이미 본 적이 있는지, 이 ACK나 리셋이 그 교환에 속하는지?

토큰은 요청/응답 계층에서 동작합니다. 클라이언트가 생성하고, 서버는 결과 응답에 그대로 되돌려줍니다. RFC 7252는 이를 동시 요청을 구분하기 위한 클라이언트 로컬 식별자로 부르며, 요청 ID라고 불렀을 수도 있다고 언급합니다. 사용 중인 토큰은 인터넷, 조직 또는 사람이 아니라 소스/목적지 엔드포인트 쌍에 대해 고유해야 합니다.

토큰의 시계는 단일 데이터그램 교환보다 오래 살아남을 수 있습니다. Confirmable 요청은 ACK 안에 함께 실린 응답을 받을 수 있지만, 응답은 별도로 도착할 수도 있습니다. 메시지 ID는 메시지 역학을 상관시키고, 토큰은 의미적 요청을 유효한 어떤 응답 형태와도 함께 따라갑니다.

두 필드는 종종 함께 등장하지만, 공존이 동등함은 아닙니다. 함께 실린 응답에서 메시지 ID와 토큰이 모두 매칭되는 것은 확인 응답과 응답이 하나의 메시지를 공유하기 때문입니다. 별도 응답에서는 토큰이 요청/응답 연결이고, 새 메시지는 자체 메시지 계층 교환을 수행합니다.

오류는 관측 시스템이 둘을 하나의 포괄적인correlation_id로 저장할 때 시작됩니다. 데이터베이스는 더 깔끔해질 수 있지만, 조사자는 어느 시계가 만료되었는지, 어느 엔드포인트 범위가 적용되었는지, 어느 재사용 규칙이 중요했는지, 그리고 중복 판정이 데이터그램에 관한 것인지 애플리케이션 동작에 관한 것인지를 잃게 됩니다.

RFC 8323은 필드를 제거하여 모호성을 제거한다

TCP 기반 CoAP는 재전송이나 중복 제거를 위해 UDP 메시지 계층을 필요로 하지 않습니다. TCP가 신뢰 가능한 순서화된 바이트를 공급하고, CoAP는 메시지 경계를 위한 프레이밍을 추가합니다. 따라서 RFC 8323은 신뢰 가능한 전송에서 CoAP 프레임에서 Type과 메시지 ID 필드를 제거합니다.

토큰은 남습니다.

이는 부록에 숨겨진 구현 편의가 아닙니다. 아키텍처적 책임에 대한 시험입니다. 메시지 ID가 애플리케이션 트랜잭션의 식별자였다면, 이를 제거하면 요청/응답 매칭이 깨졌을 것입니다. 깨지지 않는 이유는 토큰이 그 역할을 소유하기 때문입니다. 토큰이 단지 또 하나의 중복 표시자였다면 메시지 ID와 함께 사라졌을 것입니다. 사라지지 않는 이유는 신뢰 가능한 전송이 어느 CoAP 응답이 어느 CoAP 요청을 충족하는지 알지 못하기 때문입니다.

이 비교는 운영자에게 유용한 진단을 제공합니다. 문제가 UDP에서만 발생하면 재전송, 교환 수명, 메시지 ID 재사용, 중복 캐시, ACK/리셋 처리를 점검합니다. UDP와 신뢰 가능한 전송 모두에서 발생하면 위로 올라갑니다. 미완료 요청 상태, 토큰 생성과 매칭, 엔드포인트 또는 연결 바인딩, 중개자, 응답 처리, 애플리케이션 상태. 전송 차이는 텔레메트리를 통합할 이유가 아니라 고장을 지역화하는 방법이 됩니다.

동시에 한계도 설정합니다. 구성에 따라 TCP나 TLS 연결은 인증되지 않은 UDP 튜플보다 강한 채널 컨텍스트를 공급할 수 있습니다. 그래도 토큰 자체를 신원으로 만들지는 않습니다. 보안 연계와 토큰은 저자와 수명이 다른, 결합된 증거입니다.

무작위 토큰은 문 하나를 닫을 뿐, 건물 전체는 아니다

RFC 7252는 전송 계층 보안을 사용하지 않는 클라이언트에게 무의미하지 않은 무작위화된 토큰을 권고합니다. 공개 인터넷의 클라이언트는 위협 모델에 맞게 최소 32비트의 무작위성을 사용해야 합니다. 이유는 응답 위조입니다. 토큰을 추측할 수 없는 오프패스 공격자는 클라이언트가 미완료 요청에 속한다고 받아들이는 응답을 주입하기 어렵습니다.

메시지 ID는 여기서 거의 도움이 되지 않습니다. 보통 순차적이고 추측 가능하며, 공격자는 요청의 메시지 ID에 의존하지 않는 별도 응답을 보낼 수 있습니다. 이는 또 하나의 깔끔한 구분입니다. 메시지 ID는 중복과 확인 응답 기계에 유용하고, 토큰의 무작위성은 맹목적 주입에 대한 요청 상관 챌린지를 추가합니다.

그러나 성공한 매칭은 가정된 관측 모델 아에서 공격자가 추측하기 충분히 어려운 값이 응답에 담겼음만 증명합니다. 온패스 관측자는 그 값을 볼 수 있습니다. 침해된 중개자는 상태를 가질 수 있습니다. 취약한 생성기는 값을 반복할 수 있습니다. 만료된 요청 테이블은 잘못된 수명 아래 그 값을 받아들일 수 있습니다. 이 질문들 어느 것도 토큰을 인증 토큰으로 다시 명명함으로써 해결되지 않습니다.

수신 엔드포인트는 자신이 생성하지 않은 토큰을 불투명한 것으로 다루어야 합니다. 서버는 바이트를 되돌려줄 뿐, 그것을 사용자 이름, 세션 권한 또는 고객 계정으로 해석하지 않습니다. 클라이언트는 자신의 값에 로컬 의미를 부여할 수 있지만, 그 의미가 다른 홉에서 자동으로 공유되지는 않습니다.

따라서 감사는 무작위 생성 정책, 토큰 길이, 재사용 범위, 엔드포인트 바인딩, 미완료 요청 수명을 기록해야 합니다. 보안 모드는 별도로 기록합니다. 프라이버시가 중요하다면, 필요한 조인을 여전히 지원하는 방식이라면 텔레메트리에 원시 토큰 바이트 대신 키된 다이제스트를 유지할 수 있습니다. “토큰이 매칭되었다”와 “피어가 인증되었다”는 둘 다 참이더라도 두 개의 필드로 남아야 합니다.

프록시는 경로 전반에 하나의 보편적 토큰을 운반하지 않는다

엔드포인트라는 단어는 마치 안정적인 기기를 명명하는 것처럼 읽히기 쉽습니다. 배포된 제한된 시스템에서 요청은 포워드 프록시, 리버스 프록시, 게이트웨이, 주소 변환기, 전송 변경을 통과할 수 있습니다. CoAP 토큰은 홉 단위입니다.

중개자는 흔히 클라이언트 측 토큰과 전송 주소를 유지하면서, 자신의 토큰을 가진 자체 요청을 상류로 발행합니다. 원본의 응답이 도착하면 중개자는 하류 매핑을 복원하고 클라이언트를 위한 적절한 응답을 구성합니다. 따라서 동일한 애플리케이션 여정이 여러 토큰 네임스페이스, 여러 엔드포인트 컨텍스트, 둘 이상의 타임아웃을 담을 수 있습니다.

이는 사고 귀속에 중요합니다. 기기 방향 홉에서 보인 토큰은 클라이언트 방향 홉에는 나타난 적이 없을 수 있습니다. 상류 토큰만 노출하는 게이트웨이 로그는 하류 요청자를 명명할 수 없습니다. 한 홉에서의 매칭이 다음 홉이 올바른 매핑을 유지했음을 증명하지 않습니다. 최소한의 유용한 기록에는 관측 지점과 두 홉 기록 사이의 프라이버시에 안전한 로컬 조인이 포함됩니다.

시스템이 사후에 하나의 “글로벌 트랜잭션 ID”를 기록한다면, 그 기원에 대해 정직해야 합니다. 그 ID는 CoAP가 종단 간에 공급한 와이어 수준 사실이 아니라 운영자가 만든 관측 구조물입니다. 그 신뢰는 그것을 생성한 매핑 코드, 시계, 저장소, 접근 통제에 달려 있습니다.

요청 상태를 토큰에 넣는 것은 진실이 아니라 보관 권한을 바꾼다

RFC 8974는 이후의 기법을 탐구합니다. 클라이언트는 요청별 상태의 일부를 토큰으로 직렬화하고, 서버가 값을 되돌려줄 때 이를 복구할 수 있습니다. 더 긴 토큰은 더 많은 상태를 휴대 가능하게 만듭니다. 문서의 저자는 Klaus Hartke와 Michael Richardson이며 Carsten Bormann이 아닙니다. 여기서의 관련성은 앞선 필드 경계에 대한 스트레스 테스트입니다.

문서는 타당한 이유로 “스테이트리스”를 인용 부호 안에 넣습니다. 클라이언트는 각 요청에 대한 기록을 유지하지 않을 수 있지만, 여전히 서버별 상태, 토큰 생성 상태, 혼잡 제어 상태가 필요합니다. Confirmable UDP 메시지는 여전히 메시지 교환 상태가 필요합니다. 확장 토큰에 의존하는 클라이언트는 다른 신뢰 가능한 메커니즘이 그 지식을 공급하지 않는 한 먼저 상태 있는 교환에서 지원을 발견해야 합니다.

직렬화는 또한 개인 테이블 행을 이동하는 바이트로 변환합니다. 무결성 보호가 필수가 됩니다. 재전송(리플레이) 보호, 신선도, 프라이버시를 고려해야 합니다. 형식 변경에는 버전 구분이 필요합니다. 악의적으로 큰 토큰은 희소한 메모리를 소모할 수 있습니다. “스테이트리스” 중개자의 체인은 각 홉이 더 많은 클라이언트 정보를 직렬화하면서 토큰을 성장시킬 수 있습니다.

서버는 여전히 에코 지점입니다. 토큰 안의 상태를 이해할 필요가 없습니다. 돌아오는 값은 클라이언트가 자신의 이전 컨텍스트를 재구성하게 할 뿐, 서버를 그 컨텍스트의 발행자로 만들지 않고 그 진실을 인증하지도 않습니다. 상태의 보관 권한이 로컬 메모리에서 불투명한 왕복으로 바뀌었지만, 책임은 사라지지 않았습니다.

이는 프로토콜 엔지니어링 밖에서도 발견되는 동일한 제도적 실수입니다. 사실을 공유 기록으로 옮기는 것은 휴대 가능하고 검토 가능하게 만들 수 있습니다. 그러나 그 기록에 그것이 기술하는 행위자에 대한 권한을 부여하지는 않습니다. 원장 항목, 토큰, RFC는 각각 조정할 수 있습니다. 어느 것도 다른 시스템이 의존한다는 이유만으로 주체가 되지는 않습니다.

과잉 주장을 하지 않는 영수증을 만들라

유용한 CoAP 영수증은 패킷이나 프레임이 관측된 장소와 시각에서 시작합니다. 전송 계층과 엔드포인트 또는 연결 컨텍스트를 명명합니다. 존재한다면 보안 모드와 인증된 피어 주장을 기록하되, 그 주장을 토큰 필드로 복사하지 않습니다.

UDP에서는 메시지 유형, 메시지 ID, 교환 수명, 재전송 횟수, 중복 처리 판정을 유지합니다. 모든 전송에서는 토큰 길이와 값의 안전한 표현, 요청 메서드와 대상, 로컬 미완료 요청 기록, 응답 코드, 매칭 결과를 유지합니다. 중개자에서는 와이어가 보편적 식별자를 운반했다고 가장하지 않으면서 하류와 상류 기록을 연결합니다.

그리고 프로토콜 너머로 계속합니다. 어느 인가 결정이 이 동작을 허용했는가? 응답은 어느 리소스 버전을 기술했는가? 애플리케이션 트랜잭션이 커밋되었는가? 물리적 액추에이터가 독립적 신호로 완료를 확인했는가? 어느 소프트웨어 및 구성 개정판이 이 영수증을 만료시키는가?

이 질문들은 서로 다른 행위자에게 속하기 때문에 단일 필드로 답할 수 없습니다. 클라이언트는 상관 상태를 소유합니다. 전송과 CoAP 메시지 계층은 전달 역학을 소유합니다. 보안 계층은 피어 주장을 소유합니다. 서버는 인가와 리소스 처리를 소유합니다. 애플리케이션이나 기기 소유자는 결과 증거를 소유합니다. IETF는 상호 운용 가능한 동작을 명세하며, 배포를 운영하지 않습니다.

Carsten Bormann의 역할은 증거이지 위임이 아니다

현재 IETF 프로필은 Bormann을 CoRE 작업 그룹과 Thing-to-Thing Research Group의 의장으로 기재하고 65개의 RFC를 나열합니다. 이 사실들은 검토 시점에서 상당한 기여 기록을 기술합니다. 그러나 한 기여자를 합의의 소유자, 배포된 구현 또는 운영자의 리스크 결정의 소유자로 바꾸지는 않습니다.

더 강한 귀속은 더 좁습니다. RFC 7252는 Bormann을 그 분리를 명세한 저자 중 하나로 기록합니다. Bormann이 저자 목록 첫 자리에 있는 RFC 8323은 그 분리가 전송 변경을 어떻게 살아남는지 보여줍니다. 이 문서들은 공개 검토와 집단적 과정을 통해 승인된 IETF 산출물입니다.

동작하는 코드가 다음 증거 조각을 공급합니다. 적합한 파서, 측정된 무작위성을 가진 토큰 생성기, 중복 캐시, 올바르게 바인딩된 보안 연계, 게이트웨이 매핑, 애플리케이션 영수증은 특정 시스템이 무엇을 채택했는지 보여줍니다. 표준의 발행일은 그 관측을 대체할 수 없습니다.

이 절제는 엔지니어링 공로의 축소가 아닙니다. 그 자체가 엔지니어링 기여입니다. 컴팩트한 프로토콜은 독립적 시스템이 상호 운용하기에 정확히 충분한 만큼만 말하고, 그 필드들이 결코 운반하도록 설계되지 않은 신원, 권한, 결과를 주장하는 데 쓰이기 전에 멈출 때 성공합니다.

토큰은 응답에 매칭되었습니다. 나머지는 운영자가 여전히 증명해야 합니다.

출처