Пустые фрагменты IP недействительны? - PullRequest
Новая
       20

Пустые фрагменты IP недействительны?

0 голосов
/ 17 марта 2020

Я пытался диагностировать проблему с пропущенными дейтаграммами UDP-IP, и я замечаю одну вещь, с которой мы сталкиваемся с Wireshark: иногда мы получаем дейтаграмму, которую Wireshark не считает пакетом (она не будет проделайте свою хитрость автоматической сборки фрагментированной дейтаграммы UDP в пакет последнего фрагмента.

При ближайшем рассмотрении выглядит, что последний фрагмент этих пакетов, который не нравится Wireshark, является фрагментом длины без данных 60 (минимум). Кажется, что происходит то, что алгоритм фрагментации IP нашего стека, когда дейтаграмма вписывается во фрагменты точно (его размер кратен 1480), вместо очистки флага "последний пакет" на последнем полностью заполненном вместо этого пакет отправляет один последний пустой фрагмент с очищенным флагом «последний пакет».

enter image description here

Очевидно, что это достаточно странно, чтобы сбросить Wireshark. Но как это неправильно? Достаточно ли этого неправильно, чтобы заставить стеки получения (в данном случае некоторую версию Windows, я думаю) отбрасывать фрагменты IP? Является ли это на самом деле нарушением стандартов IPv4 для фрагментированных пакетов?

К счастью, у нас есть источники для этого стека IP, поэтому мы можем исправить это, если нам нужно.

1 Ответ

2 голосов
/ 17 марта 2020

Насколько это неправильно? Думаю, на этот вопрос сложно ответить однозначно. С технической точки зрения, я не думаю, что это само по себе неправильно, поскольку, похоже, оно не нарушает какие-либо RF C для повторной сборки фрагментов, но это, безусловно, неэффективно, и могут быть механизмы для удаления фрагментов этого Сортировать. Рассматривая различные RF C, я столкнулся со следующими соответствующими или связанными RF C:

  • RF C 791 : Inte * Протокол 1044 *
  • RF C 815 : алгоритмы сборки дейтаграмм IP
  • RF C 1858 : соображения безопасности при фильтрации фрагментов IP
  • RF C 3128 : защита от варианта атаки крошечного фрагмента

Могут быть и другие. Эти RF C не рассматривают этот конкретный случай; тем не менее, они учитывают вопросы повторной сборки и безопасности для других случаев, поэтому я полагаю, что разумнее всего будет изменить ваш стек IP, если это возможно, чтобы избежать неэффективной передачи пустой дейтаграммы. Вы не только повысите эффективность, но и избежите любых потенциальных проблем, которые могут возникнуть в этом случае. Учитывая количество устройств и IP-стеков, я бы сказал, что рискованно оставлять реализацию такой, какая она есть, но это только мое мнение.

Что касается того, почему Wireshark не собирает фрагментированные фрагменты датаграммы, это просто. IP-анализатор ( packet-ip. c) в настоящее время ожидает как минимум 1 байт полезной нагрузки. Вот соответствующий фрагмент кода из этого файла: 

  /* If ip_defragment is on, this is a fragment, we have all the data
   * in the fragment, and the header checksum is valid, then just add
   * the fragment to the hashtable.
   */
  save_fragmented = pinfo->fragmented;
  if (ip_defragment && (iph->ip_off & (IP_MF|IP_OFFSET)) &&
      iph->ip_len > hlen &&
      tvb_bytes_exist(tvb, offset, iph->ip_len - hlen) &&
      ipsum == 0) {
    ipfd_head = fragment_add_check(&ip_reassembly_table, tvb, offset,
                                   pinfo,
                                   iph->ip_proto ^ iph->ip_id ^ src32 ^ dst32 ^ pinfo->vlan_id,
                                   NULL,
                                   (iph->ip_off & IP_OFFSET) * 8,
                                   iph->ip_len - hlen,
                                   iph->ip_off & IP_MF);

    next_tvb = process_reassembled_data(tvb, offset, pinfo, "Reassembled IPv4",
                                        ipfd_head, &ip_frag_items,
                                        &update_col_info, ip_tree);
  } else {
      ...
  }

В качестве простого теста я настроил последний фрагмент пакета из двух частей так, чтобы он содержал 0 байтов. Затем я внес следующие изменения в IP-анализатор: 

  iph->ip_len >= hlen &&

После перекомпиляции Wireshark пакет был повторно собран. Итак, я считаю, что это простое изменение позволило бы Wireshark успешно собрать фрагменты того типа, который у вас есть сейчас, где последний фрагмент не содержит данных. Хотя я думаю, что ваш IP-стек все еще должен быть изменен, чтобы избежать отправки этих пустых фрагментов, я также считаю, что в соответствии с законом Постеля , что Wireshark должен быть модифицирован для обработки этого случая, хотя и с "Экспертной информацией " добавлено для обозначения этого странного пустого фрагмента, чтобы разработчики могли быть предупреждены об их неэффективных реализациях. В связи с этим я бы порекомендовал вам подать запрос об ошибке улучшения Wireshark , чтобы Wireshark могла собирать такие фрагменты.

...