RFC: 4340
Оригинал: Datagram Congestion Control Protocol (DCCP)
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

7.5.4. Обработка пакетов с некорректными номерами

При получении пакетов с некорректной нумерацией, конечные точки выполняют перечисленные ниже действия.

  • Все пакеты DCCP-Sync и DCCP-SyncAck с некорректными номерами должны игнорироваться.

  • Пакеты DCCP-Reset с некорректной нумерацией должны вызывать передачу в ответ пакета DCCP-Sync (возможно с ограничением скорости передачи). Пакеты отклика должны использовать новое значение Sequence Number и, таким образом, будут увеличивать значение GSS. Однако значение GSR изменяться не будет, поскольку принятый пакет имеет некорректную нумерацию. Значения Acknowledgement Number в откликах должны быть равны GSR.

  • Все остальные пакеты с некорректными номерами должны вызывать передачу в ответ похожих пакетов DCCP-Sync, отличающихся лишь тем, что значение Acknowledgement Number должно совпадать со значением Sequence Number в пакете с некорректным номером.

При получении пакета DCCP-Sync с некорректным номером партнерская конечная точка (скажем, DCCP B) должна обновить свою переменную GSR и передать в ответ пакет DCCP-SyncAck. Номер подтверждения в пакете DCCP-SyncAck будет равен порядковому номеру в пакете DCCP-Sync, который может отличаться от GSR. При получении этого пакета DCCP-SyncAck, который будет иметь корректную нумерацию, поскольку он подтверждает пакет DCCP-Sync конечная точка DCCP A будет обновлять свою переменную GSR и синхронизация номеров между конечными точками восстановится. Как исключение из этого правила конечная точка в состоянии REQUEST должна отвечать пакетом DCCP-Reset вместо DCCP-SyncAck. Это нужно для сброса полуоткрытого соединения DCCP A.

Для защиты от DoS-атак реализациям DCCP следует вводить ограничение скорости передачи пакетов DCCP-Syncs в ответ на получение пакетов с некорректной нумерацией, чтобы передавалось не более 8 пакетов DCCP-Syncs в секунду.

Конечным точкам DCCP недопустимо обрабатывать пакеты с некорректной нумерацией, за исключением, возможно, генерации пакетов DCCP-Sync. Например, не допускается обработка опций. Конечная точка может временно сохранять пакеты с некорректными номерами, если они могут позднее стать корректными — это может снижать воздействие потери множества пакетов за счет доставки приложению большего числа пакетов. В частности, конечная точка может сохранять пакеты с некорректной нумерацией на время до 2 периодов кругового обхода. Если в течение срока сохранения соответствующее окно корректности порядковых номеров изменится так, что номера в пакетах станут корректными, конечная точка может снова обработать эти пакеты.

Отметим, что пакеты DCCP-Reset с некорректными номерами вызывают генерацию пакетов DCCP-Sync. Это происходит потому, что конечная точка в несинхронизированном состоянии (CLOSED, REQUEST, LISTEN) может не иметь информации, достаточной для генерации подходящего пакета DCCP-Reset с первой попытки. Например, если партнерская точка находится в состоянии CLOSED и получает пакет DCCP-Data, она не может определить корректное значение Sequence Number для включения в генерируемый пакет DCCP-Reset (поскольку пакет DCCP-Data не имеет поля Acknowledgement Number). Пакеты DCCP-Sync, генерируемые в ответ на такие некорректные пакеты сброса, обслуживаются как отвод (challenge) и содержат информацию, которой достаточно для генерации подходящего пакета DCCP-Reset. Однако новый пакет DCCP-Reset может содержать значение Reset Code, отличающееся от кода сброса в исходном пакете DCCP-Reset (новым кодом может быть, например, Reset Code 3, "No Connection"). Конечной точке следует использовать, по возможности, информацию из исходного пакета DCCP-Reset.

Страница 45 из 113

2007 - 2022 © Русские переводы RFC, IETF, ISOC.