Subject: Re: [secdir] draft-ietf-bess-multicast-damping-04 SECDIR Review

From: Thomas Morin <[email-masked]>
Date: Wed, 4 May 2016 10:42:42 +0200

Hi Donald,

2016-04-27, Donald Eastlake:
>
> The feature specified in this document is aimed at limiting one type 
> of denial of service, or at least at interference to some users by 
> others: denial or interference due to excessive control plane traffic 
> due to a high rate of multicast group membership change. Still, it 
> makes me a bit queasy that the document has not one word, even by 
> reference, about security for the setting or changing of the 
> parameters used at a node in the damping algorithm.

The document does not introduce a new way of controlling parameters on a 
router; so in this regard it does not introduces a new security issue.
But of course, I agree letting an attacker control configuration can 
lead to much havoc ; again, nothing specific to these specs.

> I suppose it is reasonable that it doesn't talk about how any of the 
> control messages involved are protected or authenticated since the 
> document is just about suppressing such messages...

Yes, precisely.

> The Security Considerations section has a reasonable discussion of how 
> and to what extent the mechanisms specified provide the services claimed.
>
> Page 15, Section 9 (Security Considerations), 1st paragraph starting 
> on this page: There are a number of things wrong with the following 
> sentence:
>
>            Note well that the two
>     mechanism may interact: state for which Prune has been requested may
>     still remain taken into account for some time if damping has been
>     triggered and hence result in otherwise acceptable new state from
>     being successfully created.
> I would guess it should be "result in preventing otherwise" or should 
> end with "state not being successfully created". Here is a suggested 
> replacement:
>
> The two mechanisms may interact as follows: if damping has
> been triggered, state for which Prune has been requested may remain
> and still be taken into account for some timeresulting in an
> otherwise acceptable new state notbeing created.

Your replacement text is much better, and will be incorporated in next 
revision.
Thanks.

> *Editorial:*
>
> This document is very heavy with acronymic jargon with no expansion or 
> definition in this document. However, most of it is defined in other 
> RFCs that are referenced.
>
> Although I am willing to accept that it is just a matter of style, 
> this document has lots of extra words that add nothing but verbosity. 
> Things that could be completely dropped with no loss, like starting a 
> sentence with "Additionally, it is worth nothing that ...". If it 
> wasn't worth noting, it presumably wouldn't be in the document.

Your style suggestions are appreciated.
In some cases, I'd keep the original formulation (see below), but I'd 
take your suggestions in others.

>
> Page 4, Section 3, 3rd paragraph: "...this technique will allow to 
> meet the goals..." -> "...this technique will meet the goals..."
>

Ok.

> Page 12, Section 7.2: "More specifically it is RECOMMENDED to 
> complement the existing ... (e.g. MRIB states): ..." -> "Complementing 
> the existing ... (e.g. MRIB states) is RECOMMENDED: ..."
>

Done.

> Page 13, Section 7.3, 2nd paragraph: What does "dimentioning" mean?

Corrected already based on OPS review.  That should be 'dimensioning'.

> Also "...state churn to go beyond what..." -> "...state churn going 
> beyond what..."

Ok.

>
> Page 14, Section 9, 3rd paragraph: The word "shall" is used. While not 
> capitalized, this word sounds quite mandatory to me but it is not used 
> in a mandatory requirement context... I suggest "shall rely upon" -> 
> "relies on".
>

Ok.

> Page 15, near the top: "should rely upon already" -> "should use already"

Ok.

> Finally, while I understand that others have a different opinion, I 
> find it objectionable that not a single first page author is willing 
> to list a telephone number of any sort in the Authors' Addresses 
> section. To my mind, this sort of corner cutting does not speak well 
> for the document.

I'm honestly surprised that someone finds these phone numbers in IETF 
specs !

If someone wants to contacts authors of a spec, he's much more likely to 
succeed with email, not only because it can talk to all of them at the 
same time.
I have a reasonable filter on my email for spam/commercial 
sollicitations, but not on my phone lines; this is a strong obstacle to 
providing phone numbers in the wild.
Emails can also be slightly more stable than phone numbers.
Last, if voice can end up being useful for some exchange, I think it is 
likely that time will have to be coordinated in advance via email -- the 
actual phone number to use can be provided at this time, and may end up 
being the more convenient phone number among a few possible ones, a 
confcall bridge or a login on video chat system...

