Subject: [Dime] AD review of draft-ietf-dime-ovli-08

From: Stephen Farrell <[email-masked]>
Date: Sun, 05 Jul 2015 23:20:58 +0100

Hi,

Firstly, I'm your new helper-AD, Kathleen and I had to swap a
few working groups so I'll be helping out now. Most of the stuff
I've seen from this WG is pretty well baked these days though
so I'm sure it'll all be fine. (Kathleen will continue to handle
discuss-clearing for the congestion control document.)

Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just
have one question to check before I start IETF last call. The
rest of my comments (below) can be handled along with any other
last call comments received unless you'd prefer to fix something
before we start IETF last call.

The one I'd like to chat about before IETF LC is: I see that both
WG chairs are authors on this one, so how was WG consensus
evaluation handled? That was probably before I joined the list
I guess but I didn't spot it in the archive after a quick glance.

Thanks,
S.

- 55 pages! sigh;-)

- 2: throttling definition uses "DIOC" but earlier in this
section you just say reacting-node. Maybe good to be fully
consistent.

- 4 (intro) I wondered why no new messages were defined for
this and you decided to only piggyback.  Maybe good to say why
and also to give an example of the kind of thing on which
you'd normally expect DOIC stuff to be piggybacked. (That
could be done in 4.1 too.)

- 4.2 - the reporting node picks the abatement algorithm that
the reacting node will apply - is that correct? (from 2nd last
para of p8) Does that mean that DOIC will in the end only be
used intra-domain since reacting nodes aren't likely to accept
such instructions from "anyone" else? If so, it'd be good to
point that out early, and not only in section 10.

- 4.2, last para/Note: This seems to be punting on interop
which isn't a good thing for the IETF to be doing is it? Why
is that ok here?

- 4.3: Could anyone inject an OLR with a duration of zero as a
DoS? Is there something hard to guess? (Turns out, no there's
nothing added here that's hard to guess.) Maybe think about
putting in a note about that?

- Figure 1: how come there are no reporting or reacting nodes
included? I'd have thought it'd be good to have (an example
of) those in a figure.

- 5.1.2, 5th last para: is "indicate support" right here?
isn't this the reporting node asking that that alg be used,
but the alg is really "supported" at the reacting node?

- 5.2.1.3: Where do you say how to handle the case where a
sequence number wraps around? Even if that's highly improbable
the text to say what to do is cheap.

- 5.3: "[RFC6733] defined Grouped AVP extension mechanisms
apply. " is unclear, to me anyway. What's it mean?

- 6.1, step 4: I think that has to be a uniformly selected
random number.

- 6.3: "If reacting node comes out of the 100 percent traffic
reduction..." I don't get what that condition means exactly.
Would all implementers read it to mean the same thing?

- 7.5: What does a receiver do if a duration value that's
greater than 24 hours is received? One could barf the message
or treat it as default (30s) or as a day I guess.  If this is
covered by some generic Diameter default handling of bad
values, that's fine.

- 10.1 says: "t's critical that nodes validate that an
overload report received from a peer actually falls within
that peer's responsibility..." but I don't see how that can be
done solely using Diameter protocol elements so don't you need
to say that some out-of-band agreement/information is needed
for this to work? Even within a single administrative domain,
a node would need to check that the peer is "inside" and
presumably border nodes would need even more.

- 10.2, para 1: I think it'd be helpful here if an example
Diameter application with a really bad potential for a DoS,
just for emphasis. As-is, it's not really clear how bad a
potential DoS might be.

- C.5 - section 10 seems to me to be a new vulnerability that
is entirely due to DOIC, so this seems wrong. It's also a
tad late for early security review. I'd say to strike the
entire C.5 section, or at least re-word.

- Appendix C.6: I skipped this one. Not sure if it's better
to keep or drop. Keeping it might just lead to more argument
is the concern.

---

From: <[email-masked]>
Date: Sun, 5 Jul 2015 23:47:59 +0000

Hi Stephen,

This draft is the result of a joint effort between IETF and 3GPP for the definition of an overload control mechanism over Diameter.
Both chairs are (unfortunately maybe) part of the authors but around 20+ people were active in DIME WG and 3GPP WGs to review and comment the documents, with confcalls and ad-hoc meetings dedicated to this topic.

The document went through 2 WGLCs in December 2014 and January 2015), with cross review by 3GPP.
The current document takes into account all the comments received during the 2 WGLCs and the feedback received from 3GPP folks.

