On Feb 1, 2011, at 7:11 PM, Sam Hartman wrote: >>>>>> "Acee" == Acee Lindem <[email protected]> writes: > > Acee> However, I can see that a patient enough attacker could simply > Acee> wait for a cold start using the same manual key. > > Acee> Given how much extra signaling and complexity is required in > Acee> this solution, it may better to wait for a solution to the > Acee> manual keying problem. > > I think there are three solutions: > > 1) Require a time-of-day clock and have significant consequences when it > goes backwards. This solution tends to also permit attackers to keep an > adjacency alive when it goes down. So an attacker can prevent fail-over > to redundant links.
While most modern routers have a clock with fine enough granularity that will never go backwards, it is typically not preserved across cold restarts. If one used a 64 bit sequence number (for the required precision) and had a relative clock that was never reset, it would fit the bill. > > 2) Some sort of freshness exchange, like the one Dacheng, Manav and I > are putting together. We can probably do better in terms of reducing > signaling than we do now. > However I think you'll have to introduce a couple of extra packets > whenever an adjacency is lost before any new adjacencies can be > introduced. > > 3) Use automated key management. Note that automated key management > will probably be as chatty as option 2 in the election phase. > > I personally think that option 1 is not acceptable unless we find a > solution to the fail-over prevention. > > I'd like to understand your objections to our approach in option 2. > Is it number of extra packets? For one thing, I don't like the fact that multicast hellos contain the session ID and nounce for every router on the network (as shown in figure 6). > Is it just that it feels really complex? > Any chance you'd be up for an Im session or phone call to brainstorm > what the minimum complexity is and see whether it's that you think the > problem is too expensive to solve or just that our solution is too > expensive? I won't be able to do this before the IETF in Prague as I already have too many things left undone. However, I will at least make it a point to understand the proposal better before the meeting. Thanks, Acee >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
