RFC

Definicja RFC

Request for Comments (RFC) to numerowany dokument techniczny publikowany przez RFC Editor, który opisuje protokół internetowy, format danych, procedurę operacyjną albo dostarcza materiał informacyjny dla społeczności sieciowej. Pierwszy dokument tej serii - RFC 1 - opublikował Steve Crocker w 1969 roku, opisując wczesne protokoły sieci ARPANET. Od tego czasu numeracja rośnie w jednym ciągłym ciągu i nigdy się nie cofa - każdy nowy dokument, niezależnie od tematu, dostaje kolejny wolny numer.

Nazwa "Request for Comments" jest dziś myląca historycznie - w latach 60. i 70. dokumenty rzeczywiście zapraszały do dyskusji i mogły się zmieniać. Współczesny RFC po opublikowaniu jest niezmienny (immutable) - jeśli trzeba go poprawić, powstaje nowy dokument, który go aktualizuje albo zastępuje, a stary numer zostaje na zawsze przypisany do pierwotnej treści. To odróżnia RFC od np. norm ISO, które są rewidowane pod tym samym numerem.

Za publikację odpowiada RFC Editor, funkcja finansowana przez Internet Society (ISOC) i operacyjnie prowadzona we współpracy z IETF (Internet Engineering Task Force). Nie każdy RFC to jednak standard IETF - dokumenty trafiają do serii z czterech różnych źródeł, a status "standard" zdobywa tylko część z nich. Ta różnica jest źródłem większości nieporozumień opisanych niżej.

Jak to działa

Droga od pomysłu do numeru RFC ma kilka wyraźnych etapów. Autor albo grupa robocza IETF publikuje Internet-Draft - roboczą wersję dokumentu, ważną domyślnie 6 miesięcy, dostępną publicznie do komentowania. Jeśli draft dotyczy pracy grupy roboczej, przechodzi przez jej wewnętrzny proces recenzji (working group last call), a potem przez szerszy IETF Last Call obejmujący całą społeczność.

Kolejny etap to ocena przez IESG (Internet Engineering Steering Group) - to IESG formalnie zatwierdza dokument do publikacji jako RFC, niezależnie od tego, z którego strumienia pochodzi. Zatwierdzony dokument trafia do RFC Editor, który wykonuje edycję redakcyjną, sprawdza spójność terminologii i formatu, po czym nadaje kolejny numer i publikuje go trwale.

Kluczowa własność tego procesu: numer RFC jest przyznawany dopiero na etapie publikacji, nie na etapie draftu. Internet-Draft może przejść przez dziesiątki wersji roboczych (oznaczanych w nazwie pliku jako -00, -01, -02...), zanim RFC Editor nada mu ostateczny numer. Od tego momentu treść jest zamrożona - każda kolejna zmiana wymaga nowego dokumentu.

Struktura i klasyfikacja

RFC dzielą się na typy według serii dokumentów, do której należą, oraz - dla dokumentów normatywnych - według poziomu dojrzałości w Standards Track. To dwa różne wymiary klasyfikacji, które łatwo pomylić.

Dokumenty w ścieżce standardowej (Standards Track) przechodzą dodatkowo przez poziomy dojrzałości. Od RFC 6410 z 2011 roku ścieżka ma dwa poziomy zamiast dawnych trzech - pośredni Draft Standard został usunięty, bo w praktyce niewiele dokumentów przez niego przechodziło.

• Proposed Standard - dokument dojrzały technicznie, z jasną specyfikacją, gotowy do wdrożeń produkcyjnych.
• Internet Standard - najwyższy poziom, wymaga wykazanych, niezależnych, interoperacyjnych implementacji w praktyce.

Warto podkreślić: sam numer RFC nic nie mówi o statusie. RFC 8446 (TLS 1.3) jest Proposed Standard, a RFC 1149 (żartobliwy "IP over Avian Carriers") jest Experimental - kolejność numerów wynika wyłącznie z daty publikacji, nie z ważności czy dojrzałości treści.

W szerszym kontekście

RFC Editor przyjmuje dokumenty z czterech niezależnych strumieni (streams), z których każdy ma inny proces decyzyjny i inny poziom formalnego zatwierdzenia:

• IETF Stream - dokumenty wypracowane w grupach roboczych IETF, zatwierdzane przez IESG; tu powstaje większość standardów sieciowych i bezpieczeństwa.
• IAB Stream - dokumenty publikowane przez Internet Architecture Board, zwykle dotyczące architektury internetu jako całości.
• IRTF Stream - wyniki prac Internet Research Task Force, grup badawczych zajmujących się tematami długoterminowymi i eksperymentalnymi.
• Independent Submission Stream - dokumenty spoza IETF, recenzowane przez niezależny Independent Submissions Editor, bez zatwierdzenia IESG.

