Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Sep 2013 03:42:36 +0000

Hi Gabi,

[clipped]

> Nonetheless, I am sure that there are more OSPF vendors out 
> there that are still vulnerable to the attack and do not 
> check for this. Moreover, since this check is not part of the 
> standard, in most likelihood future OSPF implementations will 
> also be vulnerable.
> 

[clipped]

> 
> I am willing to write a draft describing this mitigation 
> measure. I would appreciate the list's thoughts on this.

I think it's a good idea to write a draft that describes the attack and what implementations MUST do to avoid it. 

Cheers, Manav

> 
> Gabi
> 
> ----- Original Message -----
> > From: Yi Yang (yiya) <[email-masked]>
> > To: Gabi Nakibly <[email-masked]>; Acee Lindem 
> > <[email-masked]>; David Lamparter 
> <[email-masked]>; Glen 
> > Kent <[email-masked]>
> > Cc: "[email-masked]" <[email-masked]>
> > Sent: Friday, August 9, 2013 4:37 AM
> > Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the 
> > Routing Table Attack)
> > 
> > I would think such an attack can be categorized as 
> "overclaiming", as 
> > defined at 
> http://tools.ietf.org/html/rfc4593#section-4.5.1.1. In this 
> > case, an attacker claims a resource (link state ID) which does not 
> > belong to it.
> > 
> > While it might be challenging to defense overclaiming in 
> some cases, 
> > it's not that hard to recognize the attack in this case. As pointed 
> > out by David and Acee, such LSAs should be considered as 
> malformatted 
> > as they have unmatched Advertising Router and Link State ID 
> and can be 
> > dropped. A more challenging example of overclaiming is the attacker 
> > simply advertises a bunch of prefixes that are not really 
> attached on itself.
> > 
> > Yi
> >   
> > 
> > On 8/5/13 5:03 PM, "Gabi Nakibly" <[email-masked]> wrote:
> > 
> >> Hi all,
> >> My name is Gabi. I am the researcher who presented the new 
> attack at 
> >> Black Hat last week. I have noticed the discussion on the 
> list and I 
> >> would be happy to try to clarify how the attack is different from 
> >> known ones.
> >> Indeed the attack assumes that the attacker is an insider, meaning 
> >> that the attacker has already gained control of one of the router 
> >> within the AS. I agree 100% that once an attacker is an insider he 
> >> can already do all sorts of attacks that can harm the network and 
> >> indeed a few past works have already reported on this. 
> Nonetheless,  
> >> the crux of the new attack, as Acee has already pointed 
> out, is that 
> >> an attacker is now able to falsify an LSA on behalf of 
> another router 
> >> while evading the fight-back mechanism. This new 
> capability allows an 
> >> attacker to
> >> *persistently* and *stealthily* subvert the LSA DB of 
> other routers 
> >> that install the false LSA and thereby altering their 
> routing tables. 
> >> This gives rise to a new class of attacks that in my 
> opinion have not 
> >> existed before and, in many times, are more desirable for 
> an attacker 
> >> (due to their stealth and persistence).
> >> To my best knowledge, no other general technique to 
> stealthily evade 
> >> fight back is known. The only general attack technique to 
> evade fight 
> >> back is periodic injection (flooding false LSAs at a rate higher 
> >> thanone every MinLSInterval)  presented in 
> >> http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt 
> in Section 
> >> 4.1.3.1. However,  using such technique the attack is 
> hardly stealthy.
> >> 
> >> BTW, I have also presented in the past another general 
> technique to 
> >> evade fight back called 'Disguised LSA'. It is described in 
> >> 
> https://www.cs.technion.ac.il/people/gnakibly/online-publications/Per
> >> siste
> >> ntOSPF.pdf in Section 4.2.
> >> 
> >> I would appreciate your continued feedback on the new attack.
> >> 
> >> Thanks,
> >> Gabi
> >> 
> >>> ________________________________
> >>>  From: Acee Lindem <[email-masked]>
> >>> To: David Lamparter <[email-masked]>; Glen Kent  
> >>><[email-masked]>
> >>> Cc: "[email-masked]" <[email-masked]>
> >>> Sent: Monday, August 5, 2013 5:28 AM
> >>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - 
> Owning the  
> >>>Routing Table Attack)
> >>> 
> >>> 
> >>> 
> >>> 
> >>> On 8/4/13 6:06 AM, "David Lamparter" 
> > <[email-masked]> wrote:
> >>> 
> >>>> On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote:
> >>>>>  Does anybody have details on what this OSPF vulnerability is?
> >>>>> 
> >>>>>  https://www.blackhat.com/us-13/briefings.html#Nakibly
> >>>> 
> >>>> As people may have noticed by now (the embargo on 
> providing details
> > has
> >>>> expired as the talk was presented), this issue consists of Router
> > LSAs
> >>>> where the Router ID is different from the Link State ID. 
>  As such,
> > this
> >>>> attack is implementable from any router in an OSPF area 
> against any 
> >>>> other router in the OSPF.
> >>>> 
> >>>> (Quite honestly, IMHO this is seriously far fetched.  If your
> > control
> >>>> plane got compromised this far you have other problems.)
> >>> 
> >>> I agree that once the OSPF control plane is open, you are 
> >>> susceptible to many attacks. However, this attack is a bit more 
> >>> insidious than most since the actual OSPF router corresponding to 
> >>> the link state ID will most likely not recognize the LSA as 
> >>> self-originated and re-originate a more recent version when the 
> >>> malformed one is received. Hence, the malicious LSA
> > will
> >>> remain in the routing domain and, depending upon the OSPF
> > implementation,
> >>> could result in traffic being redirected.
> >>> 
> >>>> 
> >>>> While Quagga is unaffected by this, we've implemented a
> > warning.  We're
> >>>> also considering dropping the LSA outright, but I'm somewhat
> > split on
> >>>> that (tilted towards dropping).  I'd be interested if the WG has 
> >>>> comments on that?
> >>> 
> >>> I can't speak for the WG but my implementation will skip 
> the LSA in
> > the
> >>> Link-State Update packet.
> >>> 
> >>> Thanks,
> >>> Acee
> >>> 
> >>> 
> >>>> 
> >>>> 
> >>>> -David
> >>>> _______________________________________________
> >>>> OSPF mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/ospf
> >>> 
> >>> _______________________________________________
> >>> OSPF mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ospf
> >>> 
> >>> 
> >>> 
> >> _______________________________________________
> >> OSPF mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ospf
> >
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Anton Smirnov <[email-masked]>
Date: Thu, 12 Sep 2013 13:16:28 +0200

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

