On 2010/04/13 10:24, Toni Mueller wrote:
> Working:
> --------
>
> flow esp in from 172.18.100.139 to 0.0.0.0/0 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com type use
> flow esp out from 0.0.0.0/0 to 172.18.100.139 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com type require
>
> Broken:
> -------
>
> flow esp in from 172.18.100.139 to 0.0.0.0/0 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com type use
> flow esp out from 0.0.0.0/0 to 172.18.100.139 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com type require
> flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32
> dstid uf...@example.com type use
> flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com type require
Possibly not broken:
--------------------
flow esp in from 0.0.0.0/0 to somenetwork/24 type bypass
flow esp out from somenetwork/24 to 0.0.0.0/0 type bypass
flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32
dstid uf...@example.com type use
flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32
dstid uf...@example.com type require
> > 2) Why are you implementing this in the kernel instead of isakmpd?
>
> I may be looking at iskampd, too, but since I consider this to be
> dangerous/broken behaviour by the kernel, I wanted to plug it right
> there, so no user space application can insert such bogus flows into the
> kernel.
the kernel also accepts requests to delete important system files,
change routing table entries, shutdown the machine...
IMHO isakmpd is the right place to prevent this.
> > 3) Why are you implementing this at all? Doesn't isakmpd have mechanisms
> > to prevent peers from creating undesired flows?
>
> I didn't see any. Consider this section from isakmpd.policy(5):
>
>
> remote_filter, local_filter, remote_id
> When the corresponding filter_type specifies an address range or
> subnet, these are set to the upper and lower part of the address
> space separated by a dash ('-') character (if the type specifies
> a single address, they are set to that address).
> For FQDN and User FQDN types, these are set to the respective
> string. For Key ID, these are set to the hexadecimal
> representation of the associated byte string (lower-case letters
> used) if the Key ID payload contains non-printable characters.
> Otherwise, they are set to the respective string.
> For ASN1 DN, these are set to the text encoding of the
> Distinguished Name in the payload sent or received. The format
> is the same as that used in the Licensees field.
>
>
> This, together with the description of the other "filter_*" statements,
> suggests that I cannot have an ID of UFQDN and a filter of IPV4_ADDR,
> but only ID and filters of the same type. If this understanding is
> correct then it would even be MUCH harder to do this in isakmpd while
> still allowing everyone with his own version of isakmpd to still install
> as many broken flows as he likes.
It's the phase 2 setup that you're concerned about here, and that uses
IPv4 IDs so you should be able to do this.. However isakmpd.policy *is*
complicated and hard to get right and the current ipsecctl interface
to isakmpd only deals with flows and not keynote policy.
