이 메모의 상태

이는 인터넷 표준 트랙 문서이다.¶

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물이다. 이는 IETF 커뮤니티의 합의를 나타낸다. 이 문서는 공개 검토를 받았으며, 인터넷 엔지니어링 운영 그룹(IESG)에 의해 발행 승인을 받았다. 인터넷 표준에 대한 자세한 정보는 RFC 7841의 섹션 2에서 확인할 수 있다.¶

이 문서의 현재 상태, 정오표 및 이에 대한 피드백 제공 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc8999에서 확인할 수 있다.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

목차

1. QUIC에 대한 극도로 추상적인 설명

QUIC은 두 엔드포인트 사이의 연결 지향 프로토콜이다. 이러한 엔드포인트는 UDP 데이터그램을 교환한다. 이 UDP 데이터그램에는 QUIC 패킷이 포함된다. QUIC 엔드포인트는 QUIC 패킷을 사용하여 QUIC 연결을 설정하며, 이는 이러한 엔드포인트 간에 공유되는 프로토콜 상태이다.¶

2. 모든 QUIC 버전의 고정 속성

QUIC [QUIC-TRANSPORT]은 안전하고 다중화된 전송을 제공하는 것에 더해, 버전을 협상할 수 있는 선택지를 허용한다. 이를 통해 프로토콜은 새로운 요구 사항에 대응하여 시간이 지나면서 변경될 수 있다. 프로토콜의 많은 특성은 버전 간에 변경될 수 있다.¶

이 문서는 새로운 버전이 개발되고 배포될 때 안정적으로 유지되도록 의도된 QUIC의 부분집합을 설명한다. 이러한 모든 불변 사항은 IP 버전과 독립적이다.¶

이 문서의 주된 목표는 새로운 QUIC 버전을 배포할 수 있음을 보장하는 것이다. 변경될 수 없는 속성을 문서화함으로써, 이 문서는 QUIC 엔드포인트가 프로토콜의 다른 모든 측면에 대한 변경을 협상할 수 있는 능력을 보존하는 것을 목표로 한다. 그 결과, 이는 엔드포인트가 아닌 엔터티에 제공되는 최소한의 정보량도 보장한다. 이 문서에서 명시적으로 금지하지 않는 한, 프로토콜의 모든 측면은 서로 다른 버전 간에 변경될 수 있다.¶

부록 A에는 QUIC 버전 1에 대한 지식을 바탕으로 할 수 있는 몇 가지 잘못된 가정의 비포괄적 목록이 포함되어 있으며, 이는 QUIC의 모든 버전에 적용되지 않는다.¶

3. 규약 및 정의

이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 여기에 표시된 것처럼 모두 대문자로 나타나는 경우에만, BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 한다.¶

이 문서는 규범적 언어가 사용되지 않은 경우에도 미래 QUIC 버전에 대한 요구 사항을 정의한다.¶

이 문서는 [QUIC-TRANSPORT]의 용어 및 표기 규약을 사용한다.¶

4. 표기 규약

패킷의 형식은 이 섹션에서 정의한 표기를 사용하여 설명된다. 이 표기는 [QUIC-TRANSPORT]에서 사용된 것과 동일하다.¶

복합 필드는 이름이 지정된 뒤, 일치하는 중괄호 쌍으로 둘러싸인 필드 목록이 뒤따른다. 이 목록의 각 필드는 쉼표로 구분된다.¶

개별 필드에는 길이 정보와 함께 고정 값, 선택성 또는 반복에 대한 표시가 포함된다. 개별 필드는 다음 표기 규약을 사용하며, 모든 길이는 비트 단위이다:¶

x (A):

x가 A비트 길이임을 나타낸다¶

x (A..B):

x가 A부터 B까지의 임의 길이일 수 있음을 나타낸다. A는 생략되어 최소 0비트를 나타낼 수 있고, B는 생략되어 정해진 상한이 없음을 나타낼 수 있다. 이 형식의 값은 항상 바이트 경계에서 끝난다¶

x (L) = C:

x가 C의 고정 값을 가짐을 나타낸다. x의 길이는 L로 설명되며, 이는 위의 길이 형식 중 어느 것이든 사용할 수 있다¶

x (L) ...:

x가 0회 이상 반복되고 각 인스턴스의 길이가 L임을 나타낸다¶

