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

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

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

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

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

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


person AdamIerymenko    schedule 08.07.2013    source источник
comment
Основываясь на этом вопросе, похоже, что я не дурак, и да, я правильно понимаю: (в реальном мире) невозможно добавить новый заголовок расширения в IPv6. stackoverflow.com / questions / 9847923 /   -  person AdamIerymenko    schedule 08.07.2013
comment
И да, также кажется, что вычисление длины заголовка требует обхода связанного списка: stackoverflow.com/questions/14762193/ Не поймите меня неправильно. IPv6 великолепен и очень нужен. Но это все еще кажется тупым.   -  person AdamIerymenko    schedule 08.07.2013
comment
Я думаю, учитывая количество времени, которое на это потребовалось, и задействованный совокупный интеллект, вероятно, на это есть довольно веская причина.   -  person Alan B    schedule 08.07.2013
comment
В спецификации (ссылка на верхний комментарий) говорится, что маршрутизаторы не должны просматривать заголовки, поэтому не стоит беспокоиться о том, какие заголовки вы добавляете. Только целевой узел должен просматривать заголовки.   -  person Anders E. Andersen    schedule 08.07.2013
comment
Заголовок IPv6 - это глупо. EH можно использовать для сокрытия заголовков L4 (помещая их дальше в пакете, чем маршрутизатор может проверить), вызывая обход межсетевого экрана. В настоящее время ведется работа, такая как draft-ietf-6man-ext-Transmit-01, чтобы исправить текущую ситуацию, но я не ожидаю, что будут приняты какие-то кардинальные улучшения.   -  person ytti    schedule 08.07.2013
comment
Просто примечание: hair-brained - довольно запутанное написание, и hare-brained следует предпочесть (источник: tfd )   -  person pzkpfw    schedule 08.07.2013
comment
Поскольку есть только одно правильное написание - "заячьи мозги".   -  person Alan B    schedule 08.07.2013


Ответы (4)


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

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

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

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

person arnt    schedule 08.07.2013

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

Из RFC 2460:

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