We can safely conclude that a rough consensus has been reached for this document. It ends a cooperative work started in Sept 2012, with the definition of the requirements (captured in RFC 7068), and reflects the constructive compromise reached by all the involved parties.

For your information, due to the participation of both chairs in this work, Benoit has been involved from the very beginning on the discussions on this document to monitor the discussion.

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Stephen Farrell
Envoyé : lundi 6 juillet 2015 00:21
À : [email-masked]
Objet : [Dime] AD review of draft-ietf-dime-ovli-08

Hi,

Firstly, I'm your new helper-AD, Kathleen and I had to swap a few working groups so I'll be helping out now. Most of the stuff I've seen from this WG is pretty well baked these days though so I'm sure it'll all be fine. (Kathleen will continue to handle discuss-clearing for the congestion control document.)

Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have one question to check before I start IETF last call. The rest of my comments (below) can be handled along with any other last call comments received unless you'd prefer to fix something before we start IETF last call.

The one I'd like to chat about before IETF LC is: I see that both WG chairs are authors on this one, so how was WG consensus evaluation handled? That was probably before I joined the list I guess but I didn't spot it in the archive after a quick glance.

Thanks,
S.

- 55 pages! sigh;-)

- 2: throttling definition uses "DIOC" but earlier in this section you just say reacting-node. Maybe good to be fully consistent.

- 4 (intro) I wondered why no new messages were defined for this and you decided to only piggyback.  Maybe good to say why and also to give an example of the kind of thing on which you'd normally expect DOIC stuff to be piggybacked. (That could be done in 4.1 too.)

- 4.2 - the reporting node picks the abatement algorithm that the reacting node will apply - is that correct? (from 2nd last para of p8) Does that mean that DOIC will in the end only be used intra-domain since reacting nodes aren't likely to accept such instructions from "anyone" else? If so, it'd be good to point that out early, and not only in section 10.

- 4.2, last para/Note: This seems to be punting on interop which isn't a good thing for the IETF to be doing is it? Why is that ok here?

- 4.3: Could anyone inject an OLR with a duration of zero as a DoS? Is there something hard to guess? (Turns out, no there's nothing added here that's hard to guess.) Maybe think about putting in a note about that?

- Figure 1: how come there are no reporting or reacting nodes included? I'd have thought it'd be good to have (an example
of) those in a figure.

- 5.1.2, 5th last para: is "indicate support" right here?
isn't this the reporting node asking that that alg be used, but the alg is really "supported" at the reacting node?

- 5.2.1.3: Where do you say how to handle the case where a sequence number wraps around? Even if that's highly improbable the text to say what to do is cheap.

- 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. " is unclear, to me anyway. What's it mean?

- 6.1, step 4: I think that has to be a uniformly selected random number.

- 6.3: "If reacting node comes out of the 100 percent traffic reduction..." I don't get what that condition means exactly.
Would all implementers read it to mean the same thing?

- 7.5: What does a receiver do if a duration value that's greater than 24 hours is received? One could barf the message or treat it as default (30s) or as a day I guess.  If this is covered by some generic Diameter default handling of bad values, that's fine.

- 10.1 says: "t's critical that nodes validate that an overload report received from a peer actually falls within that peer's responsibility..." but I don't see how that can be done solely using Diameter protocol elements so don't you need to say that some out-of-band agreement/information is needed for this to work? Even within a single administrative domain, a node would need to check that the peer is "inside" and presumably border nodes would need even more.