이 문서는 네트워크 바이트 순서, 즉 빅 엔디언 값을 사용한다. 필드는 각 바이트의 상위 비트부터 배치된다.¶

그림 1은 예제 구조를 보여준다:¶

Example Structure {
  One-bit Field (1),
  7-bit Field with Fixed Value (7) = 61,
  Arbitrary-Length Field (..),
  Variable-Length Field (8..24),
  Repeated Field (8) ...,
}

5. QUIC 패킷

QUIC 엔드포인트는 하나 이상의 QUIC 패킷을 포함하는 UDP 데이터그램을 교환한다. 이 섹션은 QUIC 패킷의 불변 특성을 설명한다. QUIC의 한 버전은 단일 UDP 데이터그램에 여러 QUIC 패킷을 허용할 수 있지만, 불변 속성은 데이터그램의 첫 번째 패킷만 설명한다.¶

QUIC은 두 가지 유형의 패킷 헤더, 즉 긴 헤더와 짧은 헤더를 정의한다. 긴 헤더를 가진 패킷은 첫 번째 바이트의 최상위 비트가 설정되어 식별되며, 짧은 헤더를 가진 패킷은 해당 비트가 지워져 있다.¶

QUIC 패킷은 헤더를 포함하여 무결성 보호될 수 있다. 그러나 QUIC 버전 협상 패킷은 무결성 보호되지 않는다. 섹션 6을 참조한다.¶

여기에 설명된 값들을 제외하면, QUIC 패킷의 페이로드는 버전별이며 임의 길이이다.¶

Long Header Packet {
  Header Form (1) = 1,
  Version-Specific Bits (7),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Version-Specific Data (..),
}

Short Header Packet {
  Header Form (1) = 0,
  Version-Specific Bits (7),
  Destination Connection ID (..),
  Version-Specific Data (..),
}

6. 버전 협상

QUIC 엔드포인트가 긴 헤더와 자신이 이해하지 못하거나 지원하지 않는 버전을 가진 패킷을 수신하면, 이에 대한 응답으로 Version Negotiation 패킷을 보낼 수 있다. 짧은 헤더를 가진 패킷은 버전 협상을 유발하지 않는다.¶

Version Negotiation 패킷은 첫 번째 바이트의 상위 비트를 설정하므로, 섹션 5.1에 정의된 긴 헤더를 가진 패킷의 형식을 따른다. Version Negotiation 패킷은 Version 필드가 0x00000000으로 설정되어 있다는 점으로 식별할 수 있다.¶

Version Negotiation Packet {
  Header Form (1) = 1,
  Unused (7),
  Version (32) = 0,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Supported Version (32) ...,
}

Version Negotiation 패킷의 첫 번째 바이트에서 최상위 비트만 정의된 값을 가진다. "Unused"로 표시된 나머지 7비트는 송신 시 임의 값으로 설정될 수 있으며, 수신 시 MUST 무시되어야 한다.¶

Source Connection ID 필드 뒤에, Version Negotiation 패킷은 각각 패킷을 보내는 엔드포인트가 지원하는 버전을 식별하는 Supported Version 필드 목록을 포함한다. Version Negotiation 패킷에는 다른 필드가 포함되지 않는다. 엔드포인트는 Supported Version 필드가 없거나 잘린 Supported Version 값을 포함하는 패킷을 MUST 무시해야 한다.¶

Version Negotiation 패킷은 무결성 또는 기밀성 보호를 사용하지 않는다. 특정 QUIC 버전은 엔드포인트가 지원되는 버전 집합의 수정 또는 손상을 감지할 수 있도록 하는 프로토콜 요소를 포함할 수 있다.¶

엔드포인트는 수신한 패킷의 Source Connection ID 필드 값을 Destination Connection ID 필드에 MUST 포함해야 한다. Source Connection ID 필드의 값은 수신한 패킷의 Destination Connection ID 필드에서 MUST 복사되어야 하며, 이 값은 처음에 클라이언트가 무작위로 선택한다. 두 연결 ID를 모두 에코하면, 클라이언트는 서버가 패킷을 수신했으며 Version Negotiation 패킷이 패킷을 관찰할 수 없는 공격자에 의해 생성되지 않았다는 약간의 확신을 얻을 수 있다.¶

Version Negotiation 패킷을 수신한 엔드포인트는 이후 패킷에 사용할 버전을 변경하기로 결정할 수 있다. 엔드포인트가 QUIC 버전을 변경하는 조건은 선택한 QUIC 버전에 따라 달라진다.¶