---

From: "A. Przygienda" <[email-masked]>
Date: Thu, 12 Sep 2013 13:46:32 +0200

On 09/12/2013 01:16 PM, Anton Smirnov wrote:
> pretending being an ABR/ASBR and advertise destinations with good
> metric are almost impossible to combat once authentication barrier is
> penetrated.
> 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.

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Sep 2013 14:40:10 +0000

Anton,

I understand that once the attacker can insert LSAs in the flooding domain then there are several things that can be done. However, in most cases the attacks can be easily identified and a corrective action can be easily taken. In this particular case, the attack is a little more insidious and its not straight forward catching the erring LSA.

Since its something that's missing in rfc 2328 we will keep having newer implementations that will carry this bug. A short one page RFC that updates 2328 imo would do no harm. Do you see any issue in publishing such an RFC?

I have written a short post on what the issue in 2328 is and how it can be exploited to launch an attack.
http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed-by-black-hat/

Cheers, Manav

> -----Original Message-----
> From: Anton Smirnov [mailto:[email-masked]] 
> Sent: Thursday, September 12, 2013 4:46 PM
> To: Bhatia, Manav (Manav)
> Cc: Gabi Nakibly; Acee Lindem; [email-masked]
> Owning the Routing Table Attack)
> 
>     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
> 
> 
> 
> >> Nonetheless, I am sure that there are more OSPF vendors out there 
> >> that are still vulnerable to the attack and do not check for this. 
> >> Moreover, since this check is not part of the standard, in most 
> >> likelihood future OSPF implementations will also be vulnerable.
> >>
> > [clipped]
> >
> measure. I 
> >> would appreciate the list's thoughts on this.
> > I think it's a good idea to write a draft that describes 
> the attack and what implementations MUST do to avoid it.
> >
> > Cheers, Manav
> >
> 
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 Sep 2013 10:59:28 -0400

Manav - 

> Since its something that's missing in rfc 2328 we will keep having newer implementations that will carry this bug. A short one page RFC that updates 2328 imo would do no harm. Do you see any issue…

There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will be advertised with the same Router-ID for both the LSID and the Advertising router. I don't think it is productive to write "short" RFCs for every attack and believe the CERT Alert is a better and swifter mechanism for disseminating information on attacks. 
Note that my implementation was not susceptible to this attack as the vulnerability was identified in a packet mutation suite many years back.

