From 8994f66557a7f53c0d808416d16ca33202ac3968 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Wed, 28 Jul 2021 12:38:49 +0300 Subject: [PATCH] Split usecases pages --- doc/index.texi | 2 +- doc/nncp.info.do | 4 +- doc/russian.texi | 2 +- doc/usecases.ru.texi | 501 -------------------------------- doc/usecases.ru/airgap.texi | 49 ++++ doc/usecases.ru/broadcast.texi | 20 ++ doc/usecases.ru/caller.texi | 45 +++ doc/usecases.ru/censor.texi | 18 ++ doc/usecases.ru/f2f.texi | 49 ++++ doc/usecases.ru/index.texi | 32 ++ doc/usecases.ru/mail.texi | 27 ++ doc/usecases.ru/multicast.texi | 83 ++++++ doc/usecases.ru/nolink.texi | 39 +++ doc/usecases.ru/pop.texi | 15 + doc/usecases.ru/qos.texi | 33 +++ doc/usecases.ru/satellite.texi | 27 ++ doc/usecases.ru/spy.texi | 39 +++ doc/usecases.ru/unreliable.texi | 26 ++ doc/usecases.texi | 477 ------------------------------ doc/usecases/airgap.texi | 45 +++ doc/usecases/broadcast.texi | 18 ++ doc/usecases/caller.texi | 46 +++ doc/usecases/censor.texi | 17 ++ doc/usecases/f2f.texi | 47 +++ doc/usecases/index.texi | 34 +++ doc/usecases/mail.texi | 25 ++ doc/usecases/multicast.texi | 81 ++++++ doc/usecases/nolink.texi | 36 +++ doc/usecases/pop.texi | 15 + doc/usecases/qos.texi | 31 ++ doc/usecases/satellite.texi | 25 ++ doc/usecases/spy.texi | 34 +++ doc/usecases/unreliable.texi | 24 ++ 33 files changed, 985 insertions(+), 981 deletions(-) delete mode 100644 doc/usecases.ru.texi create mode 100644 doc/usecases.ru/airgap.texi create mode 100644 doc/usecases.ru/broadcast.texi create mode 100644 doc/usecases.ru/caller.texi create mode 100644 doc/usecases.ru/censor.texi create mode 100644 doc/usecases.ru/f2f.texi create mode 100644 doc/usecases.ru/index.texi create mode 100644 doc/usecases.ru/mail.texi create mode 100644 doc/usecases.ru/multicast.texi create mode 100644 doc/usecases.ru/nolink.texi create mode 100644 doc/usecases.ru/pop.texi create mode 100644 doc/usecases.ru/qos.texi create mode 100644 doc/usecases.ru/satellite.texi create mode 100644 doc/usecases.ru/spy.texi create mode 100644 doc/usecases.ru/unreliable.texi delete mode 100644 doc/usecases.texi create mode 100644 doc/usecases/airgap.texi create mode 100644 doc/usecases/broadcast.texi create mode 100644 doc/usecases/caller.texi create mode 100644 doc/usecases/censor.texi create mode 100644 doc/usecases/f2f.texi create mode 100644 doc/usecases/index.texi create mode 100644 doc/usecases/mail.texi create mode 100644 doc/usecases/multicast.texi create mode 100644 doc/usecases/nolink.texi create mode 100644 doc/usecases/pop.texi create mode 100644 doc/usecases/qos.texi create mode 100644 doc/usecases/satellite.texi create mode 100644 doc/usecases/spy.texi create mode 100644 doc/usecases/unreliable.texi diff --git a/doc/index.texi b/doc/index.texi index 1fdf79b..fc2ab37 100644 --- a/doc/index.texi +++ b/doc/index.texi @@ -63,7 +63,7 @@ There are also articles about its usage outside this website: @end menu @include comparison.texi -@include usecases.texi +@include usecases/index.texi @include workflow.texi @include news.texi @include russian.texi diff --git a/doc/nncp.info.do b/doc/nncp.info.do index 0780f63..8d60761 100644 --- a/doc/nncp.info.do +++ b/doc/nncp.info.do @@ -7,7 +7,9 @@ redo-ifchange \ integration/*.texi \ pedro.txt \ pkt/*.texi \ - sp.plantuml.txt + sp.plantuml.txt \ + usecases.ru/*.texi \ + usecases/*.texi . ../config ${MAKEINFO:-makeinfo} \ -D "VERSION `cat ../VERSION`" \ diff --git a/doc/russian.texi b/doc/russian.texi index 8be9438..88a1cdc 100644 --- a/doc/russian.texi +++ b/doc/russian.texi @@ -10,5 +10,5 @@ @include about.ru.texi @include comparison.ru.texi -@include usecases.ru.texi +@include usecases.ru/index.texi @include news.ru.texi diff --git a/doc/usecases.ru.texi b/doc/usecases.ru.texi deleted file mode 100644 index 860f401..0000000 --- a/doc/usecases.ru.texi +++ /dev/null @@ -1,501 +0,0 @@ -@node Сценарии -@section Сценарии использования - -@menu -* Доступность почтового сервера время от времени: UsecaseMailRU -* Легковесная и быстрая замена POP3/IMAP4: UsecasePOPRU -* Ненадёжный/дорогой канал связи: UsecaseUnreliableRU -* Медленная/дорогая связь для больших объёмов данных, плохой QoS: UsecaseQoSRU -* Экстремальные наземные окружающие условия, нет связи: UsecaseNoLinkRU -* Односторонняя широковещательная связь: UsecaseBroadcastRU -* Спутниковые каналы связи: UsecaseSatelliteLinksRU -* Частные, изолированные MitM/Sybil-устойчивые сети: UsecaseF2FRU -* Высоко защищённые изолированные компьютеры с воздушным зазором: UsecaseAirgapRU -* Обход сетевой цензуры, здоровье: UsecaseCensorRU -* Разведка, шпионаж, тайная агентура: UsecaseSpyRU -* Дешёвая ночная связь: UsecaseCallerRU -* Мультивещательная flooding рассылка: UsecaseMulticastRU -@end menu - -@node UsecaseMailRU -@subsection Доступность почтового сервера время от времени - -Представьте, что у вас есть собственный @url{http://www.postfix.org/, -Postfix}/@url{http://www.exim.org/, Exim} SMTP сервер подключённый к -Интернету. Но вы читаете и пишете почтовые сообщения на своём ноутбуке, -который подключается к нему лишь время от времени. Как опустошить -очередь из ожидающих сообщений когда ноутбук подключён? - -Одна из возможностей это войти на сервер и сделать что-то типа -@command{postqueue -f}, но по умолчанию у вас есть только несколько дней -на это, плюс отправитель будет получать уведомления о том, что его -сообщение всё ещё не доставлено. Кроме того, вы должны использовать -безопасный канал связи (SSH, VPN, итд). - -Другая возможность это использовать POP3/IMAP4 сервер, но это слишком -переусложнённо и громоздко для такой простой задачи. Не вариант. -@url{https://ru.wikipedia.org/wiki/KISS_(%D0%BF%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF), -KISS}! - -Просто скажите вашим обоим Postfix/Exim-ам (на сервере и ноутбуке) -отправлять сообщения через NNCP (@ref{nncp-exec}) на заданный узел. -Более подробно читайте для Postfix @ref{Postfix, здесь}, а для Exim -@ref{Exim, здесь}. Вся почта будет сохранятся в NNCP @ref{Spool, спуле}, -который после обмена данных и распаковки вызовет локальный -@command{sendmail} для доставки почты, как-будто это произошло на этой -же машине. - -@node UsecasePOPRU -@subsection Легковесная и быстрая замена POP3/IMAP4 - -@ref{nncp-daemon} может быть соединён с @ref{nncp-caller} длительное -время -- он создаёт TCP соединение на многие часы. Когда SMTP сервер -получает письмо, то вызывает @ref{nncp-exec} для создания исходящего -зашифрованного пакета. Демон ежесекундно проверяет исходящую директорию -и сразу же посылает оповещение о недоставленных пакетах противоположной -стороне, которая сразу же их может скачать. - -Всего несколько дюжин байт оповещают о входящих пакетах, дюжины байт -начинающие доставку этих пакетов. Почтовые пакеты сжимаются (POP3 и -IMAP4, как правило, нет). У вас легковесный, сжатый, надёжный канал -связи с низкими задержками для почты, с сильным шифрованием и -двусторонней аутентификацией! - -@node UsecaseUnreliableRU -@subsection Ненадёжный/дорогой канал связи - -Представьте, что у вас медленный модем/радио/спутниковый канал связи, -который часто обрывается и вызывает timeout у TCP. Не все HTTP серверы -поддерживают возобновляемые скачивания. SMTP вообще не поддерживает -продолжение оборванного приёма и тяжёлые сообщения становится очень -проблематично получить. Более того, каждый обрыв может приводить к -отсылке данных с самого начала, что не всегда по карману. - -Просто отправьте вашу @ref{nncp-exec, почту} и @ref{nncp-file, файлы} -через NNCP. Вы сможете использовать или offline методы доставки -- -читайте о них в следующем разделе, либо использовать поставляемый NNCP -@ref{nncp-daemon, TCP демон}. - -Команды: - -@example -$ nncp-file file_i_want_to_send bob: -$ nncp-file another_file bob:movie.avi -@end example - -добавят в очередь отправки два файла для узла @emph{bob}. -Выстрелил-и-забыл! Теперь это работа демона (или offline передачи) -доставить частями эти файлы до удалённой системы когда она будет -доступна. - -@node UsecaseQoSRU -@subsection Медленная/дорогая связь для больших объёмов данных, плохой QoS - -Представьте, что относительно дешёвый 2 TiB переносной жёсткий диск вы -отдаёте кому-нибудь утром каждый день (и забираете назад вечером). Это -равносильно 185 мегабитному качественному однонаправленному каналу -связи. Как насчёт большего количества и бОльших жёстких дисков? Этот -метод обмена данными называется -@url{https://ru.wikipedia.org/wiki/%D0%A4%D0%BB%D0%BE%D0%BF%D0%BF%D0%B8%D0%BD%D0%B5%D1%82, -флоппинет}. - -NNCP поддерживает @ref{Niceness, приоритезацию трафика}: каждый пакет -имеет уровень "приятности", который гарантирует что он будет обработан -раньше или позднее остальных. Почти все команды имеют соответствующую -опцию: - -@example -$ nncp-file -nice FLASH myfile node:dst -$ nncp-xfer -nice PRIORITY /mnt/shared -$ nncp-call -nice NORMAL bob -[...] -@end example - -Огромные файлы могут быть разбиты на маленькие @ref{Chunked, части}, -давая возможность передачи, по сути, любых объёмов используя накопители -небольших размеров. - -Вы также можете использовать CD-ROM и ленточные накопители: - -@example -$ nncp-bundle -tx bob | cdrecord -tao - -$ nncp-bundle -tx bob | dd of=/dev/sa0 bs=10240 -@end example - -@node UsecaseNoLinkRU -@subsection Экстремальные наземные окружающие условия, нет связи - -Это, в некотором роде, вариант очень медленного канала связи. Offline -методы доставки -- единственный выбор. Просто отправьте, файлы как было -показано в предыдущем разделе, но используйте переносные накопители для -передачи пакетов другим узлам. - -Представьте, что вы послали два файла узлу @emph{bob}. Вставьте USB -устройство (SD гораздо предпочтительнее!) хранения, подмонтируйте и -запустите @ref{nncp-xfer}: - -@example -$ nncp-xfer -node bob /media/usbstick -@end example - -чтобы скопировать все исходящие пакеты относящиеся к @emph{bob}. -Используйте @option{-mkdir} опцию чтобы создать все необходимые -директории на накопителе, если их нет (например когда запускаемся первый -раз). - -Если вы используете один и тот же накопитель для передачи данных и к -@emph{bob} и к @emph{alice}, то тогда просто не указывайте -@option{-node} опцию, чтобы скопировать все доступные исходящие пакеты. - -@example -$ nncp-xfer /media/usbstick -@end example - -Размонтируйте и передайте накопитель Бобу и Алисе. Когда они вставят -накопитель в свои компьютеры, то выполнят точно такую же команду: - -@example -$ nncp-xfer /media/usbstick -@end example - -чтобы найти все пакеты относящиеся к их узлу и локально скопируют для -дальнейшей обработки. @command{nncp-xfer} это единственная команда -используемая с переносными устройствами хранения. - -@node UsecaseBroadcastRU -@subsection Односторонняя широковещательная связь - -Иногда у вас есть ёмкий, но односторонний, канал связи, например -широковещательный сигнал со спутника. Вы не можете использовать online -@ref{Sync, протокол синхронизации}, потому что он требует двустороннего -взаимодействия. - -Вы можете использовать, так называемые, @ref{Bundles, пачки} и потоково -отсылать их. Они -- всего-лишь последовательность @ref{Encrypted, -зашифрованных пакетов}, которые вы можете принять. - -@example -$ nncp-bundle -tx alice bob eve ... | команда для отправки широковещательной рассылки -$ команда для приёма широковещательной рассылки | nncp-bundle -rx -@end example - -Встроенная возможность определять дубляжи пакетов позволит вам -переотправлять широковещательные рассылки время от времени, повышая -шансы на то, что получатель примет их, регулярно слушая рассылку. - -@node UsecaseSatelliteLinksRU -@subsection Спутниковые каналы связи - -Спутниковые каналы связи имеют @strong{очень} большие задержки вместе с -высокими пропускными способностями. Вы можете посылать мегабиты данных в -секунду, но они достигнут удалённой стороны только спустя полсекунды! -Большинство протоколов обмена файлами, таких как -@url{https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol, FISH}, -@url{https://ru.wikipedia.org/wiki/FTP, FTP}, -@url{https://ru.wikipedia.org/wiki/SCP, scp}, -@url{https://en.wikipedia.org/wiki/XMODEM, XMODEM} will perform very -будут работать очень плохо из-за большого количества приёмо-передач -(round-trips). Каждая передача файла явно генерирует пакеты запросов и -подтверждений, посылаемые поверх канала связи. Удалённая сторона ничего -не будет делать пока она их не получит. Более того, не все протоколы -позволяют делать дуплексную отправку данных (когда обе стороны посылают -данные одновременно). - -@ref{Sync, Протокол синхронизации} (SP) NNCP пытается решить все эти -особенности за счёт сокращения количества приёмо-передач, количества -проходящих пакетов. Все списки файлов, запросов на скачивание файла -группируются вместе (pipelined) в один огромный пакет. Только запросы на -остановку передачи и подтверждения успешного приёма файла явно -посылаются. Можно запросить чтобы SP только принимал или отправлял -пакеты для нашей ноды. SP может игнорировать файлы с маленьким -приоритетом. Полные списки файлов отправляются уже на этапе процедуры -рукопожатия. - -@node UsecaseF2FRU -@subsection Частные, изолированные MitM/Sybil-устойчивые сети - -Все Интернет соединения могут быть прослушаны и сфальсифицированы. Вы -@strong{вынуждены} использовать шифрование и аутентификацию для -безопасности. Но очень сложно обезопасить метаданные, которые утекают -при каждой online сессии. Когда вы запускаете свой новый сверкающий -программный сервер, то имейте в виду, что может существовать огромное -количество поддельных узлов пытающихся произвести -@url{https://en.wikipedia.org/wiki/Sybil_attack, Sybil атаку}. Открытые -узел-к-узлу (peer-to-peer) сети опасны. - -Наиболее популярный криптографический протокол в Интернете это -@url{https://ru.wikipedia.org/wiki/TLS, TLS}, который крайне сложно -правильно реализовать и сконфигурировать для двусторонней аутентификации -собеседников. Не все конфигурации TLS обладают свойством -@url{https://ru.wikipedia.org/wiki/Perfect_forward_secrecy, совершенной -прямой секретности} -- все ранее перехваченные пакеты могут быть -прочтены если приватные ключи скомпрометированы. - -Друг-к-другу (friend-to-friend) сети, "тёмные сети" (darknet) могут -нивелировать возможные риски связанные с поддельными и фиктивными -узлами. Хотя они и сложнее в поддержке и требуют больше затрат на -построение. - -@ref{nncp-daemon, TCP демон} NNCP использует -@url{http://noiseprotocol.org/, Noise-IK} протокол для двусторонней -аутентификации узлов и предоставляет эффективный (оба участника могут -отослать полезную нагрузку сразу же в самом первом пакете) безопасный -транспорт с свойством совершенной прямой секретности. - -@example -$ nncp-daemon -bind "[::]":5400 -@end example - -запустит TCP демон, который будет слушать входящие соединения на всех -интерфейсах. - -@example -$ nncp-call bob -@end example - -попытается подключиться к известному TCP-адресу узла @emph{bob} (взятого -из конфигурационного файла), послать все связанные с ним исходящие -пакеты и получить от него. Все прерванные передачи будут автоматически -возобновлены. - -А наличие возможности @ref{MCD, multicast обнаружения} участников сети в -IPv6 сетях позволяет вообще не возиться с заданием сетевых адресов. - -@node UsecaseAirgapRU -@subsection Высокозащищённые изолированные компьютеры с воздушным зазором - -Если вы сильно беспокоитесь о безопасности, то компьютер с -@url{https://ru.wikipedia.org/wiki/%D0%92%D0%BE%D0%B7%D0%B4%D1%83%D1%88%D0%BD%D1%8B%D0%B9_%D0%B7%D0%B0%D0%B7%D0%BE%D1%80_(%D1%81%D0%B5%D1%82%D0%B8_%D0%BF%D0%B5%D1%80%D0%B5%D0%B4%D0%B0%D1%87%D0%B8_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85), -воздушным зазором} может будет вашим единственным позволительным -выбором. Компьютер без каких-либо модемов, проводных и беспроводных -сетей. Очевидно, что единственная возможность обмениваться почтой и -файлами -- использовать физически переносимые устройства хранения типа -CD-ROM, жёстких дисков, SD, лент и USB накопителей (@strong{худший} -вариант, из-за сложности подобных устройств). - -Предполагаем что у вас есть ещё один собственный узел, стоящий "до" -безопасного, который делает базовые проверки полученных накопителей, -возможно перезаписывая данные с USB/жёстких дисков на CD-RW. - -NNCP из коробки поддерживает ретрансляцию пакетов. - -@verbatim -neigh: { - bob: { - [...] - addrs: { - lan: "[fe80::5400%igb0]:5400" - } - } - bob-airgap: - [...] - via: ["bob"] - } -} -@end verbatim - -Такой @ref{Configuration, конфигурационный файл} говорит что у нас есть -два известных соседа: @emph{bob} и @emph{bob-airgap}. @emph{bob} -доступен через online соединение, используя @emph{lan} адрес. -@emph{bob-airgap} доступен путём посылки промежуточного ретранслируемого -пакета через узел @emph{bob}. - -Любая команда типа @command{nncp-file myfile bob-airgap:} автоматически -создаст инкапсулированный пакет: один непосредственно для целевой точки, -а другой несущий его для промежуточного узла. - -Имейте в виду, что узел-ретранслятор ничего не знает о внутреннем -пакете, кроме его полного размера и приоритета. Все промежуточные пакеты -тоже зашифрованы: используя хорошо известную технологию -@url{https://ru.wikipedia.org/wiki/%D0%9B%D1%83%D0%BA%D0%BE%D0%B2%D0%B0%D1%8F_%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F, -луковой маршрутизации}. @emph{bob} не может прочитать пакеты -@emph{bob-airgap}. - -@node UsecaseCensorRU -@subsection Обход сетевой цензуры, здоровье - -Это тоже подвид плохого канала связи. Некоторые правительства склонны к -запрету @strong{любого} вида личного (приватного) общения между людьми, -разрешая только доставку развлекательного контента и доступ к популярным -социальным сетям (которые уже вовсю наводнены рекламой, локально -исполняемым @url{https://www.gnu.org/philosophy/free-sw.ru.html, -проприетарным} JavaScript кодом (для слежкой за действиями пользователя, -сбором данных), бесстыдно и бессовестно эксплуатируя базовые потребности -человека в общении). - -Это их естественное желание. Но никто вас не заставляет насильно -подчиняться огромным корпорациям типа Apple, Google или Microsoft. Ваш -выбор это создавать изолированные друг-к-другу сети с кучами безобидного -контента и приватными сообщениями. Только хищники тихо наблюдают за -своими жертвами в мире млекопитающих -- слежка и чувство что вы жертва, -сделавшая что-то плохое, вредит вашему здоровью. - -@node UsecaseSpyRU -@subsection Разведка, шпионаж, тайная агентура - -Эти ребята знают насколько небезопасен Интернет, несовместим с -понятием приватности. Им необходим быстрый сброс и забор данных. Нет -возможности провести несколько итераций приёмо-передач (round-trips) -- -только сбросить данные, выстрелить и забыть. Опять же, это может быть -переносной накопитель и/или -@url{https://en.wikipedia.org/wiki/USB_dead_drop, USB тайник} (dead drop), -@url{https://en.wikipedia.org/wiki/PirateBox, PirateBox}ы, -@url{https://en.wikipedia.org/wiki/Short-range_agent_communications, -связь малой дальности (SRAC)}. Короткоживущие сети малой дальности типа -Bluetooth и WiFi могут быть и довольно быстрыми, позволяя быстро -"выстреливать" порциями исходящих пакетов. - -Очень важное свойство -- компрометация этих тайников или накопителей не -должна быть ни фатальна, ни даже опасна. Пакеты посылаемые через сети -или обмениваемые через устройства -- @ref{Encrypted, зашифрованы} по -принципу точка-точка (но, к сожалению, без совершенной прямой -секретности). Никаких имён файлов, получателей почтовых сообщений не -видно. - -Общение узлов между собой происходит в, так называемой, @ref{Spool, -спул} области: директории содержащей только необработанные зашифрованные -пакеты. После передачи пакета вы всё равно не сможете его прочитать: -необходимо запустить другую фазу: @ref{nncp-toss, распаковку}, которая -использует ваши приватные криптографические ключи. То есть, даже если вы -потеряете свой компьютер, устройства хранения и тому прочее -- это не -так плохо, потому что вы не носите с собой приватные ключи (ведь так?), -вы не "распаковываете" эти пакеты сразу же на том же самом устройстве. -Распаковка (чтение этих зашифрованных пакетов с извлечением переданных -файлов и почтовых сообщений) может и должна бы быть произведена на -отдельном компьютере (@ref{nncp-cfgmin} команда может помочь с созданием -конфигурационного файла без приватных ключей для этой цели). - -Если вы действительно хотите взять с собой приватные ключи, то -@ref{nncp-cfgenc} команда способна зашифровать ваш конфигурационный -файл. Парольная фраза вами введённая усиливается функцией нагружающей и -центральный процессор и память. - -@node UsecaseCallerRU -@subsection Дешёвая ночная связь - -Стоимость Интернет/телефонного трафика может варьироваться, в -зависимости от времени дня. Ночные звонки/соединения могут быть дешевле -в два раза. Вы хотите посылать ваши файлы в это время, но позволять -изредка проходить высокоприоритетной почте в любое время. А также вы -хотите проходить любому трафику когда узел доступен через ЛВС (LAN). - -Вы легко можете настроить ваши предпочтения в @ref{Call, настройках -звонков} для @ref{nncp-caller} команды, используемой при online связи. - -@verbatim -neigh: { - [...] - some-node: { - [...] - addrs: { - lan: "[fe80::be5f:f4ff:fedd:2752%igb0]:5400" - wan: "some-node.com:5400" - } - calls: [ - { - cron: "*/1 * * * *" - addr: lan - nice: MAX - onlinedeadline: 3600 - } - { - cron: "*/10 * * * *" - addr: wan - nice: PRIORITY - xx: rx - } - { - cron: "*/1 0-7 * * *" - addr: wan - nice: BULK - onlinedeadline: 3600 - maxonlinetime: 3600 - } - ] - } -} -@end verbatim - -@node UsecaseMulticastRU -@subsection Мультивещательная flooding рассылка - -Необходимо разослать одно и то же почтовое сообщение или файл многим -участникам? Например обновления какой либо программы, списка участников -сети или доступных файлов? Но при этом вы не соединены лично с каждым из -них: - -@verbatim - A-------->E---->F A <-> B C E - / \ |\ ^ C <-> H J - / \ | \ | E <-> D F G -v v v \v D <-> G -B C D---->G J <-> K - / \ ^ / K <-> D G - / \ | / - v v v / - H J<->K<- -@end verbatim - -В NNCP есть особые @ref{Multicast, мультивещательные} форматы пакетов -позволяющие организовывать эффективную передачу одно единственного -пакета сразу нескольким получателям (flooding алгоритм). @strong{A} -отправляет пакет трём получателям. @strong{C} в свою очередь отсылает -ещё двум, а @strong{E} трём. Некоторые участники сети получат несколько -копий одного и того же пакета, как например @strong{D}, @strong{J}, -@strong{G}, @strong{F}, но копии будут просто проигнорированы. Если -@strong{B} отошлёт пакет единственному ему известному @strong{A}, то -этот пакет распространится по всей сети подписантов широковещательной -зоны и дальше. - -Более того, мультивещательные пакеты зашифрованы и для прочтения требуют -знание ключей. Но это не мешает их обрабатывать для дальнейшей пересылки! -Кроме того, совершенно не обязательно знать ключи отправителя. Таким -образом можно создать эхоконференцию для передачи файлов или команд -(например доставки почтовых сообщений). - -Создаём ключи для мультивещательной зоны: - -@example -$ nncp-cfgnew -area filelists -nocomments -areas: @{ - filelists: @{ - id: TOU5TKOW4JBIZJBX63D4776C72FMWDAUAUSZNJX4DFOITVYQ5ZQA - pub: DSHL5O6BK2R3QKJAIJ7BC4UIGE73EC2LJPOV3VTS44KYOTUQYZLA - prv: AYD5FAA4GDDSAD5N65NJLLFS6TG2NSPQ46KAQO5U722JLVG34SOQ - @} -@} -@end example - -и отправляем ключевую пару всем кто может и хочет читать данную зону. -Посредникам, готовым участвовать в переотправке пакетов подписантам, но -которым не стоит "читать" пакеты, достаточно отправить только -идентификатор зоны. Например @strong{A} добавляет себе в конфигурацию: - -@example -areas: @{ - filelists: @{ - id: TOU... - pub: DSH... - prv: AYD... - subs: ["B", "C", "E"] - incoming: /home/A/areas/filelists - @} -@end example - -а @strong{E}, являющимся (как было решено) просто посредником: - -@example -areas: @{ - filelists: @{ - id: TOU... - subs: ["D", "F", "G"] - @} -@end example - -После распространения знания о @code{filelists} мультивещательной зоне -можно обмениваться @ref{FreqIndex, списками файлов}: - -@example -$ nncp-file tree-of-A-20210715.txt.zst area:filelists: -$ nncp-toss -node self -@end example diff --git a/doc/usecases.ru/airgap.texi b/doc/usecases.ru/airgap.texi new file mode 100644 index 0000000..a6591d6 --- /dev/null +++ b/doc/usecases.ru/airgap.texi @@ -0,0 +1,49 @@ +@node UsecaseAirgapRU +@subsection Высокозащищённые изолированные компьютеры с воздушным зазором + +Если вы сильно беспокоитесь о безопасности, то компьютер с +@url{https://ru.wikipedia.org/wiki/%D0%92%D0%BE%D0%B7%D0%B4%D1%83%D1%88%D0%BD%D1%8B%D0%B9_%D0%B7%D0%B0%D0%B7%D0%BE%D1%80_(%D1%81%D0%B5%D1%82%D0%B8_%D0%BF%D0%B5%D1%80%D0%B5%D0%B4%D0%B0%D1%87%D0%B8_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85), +воздушным зазором} может будет вашим единственным позволительным +выбором. Компьютер без каких-либо модемов, проводных и беспроводных +сетей. Очевидно, что единственная возможность обмениваться почтой и +файлами -- использовать физически переносимые устройства хранения типа +CD-ROM, жёстких дисков, SD, лент и USB накопителей (@strong{худший} +вариант, из-за сложности подобных устройств). + +Предполагаем что у вас есть ещё один собственный узел, стоящий "до" +безопасного, который делает базовые проверки полученных накопителей, +возможно перезаписывая данные с USB/жёстких дисков на CD-RW. + +NNCP из коробки поддерживает ретрансляцию пакетов. + +@verbatim +neigh: { + bob: { + [...] + addrs: { + lan: "[fe80::5400%igb0]:5400" + } + } + bob-airgap: + [...] + via: ["bob"] + } +} +@end verbatim + +Такой @ref{Configuration, конфигурационный файл} говорит что у нас есть +два известных соседа: @emph{bob} и @emph{bob-airgap}. @emph{bob} +доступен через online соединение, используя @emph{lan} адрес. +@emph{bob-airgap} доступен путём посылки промежуточного ретранслируемого +пакета через узел @emph{bob}. + +Любая команда типа @command{nncp-file myfile bob-airgap:} автоматически +создаст инкапсулированный пакет: один непосредственно для целевой точки, +а другой несущий его для промежуточного узла. + +Имейте в виду, что узел-ретранслятор ничего не знает о внутреннем +пакете, кроме его полного размера и приоритета. Все промежуточные пакеты +тоже зашифрованы: используя хорошо известную технологию +@url{https://ru.wikipedia.org/wiki/%D0%9B%D1%83%D0%BA%D0%BE%D0%B2%D0%B0%D1%8F_%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F, +луковой маршрутизации}. @emph{bob} не может прочитать пакеты +@emph{bob-airgap}. diff --git a/doc/usecases.ru/broadcast.texi b/doc/usecases.ru/broadcast.texi new file mode 100644 index 0000000..5b97a4d --- /dev/null +++ b/doc/usecases.ru/broadcast.texi @@ -0,0 +1,20 @@ +@node UsecaseBroadcastRU +@subsection Односторонняя широковещательная связь + +Иногда у вас есть ёмкий, но односторонний, канал связи, например +широковещательный сигнал со спутника. Вы не можете использовать online +@ref{Sync, протокол синхронизации}, потому что он требует двустороннего +взаимодействия. + +Вы можете использовать, так называемые, @ref{Bundles, пачки} и потоково +отсылать их. Они -- всего-лишь последовательность @ref{Encrypted, +зашифрованных пакетов}, которые вы можете принять. + +@example +$ nncp-bundle -tx alice bob eve @dots{} | команда для отправки широковещательной рассылки +$ команда для приёма широковещательной рассылки | nncp-bundle -rx +@end example + +Встроенная возможность определять дубляжи пакетов позволит вам +переотправлять широковещательные рассылки время от времени, повышая +шансы на то, что получатель примет их, регулярно слушая рассылку. diff --git a/doc/usecases.ru/caller.texi b/doc/usecases.ru/caller.texi new file mode 100644 index 0000000..af80359 --- /dev/null +++ b/doc/usecases.ru/caller.texi @@ -0,0 +1,45 @@ +@node UsecaseCallerRU +@subsection Дешёвая ночная связь + +Стоимость Интернет/телефонного трафика может варьироваться, в +зависимости от времени дня. Ночные звонки/соединения могут быть дешевле +в два раза. Вы хотите посылать ваши файлы в это время, но позволять +изредка проходить высокоприоритетной почте в любое время. А также вы +хотите проходить любому трафику когда узел доступен через ЛВС (LAN). + +Вы легко можете настроить ваши предпочтения в @ref{Call, настройках +звонков} для @ref{nncp-caller} команды, используемой при online связи. + +@verbatim +neigh: { + [...] + some-node: { + [...] + addrs: { + lan: "[fe80::be5f:f4ff:fedd:2752%igb0]:5400" + wan: "some-node.com:5400" + } + calls: [ + { + cron: "*/1 * * * *" + addr: lan + nice: MAX + onlinedeadline: 3600 + } + { + cron: "*/10 * * * *" + addr: wan + nice: PRIORITY + xx: rx + } + { + cron: "*/1 0-7 * * *" + addr: wan + nice: BULK + onlinedeadline: 3600 + maxonlinetime: 3600 + } + ] + } +} +@end verbatim diff --git a/doc/usecases.ru/censor.texi b/doc/usecases.ru/censor.texi new file mode 100644 index 0000000..1a5a95e --- /dev/null +++ b/doc/usecases.ru/censor.texi @@ -0,0 +1,18 @@ +@node UsecaseCensorRU +@subsection Обход сетевой цензуры, здоровье + +Это тоже подвид плохого канала связи. Некоторые правительства склонны к +запрету @strong{любого} вида личного (приватного) общения между людьми, +разрешая только доставку развлекательного контента и доступ к популярным +социальным сетям (которые уже вовсю наводнены рекламой, локально +исполняемым @url{https://www.gnu.org/philosophy/free-sw.ru.html, +проприетарным} JavaScript кодом (для слежкой за действиями пользователя, +сбором данных), бесстыдно и бессовестно эксплуатируя базовые потребности +человека в общении). + +Это их естественное желание. Но никто вас не заставляет насильно +подчиняться огромным корпорациям типа Apple, Google или Microsoft. Ваш +выбор это создавать изолированные друг-к-другу сети с кучами безобидного +контента и приватными сообщениями. Только хищники тихо наблюдают за +своими жертвами в мире млекопитающих -- слежка и чувство что вы жертва, +сделавшая что-то плохое, вредит вашему здоровью. diff --git a/doc/usecases.ru/f2f.texi b/doc/usecases.ru/f2f.texi new file mode 100644 index 0000000..0eb8bb8 --- /dev/null +++ b/doc/usecases.ru/f2f.texi @@ -0,0 +1,49 @@ +@node UsecaseF2FRU +@subsection Частные, изолированные MitM/Sybil-устойчивые сети + +Все Интернет соединения могут быть прослушаны и сфальсифицированы. Вы +@strong{вынуждены} использовать шифрование и аутентификацию для +безопасности. Но очень сложно обезопасить метаданные, которые утекают +при каждой online сессии. Когда вы запускаете свой новый сверкающий +программный сервер, то имейте в виду, что может существовать огромное +количество поддельных узлов пытающихся произвести +@url{https://en.wikipedia.org/wiki/Sybil_attack, Sybil атаку}. Открытые +узел-к-узлу (peer-to-peer) сети опасны. + +Наиболее популярный криптографический протокол в Интернете это +@url{https://ru.wikipedia.org/wiki/TLS, TLS}, который крайне сложно +правильно реализовать и сконфигурировать для двусторонней аутентификации +собеседников. Не все конфигурации TLS обладают свойством +@url{https://ru.wikipedia.org/wiki/Perfect_forward_secrecy, совершенной +прямой секретности} -- все ранее перехваченные пакеты могут быть +прочтены если приватные ключи скомпрометированы. + +Друг-к-другу (friend-to-friend) сети, "тёмные сети" (darknet) могут +нивелировать возможные риски связанные с поддельными и фиктивными +узлами. Хотя они и сложнее в поддержке и требуют больше затрат на +построение. + +@ref{nncp-daemon, TCP демон} NNCP использует +@url{http://noiseprotocol.org/, Noise-IK} протокол для двусторонней +аутентификации узлов и предоставляет эффективный (оба участника могут +отослать полезную нагрузку сразу же в самом первом пакете) безопасный +транспорт с свойством совершенной прямой секретности. + +@example +$ nncp-daemon -bind "[::]":5400 +@end example + +запустит TCP демон, который будет слушать входящие соединения на всех +интерфейсах. + +@example +$ nncp-call bob +@end example + +попытается подключиться к известному TCP-адресу узла @emph{bob} (взятого +из конфигурационного файла), послать все связанные с ним исходящие +пакеты и получить от него. Все прерванные передачи будут автоматически +возобновлены. + +А наличие возможности @ref{MCD, multicast обнаружения} участников сети в +IPv6 сетях позволяет вообще не возиться с заданием сетевых адресов. diff --git a/doc/usecases.ru/index.texi b/doc/usecases.ru/index.texi new file mode 100644 index 0000000..7aecbea --- /dev/null +++ b/doc/usecases.ru/index.texi @@ -0,0 +1,32 @@ +@node Сценарии +@section Сценарии использования + +@menu +* Доступность почтового сервера время от времени: UsecaseMailRU +* Легковесная и быстрая замена POP3/IMAP4: UsecasePOPRU +* Ненадёжный/дорогой канал связи: UsecaseUnreliableRU +* Медленная/дорогая связь для больших объёмов данных, плохой QoS: UsecaseQoSRU +* Экстремальные наземные окружающие условия, нет связи: UsecaseNoLinkRU +* Односторонняя широковещательная связь: UsecaseBroadcastRU +* Спутниковые каналы связи: UsecaseSatelliteLinksRU +* Частные, изолированные MitM/Sybil-устойчивые сети: UsecaseF2FRU +* Высоко защищённые изолированные компьютеры с воздушным зазором: UsecaseAirgapRU +* Обход сетевой цензуры, здоровье: UsecaseCensorRU +* Разведка, шпионаж, тайная агентура: UsecaseSpyRU +* Дешёвая ночная связь: UsecaseCallerRU +* Мультивещательная flooding рассылка: UsecaseMulticastRU +@end menu + +@include usecases.ru/mail.texi +@include usecases.ru/pop.texi +@include usecases.ru/unreliable.texi +@include usecases.ru/qos.texi +@include usecases.ru/nolink.texi +@include usecases.ru/broadcast.texi +@include usecases.ru/satellite.texi +@include usecases.ru/f2f.texi +@include usecases.ru/airgap.texi +@include usecases.ru/censor.texi +@include usecases.ru/spy.texi +@include usecases.ru/caller.texi +@include usecases.ru/multicast.texi diff --git a/doc/usecases.ru/mail.texi b/doc/usecases.ru/mail.texi new file mode 100644 index 0000000..48a3474 --- /dev/null +++ b/doc/usecases.ru/mail.texi @@ -0,0 +1,27 @@ +@node UsecaseMailRU +@subsection Доступность почтового сервера время от времени + +Представьте, что у вас есть собственный @url{http://www.postfix.org/, +Postfix}/@url{http://www.exim.org/, Exim} SMTP сервер подключённый к +Интернету. Но вы читаете и пишете почтовые сообщения на своём ноутбуке, +который подключается к нему лишь время от времени. Как опустошить +очередь из ожидающих сообщений когда ноутбук подключён? + +Одна из возможностей это войти на сервер и сделать что-то типа +@command{postqueue -f}, но по умолчанию у вас есть только несколько дней +на это, плюс отправитель будет получать уведомления о том, что его +сообщение всё ещё не доставлено. Кроме того, вы должны использовать +безопасный канал связи (SSH, VPN, итд). + +Другая возможность это использовать POP3/IMAP4 сервер, но это слишком +переусложнённо и громоздко для такой простой задачи. Не вариант. +@url{https://ru.wikipedia.org/wiki/KISS_(%D0%BF%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF), +KISS}! + +Просто скажите вашим обоим Postfix/Exim-ам (на сервере и ноутбуке) +отправлять сообщения через NNCP (@ref{nncp-exec}) на заданный узел. +Более подробно читайте для Postfix @ref{Postfix, здесь}, а для Exim +@ref{Exim, здесь}. Вся почта будет сохранятся в NNCP @ref{Spool, спуле}, +который после обмена данных и распаковки вызовет локальный +@command{sendmail} для доставки почты, как-будто это произошло на этой +же машине. diff --git a/doc/usecases.ru/multicast.texi b/doc/usecases.ru/multicast.texi new file mode 100644 index 0000000..86b17cb --- /dev/null +++ b/doc/usecases.ru/multicast.texi @@ -0,0 +1,83 @@ +@node UsecaseMulticastRU +@subsection Мультивещательная flooding рассылка + +Необходимо разослать одно и то же почтовое сообщение или файл многим +участникам? Например обновления какой либо программы, списка участников +сети или доступных файлов? Но при этом вы не соединены лично с каждым из +них: + +@verbatim + A-------->E---->F A <-> B C E + / \ |\ ^ C <-> H J + / \ | \ | E <-> D F G +v v v \v D <-> G +B C D---->G J <-> K + / \ ^ / K <-> D G + / \ | / + v v v / + H J<->K<- +@end verbatim + +В NNCP есть особые @ref{Multicast, мультивещательные} форматы пакетов +позволяющие организовывать эффективную передачу одно единственного +пакета сразу нескольким получателям (flooding алгоритм). @strong{A} +отправляет пакет трём получателям. @strong{C} в свою очередь отсылает +ещё двум, а @strong{E} трём. Некоторые участники сети получат несколько +копий одного и того же пакета, как например @strong{D}, @strong{J}, +@strong{G}, @strong{F}, но копии будут просто проигнорированы. Если +@strong{B} отошлёт пакет единственному ему известному @strong{A}, то +этот пакет распространится по всей сети подписантов широковещательной +зоны и дальше. + +Более того, мультивещательные пакеты зашифрованы и для прочтения требуют +знание ключей. Но это не мешает их обрабатывать для дальнейшей пересылки! +Кроме того, совершенно не обязательно знать ключи отправителя. Таким +образом можно создать эхоконференцию для передачи файлов или команд +(например доставки почтовых сообщений). + +Создаём ключи для мультивещательной зоны: + +@verbatim +$ nncp-cfgnew -area filelists -nocomments +areas: { + filelists: { + id: TOU5TKOW4JBIZJBX63D4776C72FMWDAUAUSZNJX4DFOITVYQ5ZQA + pub: DSHL5O6BK2R3QKJAIJ7BC4UIGE73EC2LJPOV3VTS44KYOTUQYZLA + prv: AYD5FAA4GDDSAD5N65NJLLFS6TG2NSPQ46KAQO5U722JLVG34SOQ + } +} +@end verbatim + +и отправляем ключевую пару всем кто может и хочет читать данную зону. +Посредникам, готовым участвовать в переотправке пакетов подписантам, но +которым не стоит "читать" пакеты, достаточно отправить только +идентификатор зоны. Например @strong{A} добавляет себе в конфигурацию: + +@verbatim +areas: { + filelists: { + id: TOU... + pub: DSH... + prv: AYD... + subs: ["B", "C", "E"] + incoming: /home/A/areas/filelists + } +@end verbatim + +а @strong{E}, являющимся (как было решено) просто посредником: + +@verbatim +areas: { + filelists: { + id: TOU... + subs: ["D", "F", "G"] + } +@end verbatim + +После распространения знания о @code{filelists} мультивещательной зоне +можно обмениваться @ref{FreqIndex, списками файлов}: + +@example +$ nncp-file tree-of-A-20210715.txt.zst area:filelists: +$ nncp-toss -node self +@end example diff --git a/doc/usecases.ru/nolink.texi b/doc/usecases.ru/nolink.texi new file mode 100644 index 0000000..bacc7c0 --- /dev/null +++ b/doc/usecases.ru/nolink.texi @@ -0,0 +1,39 @@ +@node UsecaseNoLinkRU +@subsection Экстремальные наземные окружающие условия, нет связи + +Это, в некотором роде, вариант очень медленного канала связи. Offline +методы доставки -- единственный выбор. Просто отправьте, файлы как было +показано в предыдущем разделе, но используйте переносные накопители для +передачи пакетов другим узлам. + +Представьте, что вы послали два файла узлу @emph{bob}. Вставьте USB +устройство (SD гораздо предпочтительнее!) хранения, подмонтируйте и +запустите @ref{nncp-xfer}: + +@example +$ nncp-xfer -node bob /media/usbstick +@end example + +чтобы скопировать все исходящие пакеты относящиеся к @emph{bob}. +Используйте @option{-mkdir} опцию чтобы создать все необходимые +директории на накопителе, если их нет (например когда запускаемся первый +раз). + +Если вы используете один и тот же накопитель для передачи данных и к +@emph{bob} и к @emph{alice}, то тогда просто не указывайте +@option{-node} опцию, чтобы скопировать все доступные исходящие пакеты. + +@example +$ nncp-xfer /media/usbstick +@end example + +Размонтируйте и передайте накопитель Бобу и Алисе. Когда они вставят +накопитель в свои компьютеры, то выполнят точно такую же команду: + +@example +$ nncp-xfer /media/usbstick +@end example + +чтобы найти все пакеты относящиеся к их узлу и локально скопируют для +дальнейшей обработки. @command{nncp-xfer} это единственная команда +используемая с переносными устройствами хранения. diff --git a/doc/usecases.ru/pop.texi b/doc/usecases.ru/pop.texi new file mode 100644 index 0000000..98a9312 --- /dev/null +++ b/doc/usecases.ru/pop.texi @@ -0,0 +1,15 @@ +@node UsecasePOPRU +@subsection Легковесная и быстрая замена POP3/IMAP4 + +@ref{nncp-daemon} может быть соединён с @ref{nncp-caller} длительное +время -- он создаёт TCP соединение на многие часы. Когда SMTP сервер +получает письмо, то вызывает @ref{nncp-exec} для создания исходящего +зашифрованного пакета. Демон ежесекундно проверяет исходящую директорию +и сразу же посылает оповещение о недоставленных пакетах противоположной +стороне, которая сразу же их может скачать. + +Всего несколько дюжин байт оповещают о входящих пакетах, дюжины байт +начинающие доставку этих пакетов. Почтовые пакеты сжимаются (POP3 и +IMAP4, как правило, нет). У вас легковесный, сжатый, надёжный канал +связи с низкими задержками для почты, с сильным шифрованием и +двусторонней аутентификацией! diff --git a/doc/usecases.ru/qos.texi b/doc/usecases.ru/qos.texi new file mode 100644 index 0000000..4b67c73 --- /dev/null +++ b/doc/usecases.ru/qos.texi @@ -0,0 +1,33 @@ +@node UsecaseQoSRU +@subsection Медленная/дорогая связь для больших объёмов данных, плохой QoS + +Представьте, что относительно дешёвый 2 TiB переносной жёсткий диск вы +отдаёте кому-нибудь утром каждый день (и забираете назад вечером). Это +равносильно 185 мегабитному качественному однонаправленному каналу +связи. Как насчёт большего количества и бОльших жёстких дисков? Этот +метод обмена данными называется +@url{https://ru.wikipedia.org/wiki/%D0%A4%D0%BB%D0%BE%D0%BF%D0%BF%D0%B8%D0%BD%D0%B5%D1%82, +флоппинет}. + +NNCP поддерживает @ref{Niceness, приоритезацию трафика}: каждый пакет +имеет уровень "приятности", который гарантирует что он будет обработан +раньше или позднее остальных. Почти все команды имеют соответствующую +опцию: + +@example +$ nncp-file -nice FLASH myfile node:dst +$ nncp-xfer -nice PRIORITY /mnt/shared +$ nncp-call -nice NORMAL bob +[@dots{}] +@end example + +Огромные файлы могут быть разбиты на маленькие @ref{Chunked, части}, +давая возможность передачи, по сути, любых объёмов используя накопители +небольших размеров. + +Вы также можете использовать CD-ROM и ленточные накопители: + +@example +$ nncp-bundle -tx bob | cdrecord -tao - +$ nncp-bundle -tx bob | dd of=/dev/sa0 bs=10240 +@end example diff --git a/doc/usecases.ru/satellite.texi b/doc/usecases.ru/satellite.texi new file mode 100644 index 0000000..749a5e7 --- /dev/null +++ b/doc/usecases.ru/satellite.texi @@ -0,0 +1,27 @@ +@node UsecaseSatelliteLinksRU +@subsection Спутниковые каналы связи + +Спутниковые каналы связи имеют @strong{очень} большие задержки вместе с +высокими пропускными способностями. Вы можете посылать мегабиты данных в +секунду, но они достигнут удалённой стороны только спустя полсекунды! +Большинство протоколов обмена файлами, таких как +@url{https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol, FISH}, +@url{https://ru.wikipedia.org/wiki/FTP, FTP}, +@url{https://ru.wikipedia.org/wiki/SCP, scp}, +@url{https://en.wikipedia.org/wiki/XMODEM, XMODEM} will perform very +будут работать очень плохо из-за большого количества приёмо-передач +(round-trips). Каждая передача файла явно генерирует пакеты запросов и +подтверждений, посылаемые поверх канала связи. Удалённая сторона ничего +не будет делать пока она их не получит. Более того, не все протоколы +позволяют делать дуплексную отправку данных (когда обе стороны посылают +данные одновременно). + +@ref{Sync, Протокол синхронизации} (SP) NNCP пытается решить все эти +особенности за счёт сокращения количества приёмо-передач, количества +проходящих пакетов. Все списки файлов, запросов на скачивание файла +группируются вместе (pipelined) в один огромный пакет. Только запросы на +остановку передачи и подтверждения успешного приёма файла явно +посылаются. Можно запросить чтобы SP только принимал или отправлял +пакеты для нашей ноды. SP может игнорировать файлы с маленьким +приоритетом. Полные списки файлов отправляются уже на этапе процедуры +рукопожатия. diff --git a/doc/usecases.ru/spy.texi b/doc/usecases.ru/spy.texi new file mode 100644 index 0000000..a81035b --- /dev/null +++ b/doc/usecases.ru/spy.texi @@ -0,0 +1,39 @@ +@node UsecaseSpyRU +@subsection Разведка, шпионаж, тайная агентура + +Эти ребята знают насколько небезопасен Интернет, несовместим с +понятием приватности. Им необходим быстрый сброс и забор данных. Нет +возможности провести несколько итераций приёмо-передач (round-trips) -- +только сбросить данные, выстрелить и забыть. Опять же, это может быть +переносной накопитель и/или +@url{https://en.wikipedia.org/wiki/USB_dead_drop, USB тайник} (dead drop), +@url{https://en.wikipedia.org/wiki/PirateBox, PirateBox}ы, +@url{https://en.wikipedia.org/wiki/Short-range_agent_communications, +связь малой дальности (SRAC)}. Короткоживущие сети малой дальности типа +Bluetooth и WiFi могут быть и довольно быстрыми, позволяя быстро +"выстреливать" порциями исходящих пакетов. + +Очень важное свойство -- компрометация этих тайников или накопителей не +должна быть ни фатальна, ни даже опасна. Пакеты посылаемые через сети +или обмениваемые через устройства -- @ref{Encrypted, зашифрованы} по +принципу точка-точка (но, к сожалению, без совершенной прямой +секретности). Никаких имён файлов, получателей почтовых сообщений не +видно. + +Общение узлов между собой происходит в, так называемой, @ref{Spool, +спул} области: директории содержащей только необработанные зашифрованные +пакеты. После передачи пакета вы всё равно не сможете его прочитать: +необходимо запустить другую фазу: @ref{nncp-toss, распаковку}, которая +использует ваши приватные криптографические ключи. То есть, даже если вы +потеряете свой компьютер, устройства хранения и тому прочее -- это не +так плохо, потому что вы не носите с собой приватные ключи (ведь так?), +вы не "распаковываете" эти пакеты сразу же на том же самом устройстве. +Распаковка (чтение этих зашифрованных пакетов с извлечением переданных +файлов и почтовых сообщений) может и должна бы быть произведена на +отдельном компьютере (@ref{nncp-cfgmin} команда может помочь с созданием +конфигурационного файла без приватных ключей для этой цели). + +Если вы действительно хотите взять с собой приватные ключи, то +@ref{nncp-cfgenc} команда способна зашифровать ваш конфигурационный +файл. Парольная фраза вами введённая усиливается функцией нагружающей и +центральный процессор и память. diff --git a/doc/usecases.ru/unreliable.texi b/doc/usecases.ru/unreliable.texi new file mode 100644 index 0000000..22542e0 --- /dev/null +++ b/doc/usecases.ru/unreliable.texi @@ -0,0 +1,26 @@ +@node UsecaseUnreliableRU +@subsection Ненадёжный/дорогой канал связи + +Представьте, что у вас медленный модем/радио/спутниковый канал связи, +который часто обрывается и вызывает timeout у TCP. Не все HTTP серверы +поддерживают возобновляемые скачивания. SMTP вообще не поддерживает +продолжение оборванного приёма и тяжёлые сообщения становится очень +проблематично получить. Более того, каждый обрыв может приводить к +отсылке данных с самого начала, что не всегда по карману. + +Просто отправьте вашу @ref{nncp-exec, почту} и @ref{nncp-file, файлы} +через NNCP. Вы сможете использовать или offline методы доставки -- +читайте о них в следующем разделе, либо использовать поставляемый NNCP +@ref{nncp-daemon, TCP демон}. + +Команды: + +@example +$ nncp-file file_i_want_to_send bob: +$ nncp-file another_file bob:movie.avi +@end example + +добавят в очередь отправки два файла для узла @emph{bob}. +Выстрелил-и-забыл! Теперь это работа демона (или offline передачи) +доставить частями эти файлы до удалённой системы когда она будет +доступна. diff --git a/doc/usecases.texi b/doc/usecases.texi deleted file mode 100644 index f676e89..0000000 --- a/doc/usecases.texi +++ /dev/null @@ -1,477 +0,0 @@ -@node Use cases -@unnumbered Use cases - -See also this page @ref{Сценарии, on russian}. - -@menu -* Occasional connection to mail server: UsecaseMail -* Lightweight fast POP3/IMAP4 replacement: UsecasePOP -* Unreliable/expensive communication link: UsecaseUnreliable -* Slow/expensive link for high-volume data, bad QoS: UsecaseQoS -* Extreme terrestrial environments, no link: UsecaseNoLink -* One-way broadcasting communications: UsecaseBroadcast -* Satellite links: UsecaseSatelliteLinks -* Private, isolated MitM/Sybil-resistant networks: UsecaseF2F -* Highly secure isolated air-gap computers: UsecaseAirgap -* Network censorship bypassing, health: UsecaseCensor -* Reconnaissance, spying, intelligence, covert agents: UsecaseSpy -* Cheap night transfers: UsecaseCaller -* Multicast flooding transmission: UsecaseMulticast -@end menu - -@node UsecaseMail -@section Occasional connection to mail server - -Assume that you have got your own @url{http://www.postfix.org/, -Postfix}/@url{http://www.exim.org/, Exim} SMTP server connected to the -Internet. But you read and write emails on your notebook, that is -connected to it just from time to time. How can you flush buffered mail -queues when your notebook is connected? - -One possibility is to log in and run something like @command{postqueue --f}, but by default you have got only several days so and sender will -receive notification emails that his messages still are not delivered -yet. Also you must have secure link (SSH, VPN, etc). - -Another possibility is to use POP3/IMAP4 servers, but this is too -overcomplicated and bloated for the simple task. Not an option. -@url{https://en.wikipedia.org/wiki/KISS_principle, KISS}! - -Just tell both of your Postfix/Exim (on the server and notebook) to drop -email as a mail via NNCP (@ref{nncp-exec}) to specified node. - -More information for Postfix is @ref{Postfix, here} and for Exim is -@ref{Exim, here}. All mail will be stored in NNCP @ref{Spool, spool}, -that after exchanging and tossing will call local @command{sendmail} -command to deliver them just like that happened on the same machine. - -@node UsecasePOP -@section Lightweight fast POP3/IMAP4 replacement - -@ref{nncp-daemon} can be connected with @ref{nncp-caller} for a long -time -- it can create TCP connection that lasts for many hours. When -SMTP server receives mail, it will call @ref{nncp-exec} creating an -outbound encrypted packet. Daemon checks outbound directory each second -and immediately sends notification about undelivered packets to remote -side, that also downloads it at once. - -There are only dozens of bytes notifying about incoming packets, dozens -of bytes telling to download those packets. Mail packets are compressed -(POP3 and IMAP4 as a rule do not). You have lightweight, compressed, -low-delay, reliable link for the mail with strong encryption and mutual -sides authentication! - -@node UsecaseUnreliable -@section Unreliable/expensive communication link - -Assume that you have got slow modem/radio/cellular link that frequently -disconnects and causes TCP timeouts. Not all HTTP servers support file -download continuation. SMTP does not support resuming at all and heavy -messages is problematic to retrieve. Moreover, each disconnect leads to -the same data retransmission again, that can not be afforded sometimes. - -Just send your @ref{nncp-exec, mail} and @ref{nncp-file, files} through -NNCP. You can use either offline delivery methods -- read about them in -the next section, or you can use included NNCP @ref{nncp-daemon, TCP -daemon}. - -The command: - -@example -$ nncp-file file_i_want_to_send bob: -$ nncp-file another_file bob:movie.avi -@end example - -will queue two files for sending to @emph{bob} node. Fire and forget! -Now this is daemon's job (or offline transfer) to send this files part -by part to remote system when it is available. - -@node UsecaseQoS -@section Slow/expensive link for high-volume data, bad QoS - -Assume that you can give your relatively cheap 2 TiB removable hard -drive to someone each day at the morning (and take it back at the -evening). This equals to 185 Mbps good quality (without any speed -degradation) link in single direction. What about more and bigger hard -drives? This type of data exchange is called -@url{https://en.wikipedia.org/wiki/Sneakernet, sneakernet}/floppynet. - -NNCP allows traffic @ref{Niceness, prioritizing}: each packet has -niceness level, that will guarantee that it will be processed earlier or -later than the other ones. Nearly all commands has corresponding option: - -@example -$ nncp-file -nice FLASH myfile node:dst -$ nncp-xfer -nice PRIORITY /mnt/shared -$ nncp-call -nice NORMAL bob -[...] -@end example - -Huge files could be split on smaller @ref{Chunked, chunks}, giving -possibility to transfer virtually any volumes using small capacity -storages. - -You can also use CD-ROM and tape drives: - -@example -$ nncp-bundle -tx bob | cdrecord -tao - -$ nncp-bundle -tx bob | dd of=/dev/sa0 bs=10240 -@end example - -@node UsecaseNoLink -@section Extreme terrestrial environments, no link - -This is some kind of too slow link. Offline delivery methods is the only -choice. Just send files as shown in previous section, but use removable -media for transferring packets to other nodes. - -Assume that you send two files to @emph{bob} node. Insert USB storage -device (SD is preferable!), mount it and run @ref{nncp-xfer}: - -@example -$ nncp-xfer -node bob /media/usbstick -@end example - -to copy all outbound packets related to @emph{bob}. Use @option{-mkdir} -option to create related directory on USB/SD storage if they are missing -(for example when running for the first time). - -If you use single storage device to transfer data both to @emph{bob} and -@emph{alice}, then just omit @option{-node} option to copy all available -outgoing packets. - -@example -$ nncp-xfer /media/usbstick -@end example - -Unmount it and transfer storage to Bob and Alice. When they will insert -it in their computers, they will use exactly the same command: - -@example -$ nncp-xfer /media/usbstick -@end example - -to find all packets related to their node and copy them locally for -further processing. @command{nncp-xfer} is the only command used with -removable devices. - -@node UsecaseBroadcast -@section One-way broadcasting communications - -Sometimes you have got high-bandwidth but unidirectional link, for -example, satellite's broadcasting signal. You are not able to use online -@ref{Sync, synchronization protocol} because it requires mutual interaction. - -You can use @ref{Bundles, bundles} and stream them above. They are just -a sequence of @ref{Encrypted, encrypted packets} you can catch on. - -@example -$ nncp-bundle -tx alice bob eve ... | command to send broadcast -$ command to receive broadcast | nncp-bundle -rx -@end example - -With built-in packet duplicates detection ability, you can retransmit -your broadcasts from time to time, to increase chances the recipient -will catch them by regular stream listening. - -@node UsecaseSatelliteLinks -@section Satellite links - -Satellite links have @strong{very} high delays together with high -bandwidths. You can send several megabits of data per second, but they -will reach the remote side only after half a second! -Most file sharing protocols like -@url{https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol, FISH}, -@url{https://en.wikipedia.org/wiki/FTP, FTP}, -@url{https://en.wikipedia.org/wiki/Secure_copy, scp}, -@url{https://en.wikipedia.org/wiki/XMODEM, XMODEM} -will perform very badly because of round-trips quantity. Each file -transmission explicitly generates request and acknowledgement packets -that are send over the link. Remote side won't do anything until it -receives them. Moreover not all protocols allow duplex data -transmission (when both sides are sending data simultaneously). - -NNCP's @ref{Sync, synchronization protocol} (SP) tries to mitigate all -that issues by reducing number of round-trips, number of packets passing -through. All file lists, file download requests are grouped together -(pipelined) in one huge packet. Only transmission halt and successful -file download acknowledgements are sent explicitly. SP could be asked -only either to upload or download packets for our node. SP could ignore -files with low priority. Full files listing is passing even during the -handshake procedure. - -@node UsecaseF2F -@section Private, isolated MitM/Sybil-resistant networks - -All Internet connections can be eavesdropped and forged. You -@strong{have to} to use encryption and authentication for securing them. -But it is very hard to secure metadata, that leaks during each online -session. When you start your shiny new software server be sure that -there could be huge quantity of bogus peers trying to perform -@url{https://en.wikipedia.org/wiki/Sybil_attack, Sybil attack}. Opennet -peer-to-peer networking is dangerous thing to do. - -The most popular cryptographic protocol in Internet is -@url{https://en.wikipedia.org/wiki/Transport_Layer_Security, TLS} that -is very hard to implement correctly and hard to configure for mutual -participants authentication. Not all TLS configurations and related -protocols provide @url{https://en.wikipedia.org/wiki/Forward_secrecy, -forward secrecy} property -- all previously intercepted packets could be -read if private keys are compromised. - -Friend-to-friend networks, darknets can mitigate risks related to fake -and forged nodes. However they are harder to support and require more -time to be done right. - -NNCP's @ref{nncp-daemon, TCP daemon} uses -@url{http://noiseprotocol.org/, Noise-IK} protocol to mutually -authenticate peers and provide effective (both participants send payload -in the very first packet) secure transport with forward secrecy -property. - -@example -$ nncp-daemon -bind "[::]":5400 -@end example - -will start TCP daemon listening on all interfaces for incoming -connections. - -@example -$ nncp-call bob -@end example - -will try to connect to @emph{bob}'s node known TCP addresses (taken from -configuration file) and send all related outbound packets and retrieve -those the Bob has. All interrupted transfers will be automatically -resumed. - -Ability to do @ref{MCD, multicast nodes discovery} of participant in -IPv6 networks allows complete ignorance of network addresses specifying. - -@node UsecaseAirgap -@section Highly secure isolated air-gap computers - -If you worry much about security, then air-gapped computer could be the -only choice you can afford. Computer without any modems, wired and -wireless networks. Obviously the only possibility to exchange mail and -files is to use physically removable storage devices like CD-ROM, hard -drive, SD, tape and USB flash drives (@strong{worst} choice, due to -those devices complexity). - -Presumably you have got another own hop before that computer: another -intermediate node which performs basic verification of retrieved storage -devices, possibly by rewriting the data from USB/hard drives to CD-RWs. - -NNCP supports packets relying (transitioning) out-of-box. - -@verbatim -neigh: { - bob: { - [...] - addrs: { - lan: "[fe80::5400%igb0]:5400" - } - } - bob-airgap: - [...] - via: ["bob"] - } -} -@end verbatim - -That @ref{Configuration, configuration file} tells that we have got two -known neighbours: @emph{bob} and @emph{bob-airgap}. @emph{bob} can be -reached via online connection using @emph{lan} address. -@emph{bob-airgap} can be reached by sending intermediate relay packet -through the @emph{bob}. - -Any command like @command{nncp-file myfile bob-airgap:} will -automatically create an encapsulated packet: one for the destination -endpoint, and other carrying it for intermediate relaying node. - -Pay attention that relaying node knows nothing about the packet inside, -but just its size and priority. Transition packets are encrypted too: -using well-known @url{https://en.wikipedia.org/wiki/Onion_routing, onion -routing} technology. @emph{bob} can not read @emph{bob-airgap}'s packets. - -@node UsecaseCensor -@section Network censorship bypassing, health - -This is some kind of bad link too. Some governments tend to forbid -@strong{any} kind of private communication between people, allowing only -entertainment content delivering and popular social networks access -(that are already bloated with advertisements, locally executed -@url{https://www.gnu.org/philosophy/free-sw.html, proprietary} -JavaScript code (for spying on user activities, collect data on them), -shamelessly exploiting the very basic human need of communication). - -This is their natural wish. But nobody forces you to obey huge -corporations like Apple, Google or Microsoft. It is your choice to -create an isolated friend-to-friend network with piles of harmless -content and private messaging. Only predators silently watch for their -victims in mammals world -- it harms your health being watched and -feeling that you are the victim that has already done something wrong. - -@node UsecaseSpy -@section Reconnaissance, spying, intelligence, covert agents - -Those guys know how Internet is a dangerous place incompatible with -privacy. They require quick, fast dropping and picking of data. No -possibility of many round-trips -- just drop the data, fire-and-forget. -It could be either removable media again and/or -@url{https://en.wikipedia.org/wiki/USB_dead_drop, USB dead drops}, -@url{https://en.wikipedia.org/wiki/PirateBox, PirateBox}es, -@url{https://en.wikipedia.org/wiki/Short-range_agent_communications, SRAC}. -Short lived short range networks like Bluetooth and WiFi can also -be pretty fast, allowing to quickly fire chunks of queued packets. - -Very important property is that compromising of those dead drops and -storages must be neither fatal nor even dangerous. Packets sent through -the network and exchanged via those devices are end-to-end -@ref{Encrypted, encrypted} (but unfortunately lacking forward secrecy). -No filenames, mail recipients are seen. - -All node communications are done with so-called @ref{Spool, spool} area: -directory containing only those unprocessed encrypted packets. After -packet transfer you still can not read any of them: you have to run -another stage: @ref{nncp-toss, tossing}, that involves your private -cryptographic keys. So even if your loose your computer, storage devices -and so on -- it is not so bad, because you are not carrying private keys -with it (don't you?), you do not "toss" those packets immediately on the -same device. Tossing (reading those encrypted packets and extracting -transferred files and mail messages) could and should be done on a -separate computer (@ref{nncp-cfgmin} command could help creating -configuration file without private keys for that purpose). - -If you really want to carry your private keys, then @ref{nncp-cfgenc} -command will be able to encrypt your configuration file. Passphrase you -enter is strengthened with both CPU and memory hard function. - -@node UsecaseCaller -@section Cheap night transfers - -Your Internet/telephone traffic price can vary, depending on daytime. -Night calls/connections could be twice as cheaper. You wish to send your -files at that time, but keep high priority email infrequently passing -through in anytime. Also you wish to pass any kind of traffic when the -node is available through the LAN. - -You can easily set your preferences in @ref{Call, call -configurations} for @ref{nncp-caller} command used in online -communications. - -@verbatim -neigh: { - [...] - some-node: { - [...] - addrs: { - lan: "[fe80::be5f:f4ff:fedd:2752%igb0]:5400" - wan: "some-node.com:5400" - } - calls: [ - { - cron: "*/1 * * * *" - addr: lan - nice: MAX - onlinedeadline: 3600 - } - { - cron: "*/10 * * * *" - addr: wan - nice: PRIORITY - xx: rx - } - { - cron: "*/1 0-7 * * *" - addr: wan - nice: BULK - onlinedeadline: 3600 - maxonlinetime: 3600 - } - ] - } -} -@end verbatim - -@node UsecaseMulticast -@section Multicast flooding transmission - -Do you need to send single mail message or file to many recipients at -once? For example an update of some program, network participants list -or available files for freqing? But you are not connected directly to -each of them? - -@verbatim - A-------->E---->F A -> B C E - / \ |\ ^ C -> H J - / \ | \ | E -> D F G -v v v \v D -> G -B C D---->G J -> K - / \ ^ / K -> D G - / \ | / - v v v / - H J<->K<- -@end verbatim - -NNCP has @ref{Multicast, multicast} packets format, allowing you to -flood transmission of the single packet to multiple recipients. -@strong{A} sends packet to three destinations. @strong{C} sends it to -the two nodes next. @strong{E} sends it to three. Some participants may -receive multiple copies of the same packet, like @strong{D}, @strong{J}, -@strong{G}, @strong{F}, but that copies will be just ignored. If -@strong{B} sends packet to single known to him @strong{A}, then that -packet will be distributed among all other multicast area subscribers. - -Moreover those multicast packets are encrypted and require key knowledge -for reading. But that does not prevent their relaying! Also you are not -required to know sender's public keys. That way you can easily create -echo-conferences for files or commands (like mail message delivering) -transmission. - -Let's create keys for the new multicast area: - -@example -$ nncp-cfgnew -area filelists -nocomments -areas: @{ - filelists: @{ - id: TOU5TKOW4JBIZJBX63D4776C72FMWDAUAUSZNJX4DFOITVYQ5ZQA - pub: DSHL5O6BK2R3QKJAIJ7BC4UIGE73EC2LJPOV3VTS44KYOTUQYZLA - prv: AYD5FAA4GDDSAD5N65NJLLFS6TG2NSPQ46KAQO5U722JLVG34SOQ - @} -@} -@end example - -and send that keypair everybody who wants to read that area. -For intermediaries willing to relay packets on, but that should not read -them, you just need to send area's identity. For example @strong{A} adds -to his configuration: - -@example -areas: @{ - filelists: @{ - id: TOU... - pub: DSH... - prv: AYD... - subs: ["B", "C", "E"] - incoming: /home/A/areas/filelists - @} -@end example - -and @strong{E}, that will be relaying intermediary (as we decided): - -@example -areas: @{ - filelists: @{ - id: TOU... - subs: ["D", "F", "G"] - @} -@end example - -After you distributed the knowledge about @code{nodelist} multicast -area, you can share @ref{FreqIndex, file lists}: - -@example -$ nncp-file tree-of-A-20210715.txt.zst area:filelists: -$ nncp-toss -node self -@end example diff --git a/doc/usecases/airgap.texi b/doc/usecases/airgap.texi new file mode 100644 index 0000000..2c75d19 --- /dev/null +++ b/doc/usecases/airgap.texi @@ -0,0 +1,45 @@ +@node UsecaseAirgap +@section Highly secure isolated air-gap computers + +If you worry much about security, then air-gapped computer could be the +only choice you can afford. Computer without any modems, wired and +wireless networks. Obviously the only possibility to exchange mail and +files is to use physically removable storage devices like CD-ROM, hard +drive, SD, tape and USB flash drives (@strong{worst} choice, due to +those devices complexity). + +Presumably you have got another own hop before that computer: another +intermediate node which performs basic verification of retrieved storage +devices, possibly by rewriting the data from USB/hard drives to CD-RWs. + +NNCP supports packets relying (transitioning) out-of-box. + +@verbatim +neigh: { + bob: { + [...] + addrs: { + lan: "[fe80::5400%igb0]:5400" + } + } + bob-airgap: + [...] + via: ["bob"] + } +} +@end verbatim + +That @ref{Configuration, configuration file} tells that we have got two +known neighbours: @emph{bob} and @emph{bob-airgap}. @emph{bob} can be +reached via online connection using @emph{lan} address. +@emph{bob-airgap} can be reached by sending intermediate relay packet +through the @emph{bob}. + +Any command like @command{nncp-file myfile bob-airgap:} will +automatically create an encapsulated packet: one for the destination +endpoint, and other carrying it for intermediate relaying node. + +Pay attention that relaying node knows nothing about the packet inside, +but just its size and priority. Transition packets are encrypted too: +using well-known @url{https://en.wikipedia.org/wiki/Onion_routing, onion +routing} technology. @emph{bob} can not read @emph{bob-airgap}'s packets. diff --git a/doc/usecases/broadcast.texi b/doc/usecases/broadcast.texi new file mode 100644 index 0000000..a6c32f8 --- /dev/null +++ b/doc/usecases/broadcast.texi @@ -0,0 +1,18 @@ +@node UsecaseBroadcast +@section One-way broadcasting communications + +Sometimes you have got high-bandwidth but unidirectional link, for +example, satellite's broadcasting signal. You are not able to use online +@ref{Sync, synchronization protocol} because it requires mutual interaction. + +You can use @ref{Bundles, bundles} and stream them above. They are just +a sequence of @ref{Encrypted, encrypted packets} you can catch on. + +@example +$ nncp-bundle -tx alice bob eve @dots{} | command to send broadcast +$ command to receive broadcast | nncp-bundle -rx +@end example + +With built-in packet duplicates detection ability, you can retransmit +your broadcasts from time to time, to increase chances the recipient +will catch them by regular stream listening. diff --git a/doc/usecases/caller.texi b/doc/usecases/caller.texi new file mode 100644 index 0000000..df40dce --- /dev/null +++ b/doc/usecases/caller.texi @@ -0,0 +1,46 @@ +@node UsecaseCaller +@section Cheap night transfers + +Your Internet/telephone traffic price can vary, depending on daytime. +Night calls/connections could be twice as cheaper. You wish to send your +files at that time, but keep high priority email infrequently passing +through in anytime. Also you wish to pass any kind of traffic when the +node is available through the LAN. + +You can easily set your preferences in @ref{Call, call +configurations} for @ref{nncp-caller} command used in online +communications. + +@verbatim +neigh: { + [...] + some-node: { + [...] + addrs: { + lan: "[fe80::be5f:f4ff:fedd:2752%igb0]:5400" + wan: "some-node.com:5400" + } + calls: [ + { + cron: "*/1 * * * *" + addr: lan + nice: MAX + onlinedeadline: 3600 + } + { + cron: "*/10 * * * *" + addr: wan + nice: PRIORITY + xx: rx + } + { + cron: "*/1 0-7 * * *" + addr: wan + nice: BULK + onlinedeadline: 3600 + maxonlinetime: 3600 + } + ] + } +} +@end verbatim diff --git a/doc/usecases/censor.texi b/doc/usecases/censor.texi new file mode 100644 index 0000000..c32225f --- /dev/null +++ b/doc/usecases/censor.texi @@ -0,0 +1,17 @@ +@node UsecaseCensor +@section Network censorship bypassing, health + +This is some kind of bad link too. Some governments tend to forbid +@strong{any} kind of private communication between people, allowing only +entertainment content delivering and popular social networks access +(that are already bloated with advertisements, locally executed +@url{https://www.gnu.org/philosophy/free-sw.html, proprietary} +JavaScript code (for spying on user activities, collect data on them), +shamelessly exploiting the very basic human need of communication). + +This is their natural wish. But nobody forces you to obey huge +corporations like Apple, Google or Microsoft. It is your choice to +create an isolated friend-to-friend network with piles of harmless +content and private messaging. Only predators silently watch for their +victims in mammals world -- it harms your health being watched and +feeling that you are the victim that has already done something wrong. diff --git a/doc/usecases/f2f.texi b/doc/usecases/f2f.texi new file mode 100644 index 0000000..7d53e04 --- /dev/null +++ b/doc/usecases/f2f.texi @@ -0,0 +1,47 @@ +@node UsecaseF2F +@section Private, isolated MitM/Sybil-resistant networks + +All Internet connections can be eavesdropped and forged. You +@strong{have to} to use encryption and authentication for securing them. +But it is very hard to secure metadata, that leaks during each online +session. When you start your shiny new software server be sure that +there could be huge quantity of bogus peers trying to perform +@url{https://en.wikipedia.org/wiki/Sybil_attack, Sybil attack}. Opennet +peer-to-peer networking is dangerous thing to do. + +The most popular cryptographic protocol in Internet is +@url{https://en.wikipedia.org/wiki/Transport_Layer_Security, TLS} that +is very hard to implement correctly and hard to configure for mutual +participants authentication. Not all TLS configurations and related +protocols provide @url{https://en.wikipedia.org/wiki/Forward_secrecy, +forward secrecy} property -- all previously intercepted packets could be +read if private keys are compromised. + +Friend-to-friend networks, darknets can mitigate risks related to fake +and forged nodes. However they are harder to support and require more +time to be done right. + +NNCP's @ref{nncp-daemon, TCP daemon} uses +@url{http://noiseprotocol.org/, Noise-IK} protocol to mutually +authenticate peers and provide effective (both participants send payload +in the very first packet) secure transport with forward secrecy +property. + +@example +$ nncp-daemon -bind "[::]":5400 +@end example + +will start TCP daemon listening on all interfaces for incoming +connections. + +@example +$ nncp-call bob +@end example + +will try to connect to @emph{bob}'s node known TCP addresses (taken from +configuration file) and send all related outbound packets and retrieve +those the Bob has. All interrupted transfers will be automatically +resumed. + +Ability to do @ref{MCD, multicast nodes discovery} of participant in +IPv6 networks allows complete ignorance of network addresses specifying. diff --git a/doc/usecases/index.texi b/doc/usecases/index.texi new file mode 100644 index 0000000..938908f --- /dev/null +++ b/doc/usecases/index.texi @@ -0,0 +1,34 @@ +@node Use cases +@unnumbered Use cases + +See also this page @ref{Сценарии, on russian}. + +@menu +* Occasional connection to mail server: UsecaseMail +* Lightweight fast POP3/IMAP4 replacement: UsecasePOP +* Unreliable/expensive communication link: UsecaseUnreliable +* Slow/expensive link for high-volume data, bad QoS: UsecaseQoS +* Extreme terrestrial environments, no link: UsecaseNoLink +* One-way broadcasting communications: UsecaseBroadcast +* Satellite links: UsecaseSatelliteLinks +* Private, isolated MitM/Sybil-resistant networks: UsecaseF2F +* Highly secure isolated air-gap computers: UsecaseAirgap +* Network censorship bypassing, health: UsecaseCensor +* Reconnaissance, spying, intelligence, covert agents: UsecaseSpy +* Cheap night transfers: UsecaseCaller +* Multicast flooding transmission: UsecaseMulticast +@end menu + +@include usecases/mail.texi +@include usecases/pop.texi +@include usecases/unreliable.texi +@include usecases/qos.texi +@include usecases/nolink.texi +@include usecases/broadcast.texi +@include usecases/satellite.texi +@include usecases/f2f.texi +@include usecases/airgap.texi +@include usecases/censor.texi +@include usecases/spy.texi +@include usecases/caller.texi +@include usecases/multicast.texi diff --git a/doc/usecases/mail.texi b/doc/usecases/mail.texi new file mode 100644 index 0000000..2336136 --- /dev/null +++ b/doc/usecases/mail.texi @@ -0,0 +1,25 @@ +@node UsecaseMail +@section Occasional connection to mail server + +Assume that you have got your own @url{http://www.postfix.org/, +Postfix}/@url{http://www.exim.org/, Exim} SMTP server connected to the +Internet. But you read and write emails on your notebook, that is +connected to it just from time to time. How can you flush buffered mail +queues when your notebook is connected? + +One possibility is to log in and run something like @command{postqueue +-f}, but by default you have got only several days so and sender will +receive notification emails that his messages still are not delivered +yet. Also you must have secure link (SSH, VPN, etc). + +Another possibility is to use POP3/IMAP4 servers, but this is too +overcomplicated and bloated for the simple task. Not an option. +@url{https://en.wikipedia.org/wiki/KISS_principle, KISS}! + +Just tell both of your Postfix/Exim (on the server and notebook) to drop +email as a mail via NNCP (@ref{nncp-exec}) to specified node. + +More information for Postfix is @ref{Postfix, here} and for Exim is +@ref{Exim, here}. All mail will be stored in NNCP @ref{Spool, spool}, +that after exchanging and tossing will call local @command{sendmail} +command to deliver them just like that happened on the same machine. diff --git a/doc/usecases/multicast.texi b/doc/usecases/multicast.texi new file mode 100644 index 0000000..8c3bf31 --- /dev/null +++ b/doc/usecases/multicast.texi @@ -0,0 +1,81 @@ +@node UsecaseMulticast +@section Multicast flooding transmission + +Do you need to send single mail message or file to many recipients at +once? For example an update of some program, network participants list +or available files for freqing? But you are not connected directly to +each of them? + +@verbatim + A-------->E---->F A -> B C E + / \ |\ ^ C -> H J + / \ | \ | E -> D F G +v v v \v D -> G +B C D---->G J -> K + / \ ^ / K -> D G + / \ | / + v v v / + H J<->K<- +@end verbatim + +NNCP has @ref{Multicast, multicast} packets format, allowing you to +flood transmission of the single packet to multiple recipients. +@strong{A} sends packet to three destinations. @strong{C} sends it to +the two nodes next. @strong{E} sends it to three. Some participants may +receive multiple copies of the same packet, like @strong{D}, @strong{J}, +@strong{G}, @strong{F}, but that copies will be just ignored. If +@strong{B} sends packet to single known to him @strong{A}, then that +packet will be distributed among all other multicast area subscribers. + +Moreover those multicast packets are encrypted and require key knowledge +for reading. But that does not prevent their relaying! Also you are not +required to know sender's public keys. That way you can easily create +echo-conferences for files or commands (like mail message delivering) +transmission. + +Let's create keys for the new multicast area: + +@verbatim +$ nncp-cfgnew -area filelists -nocomments +areas: { + filelists: { + id: TOU5TKOW4JBIZJBX63D4776C72FMWDAUAUSZNJX4DFOITVYQ5ZQA + pub: DSHL5O6BK2R3QKJAIJ7BC4UIGE73EC2LJPOV3VTS44KYOTUQYZLA + prv: AYD5FAA4GDDSAD5N65NJLLFS6TG2NSPQ46KAQO5U722JLVG34SOQ + } +} +@end verbatim + +and send that keypair everybody who wants to read that area. +For intermediaries willing to relay packets on, but that should not read +them, you just need to send area's identity. For example @strong{A} adds +to his configuration: + +@verbatim +areas: { + filelists: { + id: TOU... + pub: DSH... + prv: AYD... + subs: ["B", "C", "E"] + incoming: /home/A/areas/filelists + } +@end verbatim + +and @strong{E}, that will be relaying intermediary (as we decided): + +@verbatim +areas: { + filelists: { + id: TOU... + subs: ["D", "F", "G"] + } +@end verbatim + +After you distributed the knowledge about @code{nodelist} multicast +area, you can share @ref{FreqIndex, file lists}: + +@example +$ nncp-file tree-of-A-20210715.txt.zst area:filelists: +$ nncp-toss -node self +@end example diff --git a/doc/usecases/nolink.texi b/doc/usecases/nolink.texi new file mode 100644 index 0000000..7886e81 --- /dev/null +++ b/doc/usecases/nolink.texi @@ -0,0 +1,36 @@ +@node UsecaseNoLink +@section Extreme terrestrial environments, no link + +This is some kind of too slow link. Offline delivery methods is the only +choice. Just send files as shown in previous section, but use removable +media for transferring packets to other nodes. + +Assume that you send two files to @emph{bob} node. Insert USB storage +device (SD is preferable!), mount it and run @ref{nncp-xfer}: + +@example +$ nncp-xfer -node bob /media/usbstick +@end example + +to copy all outbound packets related to @emph{bob}. Use @option{-mkdir} +option to create related directory on USB/SD storage if they are missing +(for example when running for the first time). + +If you use single storage device to transfer data both to @emph{bob} and +@emph{alice}, then just omit @option{-node} option to copy all available +outgoing packets. + +@example +$ nncp-xfer /media/usbstick +@end example + +Unmount it and transfer storage to Bob and Alice. When they will insert +it in their computers, they will use exactly the same command: + +@example +$ nncp-xfer /media/usbstick +@end example + +to find all packets related to their node and copy them locally for +further processing. @command{nncp-xfer} is the only command used with +removable devices. diff --git a/doc/usecases/pop.texi b/doc/usecases/pop.texi new file mode 100644 index 0000000..5edc3e8 --- /dev/null +++ b/doc/usecases/pop.texi @@ -0,0 +1,15 @@ +@node UsecasePOP +@section Lightweight fast POP3/IMAP4 replacement + +@ref{nncp-daemon} can be connected with @ref{nncp-caller} for a long +time -- it can create TCP connection that lasts for many hours. When +SMTP server receives mail, it will call @ref{nncp-exec} creating an +outbound encrypted packet. Daemon checks outbound directory each second +and immediately sends notification about undelivered packets to remote +side, that also downloads it at once. + +There are only dozens of bytes notifying about incoming packets, dozens +of bytes telling to download those packets. Mail packets are compressed +(POP3 and IMAP4 as a rule do not). You have lightweight, compressed, +low-delay, reliable link for the mail with strong encryption and mutual +sides authentication! diff --git a/doc/usecases/qos.texi b/doc/usecases/qos.texi new file mode 100644 index 0000000..8089888 --- /dev/null +++ b/doc/usecases/qos.texi @@ -0,0 +1,31 @@ +@node UsecaseQoS +@section Slow/expensive link for high-volume data, bad QoS + +Assume that you can give your relatively cheap 2 TiB removable hard +drive to someone each day at the morning (and take it back at the +evening). This equals to 185 Mbps good quality (without any speed +degradation) link in single direction. What about more and bigger hard +drives? This type of data exchange is called +@url{https://en.wikipedia.org/wiki/Sneakernet, sneakernet}/floppynet. + +NNCP allows traffic @ref{Niceness, prioritizing}: each packet has +niceness level, that will guarantee that it will be processed earlier or +later than the other ones. Nearly all commands has corresponding option: + +@example +$ nncp-file -nice FLASH myfile node:dst +$ nncp-xfer -nice PRIORITY /mnt/shared +$ nncp-call -nice NORMAL bob +[@dots{}] +@end example + +Huge files could be split on smaller @ref{Chunked, chunks}, giving +possibility to transfer virtually any volumes using small capacity +storages. + +You can also use CD-ROM and tape drives: + +@example +$ nncp-bundle -tx bob | cdrecord -tao - +$ nncp-bundle -tx bob | dd of=/dev/sa0 bs=10240 +@end example diff --git a/doc/usecases/satellite.texi b/doc/usecases/satellite.texi new file mode 100644 index 0000000..d152a3b --- /dev/null +++ b/doc/usecases/satellite.texi @@ -0,0 +1,25 @@ +@node UsecaseSatelliteLinks +@section Satellite links + +Satellite links have @strong{very} high delays together with high +bandwidths. You can send several megabits of data per second, but they +will reach the remote side only after half a second! +Most file sharing protocols like +@url{https://en.wikipedia.org/wiki/Files_transferred_over_shell_protocol, FISH}, +@url{https://en.wikipedia.org/wiki/FTP, FTP}, +@url{https://en.wikipedia.org/wiki/Secure_copy, scp}, +@url{https://en.wikipedia.org/wiki/XMODEM, XMODEM} +will perform very badly because of round-trips quantity. Each file +transmission explicitly generates request and acknowledgement packets +that are send over the link. Remote side won't do anything until it +receives them. Moreover not all protocols allow duplex data +transmission (when both sides are sending data simultaneously). + +NNCP's @ref{Sync, synchronization protocol} (SP) tries to mitigate all +that issues by reducing number of round-trips, number of packets passing +through. All file lists, file download requests are grouped together +(pipelined) in one huge packet. Only transmission halt and successful +file download acknowledgements are sent explicitly. SP could be asked +only either to upload or download packets for our node. SP could ignore +files with low priority. Full files listing is passing even during the +handshake procedure. diff --git a/doc/usecases/spy.texi b/doc/usecases/spy.texi new file mode 100644 index 0000000..b1e1de8 --- /dev/null +++ b/doc/usecases/spy.texi @@ -0,0 +1,34 @@ +@node UsecaseSpy +@section Reconnaissance, spying, intelligence, covert agents + +Those guys know how Internet is a dangerous place incompatible with +privacy. They require quick, fast dropping and picking of data. No +possibility of many round-trips -- just drop the data, fire-and-forget. +It could be either removable media again and/or +@url{https://en.wikipedia.org/wiki/USB_dead_drop, USB dead drops}, +@url{https://en.wikipedia.org/wiki/PirateBox, PirateBox}es, +@url{https://en.wikipedia.org/wiki/Short-range_agent_communications, SRAC}. +Short lived short range networks like Bluetooth and WiFi can also +be pretty fast, allowing to quickly fire chunks of queued packets. + +Very important property is that compromising of those dead drops and +storages must be neither fatal nor even dangerous. Packets sent through +the network and exchanged via those devices are end-to-end +@ref{Encrypted, encrypted} (but unfortunately lacking forward secrecy). +No filenames, mail recipients are seen. + +All node communications are done with so-called @ref{Spool, spool} area: +directory containing only those unprocessed encrypted packets. After +packet transfer you still can not read any of them: you have to run +another stage: @ref{nncp-toss, tossing}, that involves your private +cryptographic keys. So even if your loose your computer, storage devices +and so on -- it is not so bad, because you are not carrying private keys +with it (don't you?), you do not "toss" those packets immediately on the +same device. Tossing (reading those encrypted packets and extracting +transferred files and mail messages) could and should be done on a +separate computer (@ref{nncp-cfgmin} command could help creating +configuration file without private keys for that purpose). + +If you really want to carry your private keys, then @ref{nncp-cfgenc} +command will be able to encrypt your configuration file. Passphrase you +enter is strengthened with both CPU and memory hard function. diff --git a/doc/usecases/unreliable.texi b/doc/usecases/unreliable.texi new file mode 100644 index 0000000..93a40d9 --- /dev/null +++ b/doc/usecases/unreliable.texi @@ -0,0 +1,24 @@ +@node UsecaseUnreliable +@section Unreliable/expensive communication link + +Assume that you have got slow modem/radio/cellular link that frequently +disconnects and causes TCP timeouts. Not all HTTP servers support file +download continuation. SMTP does not support resuming at all and heavy +messages is problematic to retrieve. Moreover, each disconnect leads to +the same data retransmission again, that can not be afforded sometimes. + +Just send your @ref{nncp-exec, mail} and @ref{nncp-file, files} through +NNCP. You can use either offline delivery methods -- read about them in +the next section, or you can use included NNCP @ref{nncp-daemon, TCP +daemon}. + +The command: + +@example +$ nncp-file file_i_want_to_send bob: +$ nncp-file another_file bob:movie.avi +@end example + +will queue two files for sending to @emph{bob} node. Fire and forget! +Now this is daemon's job (or offline transfer) to send this files part +by part to remote system when it is available. -- 2.44.0