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

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 07 Jan 2019 08:11:35 -0800

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.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 7 Jan 2019 17:05:09 +0000

> 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

---

From: <[email-masked]>
Date: Tue, 8 Jan 2019 08:49:11 +0000

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:[email-masked]]
Sent: Monday, January 07, 2019 18:05
To: Phillip Hallam-Baker; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-09

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 12 Jan 2019 00:06:06 -0500

If the security considerations are addressed in a different document, this
should be stated in the security considerations section.

On Mon, Jan 7, 2019 at 12:05 PM Stewart Bryant <[email-masked]>
wrote:

> normative reference RFC8405 and thus would be fully aware of the security
> issues related to the solution being analysed.
>
> 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.
>

-- 
Website: http://hallambaker.com/