[Xorp-hackers] OSPF auth...

[Hasso Tepper]

Pavlin Radoslavov wrote:
>   Interestingly, in Juniper you cannot configure the RIP MD5 key ID.
>   E.g., see Juniper's "Routing Protocols Configuration Guide"
>   (Release 7.5) document, page 417, and the following email:
>
>   http://www.atm.tut.fi/list-archive/juniper-nsp/msg03544.html

It just isn't in very high place in the list of their priorities probably. 
Who uses RIP nowadays at all ;)? Especially in the routers with Junos. 

>   The Cisco solution is not really acceptable for us, not only
>   because of the extra traffic but also because it doesn't follow
>   RFC 2328.

This kind of arguments are irrelevant here. I already brought examples 
that even MUST part of RFC are ignored. Interoperability matters, that's 
all. As long as you don't create interoperability problems, you are OK. 
And note that this kind of info like key management isn't in the 
standards nowadays at all (with sentence "it isn't in the scope of this 
document") or is in separate document with note "best practice".

OSPFv2 RFC is really old, there is a lot of differences with nowadays 
implementations, but as there is no real interoperability problems yet, 
nobody will update to conform latest changes and best practices.

>   However, in other scenarios it is preferable to have expiration
>   time for the keys. E.g., think about a scenario when you want to
>   create a temporary time window (e.g., for testing purpose) for
>   someone when they are allowed to be a part of your OSPF network,
>   and after that you want to automatically revoke the MD5 key used
>   for the experiment.

I don't see the any need for such behaviour. I already said that I take 
this kind of automatic dangerous.

> Instead, we plan to use a new configurable time variable, say
> TimeSlack that is used to calculate KeyStartAccept and
> KeyStopAccept:
>
> KeyStartAccept = KeyStartGenerate - TimeSlack
> KeyStopAccept  = KeyStopGenerate + TimeSlack
>
> The TimeSlack variable will have a default value (say, 1800 secs),
> and will be configurable, but typically the user won't need to do
> anything about it.

I'm not so sure. So, instead of four selfdescriptive statements there will 
be three relevant statements in the configuration, but one of them will 
not be selfdescriptive in any way - it needs exact knowledge how this 
stuff works together.

But I have no better ideas either how to avoid "shooting into foot" 
situations and provide end-time as well.

Btw, this reminds me the question - there is some "%help: long" statements 
in templates. How to use them? Or isn't this implemented yet?


regards,

-- 
Hasso Tepper