[Xorp-hackers] OSPF auth...

Pavlin Radoslavov pavlin@icir.org
Mon, 20 Mar 2006 17:18:53 -0800


> >   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. 

I hope you are not going to recommend us to remove our RIP
implementation ;)

> >   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".

The example you gave about RFC 2328 Appendix B is about changing
protocol parameters. This is typically allowed when
implementing/configuring a protocol.
The Cisco's change I am referring to is about a not-so elegant
deviation from the spec.

> >   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.

I understand that in your production environment (and probably
everybody else's) you want strict control.
With our solution we don't take this control away from you.

You could always set the start-time to the value you want and ignore
end-time and the new TimeSlack: the end time of the key becomes
infinity (as in Juniper). The only difference from Juniper's
behavior would be that the KeyStartAccept time will be, say, 30
minutes before the router starts generating the packets with that
key (rather than starting to accept the packets NOW as in Juniper).

Consider the end-time and TimeSlack mechanism as an extention that
may not be useful for you (or for production environment in
general), but useful for people who are playing and testing things
with OSPF.

> > 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.

This is more of a documentation issue.

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

If somebody is really messing with the configuration, then they should
know what they are doing :)

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

Good question. I guess the original idea was to use them to obtain
more verbose information about a configuration node.
E.g., "help protocols ospf4 area" should provide you with detailed
information about an OSPF area.
However, the xorpsh doesn't implement this yet, so for the time
being the "%help: long" statements are ignored.

Pavlin