[sip-overload] AD review: draft-ietf-soc-overload-control-13

Richard Barnes <rlb@ipv.sx> Fri, 12 July 2013 13:35 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A614521F9477 for <sip-overload@ietfa.amsl.com>; Fri, 12 Jul 2013 06:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level:
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxiRBEfJ-FGC for <sip-overload@ietfa.amsl.com>; Fri, 12 Jul 2013 06:35:48 -0700 (PDT)
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4475B11E80F9 for <sip-overload@ietf.org>; Fri, 12 Jul 2013 06:35:48 -0700 (PDT)
Received: by mail-ob0-f173.google.com with SMTP id wc20so11168632obb.4 for <sip-overload@ietf.org>; Fri, 12 Jul 2013 06:35:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=qEDM6+N2qctjm1R9zeMpnfLMrPeD1c71BEGZIj6W4dk=; b=emfffKfLsAAboTc0Cb3vLNhwIYBS6PdFu3OjZ2DWZtxOySi2HHCkDrzC9sJ+XQtgL0 UcNLm1jVBJ/TdRBVOFc7fBok1/uWMsYFgrubPDSQC+A2Yn03PuS4wuSyi7Oqp4U8VsEd wlUPIt0AHxWc4lv1QCYJjRUxlNtk8r2LnF6VOmUiugECB8jtBb6bVqo26wKkqUeC3i2s B5Q3ZECfKREASMwaHUFbhHqN1xzLXkxrKbJvlwrPiz+wCJTOuOFYjhi5v9/j50iDsAba GMnftvt94jlZN2XX4Unua2qNsR6ykccPbswskWMG/frINnQs0HcKn/KDZXFKnMgMoG2r Nyqg==
MIME-Version: 1.0
X-Received: by 10.182.232.225 with SMTP id tr1mr35758106obc.69.1373636147682; Fri, 12 Jul 2013 06:35:47 -0700 (PDT)
Received: by 10.60.26.135 with HTTP; Fri, 12 Jul 2013 06:35:47 -0700 (PDT)
X-Originating-IP: [76.21.182.222]
Date: Fri, 12 Jul 2013 09:35:47 -0400
Message-ID: <CAL02cgQDhgew9f93zAqeNhxeePoTE_QXCuC6JpoJpiEStFhT5A@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: sip-overload@ietf.org
Content-Type: multipart/alternative; boundary=001a11c31242a22e8a04e1509682
X-Gm-Message-State: ALoCoQlUEvkjFPIk/b1+KAoXevpb7gK5ehGzsvFvOcOIJ24OMsangJzvZZ/V8O5erAD056CxaQDc
Subject: [sip-overload] AD review: draft-ietf-soc-overload-control-13
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2013 13:35:56 -0000

I have reviewed this draft, and there are several issues that I would like
to address before sending it to IETF LC.

MAJOR:

1. The fourth paragraph of Section 4.4 does not allow clients to detect
when overflow has happened.  It seems like there are two options: (1)
Define the timestamp so it cannot overflow (e.g., as a sufficiently long
timestap), or (2) define what an "appropriate base value" is so that a
client can recognize when the "oc-seq" has been reset there.  It seems like
it would be simplest to imply say that "oc-seq" MUST be an N-bit counter
value or a timestamp.  (Or better, choose one.)

2. "oc=0" seems like a bad way to signal that there's no overload going on.
 "oc-validity=0" does that.  And if there's no overload condition, on
algorithm is being applied, so no "oc" parameter value needs to be
supplied.  So it seems like you should signal support with no overload with
"oc;oc-validity=0".

3. As written, it seems like Section 5.9 could be read to require a
behavior that would exacerbate overload conditions with liveness checks.
 (For example, "periodically" with period 500ms.)  Suggest that this
section recommend a back-off algorithm, possibly with some concrete timing
paramters.  E.g., start at whatever interval you like, exponential back-off
to some floor (say 10sec).

4. The Security Considerations do a good job of describing the threats that
this mechanism introduces, but less so the mitigations to these threats.
 In particular, there is no mitigation provided for the multi-hop attack,
and the mitigation for a malicious client is not clearly stated.  Suggest:
-- Recommending that clients enforce a maximum validity period (e.g.,
3600s) in order to limit the scope of spoofing attacks (off-path or
multi-hop)
-- "Servers SHOULD monitor client behavior to determine whether they are
complying with overload control policies.  If a client is not conforming,
then the server SHOULD treat it as a non-supporting client (Section
5.10.2)."


MINOR:

1. The last paragraph of Section 2 is tautological.  ("The normative
statements...this specification.")  If an entity doesn't support this
specification, then of course the normative requirements don't apply!  Do
you mean something different from that?

2. In Section 4.2, it would help if you could say briefly why multiple
algorithms are needed.  Are some algorithms better suited to different
overload conditions?  Or could the group just not make up its mind?  (Maybe
there's a reference for this?)

3. Mandating that "loss" be included in the list of supported algorithms
seems duplicative.  Clients are already required to support "loss" and put
supported algorithms in the list.  It also seems undesirable for servers to
rely on "loss" being present, since that could cause problems if for some
reason we decide to deprecate "loss" in the future (cf. [[ SDP codec change
]])

4. It's not clear why the "oc-seq" parameter needs a fractional portion.
 Wouldn't it be simple just to make it an integer?

5. In Section 5.8, "frequent changes of overload control algorithm MUST be
avoided" -- This is not an RFC 2119 MUST.

6. In Section 5.8, "the algorithm MUST remain in effect" -> "the server
SHOULD NOT change the algorithm for that client"  It seems like you
wouldn't want to prevent the server from changing if it really needed to.

7. In Section 5.10.2, the recommendation at the end seems a little light,
and unclear how to implement.  You might recommend a simple algorithm to
apply here, e.g., just drop everything from non-supporting clients.

8. In Section 6.1, the last two paragraphs are completely redundant with
the general behavior specified above.

9. The example in Section 6.2 is not specific to the "loss" algorithm.  It
should be moved up to the top level.

10. Should Section 9 be moved to an appendix?

11. In Section 10, it's not really even necessary to use TLS to prevent
spoofing.  In many cases just using a connection-oriented protocol like TLS
or WS would be sufficient.


Thanks,
--Richard