Watson -
Please see LES2: inline.
> -----Original Message-----
> From: Watson Ladd <watsonbl...@gmail.com>
> Sent: Friday, May 5, 2023 3:32 PM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> Cc: secdir <sec...@ietf.org>; draft-ietf-lsr-rfc8919bis....@ietf.org; last-
> c...@ietf.org; lsr@ietf.org
> Subject: Re: Secdir last call review of draft-ietf-lsr-rfc8919bis-01
>
> On Thu, May 4, 2023, 9:20 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> wrote:
> >
> > Watson -
> >
> > Before responding to your comments, I point out that this is a bis of RFC
> 8919 - and it makes no changes to the protocol extensions defined in RFC
> 8919 - it only provides some clarifications so that readers/implementors are
> more likely to have a common understanding.
> > The Security section is unchanged from RFC 8919. As it passed Security
> review at that time, there was no reason for the authors of the bis draft to
> think that any changes to the Security section would be required.
> >
> > Still, you are looking at this with a fresh set of eyes - let's see what
> > can be
> gleaned from your comments.
>
> I think a lot of this stems from my lack of exposure to the underlying
> tech: it can make it difficult to see why certain claims in the
> security section are true.
>
[LES2:] Understood.
> >
> > Inline...
> >
> > > -----Original Message-----
> > > From: Watson Ladd via Datatracker <nore...@ietf.org>
> > > Sent: Thursday, May 4, 2023 4:19 PM
> > > To: sec...@ietf.org
> > > Cc: draft-ietf-lsr-rfc8919bis....@ietf.org; last-c...@ietf.org;
> > > lsr@ietf.org
> > > Subject: Secdir last call review of draft-ietf-lsr-rfc8919bis-01
> > >
> > > Reviewer: Watson Ladd
> > > Review result: Has Issues
> > >
> > > Dear all,
> > >
> > > I have reviewed this document as part of the security directorate's
> > > ongoing effort to review all IETF documents being processed by the
> > > IESG. These comments were written primarily for the benefit of the
> > > security area directors. Document editors and WG chairs should treat
> > > these comments just like any other last call comments.
> > >
> > > The summary of my review is Has Issues. While this document is a pretty
> > > concise and well written description of a problem and solution, the
> securities
> > > consideration section is pretty perfunctory.
> > >
> > > In particular this document seems to assert that the new extensions can
> only
> > > be enabled when all routers support them, and not in a link-by-link
> manner.
> >
> > [LES:] The extensions define a new way to advertise per link attributes. To
> guarantee that all nodes who utilize the link attribute information in a
> constrained SPF associated with a legacy application (RSVP-TE, SR Policy,
> and/or LFA) use the same set of link attribute information, it is necessary to
> utilize a form of advertisement that all nodes in the network supporting that
> application understand.
>
>
> Why isn't that a link by link issue?
[LES2:] Fundamental to a link state protocol like IS-IS is that the
advertisements generated by each and every node will be flooded to all nodes in
the same area. In this way all nodes operate on the same link state database
and have a complete picture of the topology.
Although the advertisements we are concerned with here are per link attributes,
they will be flooded to all nodes in the network and all nodes in the network
who support the application associated with those advertisements need to
understand the advertisements - whether they are one hop away from the
originator or multiple hops away.
This differs from distance vector protocols (like RIP) where routing
calculations are hop-by-hop and exchange of routing information is only to
direct neighbors.
>
> > If the new ASLA advertisements are sent in the presence of one or more
> legacy nodes, those nodes will not process the new ASLA advertisements -
> thereby introducing inconsistency with non-legacy nodes. That is why Section
> 6.3.3 specifies that legacy advertisements MUST be sent in the presence of
> legacy routers.
> > This isn’t a security related matter - it is identifying a form of
> misconfiguration to be avoided.
> >
> > If an attacker were to introduce ASLA advertisements in the presence of
> legacy nodes, this would have no impact on legacy nodes as they would not
> process the ASLA advertisements.
> > More on this below.
>
> Could that discrepancy cause more issues than failure of a mode? If so
> there is a potential amplification of attacker access.
[LES2:] For the advertisements introduced by this document, the only impact
will be on routing calculations which depend on those advertisements. Since the
new advertisements are scoped by the (set of) applications specified in the
advertisement, the impact is limited to those applications.
>
> >
> > > If
> > > that's the case, then an attacker can enable the new advertisements on a
> > > router
> > > and cause problems, while the securities consideration section seems to
> say
> > > this is
> > > only per application.
> > >
> > [LES:] If an attacker were to advertise new ASLA advertisements, this could
> affect the operation of nodes which support the protocol extensions. But as
> the new ASLA advertisements only apply to the application(s) specified in the
> Application Bit Mask(ABM) associated with those advertisements, the
> attacker's impact is limited to those applications.
> > This is what the text in the Securities section is stating.
> >
> > > IS-IS is normally within an adminstrative domain, which does minimize
> many
> > > of the impacts,
> > > but the impact of an attacker having access aren't completely solved by
> > > authentication,
> > > particularly if messages can have effect at large distances.
> >
> > [LES:] The Securities section in RFC 8570 speaks to the issue - specifically
> man-in-the-middle attacks - which is why we reference the RFC 8570
> securities section.
> > I do not see that anything needs to be added.
>
> This is where I'm really confused. If all nodes are in same
> administrative domain authentication is about preventing physical
> layer injection. If not in same domain authentication isn't
> sufficient.
[LES2:] IGPs typically only operate within a single administrative domain. It
is conceivable that two network operators could agree to interconnect their
networks and configure the IGP on their respective boxes to participate in a
common IGP area.
Clearly when doing so, they are introducing new vulnerabilities. This isn’t
recommended or commonplace - but it is conceivable.
If the link interconnecting the two domains is less secure than the
"intra-domain" links, then additional security vulnerabilities exist. This is
what RFC 8570 is speaking to.
Les
>
> >
> >
> > >
> > > I think the security considerations section needs some revision in light
> > > of
> this,
> > > either clarifying that IS-IS must be used within a domain, or more
> attention
> > > paid
> > > to thinking about what could go wrong.
> >
> > [LES:] At this point I do not know what to add as I believe the Security
> issues you raise have been addressed by the existing text.
> > Perhaps you could be more specific as to what you believe is required?
> >
> > Les
> >
> > >
> > > Sincerely,
> > > Watson Ladd
> > >
> >
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