I spoke to Gabi offline about authoring an informational RFC that discusses classes of OSPF attacks and possible mechanisms to thwart them. 

Thanks,
Acee

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 12 Sep 2013 15:05:24 +0000

Hi Acee,
 
> There is NO bug in RFC 2328. The RFC clearly states that a 

While I did use the "b" word, I did not mean a "bug" -- have always referred to it as an ommission.

> Router-LSA will be advertised with the same Router-ID for 
> both the LSID and the Advertising router. I don't think it is 

This is at the sending side. What about the RX side? I guess that's where the omission was.

> productive to write "short" RFCs for every attack and believe 
> the CERT Alert is a better and swifter mechanism for 
> disseminating information on attacks. 
> Note that my implementation was not susceptible to this 
> attack as the vulnerability was identified in a packet 
> mutation suite many years back.
> 
> I spoke to Gabi offline about authoring an informational RFC 
> that discusses classes of OSPF attacks and possible 
> mechanisms to thwart them. 

I am fine with that as well. I just want the different kids of attacks to get documented somewhere.

Cheers, Manav

> 
> Thanks,
> Acee
> 
> > 
> > I have written a short post on what the issue in 2328 is 
> and how it can be exploited to launch an attack.
> > 
> >> LSDB then it can screw up routing in the domain.
> >> 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 
> vulnerability. It 
> >> 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
> >> 
> >> 
> >>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 12 Sep 2013 17:46:18 +0000

Manav,

The premise of the attack is still somebody know the AUTH keys of the router.
If private keys of the router can be possibly subverted/leaked/stolen,  then we all agree lot of things in lot of
protocols can break (not only in OSPF or this is not specific to OSPF issue). 

One can definitely try to introduce protocol mechanisms to thwart some of these attacks to a certain extent,
but the point is the problem is not still addressable this way.

The question is how far it's real (I know KARP WG is contending with this) and what are 
the other mechanism one can adopt to solve the issue at the root instead of introducing 
more complicated protocol machinery.

I also feel this should be analyzed more from KARP protocol threat documents...
-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Thursday, September 12, 2013 7:59 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)

Manav - 

Thanks,
Acee

>> particular network then attacker will simply resort to other numerous

---

From: Glen Kent <[email-masked]>
Date: Fri, 13 Sep 2013 03:16:09 +0530

No, this is not the premise. Yes, somebody could do this if he has access
to the keys. In this case the attack was done in the absence of any
authentication being used.

Glen

On Thu, Sep 12, 2013 at 11:16 PM, Uma Chunduri <[email-masked]>wrote:

> If private keys of the router can be possibly subverted/leaked/stolen,
>  then we all agree lot of things in lot of
> > I understand that once the attacker can insert LSAs in the flooding
> domain then there are several things that can be done. However, in most
> cases the attacks can be easily identified and a corrective action can be
> easily taken. In this particular case, the attack is a little more
> insidious and its not straight forward catching the erring LSA.
> >
> > Since its something that's missing in rfc 2328 we will keep having newer
> implementations that will carry this bug. A short one page RFC that updates
> 2328 imo would do no harm. Do you see any issue in publishing such an RFC?
>
> There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will
> be advertised with the same Router-ID for both the LSID and the Advertising
> router. I don't think it is productive to write "short" RFCs for every
> attack and believe the CERT Alert is a better and swifter mechanism for
> Note that my implementation was not susceptible to this attack as the
> vulnerability was identified in a packet mutation suite many years back.
>
> I spoke to Gabi offline about authoring an informational RFC that
> discusses classes of OSPF attacks and possible mechanisms to thwart them.
>
> Thanks,
> Acee
>
> >

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 12 Sep 2013 21:52:50 +0000

>> In this case the attack was done in the absence of any authentication being used.
One should worry for attack, if one configures some form of existing AUTH protections (we have) in the network.
..else we should not spend  time on this topic!

--
Uma C.

________________________________
From: Glen Kent [mailto:[email-masked]]
Sent: Thursday, September 12, 2013 2:46 PM
To: Uma Chunduri
Cc: Acee Lindem; Bhatia, Manav (Manav); [email-masked]
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)

No, this is not the premise. Yes, somebody could do this if he has access to the keys. In this case the attack was done in the absence of any authentication being used.

Glen

On Thu, Sep 12, 2013 at 11:16 PM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:
Manav,

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Acee Lindem
Sent: Thursday, September 12, 2013 7:59 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)

Manav -

Thanks,
Acee