- 10.2, para 1: I think it'd be helpful here if an example Diameter application with a really bad potential for a DoS, just for emphasis. As-is, it's not really clear how bad a potential DoS might be.

- C.5 - section 10 seems to me to be a new vulnerability that is entirely due to DOIC, so this seems wrong. It's also a tad late for early security review. I'd say to strike the entire C.5 section, or at least re-word.

- Appendix C.6: I skipped this one. Not sure if it's better to keep or drop. Keeping it might just lead to more argument is the concern.

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

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: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jul 2015 10:18:19 +0100

Hi Lionel,

That all sounds good. How's about though, just to be sure to be
sure, that I wait a week before starting IETF LC and ask that during
that week, anyone who has concerns about the chairs' evaluation of WG
consensus for this draft, please either send to the list or else tell
me offlist (if there's a good reason that's needed). That way, if
someone asks about this during IETF LC or IESG evaluation, we can
point them at this (recent) thread.

If, as I expect, I hear no objections, I'll start IETF LC in a week
and that'll have no effect on the overall timing given the upcoming
IETF meeting - we'll still be fine all going well to put this on
the August 5th IESG telechat. If something (*) does come up in the
next week, we'll deal with that as necessary.

In the meantime, the authors should feel free to respond to any of
my review comments that are useful (or useless:-) Or if you want,
it's fine to wait and handle 'em with other IETF LC comments
received if you prefer that.

Cheers,
S.

(*) By "something" here I *only* mean issues related to the chairs'
evaluation of the level of WG consensus for this draft. I do not
mean it's ok to re-raise technical topics that were already discussed
on the list or at meetings and disposed of via the usual WG process.

