Hi John, > On Feb 1, 2024, at 11:55 AM, John Scudder <[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]> wrote: >> >> >> >>> On Jan 31, 2024, at 20:14, Acee Lindem <[email protected]> wrote: >>> >>> >>> >>>> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker >>>> <[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] >> 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
