[Xorp-hackers] OSPF auth...
Kristian Larsson
kristian@juniks.net
Fri, 17 Mar 2006 14:23:48 +0100
On Fri, Mar 17, 2006 at 03:40:06AM -0800, Pavlin Radoslavov wrote:
> > Pavlin Radoslavov wrote:
> > > This is different from the mechanism suggested by RFC 2082
> > > (Section 4.3).
> >
> > Which is from 1997. And which is different from recommendations in RFC2328
> > (appendix D) from 1998.
> >
> > At first - time is passed since these times. Many points valid in these
> > days are void nowadays. Take RFC2328 appendix B - Architectural
> > Constants. They were meant to be really constants in '98, but I don't
> > know any commercial OSPF implementation which have first three constants
> > set to values defined there. They aren't even constants any more, but
> > adaptive values.
> >
> > And even if something is described in (recent) RFC, it doesn't mean that
> > it is useful. Many times writers of standards put something into RFC's
> > which turned to be void issue in practise or too complicate to implement
> > or ... "Should" and "should not" are interpreted as "you can ignore this"
> > anyway by implementers. No joking, btw, these are words from Juniper
> > engineer.
> >
> > Back to OSPF auth issues. Just start and end times valid for both
> > generating and accepting are not suitable for OSPF. Think of hello timers
> > set to 1s or even less (there are some implementations with thing called
> > "fast timers"). Even slight difference in clocks would bring adjacencies
> > down.
> >
> > As far as I can see there is mostly two different ways the OSPF key switch
> > mechanism is implemented in nowadays implementations (there are also
> > implementations which allow only one key configured at time, but it
> > shouldn't be option for Xorp).
> >
> > IOS way: no any times associated with keys, if multiple keys are
> > configured, multiple copies of every packet are sent over the interface -
> > one with each configured keys.
> >
> > Method is very simple, works well, but of course there is overhead in the
> > moment of switch. With thousands of external prefixes it can be quite
> > heavy traffic.
> >
> > Junos way: one key active for sending OSPF packets, one timestamp can be
> > configured per key - start generate time. Rules for choosing active key
> > are simple: active is the key with most recent start-time in the past or
> > if there isn't such key, then key with greatest ID without start-time. As
> > you can see it's quite close to method described in D.3 RFC2328, except
> > that only KeyStartGenerate is implemented. Accept time is always
> > infinite.
> >
> > In this way configuration and rules you should take into account are still
> > kept quite simple (although it is more complicated than IOS way), but
> > traffic overhead is avoided.
> >
> > These are exactly the cases where implementers implemented minimal set of
> > features required in practise without cluttering CLI with useless options
> > which would make only shooting into foot easier. For Cisco engineers
> > traffic overhead was acceptable, for Junos engineers it wasn't.
>
> Let me describe what we have implemented so far and what we are
> planning to add so you can see the tradeoffs we have chosen.
>
> * RIP MD5
> There is optional start time and optional end time per key.
> If start time is missing from the configuration, it means "now";
> if end time is missing from the configuration, it means "forever".
> Only while a key is valid (i.e., within its start-end time
> period), a packet that matches that key is accepted.
> Also, if a key is valid, RIP transmits a copy of the packet with
> that authentication key.
> This means that RIP may transmit each packet more than once during
> key switchover: one copy per valid key.
> Opbiiously, it increases the control traffic during the
> switchover, but as you say it is relatively simple and robust
> solution.
> Though, the major reason we have chosen this solution is because
> it is within the lines of RFC 2082 "RIP-2 MD5 Authentication"
> Section 4.3.
> There are few things we need to fix in the current implementation,
> but the basic mechanism will remain same.
>
> 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
>
> * OSPF MD5
> Indeed, RFC 2328 Section D describes a mechanism where there are
> four time constants associated with a key: KeyStartAccept,
> KeyStartGenerate, KeyStopGenerate, KeyStopAccept.
> And, yes, currently in XORP we have
> KeyStartAccept=KeyStartGenerate and KeyStopGenerate=KeyStopAccept.
> Furthermore, unlike the RIP MD5 implementation, we don't send
> multiple OSPF packets (one per each valid). Instead, we send a
> single packet (for one of the valid keys).
> As it is, we understand that this solution won't work when the
> clocks are not synchronized. And we didn't want to send multiple
> packets (one per key) as we do for RIP so due to time constraints
> we decided to come back to it and improve it later (after the 1.2
> release is out).
>
> 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.
> The Juniper solution is admirable, because they conform to RFC
> 2328 and at the same time have a nice solution to deal with clock
> differences: KeyStartGenerate=NOW, and
> KeyStopGenerate=KeyStopAccept=INFINITY.
>
> The downside of the Juniper solution is that you can't timeout the
> keys, but you have to remember to delete them when not needed
> anymore. Indeed, in your scenario of updating the keys for all
> your routers this is not an issue because you are closely
> monitoring everything.
> 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.
>
> To solve the clock differences problem, we need to make sure that
> KeyStartAccept < KeyStartGenerate and KeyStopGenerate < KeyStopAccept
> We don't want to make all four time values configurable by the
> user, because this will make the configuration process too
> complicated.
>
> To solve the KeyStartAccess < KeyStartGenerate requirement we
> could use the Juniper solution by assuming that KeyStartAccept=NOW;
> however, this won't solve the KeyStopGenerate < KeyStopAccept
> requirement.
>
> 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. By doing so we:
>
> - Provide the additional functionality of having start-time and/or
> end-time.
> - Have a (configurable) solution for the clock syncronization
> problem.
> - Avoid the duplicated traffic.
> - Keep the MD5 key configuration relatively simple.
>
> If folks have other suggestions/recommendations, now is the time to
> speak before the above mechanism is implemented.
Aye! I like the sound of it. I'm all for.
Regards,
Kristian