So we aren't "cutting corners".
I think it simply reflects the reality that this is an obsolete practice.
In fact, I would suggest removing the postal address as well.

Thanks for your comments,

-Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 10 May 2016 15:11:47 -0400

Hi,

Thanks for the changes. This resolves my technical and editorial comments.

I also have one response at the end below which is unlikely to be of
interest to most people.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Wed, May 4, 2016 at 4:42 AM, Thomas Morin <[email-masked]> wrote:
> The feature specified in this document is aimed at limiting one type of
> denial of service, or at least at interference to some users by others:
> denial or interference due to excessive control plane traffic due to a high
> rate of multicast group membership change. Still, it makes me a bit queasy
> that the document has not one word, even by reference, about security for
> the setting or changing of the parameters used at a node in the damping
> algorithm.
>
>
> But of course, I agree letting an attacker control configuration can lead to
> much havoc ; again, nothing specific to these specs.
>
> I suppose it is reasonable that it doesn't talk about how any of the control
> messages involved are protected or authenticated since the document is just
> about suppressing such messages...
>
>
> Yes, precisely.
>
>
> The Security Considerations section has a reasonable discussion of how and
> to what extent the mechanisms specified provide the services claimed.
>
>
> Page 15, Section 9 (Security Considerations), 1st paragraph starting on this
> page: There are a number of things wrong with the following sentence:
>
>           Note well that the two
> I would guess it should be "result in preventing otherwise" or should end
> with "state not being successfully created". Here is a suggested
> replacement:
>
>    and still be taken into account for some time resulting in an
>
>    otherwise acceptable new state not being created.
>
>
> Editorial:
> definition in this document. However, most of it is defined in other RFCs
> that are referenced.
>
> Although I am willing to accept that it is just a matter of style, this
> document has lots of extra words that add nothing but verbosity. Things that
> could be completely dropped with no loss, like starting a sentence with
> "Additionally, it is worth nothing that ...". If it wasn't worth noting, it
> presumably wouldn't be in the document.
>
>
> In some cases, I'd keep the original formulation (see below), but I'd take
> your suggestions in others.
>
>
> Page 4, Section 3, 3rd paragraph: "...this technique will allow to meet the
> goals..." -> "...this technique will meet the goals..."
>
>
> Ok.
>
>
> Page 12, Section 7.2: "More specifically it is RECOMMENDED to complement the
> existing ... (e.g. MRIB states): ..." -> "Complementing the existing ...
> (e.g. MRIB states) is RECOMMENDED: ..."
>
>
> Done.
>
>
> Also "...state churn to go beyond what..." -> "...state churn going beyond
> what..."
>
>
> Ok.
>
>
>
> capitalized, this word sounds quite mandatory to me but it is not used in a
> mandatory requirement context... I suggest "shall rely upon" -> "relies on".
>
>
> Ok.
>
> Finally, while I understand that others have a different opinion, I find it
> objectionable that not a single first page author is willing to list a
> telephone number of any sort in the Authors' Addresses section. To my mind,
> this sort of corner cutting does not speak well for the document.
>
>
> I'm honestly surprised that someone finds these phone numbers in IETF specs
> !

I am not going to engage in a conversation about this but I will respond once.

> succeed with email, not only because it can talk to all of them at the same
> time.

I agree it is convenient to have email addresses if you with to
shotgun a query to all the authors. I have not suggested leaving out
email addresses.

> I have a reasonable filter on my email for spam/commercial sollicitations,
> but not on my phone lines; this is a strong obstacle to providing phone
> numbers in the wild.

Most IETF participants can easily list a main number for a sponsor
which is, in effect, filtered. In any case, experience show this is
not a problem.

> Emails can also be slightly more stable than phone numbers.

Any of the three types of pointers can, in some cases, be much more
stable than the other two. Direct pointers for an individual can
change asynchronously from those via a sponsor. Of the three types of
information, any one could, in a particular case change more rapidly
than the others. It is more robust to list all three.

> being the more convenient phone number among a few possible ones, a confcall
> bridge or a login on video chat system...

You seem to keep falsely implying I asked for email addresses to be
left out. I didn't.

> In fact, I would suggest removing the postal address as well.

Sure you are. You are trying to get by with the minimal author address
information you can get away with. It's not hard to include a bit
more. So when I see this, I wonder what other corners have been cut.

But, not to worry, I'm pretty sure you will find your opinion on this
being backed up by the IAB and IESG.