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

[Acee Lindem <[e-mail]>]

> On Jan 31, 2024, at 20:14, Acee Lindem <[e-mail]> wrote:
> 
> 
> 
>> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker <[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.