>> From: Anton Smirnov [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: Gabi Nakibly; Acee Lindem; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 Sep 2013 22:10:11 +0000

Hi Manav, 

> This is at the sending side. What about the RX side? I guess that's where the omission was.

Note that if you use a simplistic reference implementation and do the LSDB lookups during your SPF, you will have no problems. It is only optimized implementations that have a problem. For example, my implementation would have had the problem had I not ignored the malformed LSA while the public domain ZebOS would not have a problem. I won't speak for any other vendor's implementation on this list.  Hence, there is no omission from RFC 2328 since it describes a simplistic SPF intra-area computation in section 16.1. 

> I am fine with that as well. I just want the different kids of attacks to get documented somewhere.

A think a single OSPF(v3) vulnerabilities document would be much more useful than short RFCs documenting very specific attacks. One was started in RPSEC but never finished due to the demise of the author's company and the RPSEC WG itself. 

Thanks,
Acee

---

From: "A. Przygienda" <[email-masked]>
Date: Fri, 13 Sep 2013 00:50:56 +0200

On 09/12/2013 11:46 PM, Glen Kent wrote:
> No, this is not the premise. Yes, somebody could do this if he has
> access to the keys. In this case the attack was done in the absence of
> any authentication being used.
>

this will be unfortunately the tenor of this discussion until a threat
model is being talked about first in terms of what is that
is being feared [protected value] and how the attack is mounted
[attacker sophistication and resources]. Only then what is
being done & whether a solution makes sense will be agreed upon.

And on a lighter note and to keep things in perspective: In my
experience over years, the worst threats to routing protocols were

01. coding bugs/naive implementation
02. coding bugs/naive implementation
..
31. coding bugs/naive implementation
32. misunderstanding of the spec
33. misunderstanding of the spec
..
66. misunderstanding of the spec
67. misconfiguration: (wonder what happens if I just inject this default
route into this statement I don't understand ??? ;-)
68. misconfiguration: well, I need another patch and this one looks like
it can be borrowed.
69. misconfiguration: well, let's test our spanning tree, more patches
in a rack are better, right ;-)
70. deteriorating links (how about 50-60 flaps/min ?)
71. memory chip failures
..
???. malicious, intended link-state packet attacks [there were cases
people breaking via telnets & stuff & (cough, cough ...) MIB
writes of cause)] but I fail to remember anyone injecting LSA, replaying
adjancencies or any such stuff since you simply
have to be on a link that carries OSPF adj normally (unless you fwd'
OSPF protocol in your network in a promiscuous fashion or naively
peer on any GRE tunnel in sight)  and those are hard to find on the
outside. Albeit an interesting paper by Boneh shows
a somewhat interesting remote adjacency attack. That shows however how
sophisticated the attacker must be and
he'll be debugging his code for long time until he has any success with
such a threat.

On the other hand, CC'suming the LSPs/LSA (well, more in ISIS unless you
don't age in OSPF)
when you have a router sitting in there for years was a [very good thing
to do] (TM) and I saw my share of flipped bits.
A memory chip never thought itself a threat possibly but it was a
realistic one.

so keep the blackhat-threats along the 1-71 (byzantine robustness)
before worrying about people stealing keys (80% of
security breaches are from the inside) and then about injection into
OSPF carrying links (unless it's on the edge but then
I would start to worry about 1-69. again when a no-name edge vendor
configured by an optimistic admin tries to talk
OSPF to you).

my semi-rusty 2c ;-)

--- tony

---

From: Mitchell Erblich <[email-masked]>
Date: Thu, 12 Sep 2013 16:33:42 -0700

Anton,

	I agree partially with the below qualifications:

		A valid set of LSAs that constitute a flooding attack, where the flooding attack is based on a reverse route summarization, should be able to be identified and mitigated,

		An excess of valid and invalid LSAs could be run against an acceptable quantity of LSAs, and any quantity above X from a single non-trusted source, could cause the equiv of a tail or a RED drop of some percentage of LSAs per period of time, 
	
		Some form of authentication challenge against LSAs (like a ICMP echo request) or first recv'ing packets from the path, could be used to validate the LSA before using the actual LSA (if the LSA is suspect) could be done…

		Thus, as in most de facto implementations, a layering of secure/authentication methods tend to be more effective then just at a single layer.

		So, why wouldn't a best practices type document given a set of well known attacks with SHOULDs be minimally productive?

		Mitchell Erblich

On Sep 12, 2013, at 4:16 AM, 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
> 
> 
>