Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-dime-drmp-04

From: Meral Shirazipour <[email-masked]>
Date: Thu, 24 Mar 2016 07:32:47 +0000

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document:  draft-ietf-dime-drmp-04
Reviewer: Meral Shirazipour
Review Date: 2016-03-24
IETF LC End Date:  2016-03-24
IESG Telechat date: NA

Summary:
This draft is ready to be published as Standards Track RFC but I have some comments.

Major issues:

Minor issues:
-[Page 7],
"The mechanism for how the agent determines which requests are
       throttled is implementation dependent and is outside the scope of  this document.
"

Shouldn't all nodes handshake the mechanism to use to avoid countering each other's throttling decision/effect?

-Security:
Security section is well written but not convincing that the method described in this draft is a viable solution specially for first responder and public safety scenarios.
Section 11.2 says DDOS is not an imminent thread but a few compromised nodes could send heavy load of high priority requests - I may be missing something here?

Nits/editorial comments:
-[Page 2], Please spell out DOIC at first use "Diameter Overload Indication Conveyance"

-[Page 3], second sentence would read better as:
old:
"For instance it might be considered important to reduce the
   probability of transactions involving first responders during a
   period of heavy signaling resulting from a natural disaster being
   throttled during overload scenarios.
"
new (suggested):
"For instance it might be considered important to reduce the
probability of transactions involving first responders being throttled
during overload scenarios caused for example by a period of heavy signaling
resulting from a natural disaster.
"
-[Page 3], "the DIOC reacting node", should it be DOIC?

-[Page 4], Please spell out AVP at first use (currently done in Section 9)

-[Page 6], "Platinum SLA the includes"--->"Platinum SLA that includes"

-comment on above sentence? (should we say in case net neutrality rules are not in place, ...." ?

-[Page 6], sentence below did not read well.
old:
"In this scenario it is requests with the same command code that have
different implied priorities.

"

new (suggested):
"In this scenario requests with the same command code have
different implied priorities.
"

-[Page 6], Please spell out ULR at first use

-[Page 7]

-[Page 7], [Page 8], and [Page 9] "non supportant"--->"non-supporting"

-[Page 12], "which requests are are"--->"which requests are"

-[Page 13], Please spell out TCP, SCTP, TLS, DTLS at first use

-[Page 14], "degrated"--->"degraded"

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com

---

From: Steve Donovan <[email-masked]>
Date: Thu, 24 Mar 2016 16:38:10 -0500

Meral,

Thank you for the review.  Please see my comments inline.

Regards,

Steve

On 3/24/16 2:32 AM, Meral Shirazipour wrote:
>
> I am the assigned Gen-ART reviewer for this draft. The General Area 
> Review Team (Gen-ART) reviews all IETF documents being processed by 
> the IESG for the IETF Chair. Please treat these comments just like any 
> other last call comments.
>
> For more information, please see the FAQ at 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Shouldn’t all nodes handshake the mechanism to use to avoid countering 
> each other’s throttling decision/effect?
>
SRD> The handshake on the overload abatement algorithm is outlined in 
RFC 7683.  This document just allows for communication of message 
priority information that can then feed into the abatement algorithm used.
>
> -Security:
>
> Security section is well written but not convincing that the method 
> described in this draft is a viable solution specially for first 
> responder and public safety scenarios.
>
> Section 11.2 says DDOS is not an imminent thread but a few compromised 
> nodes could send heavy load of high priority requests – I may be 
> missing something here?
>
SRD> I guess I don't understand the question.  It is true, as stated in 
the draft, that the DRMP mechanism can be abused.  It is also stated 
that the transitive trust limitation that currently exists in Diameter 
must be understood when using DRMP because of this.  There are efforts 
in the DIME group to address the need for end-to-end security but that 
doesn't exist yet.  So this draft is limited to outlining the 
limitations and impacts of the solution.
> -[Page 2], Please spell out DOIC at first use "Diameter Overload 
SRD> Done.
> resulting from a natural disaster.
SRD> OK
> -[Page 3], "the DIOC reacting node", should it be DOIC?
SRD> Yes, good catch.
> -[Page 4], Please spell out AVP at first use (currently done in Section 9)
SRD> Done
> -[Page 6], "Platinum SLA the includes"--->"Platinum SLA that includes"
SRD> Done
> rules are not in place, ...." ?
SRD> I don't see the need.  If net neutrality rules forbid 
prioritization of Diameter overload abatement decisions then this 
sentence doesn't apply.  If those rules do not exist then it does. This 
seems pretty self evident.
> different implied priorities.
SRD> Good suggestion.
> -[Page 6], Please spell out ULR at first use
SRD> Done
> -[Page 7], [Page 8], and [Page 9] "non supportant"--->"non-supporting"
SRD> I changed the two instances of non supporting that I found.
> -[Page 12], "which requests are are"--->"which requests are"
SRD> No pirates allows... :-) Change made.
> -[Page 13], Please spell out TCP, SCTP, TLS, DTLS at first use
SRD> Done
> -[Page 14], "degrated"--->"degraded"
SRD> Done

---

From: Meral Shirazipour <[email-masked]>
Date: Fri, 25 Mar 2016 18:53:28 +0000

Hi,
  Many thanks for the response and changes. Please see in line.

Best,
Meral

From: Steve Donovan [mailto:[email-masked]]
Sent: Thursday, March 24, 2016 2:38 PM
To: Meral Shirazipour; [email-masked]; [email-masked]
Subject: Re: Gen-ART Last Call review of draft-ietf-dime-drmp-04

Meral,

Regards,

Steve

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Summary:

Major issues:

Minor issues:
-[Page 7],

Shouldn't all nodes handshake the mechanism to use to avoid countering each other's throttling decision/effect?
SRD> The handshake on the overload abatement algorithm is outlined in RFC 7683.  This document just allows for communication of message priority information that can then feed into the abatement algorithm used.

-Security:
Security section is well written but not convincing that the method described in this draft is a viable solution specially for first responder and public safety scenarios.
Section 11.2 says DDOS is not an imminent thread but a few compromised nodes could send heavy load of high priority requests - I may be missing something here?
SRD> I guess I don't understand the question.  It is true, as stated in the draft, that the DRMP mechanism can be abused.  It is also stated that the transitive trust limitation that currently exists in Diameter must be understood when using DRMP because of this.  There are efforts in the DIME group to address the need for end-to-end security but that doesn't exist yet.  So this draft is limited to outlining the limitations and impacts of the solution.

[MSh] I may have missed it but is there any note in the draft referring to DIME group's work? If not I would suggest to clarify this limitation and refer to the work perhaps  in the Security section.

Nits/editorial comments:

-comment on above sentence? (should we say in case net neutrality rules are not in place, ...." ?
SRD> I don't see the need.  If net neutrality rules forbid prioritization of Diameter overload abatement decisions then this sentence doesn't apply.  If those rules do not exist then it does.  This seems pretty self evident.

"

new (suggested):

-[Page 7]

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com<http://www.ericsson.com>