Разбор заголовков расширений IPv6, содержащих неизвестные расширения


113

Я пишу очень простой сетевой фильтр и добираюсь до места, где хочу проанализировать заголовки IPv6, чтобы они соответствовали таким вещам, как типы ICMPv6, номера портов TCP / UDP и т. Д.

Итак, я подробно читаю о формате пакетов IPv6 , и я вроде как ... ну ... мне как бы приходилось читать его снова и снова, чтобы убедиться, что я действительно читаю его правильно. Мне кажется, вам нужно начать с 40-байтового фиксированного заголовка и посмотреть на его следующее поле заголовка. Затем вы должны смотреть на следующее поле заголовка следующего заголовка и так далее, как на связанный список, пока не дойдете до конца. Если есть полезная нагрузка, она последует.

Проблема в том, что ни в фиксированном заголовке, ни в расширенных заголовках нет поля длины. У вас должна быть таблица типов заголовков расширений и их размеров, чтобы вы могли пройти этот связанный список до конца.

Мне это кажется странным, возможно, даже заячьим мозгом. Что делать, если я обнаружу нераспознанный тип заголовка расширения? Что мне делать? Я не знаю его длины. Я предполагаю, что мне нужно выбросить пакет и заблокировать его, поскольку в сетевом фильтре разрешение прохождения пакета позволит злоумышленнику уклониться от сетевого фильтра, включив фиктивный тип заголовка. Но это означает, что если протокол когда-либо будет расширен, каждая отдельная часть программного обеспечения для анализа заголовка IPv6, когда-либо написанная, должна быть одновременно обновлена, если новое расширение будет использоваться.

Итак, как я могу разобрать заголовки IPv6, если я не знаю, какие расширения они используют? Как пропустить заголовок для неизвестного расширения, если я не знаю его длины?


10
Исходя из этого вопроса, похоже, что я не дурак, и да, я правильно понимаю: (в реальном мире) невозможно добавить новый заголовок расширения в IPv6. stackoverflow.com/questions/9847923/…
— AdamIerymenko

10
И да, также кажется, что вычисление длины заголовка требует обхода связанного списка: stackoverflow.com/questions/14762193/… Не поймите меня неправильно. IPv6 великолепен и очень нужен. Но это все еще кажется тупым.
— AdamIerymenko

3
Спецификация (ссылка на верхний комментарий) говорит, что маршрутизаторы не должны просматривать заголовки, поэтому не нужно заботиться о том, какие заголовки вы добавляете. Только целевой узел должен смотреть на заголовки.
— Anders E. Andersen

2
Просто примечание: «с волосами с мозгами» - довольно запутанное написание, и следует предпочесть «с заячьими мозгами» (источник: tfd )
— pzkpfw

2
Поскольку есть только одно правильное написание - «заячий мозг».
— Alan B

Ответы:


33

Если вы столкнетесь с чем-то, что не можете разобрать, вам придется принять решение или выполнить действие на основе того, что вы уже проанализировали.

Дизайн таков, потому что в IPv6 каждый заголовок расширения «обертывает» остальную часть пакета. Если вы видите заголовок маршрутизации, затем какой-то заголовок, о котором вы никогда не слышали, затем полезную нагрузку, тогда вы не можете проанализировать полезную нагрузку. Значение полезной нагрузки в принципе зависит от заголовка, который вы не знаете, как интерпретировать.

Маршрутизаторы могут маршрутизировать такие пакеты, потому что им нужен только заголовок маршрутизации. Устройствам глубокой проверки пакетов и тому подобному нужно много знать, но в любом случае это их судьба.

Отредактировано для добавления: этот дизайн означает, что промежуточные ящики могут изменять только то, что они знают. Если промежуточный ящик видит заголовок, о котором он не знает, то у него есть только два варианта: отклонить или передать. В IPv4 он также может удалить неизвестное расширение и передать остальное. ИМО, это свойство делает дизайн более, чем менее расширяемым.


97

Что делать, если я обнаружу нераспознанный тип заголовка расширения?

Из RFC 2460 :

Если в результате обработки заголовка узел должен перейти к следующему заголовку, но значение следующего заголовка в текущем заголовке не распознано узлом, он должен отбросить пакет и отправить сообщение о проблеме параметра ICMP источнику. пакета со значением кода ICMP, равным 1 («обнаружен нераспознанный тип следующего заголовка»), и полем указателя ICMP, содержащим смещение нераспознанного значения в исходном пакете. То же действие следует предпринять, если узел встречает нулевое значение Next Header в любом заголовке, кроме заголовка IPv6.


15
Хорошо. Я думал, что схожу с ума. Так что да, это действительно полностью нерасширяемый дизайн ... по крайней мере, без внутриполосной сигнализации и других хаков. Это простительно в протоколе приложения, где вы контролируете оба конца и должны учитывать только новые версии вашего приложения, но не в чем-то, рассчитанном на ... сотни лет?
— AdamIerymenko

8
Возможность игнорировать неизвестные заголовки может привести к гораздо более сложным проблемам. (Что, если промежуточный прокси изменил заголовки TCP, не зная об инкапсулирующем заголовке ESP?) В этом случае простота превосходит «расширяемость»!
— jman 08

4
@Max IPv6 имеет буквально достаточно адресов, чтобы назначить по одному каждому атому на Земле. Нет такого количества подключенных к Интернету тостеров, которые занимали бы это пространство.
— Tyler McHenry

8
@Max Я не скажу, что нам абсолютно никогда не понадобится IPv7, но с IPv6 у нас достаточно адресного пространства, чтобы дать каждому кубическому миллиметру в атмосфере Земли (130 000 км вверх) уникальный адрес ... 100 000 раз. Я имею в виду, что как только мы начнем колонизировать другие галактики, нам, возможно, будет о чем беспокоиться, но до тех пор мы должны быть довольно хороши.
— cincodenada 08

4
Некоторый контекст отсутствует:With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
— Tobu

28

В реальном мире невозможно добавить новый заголовок расширения в IPv6.

Неправильно, потому что:

  1. Только хосту назначения разрешено отклонять на основе нераспознанных заголовков расширений (с одним исключением, упомянутым в вопросе, который вы связали )

  2. Если ваш новый заголовок расширения каким-то образом является необязательным (лучше), вы получите сообщение об ошибке ICMP и сможете повторить попытку без него.


1
И вы уверены, что этот пакет ICMP пройдет через NAT к фактическому отправителю?
— Dexter

5
@Dexter ipv6 убьет NAT ... надеюсь,
— Янус Троелсен

2
@Dexter: Эти ICMP-пакеты должны приходить по ряду причин. Например, если MTU канала сократился (возможно, инкапсуляция пакета произошла из-за PPPoE или VPN), а отправляемый пакет слишком велик, будет возвращен пакет ICMP, в котором говорится, что пакет слишком велик.
— Билл Линч

4
@JanusTroelsen не все разделяют ваши надежды.
— Dexter

4

Обновление RFC 6564 охватывает этот случай. Он точно описывает сценарий, который вы описываете, и предлагает формат для любых новых заголовков расширений (если они когда-либо были определены), с которыми промежуточные ящики, такие как ваш, смогут работать, по крайней мере, некоторое время.

Имейте в виду, что он предназначен не для расширения IPv6 путем создания новых заголовков расширения, а путем добавления новых параметров назначения. Это должно быть тривиально или, по крайней мере, намного проще для вас иметь дело с неизвестными вариантами назначения.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.