Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

[Acee Lindem <[e-mail]>]

> On Feb 1, 2024, at 16:28, Yingzhen Qu <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi John, 
>> 
>> > On Feb 1, 2024, at 11:55 AM, John Scudder <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> >> 
>> >> 
>> >> 
>> >>> On Jan 31, 2024, at 20:14, Acee Lindem <[e-mail] <mailto:[e-mail]>> wrote:
>> >>> 
>> >>> 
>> >>> 
>> >>>> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker <[e-mail] <mailto:[e-mail]>> 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
>> >> [e-mail] <mailto:[e-mail]>
>> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!CSaaziWFGrg6dv81sm55-XN-CP5eUEsFoeObIEuQzH8mYmJPURb3VboumvFzwTwOiHyiHP8O67tleiE$
>> > 
>>