setkey

Victor Sudakov написал(а) к All в Apr 15 19:59:12 по местному времени:

Dear All,

Кто обладает достаточной квалификацией для чтения кода, скажите мне пожалуйста. В случае

spdadd 192.168.13.0/24 192.168.0.0/16 any
-P in ipsec esp/tunnel/x.x.x.x-y.y.y.y/unique ;

spdadd 192.168.13.0/24 192.168.11.0/24 any
-P in ipsec esp/tunnel/x.x.x.x-z.z.z.z/unique ;

матчинг будет по first match wins или по more specific prefix?


Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Serguei E. Leontiev написал(а) к Victor Sudakov в Apr 15 01:12:54 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Виктор, привет,

Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:
> Кто обладает достаточной квалификацией для чтения кода, скажите мне пожалуйста.

А надо ли в код смотреть?

> В случае
>
> spdadd 192.168.13.0/24 192.168.0.0/16 any
> -P in ipsec esp/tunnel/x.x.x.x-y.y.y.y/unique ;
>
> spdadd 192.168.13.0/24 192.168.11.0/24 any
> -P in ipsec esp/tunnel/x.x.x.x-z.z.z.z/unique ;
>
> матчинг будет по first match wins или по more specific prefix?

Если я правильно понимаю < http://tools.ietf.org/html/rfc4301#section-4.4.1
>:

The SPD is an ordered database, consistent with the use of Access
Control Lists (ACLs) or packet filters in firewalls, routers, etc.
The ordering requirement arises because entries often will overlap
due to the presence of (non-trivial) ranges as values for selectors.
Thus, a user or administrator MUST be able to order the entries to
express a desired access control policy. There is no way to impose a
general, canonical order on SPD entries, because of the allowed use
of wildcards for selector values and because the different types of
selectors are not hierarchically related.

И далее до < http://tools.ietf.org/html/rfc4301#section-4.4.1.2 >,
включительно:
An SPD is an ordered list of entries each of which contains the
following fields.


Вряд ли реализация отличается от стандарта, т.к. наличие политик
discard/none/ipsec, селектора протокола верхнего уровня и порта делает
невозможным однозначный выбор "наиболее специфичного правила".

--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
--- ifmail v.2.15dev5.4

Serguei E. Leontiev написал(а) к Serguei E. Leontiev в Apr 15 02:14:58 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

P.S.

"Serguei E. Leontiev" <leo@sai.msu.ru> wrote:
> Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:
>> Кто обладает достаточной квалификацией для чтения кода, скажите мне пожалуйста.
> А надо ли в код смотреть?
> ...
>> матчинг будет по first match wins или по more specific prefix?
> ...
> Вряд ли реализация отличается от стандарта, т.к. наличие политик
> discard/none/ipsec, селектора протокола верхнего уровня и порта делает
> невозможным однозначный выбор "наиболее специфичного правила".

Можешь сам взглянуть файл sys/netipsec/key.c <
http://fxr.watson.org/fxr/source/net....c?v=FREEBSD10 >, начиная с
функции key_spdadd() <
http://fxr.watson.org/fxr/ident?v=FR...0;i=key_spdadd >, которая
добавляет политику в один из двух линейных списков V_sptree (по
направлениям in/out). На первый взгляд, поиск по этим спискам всегда
осуществляется до первого удовлетворения пакета селектору политики.

К сожалению man на расширение протокола PF_KEY возможностью задания политик
для SPD, похоже так и никто не удосужился написать. :(

--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
--- ifmail v.2.15dev5.4