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

Charles Shen <qs2005@columbia.edu> Thu, 31 October 2013 15:00 UTC

Return-Path: <charles.newyork@gmail.com>
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 BC2F611E81C6 for <sip-overload@ietfa.amsl.com>; Thu, 31 Oct 2013 08:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYUdF0zX9NkP for <sip-overload@ietfa.amsl.com>; Thu, 31 Oct 2013 08:00:39 -0700 (PDT)
Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id A20C911E8196 for <sip-overload@ietf.org>; Thu, 31 Oct 2013 08:00:31 -0700 (PDT)
Received: by mail-oa0-f52.google.com with SMTP id j1so3195963oag.11 for <sip-overload@ietf.org>; Thu, 31 Oct 2013 08:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.60.116.230 with SMTP id jz6mr3045835oeb.21.1383231628039; Thu, 31 Oct 2013 08:00:28 -0700 (PDT)
MIME-Version: 1.0
Sender: charles.newyork@gmail.com
Received: by 10.182.27.9 with HTTP; Thu, 31 Oct 2013 08:00:07 -0700 (PDT)
In-Reply-To: <CAL02cgSKQOhb_8v6SF4o=_WDieobFki_Qy2aaO=-KA-FRJqTsw@mail.gmail.com>
References: <CAL02cgQW3eJg+f0nwEwihJGRgE82o+B0gSx0LJ6vTP1M8F+n5w@mail.gmail.com> <CAL02cgSMrQTJt=LJg+j7c-9XrX=N9i=14vAvxqkq2KBgPbdHiQ@mail.gmail.com> <CAPSQ9ZUY547AXNgsiSQE9H7Wr8UZAv_0N-rgyAdm5FeWsfjb1w@mail.gmail.com> <CAL02cgSKQOhb_8v6SF4o=_WDieobFki_Qy2aaO=-KA-FRJqTsw@mail.gmail.com>
From: Charles Shen <qs2005@columbia.edu>
Date: Thu, 31 Oct 2013 11:00:07 -0400
X-Google-Sender-Auth: gsdbLhGvP0MvAd8oFqfRQ_o4ltg
Message-ID: <CAPSQ9ZXfH7YQX-wjWZkKJRSzpXnWFch0_i=TUvAkVjjNpGj0gA@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary=089e0115e84ad4df8204ea0ab558
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>, "draft-ietf-soc-load-control-event-package@tools.ietf.org" <draft-ietf-soc-load-control-event-package@tools.ietf.org>
Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08
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: 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 <rlb@ipv.sx> 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 <qs2005@columbia.edu> 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 <rlb@ipv.sx> 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 victim@outside-of-trust-domain.com
>>> -- 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 <rlb@ipv.sx> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sip-overload
>>>
>>>
>>
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>