Разбор заголовков расширений 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.