QUIC 버전 1을 지원하는 엔드포인트가 Version Negotiation 패킷을 생성하고 처리하는 방식에 대한 더 자세한 설명은 [QUIC-TRANSPORT]를 참조한다.¶

7. 보안 및 개인정보 보호 고려 사항

미들박스가 QUIC의 특정 버전의 특징을 관찰한 뒤, QUIC의 다른 버전이 유사한 특징을 보일 때 동일한 기본 의미가 표현되고 있다고 가정할 가능성이 있다. 그러한 특징은 잠재적으로 많다. 부록 A를 참조한다. QUIC 버전 1에서는 관찰 가능한 일부 특징을 제거하거나 모호하게 만들기 위한 노력이 이루어졌지만, 이러한 특징 중 상당수는 여전히 남아 있다. 다른 QUIC 버전은 다른 설계 결정을 내릴 수 있으므로 다른 특징을 보일 수 있다.¶

QUIC 버전 번호는 모든 QUIC 패킷에 나타나지 않는다. 이는 버전별 특징을 기반으로 흐름에서 정보를 신뢰성 있게 추출하려면 미들박스가 자신이 보는 모든 연결 ID에 대한 상태를 유지해야 함을 의미한다.¶

이 문서에서 설명하는 Version Negotiation 패킷은 무결성 보호되지 않으며, 공격자에 의한 삽입에 대해서는 제한적인 보호만 제공한다. 엔드포인트는 그 결과 다른 QUIC 버전을 시도하는 경우 Version Negotiation 패킷의 의미적 내용을 MUST 인증해야 한다.¶

부록 A. 잘못된 가정

QUIC 버전 1 [QUIC-TRANSPORT]에는 관찰로부터 보호되지 않지만 새 버전이 배포될 때 변경 가능한 것으로 간주되는 여러 특징이 있다.¶

이 섹션은 QUIC 버전 1에 대한 지식을 바탕으로 QUIC에 대해 할 수 있는 잘못된 가정의 예를 나열한다. 이러한 문장 중 일부는 QUIC 버전 1에서도 참이 아니다. 이는 포괄적 목록이 아니며, 설명을 위한 예시일 뿐이다.¶

다음 문장 중 일부 또는 전부는 특정 QUIC 버전에 대해 거짓일 수 있다:¶

• QUIC은 TLS [QUIC-TLS]를 사용하며, 일부 TLS 메시지는 전송 경로에서 볼 수 있다.¶
• QUIC 긴 헤더는 연결 설정 중에만 교환된다.¶
• 주어진 5-튜플의 모든 흐름에는 연결 설정 단계가 포함된다.¶
• 흐름에서 처음 교환되는 패킷은 긴 헤더를 사용한다.¶
• 긴 정지 기간 직전의 마지막 패킷은 승인 응답만 포함한다고 가정될 수 있다.¶
• QUIC은 연결 설정 중에 교환하는 패킷을 보호하기 위해 연관 데이터가 있는 인증 암호화(AEAD) 함수 (AEAD_AES_128_GCM, [RFC5116] 참조)를 사용한다.¶
• QUIC 패킷 번호는 암호화되며 첫 번째 암호화된 바이트로 나타난다.¶
• QUIC 패킷 번호는 전송되는 모든 패킷마다 1씩 증가한다.¶
• QUIC에는 클라이언트가 보내는 첫 번째 핸드셰이크 패킷의 최소 크기가 있다.¶
• QUIC은 클라이언트가 먼저 말하도록 규정한다.¶
• QUIC 패킷은 항상 첫 번째 바이트의 두 번째 비트(0x40)가 설정되어 있다.¶
• QUIC Version Negotiation 패킷은 서버에 의해서만 전송된다.¶
• QUIC 연결 ID는 드물게 변경된다.¶
• QUIC 엔드포인트는 Version Negotiation 패킷을 받으면 사용하는 버전을 변경한다.¶
• QUIC 긴 헤더의 Version 필드는 양방향에서 동일하다.¶
• Version 필드에 특정 값이 있는 QUIC 패킷은 해당 QUIC 버전이 사용 중임을 의미한다.¶
• QUIC 엔드포인트 쌍 사이에는 한 번에 하나의 연결만 설정된다.¶

저자 주소