On 06/07/15 00:47, [email-masked] wrote:
> Hi Stephen,
> 
> This draft is the result of a joint effort between IETF and 3GPP for
> the definition of an overload control mechanism over Diameter. Both
> chairs are (unfortunately maybe) part of the authors but around 20+
> people were active in DIME WG and 3GPP WGs to review and comment the
> documents, with confcalls and ad-hoc meetings dedicated to this
> topic.
> 
> The document went through 2 WGLCs in December 2014 and January 2015),
> with cross review by 3GPP. The current document takes into account
> all the comments received during the 2 WGLCs and the feedback
> received from 3GPP folks.
> 
> We can safely conclude that a rough consensus has been reached for
> this document. It ends a cooperative work started in Sept 2012, with
> the definition of the requirements (captured in RFC 7068), and
> reflects the constructive compromise reached by all the involved
> parties.
> 
> For your information, due to the participation of both chairs in this
> work, Benoit has been involved from the very beginning on the
> discussions on this document to monitor the discussion.
> 
> Regards,
> 
> Lionel
> 
> -----Message d'origine----- De : DiME [mailto:[email-masked]]
> De la part de Stephen Farrell Envoyé : lundi 6 juillet 2015 00:21 À :
> [email-masked] Objet : [Dime] AD review of draft-ietf-dime-ovli-08
> 
> 
> Hi,
> 
> Firstly, I'm your new helper-AD, Kathleen and I had to swap a few
> working groups so I'll be helping out now. Most of the stuff I've
> seen from this WG is pretty well baked these days though so I'm sure
> it'll all be fine. (Kathleen will continue to handle discuss-clearing
> for the congestion control document.)
> 
> Anyway, here's my AD review for draft-ietf-dime-ovli-08. I just have
> one question to check before I start IETF last call. The rest of my
> comments (below) can be handled along with any other last call
> comments received unless you'd prefer to fix something before we
> start IETF last call.
> 
> The one I'd like to chat about before IETF LC is: I see that both WG
> chairs are authors on this one, so how was WG consensus evaluation
> handled? That was probably before I joined the list I guess but I
> didn't spot it in the archive after a quick glance.
> 
> Thanks, S.
> 
> 
> - 55 pages! sigh;-)
> 
> - 2: throttling definition uses "DIOC" but earlier in this section
> you just say reacting-node. Maybe good to be fully consistent.
> 
> - 4 (intro) I wondered why no new messages were defined for this and
> you decided to only piggyback.  Maybe good to say why and also to
> give an example of the kind of thing on which you'd normally expect
> DOIC stuff to be piggybacked. (That could be done in 4.1 too.)
> 
> - 4.2 - the reporting node picks the abatement algorithm that the
> reacting node will apply - is that correct? (from 2nd last para of
> p8) Does that mean that DOIC will in the end only be used
> intra-domain since reacting nodes aren't likely to accept such
> instructions from "anyone" else? If so, it'd be good to point that
> out early, and not only in section 10.
> 
> - 4.2, last para/Note: This seems to be punting on interop which
> isn't a good thing for the IETF to be doing is it? Why is that ok
> here?
> 
> - 4.3: Could anyone inject an OLR with a duration of zero as a DoS?
> Is there something hard to guess? (Turns out, no there's nothing
> added here that's hard to guess.) Maybe think about putting in a note
> about that?
> 
> included? I'd have thought it'd be good to have (an example of) those
> in a figure.
> 
> - 5.1.2, 5th last para: is "indicate support" right here? isn't this
> the reporting node asking that that alg be used, but the alg is
> really "supported" at the reacting node?
> 
> - 5.2.1.3: Where do you say how to handle the case where a sequence
> number wraps around? Even if that's highly improbable the text to say
> what to do is cheap.
> 
> - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms apply. "
> is unclear, to me anyway. What's it mean?
> 
> reduction..." I don't get what that condition means exactly. Would
> all implementers read it to mean the same thing?
> 
> - 7.5: What does a receiver do if a duration value that's greater
> than 24 hours is received? One could barf the message or treat it as
> default (30s) or as a day I guess.  If this is covered by some
> generic Diameter default handling of bad values, that's fine.
> 
> - 10.1 says: "t's critical that nodes validate that an overload
> report received from a peer actually falls within that peer's
> responsibility..." but I don't see how that can be done solely using
> Diameter protocol elements so don't you need to say that some
> out-of-band agreement/information is needed for this to work? Even
> within a single administrative domain, a node would need to check
> that the peer is "inside" and presumably border nodes would need even
> more.
> 
> - 10.2, para 1: I think it'd be helpful here if an example Diameter
> application with a really bad potential for a DoS, just for emphasis.
> As-is, it's not really clear how bad a potential DoS might be.
> 
> - C.5 - section 10 seems to me to be a new vulnerability that is
> entirely due to DOIC, so this seems wrong. It's also a tad late for
> early security review. I'd say to strike the entire C.5 section, or
> at least re-word.
> 
> - Appendix C.6: I skipped this one. Not sure if it's better to keep
> or drop. Keeping it might just lead to more argument is the concern.
> 
> 
> 
> 
> 
> _______________________________________________ DiME mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dime
> 
>  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: Jouni Korhonen <[email-masked]>
Date: Mon, 06 Jul 2015 11:00:21 -0700

Stephen,

We also ran all the questions and concerns through issue tracker. That 
also documents the process of concensus reaching way before we entered 
into WGLCs. See:
http://www.ietf.org/mail-archive/web/dime/current/msg06443.html

And as usual with all that I govern can also be found from github where 
every change is pretty much traceable:
https://github.com/jounikor/draft-docdt-dime-ovli

- Jouni

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jul 2015 19:20:54 +0100

Hi Jouni,

Great - if anything comes up then that'd help us figure out
what happened. But I don't really expect anything to come up
here, we're just being doubly-sure everyone's had a chance
to raise issues if needed.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Jul 2015 12:40:45 +0100

And a week has passed. I heard nothing so I'll start IETF
LC now. Thanks for your patience. Please consider my other
comments as part of the IETF LC.

Thanks,
S.