Ten sam dokument może też wchodzić w relacje z innymi RFC. Obsoletes oznacza całkowite zastąpienie - stary dokument przestaje być aktualnym źródłem. Updates oznacza częściową modyfikację - oryginał wciąż obowiązuje, ale trzeba go czytać razem z aktualizacją. Klasycznym przykładem łańcucha zastąpień w obszarze bezpieczeństwa jest historia specyfikacji HTTP.

RFC 2616 z 1999 roku opisywał HTTP/1.1 jako jeden monolityczny dokument. W 2014 roku został podzielony i zastąpiony przez grupę RFC 7230-7235, rozdzielającą semantykę, buforowanie, autoryzację i warunkowe żądania. W 2022 roku ta grupa z kolei została zastąpiona przez RFC 9110-9114, które doprecyzowały semantykę wspólną dla HTTP/1.1, HTTP/2 i HTTP/3. Kto dziś cytuje RFC 2616 jako aktualny opis HTTP, opiera się na dokumencie nieaktualnym od dekady - relacja Obsoletes jest tu jednoznaczna i sprawdzalna na stronie RFC Editora.

Ta struktura relacji ma bezpośrednie znaczenie dla pentest i audytów zgodności - konfiguracja oceniana względem nieaktualnego RFC może być formalnie "zgodna" z dokumentem, który od lat nie opisuje rekomendowanej praktyki.

Zastosowanie w praktyce

W codziennej pracy zespołów bezpieczeństwa RFC pełnią kilka konkretnych ról:

• Referencja przy implementacji protokołów - deweloperzy wdrażający TLS, IPsec czy DNSSEC sprawdzają w RFC dokładną semantykę pól, kolejność komunikatów i dopuszczalne wartości, zamiast polegać na dokumentacji trzeciej ręki.
• Podstawa audytów zgodności - audytorzy porównują konfigurację systemu z wymaganiami konkretnego RFC, np. dopuszczalnych zestawów szyfrów w TLS albo poprawnej obsługi nagłówków HTTP.
• Materiał źródłowy w pracy CSIRT - zespoły reagowania na incydenty sięgają po RFC, gdy trzeba ustalić, czy zaobserwowane zachowanie protokołu jest zgodne ze specyfikacją, czy jest anomalią wartą dalszej analizy.
• Punkt odniesienia dla pentest i red teamów - znajomość niskopoziomowych detali protokołu (dopuszczalnych stanów, obsługi błędów, przypadków brzegowych) ułatwia identyfikację odstępstw implementacji od specyfikacji, które bywają źródłem podatności.
• Wsparcie zgodności z normami - wymagania takich norm jak ISO 27001 czy wytyczne NIST CSF często odwołują się pośrednio do konkretnych RFC jako źródła technicznych minimów, np. w zakresie kryptografii czy zarządzania certyfikatami.

Przykłady RFC szczególnie istotnych w obszarze cyberbezpieczeństwa:

Najczęstsze nieporozumienia

Kilka błędnych przekonań o RFC powtarza się na tyle często, że warto je wprost obalić.

• "RFC to standard" - fałsz w większości przypadków. Tylko dokumenty w Standards Track (Proposed Standard, Internet Standard) mają status normatywny. Znaczna część serii RFC to Informational, Experimental albo Historic - dokumenty te nigdy nie były ani nie miały być standardem.
• "Wyższy numer RFC oznacza nowszą wersję tego samego protokołu" - fałsz. Numeracja jest globalnym, ciągłym licznikiem dla wszystkich dokumentów RFC Editor, niezależnie od tematu. RFC 9110 nie jest "wersją 9110" żadnego wcześniejszego dokumentu - to po prostu 9110. dokument opublikowany w kolejności chronologicznej.
• "RFC 2616 opisuje dziś HTTP/1.1" - fałsz. RFC 2616 został zastąpiony w 2014 roku przez grupę RFC 7230-7235, a ta z kolei w 2022 roku przez RFC 9110-9114. Odwoływanie się do RFC 2616 jako aktualnego źródła to odwoływanie się do dokumentu nieaktualnego od dekady.
• "Draft Standard to wciąż obowiązujący poziom dojrzałości" - fałsz od 2011 roku. RFC 6410 usunął pośredni poziom Draft Standard ze Standards Track, który dziś ma tylko dwa poziomy: Proposed Standard i Internet Standard.
• "RFC-y są recenzowane i zatwierdzane tak samo, niezależnie od pochodzenia" - fałsz. Dokument ze strumienia Independent Submission nie przechodzi przez IESG i working group last call tak jak dokument IETF Stream - ma inny, lżejszy proces recenzji prowadzony przez Independent Submissions Editor.

FAQ

Powiązane pojęcia