Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08

Charles Shen <> Thu, 31 October 2013 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC2F611E81C6 for <>; Thu, 31 Oct 2013 08:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yYUdF0zX9NkP for <>; Thu, 31 Oct 2013 08:00:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::234]) by (Postfix) with ESMTP id A20C911E8196 for <>; Thu, 31 Oct 2013 08:00:31 -0700 (PDT)
Received: by with SMTP id j1so3195963oag.11 for <>; Thu, 31 Oct 2013 08:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EL13KFjOHUmxBoKFejA6rtwviRpWI+zkEr9GTWLu+kI=; b=Is5FJrYYc/mzonDw6jrubHjp0b/pNvmOLSmNvi4ZY831IgyBMr4sFQ8FnPJSgmm6ZL pB48Qgo34zUsoMaDghyg9AV2OjPoe2EsSv/ahiZe8sQ6TR18ycX+7rdsqF7/kTMFVnJf IWYd8a65j4s8WKHdWOamUKtv9RHgwfu9MfjXdQUdgrQKPY7FDVHo65V/D7icHaulLf3A 7VqT+fZWmQ7Ayf6M4f7S3olWojP6Ee+gjauXFlDbXgZt/oDdzKGmZ4Qkm1F2RDlpSirO kJXb5lCPRFr/tYYFX5WPgzWxdZr1KM8Ciso2Bx8sisopgJPZnqdfnj7AuYKMnJ/woZ0w chtg==
X-Received: by with SMTP id jz6mr3045835oeb.21.1383231628039; Thu, 31 Oct 2013 08:00:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 31 Oct 2013 08:00:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Charles Shen <>
Date: Thu, 31 Oct 2013 11:00:07 -0400
X-Google-Sender-Auth: gsdbLhGvP0MvAd8oFqfRQ_o4ltg
Message-ID: <>
To: Richard Barnes <>
Content-Type: multipart/alternative; boundary=089e0115e84ad4df8204ea0ab558
Cc: "" <>, "" <>
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 15:00:43 -0000

Hi Richard, I will let the "bunch of"s go before upload :)

On Wed, Oct 30, 2013 at 4:52 PM, Richard Barnes <> wrote:

> I wouldn't have used my text quite so directly (maybe edited out some
> "bunch of" instances), but this looks OK to me.  Thanks for the quick
> update.  Please feel free to post.
> Is there anyone in the WG that has an objection to these changes?
> On Wed, Oct 30, 2013 at 2:11 PM, Charles Shen <> wrote:
>> Dear Richard,
>> Thank you very much for your comments! I've incorporated your suggestions
>> into a revised version, as attached for your reference. Changes are in
>> Section 5.4 (definition of Trust Domain) and Section 11 (Security
>> Considerations). If there are any further concerns please let me know, I
>> will upload the most updated revision when the IETF submission site
>> re-opens on Nov. 4.
>> Thanks!
>> Charles
>> On Tue, Oct 29, 2013 at 3:08 PM, Richard Barnes <> wrote:
>>> Dear authors,
>>> Thanks for updating this document.  It looks much better.  Sorry for the
>>> delay in my reply.
>>> The one thing I don't think is quite adequately addressed by the
>>> considerations around the use of the "redirect" action.
>>> The attack I'm worried about is something like the following:
>>> -- A bunch of proxies in a Trust Domain are using UDP, and configured to
>>> get their policies from a central server.
>>> -- Attacker spoofs the server's address to send a bunch of NOTIFY bodies
>>> telling proxies to send all calls to
>>> -- Proxies redirect all calls to victim, who is now DoSed off of the
>>> Internet
>>> In order to address this threat, you need to either (1) remove the
>>> "redirect" action, or (2) constrain redirects to a safe space.  I assume
>>> that the WG doesn't want to do (1) :)
>>> Proposed edits:
>>> -- Add to the definition of a Trust Domain an agreement on the types of
>>> calls that can be affected by load control.  For example, <one> and <many>
>>> element might be limited to specific domains; <*-tel> elements might be
>>> limited to be within certain prefixes.
>>> -- Add to the definition of a Trust Domain an agreement on the
>>> destinations to which calls may be redirected.  For example, the URI might
>>> have to match a given set of domains.
>>> -- Add text to the Security Considerations describing the above attack,
>>> and REQUIREing that implementations enforce the limits described in the
>>> definition of their Trust Domain.
>>> Thanks,
>>> --Richard
>>> On Wed, Apr 17, 2013 at 1:53 PM, Richard Barnes <> wrote:
>>>> I have reviewed this document, and have a few questions before IETF LC:
>>>> Major:
>>>> In a few places, for example Section 5.3., the document suggests that
>>>> this event package could be used to communicate load filtering policies
>>>> between domains.  This seems like a bad idea for a few reasons.  First,
>>>> policies can be based on "P-Asserted-Identity", which is itself limited to
>>>> use within a trust domain / Spec(T).  It doesn't make sense to have
>>>> policies based on these identifiers outside of the domain in which they are
>>>> used.  Second, inter-domain policies can create subtle and dangerous
>>>> security risks.  For example, according to the current specification,
>>>> Domain A could tell Domain B to drop all calls between Domain B and Domain
>>>> C.  It's not clear how you would prevent these sorts of attacks, especially
>>>> where "tel:" URIs are involved.  I think both of these issues go away if
>>>> this event package is limited in a similar way to P-Asserted-Identity,
>>>> i.e., limited to use within a trust domain.
>>>> Section 6.3., "SUBSCRIBE Bodies" doesn't actually say anything about
>>>> what goes in the body of a SUBSCRIBE message.  On the one hand, it implies
>>>> that there could be a body (since the last sentence considers a request
>>>> without a body as a special case), but it doesn't say what goes in the body
>>>> if there is one.  Please either (1) define what may go in the body, (2)
>>>> explicitly say that this document does not specify what goes in SUBSCRIBE
>>>> bodies, or (3) require that the body be empty.   (Also, the first paragraph
>>>> of this section seems out of place here, since it also has nothing to do
>>>> with the body.)
>>>> In Section 6.5., the last sentence is wrong.  The presence of an Accept
>>>> header indicates that the response body should be one of the indicated
>>>> types.  The indicated behavior would only be acceptable if the Accept
>>>> header included "multipart/mixed".  Suggest deleting the last sentence.
>>>>  (Also,  it would be clearer to change "the request body will contain" to
>>>> "the request body MUST contain".)
>>>> In Section 7.3.1, you need to specify how a "tel:" URI is matched
>>>> against a domain value starting with "+".  Your examples seem to indicate
>>>> simple string prefix matching, but I doubt that's what you actually want,
>>>> since non-digit characters can break things.  For example, "+1212" should
>>>> match "+1-212-555-1212".  Please specify a matching algorithm here.
>>>> In Section 7.3.2, please change "Non-initial requests ... are not
>>>> subjected" to "Non-initial requests ... MUST NOT be subjected".
>>>> Section 7.4. doesn't adequately define the actions to be taken.  Each
>>>> of the action elements (<rate>, <window>, <percent>) need to define a
>>>> concrete action that the proxy should take.
>>>> RFC 4745 allows rules to combine when multiple rules match a given
>>>> call.  This document needs to define combination rules for the actions
>>>> defined here.
>>>> What's the reason for having both the "drop" action and the "reject"
>>>> action?  It seems like the "drop" action is almost always harmful.  With
>>>> unreliable transport, it causes retransmits, and even with reliable
>>>> transport, it causes the client to wait unnecessarily until the connection
>>>> times out.  In any case, the "simple drop" action is underspecified.  For
>>>> example, does the server simply ignore the SIP message, or does it close
>>>> the transport connection?
>>>> Minor:
>>>> In Section 7.3, "we re-define" -- the document doesn't re-define any of
>>>> the elements in RFC 4745 (that's good; redefinition is bad).  Instead, you
>>>> should say you define new identity elements.
>>>> In Section 7.3.1, please break up paragraph starting "To include the
>>>> two forms..." for greater readability.  Suggested break points: Before
>>>> "Note that the tradeoff...", and before "It should be noted..."
>>>> In Section 7.3.3, it would be helpful to break up the paragraph
>>>> starting "The following are two example...".  Break before "Usecase I" and
>>>> "Usecase II".  Also, s/Usecase/Use case/g
>>>> Thanks,
>>>> --Richard
>>> _______________________________________________
>>> sip-overload mailing list
> _______________________________________________
> sip-overload mailing list