> On Feb 1, 2024, at 16:28, Yingzhen Qu <[email protected]> wrote: > > Hi, > > The configuration to enable/disable OSPFv3 Extended LSA is for migration, > please refer to RFC 8362 section 6 (RFC 8362 - OSPFv3 Link State > Advertisement (LSA) Extensibility (ietf.org) > <https://datatracker.ietf.org/doc/html/rfc8362#section-6>). If it's disabled, > the router under attack won't be able to exchange extended LSAs with other > routers, and new features using only extended LSAs won't work. > > How about the following changes? > old: > /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support > The ability to disable OSPFv3 Extended LSA support can result in a > denial of service. > new: > /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support > The ability to disable OSPFv3 Extended LSA support can result in a > denial of service. Any OSPFv3 extensions using only Extended LSAs won't > work.
No - there will not be connectivity between the OSPFv3 routers. For the draft that became RFC 8263, we initially had a complex interoperability mode but when no vendors signed up for implementation, we simplified the specification to use either the base or extended LSAs for the base SPF. One could use sparse-mode for specific features (e.g., segment routing) but this is dependent on the feature configuration. I’ll change it to “enable or disable” since either could have this consequence. Thanks, Acee > > Thanks, > Yingzhen > > On Thu, Feb 1, 2024 at 9:54 AM Acee Lindem <[email protected] > <mailto:[email protected]>> wrote: >> Hi John, >> >> > On Feb 1, 2024, at 11:55 AM, John Scudder <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Hi Acee, Roman, all, >> > >> > [top posting, hope that’s OK] >> > >> > After talking with Roman about this today, what I understand his position >> > to be is (at least in part), since the document identifies one specific >> > case of a type of attack ("The ability to disable OSPFv3 Extended LSA >> > support can result in a denial of service”), shouldn’t it also list other >> > cases? What’s special about "denial of service” vs. other things such as >> > the ones Roman mentioned? I don’t think he was seeking an in-depth >> > exploration of these, just a more complete summary list. I also wonder if >> > the concern could equally be satisfied by removing the one special case. >> >> By enabling or disabling this parameter, you can only limit exchange of >> OSPFv3 LSAs between OSPFv3 routers. You cannot inject compromised LSAs into >> the OSPFv3 routing domain through modification of this parameter alone? >> How could this exploit be used to: >> >> >>>> modify network topologies to enable select traffic to avoid inspection >> >>>> or >> >>>> treatment by security controls; route traffic in a way that it would be >> >>>> subject >> >>>> to inspect/modification by an adversary node; or gain access to >> >>>> otherwise >> >>>> segregated parts of the network. >> >> >> >> Thanks, >> Acee >> >> >> >> > >> > I’m sure Roman will chime in if I’ve gotten this wrong. >> > >> > Thanks, >> > >> > —John >> > >> >> On Jan 31, 2024, at 8:50 PM, Acee Lindem <[email protected] >> >> <mailto:[email protected]>> wrote: >> >> >> >> >> >> >> >>> On Jan 31, 2024, at 20:14, Acee Lindem <[email protected] >> >>> <mailto:[email protected]>> wrote: >> >>> >> >>> >> >>> >> >>>> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker >> >>>> <[email protected] <mailto:[email protected]>> wrote: >> >>>> >> >>>> Roman Danyliw has entered the following ballot position for >> >>>> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss >> >>>> >> >>>> When responding, please keep the subject line intact and reply to all >> >>>> email addresses included in the To and CC lines. (Feel free to cut this >> >>>> introductory paragraph, however.) >> >>>> >> >>>> >> >>>> Please refer to >> >>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> >>>> >> >>>> for more information about how to handle DISCUSS and COMMENT positions. >> >>>> >> >>>> >> >>>> The document, along with other ballot positions, can be found here: >> >>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ >> >>>> >> >>>> >> >>>> >> >>>> ---------------------------------------------------------------------- >> >>>> DISCUSS: >> >>>> ---------------------------------------------------------------------- >> >>>> >> >>>> ** Section 5. >> >>>> >> >>>> Write >> >>>> operations (e.g., edit-config) to these data nodes without proper >> >>>> protection can have a negative effect on network operations. There >> >>>> are the subtrees and data nodes and their sensitivity/vulnerability: >> >>>> >> >>>> /ospf:ospf/extended-lsa-support >> >>>> /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support >> >>>> The ability to disable OSPFv3 Extended LSA support can result in a >> >>>> denial of service. >> >>>> >> >>>> Isn’t it more than just denial of service? In certain environments >> >>>> wouldn’t >> >>>> the ability to modify OSPF Extended LSA configurations enable an >> >>>> attacker to: >> >>>> modify network topologies to enable select traffic to avoid inspection >> >>>> or >> >>>> treatment by security controls; route traffic in a way that it would be >> >>>> subject >> >>>> to inspect/modification by an adversary node; or gain access to >> >>>> otherwise >> >>>> segregated parts of the network. >> >>> >> >>> Only if they were able to craft extended LSAs on behalf of the original >> >>> as well as >> >>> modify the YANG configuration added by this document. I didn’t think >> >>> we’d have to >> >>> reiterate all the possible protocol attacks for every incremental >> >>> enhancement. >> >> >> >> Furthermore, no one is going to use the support of extended LSAs to >> >> isolate OSPFv3 domains >> >> from one another. The configuration is to control migration to the >> >> extended LSA encodings. >> >> Please see RFC 8362 for more information on OSPFv3 Extended LSAs. >> >> >> >> Acee >> >> >> >> >> >> >> >> >> >> >> >>> >> >>> Acee >> >>> >> >>> >> >>> >> >>>> >> >>>> >> >>>> ---------------------------------------------------------------------- >> >>>> COMMENT: >> >>>> ---------------------------------------------------------------------- >> >>>> >> >>>> As an editorial note, I would have benefit from some narrative prose on >> >>>> the data model. >> >> >> >> _______________________________________________ >> >> Lsr mailing list >> >> [email protected] <mailto:[email protected]> >> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!CSaaziWFGrg6dv81sm55-XN-CP5eUEsFoeObIEuQzH8mYmJPURb3VboumvFzwTwOiHyiHP8O67tleiE$ >> > >>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
