GTSM (TTL security)/RFC 5082 support?

Alexander V. Chernikov melifaro at ipfw.ru
Tue Aug 16 07:45:11 CEST 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ondrej Zajicek wrote:
> On Sun, Aug 14, 2011 at 07:26:36PM +0400, Alexander V. Chernikov wrote:
>>>> +    if (sk_set_min_ttl(s, p->cf->min_ttl) != 0)
>>>> +    {
>>>> +      log(L_ERR "TTL security configuration failed, closing session");
>>>> +      bgp_sock_err(s, 0);
>>>> +      return;
>>>> +    }
>>>> +  }
>>> Shouldn't be better to set min TTL before sk_open?
>> Not sure. Not many callers need this, so adding another min_ttl field
>> seems unnecessary IMHO. Anyway, you will need to specify minimum ttl
>> directly in case of new connection from listening socket.
> 
> You are right.
> 
>>> Perhaps TTL SECURITY HOPS, or just MIN TTL?
>> 'TTL SECURITY HOPS' sounds good and is at least used by cisco.
>>> (MIN TTL is probably much better name as we do not specify the number
>>> of hops, but the complement (255 - hops), if i understand it correctly.)
>>>
>> Well, actually we're specifying minimal TTL packet needs to have in its
>> packet header to be accepted. Packets with lower TTL are silently dropped.
>>
>> If we name this option 'min ttl' or 'min hops' it will:
>>
>> * be confised with 'multihop' option
>> * not be associated with enabling TTL security
>>
>> We can also make 'TTL SECURITY' boolean option and use 'multihop' option
>> value (like 255 - hops + 1)
> 
> This is probably the best alternative. Note that 'multihop' value is 
> an original TTL (i.e. a path length in number of networks/edges),
> so it would be: multihop ? 256 - multihop : 255 .
Unfortunately, we can't distinguish between enabled/disabled multihop if
 ttl security is on :(


I've also set listening socket TTL to 255 since it is required by RFC
(from ttlsec-enabled neithbour SA received from bird can definitely be
associated with protected session and dropped if its TTL is not within
range).
We can increase socket TTL conditionally though it will require a bit
more code (initial configuration/reconfiguration) but I see no problem
in increased (64->255) TTL.

There are some minor changes in bgp_open not directly related to RFC.


> 
>>> The new config option should be also documented in doc/bird.sgml .
>> Should I supply updated patch?
> 
> That would be great (esp. if it would contain updated documentation ;-) ).
> 
Done :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk5KA+cACgkQwcJ4iSZ1q2lURACWL2A2ZByuQvQlcD22sSUAh/wH
/ACdHi34hXiv1Ki8hU6Y1iZUfAC02ac=
=jLE4
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bird_ttlsec_20110816.diff
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20110816/6b70254b/attachment-0001.diff>


More information about the Bird-users mailing list