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. > > 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? > 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. > > > 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. > > > > > > 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
