Hi John, Roman, I’ve updated the text in -29 to clarify how modifying the enabling and disabling OSPFv3 Extended LSA support could prevent the correct routes from being installed (i.e., a denial of service attack). I really don’t see how this could be used to misroute traffic (as suggested by Roman) unless the alternate routes already installed (e.g., a default route) that would misroute the traffic. So, this would be, at best, a non-deterministic attack.
Thanks, Acee > 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. > > 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
