Subject: Re: [GROW] Alvaro Retana's No Objection on draft-ietf-grow-filtering-threats-07: (with COMMENT)

From: Camilo Cardona <[email-masked]>
Date: Tue, 15 Sep 2015 13:48:18 +0200

Hello Alvaro,

Thanks for your comments. Answers inline.

Camilo C.

> On 18 Aug 2015, at 22:03, Alvaro Retana <[email-masked]> wrote:
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-grow-filtering-threats-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I have a non-blocking comment related to the characterization of the
> unexpected traffic flows (and a nit).
> 
> Section 6. (Security Considerations)  Throughout the document the
> unexpected traffic flows were characterized as potential policy
> violations, not as routing security issues as is done here.  I know that
> the text has gone around the point of malicious intent (or not) before,
> but I think that if you’re going to mention that it could be a "potential
> routing security issue”, then you should say something more about it
> (even if it is the result of non-malicious intent) — or just leave it at
> policy violations.
> 

<JCC> The security section indeed mentions that the objective of the document is security, however, we stopped focusing on that aspect at an earlier version. We’ll correct that part to something along the next lines:

OLD: The objective of this document is to inform on this potential routing security issue, and analyze ways for operators to defend against them.
NEW: The document informed on the potential routing security issue, and analyzed ways for operators to defend against them.

> 
> Nit:
> 
> The example in Section 2.2.1. (Unexpected traffic flows caused by
> remotely triggered filtering of more specific prefixes) didn’t look good
> to me at first..then I re-read the text until I discovered that the other
> ASes (including 64505) are peering with both 64502 and 64503.  Because of
> how Figure 4 is drawn, it looks like 64505 is only connected to 64502.  
> Maybe centering that AS will avoid confusion.
> 

<JCC> We wanted to depict that AS 64505 is peering with 64502 and to other ASes (possibly, but not necessarily 64503). However, We could reformat the figure 4 and make 64505 peer directly with 64503 to make it more clear. 

> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 15 Sep 2015 12:24:16 +0000

On 9/15/15, 7:48 AM, "Camilo Cardona" <[email-masked]> wrote:

Camilo:

Hi!

>>but I think that if you¹re going to mention that it could be a "potential
>>routing security issue², then you should say something more about it
>>(even if it is the result of non-malicious intent) ‹ or just leave it at
>>policy violations.
>
><JCC> The security section indeed mentions that the objective of the
>document is security, however, we stopped focusing on that aspect at an
>earlier version. We¹ll correct that part to something along the next
>lines:
>
>OLD: The objective of this document is to inform on this potential
>routing security issue, and analyze ways for operators to defend against
>them.
>NEW: The document informed on the potential routing security issue, and
>analyzed ways for operators to defend against them.

That does not solve the point I was trying to make.

The point is this: this (the sentence above) is the only place in the
draft where an unexpected traffic flow is characterized as a ³potential
routing security issue².  If you¹re going to characterize it that way,
then I think you should explain more: why is is a security issue, what is
the effect, what can be done to avoid it, etc.

You mention that the security focus is no more; that¹s in line with what
Joel wrote (in the thread related to Kathleen¹s comments:

On 9/1/15, 12:11 PM, "iesg on behalf of joel jaeggli"
<[email-masked] on behalf of [email-masked]> wrote:

>We worked pretty hard to keep both the attack terminology out of the
>document and to keep the focus on the non-malicious action of ordinary
>actors. I think it's better that we don't lump that in with malicious
>action of varying varieties.

I fully agree!  You can make the decision, but if it was me, I would just
take the sentence out.

Thanks!

Alvaro.

---

From: Camilo Cardona <[email-masked]>
Date: Tue, 15 Sep 2015 14:41:05 +0200

Hi Alvaro,

It becomes a security problem when an AS uses any of the techniques to willingly affect another one. However, as Joel mentioned, we removed any type of reference to security, as operators use these almost never for this purpose. At one point, we even removed the security considerations, but we were advised to add it again as a warning to cover that cornercase. 

I understand your point. As this is becoming a loop, I will take the advise of the chairs and the AD of what to do..

Camilo

> On 15 Sep 2015, at 14:24, Alvaro Retana (aretana) <[email-masked]> wrote:
>