Hi Damien,
On Tue, 13.04.2010 at 12:10:27 +1000, Damien Miller <d...@mindrot.org> wrote:
> On Mon, 12 Apr 2010, Toni Mueller wrote:
> > with your comments, I have produceds a second version of the patch,
> > which includes the following changes:
>
> IPsec isn't really my area, but some questions:
>
> 1) Why are these flows "illegal"? 0/0 -> 0/0 seems like it might have a
> use as a shorthand for "tunnel absolutely everything".
that is not quite true in practice. Please consider the following
scenario which exhibits the problem that I'm trying to solve:
"gatewayip" is the IP of an OpenBSD gateway, with this topology:
company lan --- OpenBSD gateway --- Internet --- road warrior (eg. at
87.186.99.179)
The following is an exerpt of 'ipsecctl -s a' on the OpenBSD gateway:
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
I was alerted to the option of getting the two lower two flows (0/0 -
0/0) blocked by using a filter entry in isakmpd.policy, but was so far
unable to get that to work. The documentation is imho a bit unclear
about this, and I can't judge whether I did something really wrong with
the configuration, or whether this is a glitch in the implementation of
isakmpd, or a behaviour mandated by some of the standards.
Now, from the road warrior's end, the first configuration mentioned
above illustrates the situation where the road warrior sends *all*
traffic towards the gateway, no matter what. This is ok, of course, and
illustrates that there is no operational requirement to have such a
"shorthand". On the other hand, though (as stated), I was unable to
prevent the gateway from installing these bogus flows which result in
the _gateway_ considering the road warrior as _its_ default gateway,
which is highly broken, of course, and not only breaks _all_other_
connectivity with the gateway, once it occurs, but also suddenly allows
the road warrior to see all traffic that the gateway might be
transferring, which could (imho: certainly) result in the road warrior
to steal information.
The status quo is that I cannot stop a user on the other side to
completely break the routing on the gateway, which is completely
unacceptable.
I have created workarounds, and my patch so far prevents such users from
establishing bogus flows, but that's about it - not the desired state of
affairs.
> 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.
> 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.
Kind regards,
--Toni++
