RE: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09

[<[e-mail]>]

Hi,

I fully agree with what Stewart has mentioned.
The document does not introduce anything new regarding microloops.
There is no way for an attacker to trigger a microloop except by creating some IGP events (link or node down for example). In addition, there will never be a guarantee that there will be a microloop.
Again as Stewart has mentioned, if such an attacker can access to a router to create IGP events, it would be easier for him to bring the network down (erasing router config, changing critical parameters…) rather than trying to play with microloops.

Brgds,


From: Stewart Bryant [mailto:[e-mail]]
Sent: Monday, January 07, 2019 18:05
To: Phillip Hallam-Baker; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09



On 07/01/2019 16:11, Phillip Hallam-Baker wrote:

Reviewer: Phillip Hallam-Baker

Review result: Has Issues



The document describes the problem and solution pretty clearly. Unfortunately,

there is no discussion of the security considerations which is not appropriate

for a document addressing an availability which is a security issue.



While microloops can form by chance, some consideration should be given to the

possibility that an attacker could induce a loop to perform a DoS attack.

In section 1 the text says:

[RFC8405] defines a solution that satisfies this problem statement

   and this document captures the reasoning of the provided solution.

It is safe to assume that the reader of this text would have read normative reference RFC8405 and thus would be fully aware of the security issues related to the solution being analysed.

An attacker that had access to a network such that they could induce microloops would have the ability to do many worse things to the network.

If they were able to attack in-band they could poison the routing system to take it down in far more interesting ways. Operators use security at the physical and network layer to prevent this.

If they were operating at the physical layer then they could take circuits down at will and cause microloops in the base protocol, traffic overloads and application malfunction.

Thus if the attacker could deploy either of those attacks in a network to induce micro-loops, then any security considerations in this draft would count for nothing.

The draft is an analysis, and thus I think that it correctly states that it introduces no additional matters for security consideration.

- Stewart

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.