Watson -
Where are we with this discission?
Have my responses clarified things sufficiently or do you still have unresolved
issues?
Thanx.
Les
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> Sent: Friday, May 5, 2023 4:54 PM
> To: Watson Ladd <watsonbl...@gmail.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
>
> 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
