On 09/12/2013 01:16 PM, Anton Smirnov wrote: > If attacker has joined flooding domain and can inject an LSA into > LSDB then it can screw up routing in the domain. Methods such as > pretending being an ABR/ASBR and advertise destinations with good > metric are almost impossible to combat once authentication barrier is > penetrated. > This particular vulnerability allows attacker to bring network down > in style but if this vulnerability is not present in the particular > network then attacker will simply resort to other numerous > possibilities to affect routing via LSA injection. If attacker can > inject LSA into LSDB then your network is at his mercy. Give or take > one particular method is a detail. > So IMO we don't need a draft on this particular vulnerability. It > might be of some limited interest to document all known methods to > exploit LSA injection which would include this vulnerability but what > value would this RFC bring? Such methods are regularly published in > academic literature since 90-th. > > IMO we need good (reliable, secure, manageable etc) methods of > authenticating adjacencies. KARP group is working on that. We *might* > benefit from a work on mechanism to prevent any router to originate > reachable LSA on behalf of any other router (kind of LSA signing). But > work on what will go wrong when intended security barriers are broken > IMO is not needed. > > Anton
Anton, 'securing an adjacency' is ok a step but it will not give you what people seem to look for here. Once you have that you start to talk about the threat models where an adjacency can be compromised or an LSA be injected by some nefarious means. So first thing first: What's the threat model here ? blackhats getting to phy links ? blackhats being able to fake adjacencies ? blackhats being in possesions of PKAs to fake their way into forming secure adjacencies with other people ? blackhats compromising router configurations ? blackhats spoofing end-system addresses to make routers advertise their /32 reachability ? All vastly different things & attacks. So, without a threat model first of all those security discussion tend to change the target while the hunt is ongoing. As it already does, it started from simple attack I-claim-to-be-someone-else attack easily mounted & defeated and talks here now about harder things (reachability attacks, those actually need end-system adjacencies secured as well, hard stuff & not in Internet routing architecture much @ all normally). The thing that holds for the kind of threats this discussion started on quite well is a chain-of-trust security where you basically have to assure not only that an LSP/LSU has been originated by the person claiming to be the originator but as well that all the flooding has happened along trust-of-chain (to prevent .e.g. replay attacks by someone injecting into a link [without an adjacency, not unlikely on ether e.g.]). Techniques for that are known and not that expensive computationally but it is a non-negligible amounts of work involved in such an undertaking. That better be on workgroup charter, requirements docs then ;-) If links to paper, previous art on that are desired, pls ping me, I'll provide --- tony
<<attachment: prz.vcf>>
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
