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

From: Steve Donovan <[email-masked]>
Date: Tue, 04 Aug 2015 06:47:53 -0500

Stephen,

Please find my responses inline.

Regards,

Steve

On 7/5/15 5:20 PM, Stephen Farrell wrote:
> 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.
SRD> Agreed.  Propose removing the "DOIC" from the throttling definition.
>
> - 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.)
SRD> This was one of the early decisions made.  We can add wording along 
the lines of "This eases the integration of the DOIC mechanism into 
existing applications as all that is required is defining new AVPs."  I 
am, however, hesitant to add a lot of rational for decisions made in the 
design phase.  As you point out, it is already 55 pages.  :-)
>
> - 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.
SRD> Yes, the reporting node selects from the abatement algorithms 
advertised by the reacting node.  I don't see the inter/intra domain 
issue.  The reacting node indicates what it supports, the reporting 
nodes selects one of the algorithms.  If the reacting node doesn't want 
to support an algorithm then it won't advertise support in the first place.

SRD> There are other inter domain issues that are discussed in Appendix 
B (Topology Hiding Interactions) that are considered outside of the 
scope of the DOIC specification.
>
> - 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?
SRD> The logic of an agent in this case is considered to be an 
implementation decision.  When an agent handles this scenario, it is, in 
essence, acting as a back-to-back agent.  It is a reporting node on one 
side and a reacting node on the other.  Maybe it would help to add 
wording to the effect that the agent must be a fully compliant reporting 
node and reacting node.  That was the intent of the statement "Care must 
be taken not to introduce interoperability issues for downstream or 
upstream DOIC nodes."

SRD> I'm happy to beef this up if it is considered necessary.
>
> - 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?
SRD> Yes, this is an issue.  It is addressed in the first paragraph of 
the security considerations section.  Do we need to discuss it in the 
intro section as well?
>
> - 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.
SRD> This is because all of the Diameter nodes in the picture can take 
on both reacting and reporting node functionality depending on the 
context of an individual transaction.  Would it suffice to put wording 
to this effect in the paragraph after Figure 1?
>
> - 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?
SRD> I agree, the wording is misleading.  I propose to change it to "A 
reporting node MUST select a single abatement algorithm in the 
OC-Feature-Vector AVP.
>
> - 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.
SRD> Agreed.  How about the following: "If the reacting node determines 
that the sequence number has rolled over then the reacting node MUST 
update the matching OCS entry.  This can be determined by recognizing 
that the number has changed from something close to the maximum value in 
the OC-Sequence-Number AVP to something close to the minimum value in 
the OC-Sequence-Number AVP.
>
> - 5.3: "[RFC6733] defined Grouped AVP extension mechanisms
> apply. " is unclear, to me anyway. What's it mean?
SRD> This is a reference back to the base Diameter specification saying 
that extensibility mechanisms defined there also apply to the DOIC group 
AVPs.  This means that it is always possible to add new sub AVPs and 
that a node receiving a sub AVP that it does not understand should just 
ignore the sub AVP.
>
> - 6.1, step 4: I think that has to be a uniformly selected
> random number.
SRD> Agreed.
>
> - 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?
SRD> There is one way to get into 100% reduction - with an OLR 
indicating such.  A reacting node comes out of this when the OLR 
expires.  I'm not sure there is ambiguity here but we can modify the 
first sentence as follows if we think it is necessary: "If reacting node 
comes out of the 100 percent traffic reduction, meaning it has received 
an OLR indicating that no traffic should be sent, as a result of the 
overload report timing out..."
>
> - 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.
SRD> The receiving node should use the default value in this case.  I 
thought we had that there already.  I propose adding the following:  "If 
the value received in the OC-Validity-Duration is greater than the 
maximum value then the default value applies."
>
> - 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.
SRD> Would it suffice to add the following: "This may require 
out-of-band, non Diameter agreements and/or mechanisms."
>
> - 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.
SRD> We could add: "In the worst case, where the Diameter application is 
being used for access control into an IP network, a coordinated DOS 
attack could result in the blockage of all traffic into that network."
>
> - 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.
SRD> I vote that we strike all of Appendix C.  This was mostly a 
checkpoint to see how well the DOIC spec met requirements.  I'm not sure 
it adds value a part of an RFC.
>
> - 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.
SRD> See my previous comment.
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 17:40:04 +0100

Hiya,

A few notes below. Where I don't respond, your suggestions
are just fine.

I guess I'll mark this one as revised-I-D needed to handle
this and the gen-art review stuff and then when we get that
I can put it on an IESG telechat agenda.

Thanks,
S.

> design phase.  As you point out, it is already 55 pages.  :-)

Fair enough.

> to support an algorithm then it won't advertise support in the first place.

Maybe. I guess. I'd be surprised if folks took instructions
from outside that included saying to drop packets and how,
especially in the absence of any e2e security, but perhaps
you're right.

> SRD> I'm happy to beef this up if it is considered necessary.

Hmm. Sorry I'm still not getting it. Maybe if you said how one
could preserve or bugger-up interop that'd help?

> the security considerations section.  Do we need to discuss it in the

I'd say either mention if in 4.3 or else refer to a duration of
zero in section 10 if that's not there somewhere (and I don't
see it, just a mention of DoS in general).

> to this effect in the paragraph after Figure 1?

I just wondered. Do as you think best.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Aug 2015 16:19:25 -0500

>> On 7/5/15 5:20 PM, Stephen Farrell wrote:
<snip>
> especially in the absence of any e2e security, but perhaps
SRD2> Yes, but what you are talking about is a local policy decision.  
It's actually pretty likely that an operator won't let an overload 
report from individual servers be sent across administrative boundaries, 
as many consider the topology information contained to be sensitive 
information.  There is likely to be enforcement of reduction of Diameter 
signaling done at the edge of Diameter networks.  This, however, is just 
moving where the reacting node sits and is a deployment decision.

SRD2> I'll look to add some wording to the introductory section 
summarizing this.
> could preserve or bugger-up interop that'd help?
SRD2> I can add some wording on how to preserve.  Something to the 
effect that the agent must operate as a fully compliant reporting node 
in one direction and as a fully compliant reacting node in the other.
> see it, just a mention of DoS in general).
SRD> Ok.  I'll look at adding something in both places.

<snip>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 06 Aug 2015 09:45:55 -0500

I think the following point is better handled in the deployment 
considerations appendix.  As such, I've added the following wording to 
that appendix:

Inter Realm/Administrative Domain Considerations

There are likely to be special considerations for handling DOIC 
signaling across administrative boundaries.  This includes 
considerations for whether or not information included in the DOIC 
signaling should be sent across those boundaries.  In addition 
consideration should be taken as to whether or not a reacting node in 
one realm can be trusted to implement the requested overload abatement 
handling for overload reports received from a separately administered 
realm.

Steve
> report from individual servers be sent across administrative 
> boundaries, as many consider the topology information contained to be 
> sensitive information.  There is likely to be enforcement of reduction 
> of Diameter signaling done at the edge of Diameter networks.  This, 
> however, is just moving where the reacting node sits and is a 
> deployment decision.
>