Some small OSPF changes

[Ondrej Zajicek]

On Tue, Feb 28, 2012 at 02:51:49AM +0000, Alexander V. Chernikov wrote:
> On 27.02.2012 10:20, Ondrej Zajicek wrote:
>> On Fri, Feb 24, 2012 at 11:30:19PM +0400, Alexander V. Chernikov wrote:
>>> Hello list!
>>>
>>> There are several improvements that can be applied to OSPF:
>>>
>>> 1) At the moment TTL is not explicitly set in per-interface sockets, so
>>> multicast messages are sent with default OS ttl (which is 255 on *BSD).
>> Hmm, you are right, default TTL for multicast seems to be 1 on Linux,
>> so i missed that.
>>
>>>     sk->flags = SKF_LADDR_RX;
>>> +  sk->ttl = 1;
>> This will break vlinks (they use same sockets). As TTL for unicast can
>> be different than TTL for multicast, the simplest fix would be to keep
>> sk->ttl for unicast and add a ttl arg to sk_setup_multicast(). This will
>> leave 255 TTL for unicast packets on NBMA ifaces, which is probably not
>> a big issue.
>>
>> Another possibility is to have a common independent socket
>> for vlinks, but i am not sure whether vlinks need an iface-specific
>> socket - have to be checked what are requirements for vlink
>> sockets. This would be probably better for implementing TTL
>> security later.
> Vlink sockets are not bound to interface since ospf_iface_new() are  
> called with NULL interface address (ospf.c).
...
> Are you sure ospf_sk_open() is ever called by vlink code?

It is more complicated - vlink ifaces do not have their sockets,
but when a vlink iface is activated, the socket is shared with 'proper'
OSPF iface through which the vlink goes. See ospf_check_vlinks().

> Maybe we can simply add some kind of:
>
> +  if (s->ttl == -1)
> +    s->ttl = 1;

You are right, this is probably enough. I will fix this.

>> 3) Another problem with OSPF sockets is that they depend on device
>> routes in routing tables and depend on kernel to choose proper source
>> address (if there are more IPv4 prefixes on one iface.
>>
>> In Linux, the multicast  source address is specified in IP_MULTICAST_IF or
>> IP_ADD_MEMBERSHIP, unicast source address is chosen based on dst. address.
>>
>> I am not sure, but if i remember correctly, this does not work on
>> (at least some) BSD.
>>
>> Depending on device routes is not a big problem, but makes it a bit more
>> fragile (and also a reason why we do not support _real_ unnumbered ptp
>> ifaces).
> Sorry, can't get the idea (I'm mostly unaware about multicast API). What  
> we're trying to accomplish?

The problem is not specific to multicast. There are two related but different
issues:

1) send a packet through a specific iface, regardless of a state of
the kernel routing table (device routes in the routing table in case
of a packet to a neighbors).

2) choose a proper source address for that packet.

I guess that both could be solved with SO_DONTROUTE, SO_BINDTOIFACE
(Linux specific) and/or IP_PKTINFO socket options, but IP_PKTINFO does not
work with raw sockets on some BSDs.

For multicast sockets, a source address is specified in
IP_ADD_MEMBERSHIP on Linux, but on BSD the address used in that option
is AFAIK just used to specify an iface and does not affect a source
address of sent packets.

Unfortunately, this part of socket interface is not well documented
and not really consistent between Linux and all BSDs.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120229/c9c03246/attachment-0001.asc>