person Oliver Charlesworth    schedule 08.07.2013
comment
Хорошо. Я думал, что схожу с ума. Так что да, это действительно полностью нерасширяемый дизайн ... по крайней мере, без внутриполосной сигнализации и других хаков. Это простительно в протоколе приложения, где вы контролируете оба конца и должны учитывать только новые версии вашего приложения, но не в том, что рассчитано на ... сотни лет? - person AdamIerymenko; 08.07.2013
comment
Видел вашу правку, кажется, довольно окончательно. Проблема в том, что да, это делает протокол нерасширяемым, поскольку интеллектуальные маршрутизаторы и фильтры не могут передавать пакеты с нераспознанными заголовками расширения по соображениям безопасности. Ух ты. - person AdamIerymenko; 08.07.2013
comment
Возможность игнорировать неизвестные заголовки может привести к гораздо более сложным проблемам. (Что, если промежуточный прокси изменил заголовки TCP, не зная об инкапсулирующем заголовке ESP?) В этом случае простота превосходит расширяемость! - person jman; 08.07.2013
comment
Да, я понимаю, что ты имеешь в виду. Я возьму это. Но все же ... 2 ^ 128 адресов означает, что нам никогда не понадобится IPv7, поэтому нам лучше не добавлять новое поле заголовка в любое время в ближайшие 10 000 лет или около того. Конечно, если произойдет межпланетная колонизация, я полагаю, вы могли бы воспользоваться возможностью, чтобы вставить новый заголовок для использования только на Марсе. - person AdamIerymenko; 08.07.2013
comment
Нам может не понадобиться новый заголовок IP, но наверняка у нас будут новые заголовки расширений (en.wikipedia.org/wiki/IPv6_packet#Extension_headers) гораздо чаще! - person jman; 08.07.2013
comment
@ Адамлерименко But still... 2^128 addresses means we'll never need IPv7, 640K is more memory than anyone will ever need. Я верю, что так и будет. Люди будут использовать IP-адреса для домашней электроники, часов, смартфонов и т. Д. Затем люди начнут использовать несколько IP-адресов на одном ПК по некоторым причинам (виртуальные машины и прочее, или просто удобство), и постепенно IP-адреса снова не останутся. - person bezmax; 08.07.2013
comment
@Max IPv6 имеет буквально достаточно адресов, чтобы назначить по одному каждому атому на Земле. Нет такого количества подключенных к Интернету тостеров, которые опустошили бы это пространство. - person Tyler McHenry; 08.07.2013
comment
@Max Вы знаете, сколько это 2 ^ 128? Если у вас дома есть / 64, вы можете адресовать 2 ^ 64, примерно 1,8 квинтиллиона устройств (если я не совсем ошибаюсь). Равномерно во всем мире может быть 1,8 квинтиллиона сетей / 64. Я просто не могу представить, что нам когда-нибудь понадобится больше. - person glglgl; 08.07.2013
comment
@Max Я не скажу, что нам абсолютно никогда не понадобится IPv7, но с IPv6 у нас достаточно адресного пространства, чтобы дать каждому кубическому миллиметру в атмосфере Земли (130 000 км вверх) уникальный адрес ... 100 000 раз больше. Я имею в виду, что как только мы начнем колонизировать другие галактики, нам, возможно, будет о чем беспокоиться, но до тех пор мы должны быть довольно хороши. - person cincodenada; 08.07.2013
comment
@Max Возможно, что с помощью действительно глупых политик мы можем спроецировать исчерпание адресов IPv6. Если это произойдет, было бы очень просто исправить политики, чтобы они были менее глупыми (нет ни внутренней зависимости от SLAAC, ни внутренней технической необходимости, чтобы SLAAC LAN была 64b или больше, просто выделите urnd-адрес и DAD до тех пор, пока не освободится нашел). У IPv6 есть проблемы, исчерпание адресов не входит в их число. - person ytti; 08.07.2013
comment
@cincodenada Ничего не бывает в изобилии. Если что-то есть - этим злоупотребляют, тогда все к этому привыкают, и никакие политики не помогают. Возьмем этот пример с памятью, кто бы мог подумать, что мы будем загружать виртуальные машины в память других машин, используя везде списки, даже если будет достаточно массивов и т.д. сумасшедший. Я считаю, что то же самое произойдет и с IPv6. Например, приложения могут начать резервировать целые IP-адреса или даже их диапазоны, возникнут новые способы связи и так далее. - person bezmax; 08.07.2013
comment
Конечно, политики помогают, если вы не подходите для нового распределения RIR из-за неправильного распределения адресов, это конец вашей потери адреса. Если мы полностью проверим текущий глобальный интернет-блок, у нас будет намного больше полностью неназначенных блоков, и мы сможем начать все заново, используя более эффективные политики. Вытягивание аргумента 640k - довольно плохой аргумент, когда аргумент был сделан, люди уже использовали более 640k в некоторых средах, и было легко привести убедительные аргументы. Вместо того, чтобы использовать аргумент 640k, представьте убедительный аргумент, как у нас могут закончиться адреса IPv6. - person ytti; 08.07.2013
comment
Отсутствует некоторый контекст: 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. - person Tobu; 09.07.2013

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

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

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

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

person Andreas Klöckner    schedule 08.07.2013
comment
И вы уверены, что этот пакет ICMP дойдет до фактического отправителя через NAT? - person Dexter; 08.07.2013
comment
@Dexter ipv6 убьет NAT ... надеюсь - person Janus Troelsen; 08.07.2013
comment
@Dexter: Эти ICMP-пакеты должны прибыть по ряду причин. Например, если MTU канала сократился (возможно, инкапсуляция пакета произошла из-за PPPoE или VPN), и отправляемый пакет слишком велик, будет возвращен пакет ICMP, говорящий, что пакет слишком велик. - person Bill Lynch; 08.07.2013
comment
@JanusTroelsen не все разделяют ваши надежды. - person Dexter; 08.07.2013

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

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

person Michael Hampton    schedule 09.07.2013