GTSM (TTL security)/RFC 5082 support?

Alexander V. Chernikov melifaro at ipfw.ru
Tue Aug 16 13:32:34 CEST 2011


On 16.08.2011 19:15, Ondrej Zajicek wrote:
> On Tue, Aug 16, 2011 at 09:45:11AM +0400, Alexander V. Chernikov wrote:
>
>>> 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 don't see why - the argument of multihop option is the same value
> (number of hops - networks, not routers) as the the argument of 'ttl
> security hops' option - see attached code, just the relevant part of
> diff. Or i miss something?
Nono. You are absolutely right :) ENOSLEEP issue :)
>
> Enabled/disabled multihop has many other implications than just
> TTL, so even if TTL security is used, user have to set that
> option if BGP session is multihop.
>
>> 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.
>
> OK
>
>> There are some minor changes in bgp_open not directly related to RFC.
>
> And one bug in these changes (errcause not filled in the second case)
> ;-)
>
>>>
>>>>> 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 :)
>
> Thanks, i will do some minor clean ups and merge it with
> the boolean modification.
>
Thanks!




More information about the Bird-users mailing list