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.
Thanks,
Yingzhen
On Thu, Feb 1, 2024 at 9:54 AM Acee Lindem <[email protected]> wrote:
> 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
