Return-Path: 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 3E91821E8056 for ; Wed, 19 Jun 2013 22:40:27 -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 IuNpNpakKbQo for ; Wed, 19 Jun 2013 22:40:26 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1777C11E80D9 for ; Wed, 19 Jun 2013 22:40:25 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so6729036obc.20 for ; Wed, 19 Jun 2013 22:40:25 -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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Ax0/fPcjWLTFHXAfuUH2fox5GpjN/mIvUgdJcead2Y0=; b=WlX1j4Dic6AX44CwNWYRNnGTaEPwseqhQuu7eTmfCV/GIjlIFUAsducirkq08/940F xrWYyx9qcetSpYfPZuuFKinGva7EoUT7BRDkfbL+gOEurVU/tXxnrNXpwirla5QBEAun ETTB7ehq4tTp81ylpJK6mFnTygFs4pgAJD7JaZZ4Ol+PPl7aSX5H2+bEIurbpgQS245J yYsgqTYpDuu2gVQP4sQ2NOzK4DkWivd6r09/a3jf34081RkHVET9LMf2YCiQra5j2lxZ 3zaa8Jakov/1CHnxe7hnv7nAk0dNQ4hEkG9/+wUN3YSM1lMVFOTOjVS+BiLS11hQLnV9 7Byg== X-Received: by 10.182.220.199 with SMTP id py7mr804966obc.92.1371706825485; Wed, 19 Jun 2013 22:40:25 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.112.131 with HTTP; Wed, 19 Jun 2013 22:40:05 -0700 (PDT) In-Reply-To: References: From: Charles Shen Date: Thu, 20 Jun 2013 13:40:05 +0800 X-Google-Sender-Auth: qWECBkBPhjsAOj8QMQpdguzHwFE Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11c334aa12050004df8f628a Cc: sip-overload@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 05:40:27 -0000 --001a11c334aa12050004df8f628a Content-Type: text/plain; charset=UTF-8 Hi Richard, Thank you for the follow up, please see some comments below. On Sat, Jun 15, 2013 at 4:32 AM, Richard Barnes wrote: > >>> >> [CS] How about phrasing it as being applicable "within trusted >> intra-domain and/or trusted inter-domain" scenarios? >> > > We really need to be clear here about what "trusted" means. ("Trusted" is > a word that makes Security ADs pounce :) ) What is each party "trusted" > not to do? If you look at RFC 3325, it lays out exactly what the parties > need to be agree on before they use P-Asserted-ID. I think an analogous > list of criteria is needed here. > [CS] It makes a lot of sense to adopt RFC3325/3324 notion of Trusted domains, I will work on that. > I agree, let's do option (2). Suggested text: > """ > This document does not define the content of SUBSCRIBE bodies. Future > specifications could define bodies for SUBSCRIBE messages, for example to > request specific types of load control event notifications. > """ > [CS] Will do. > > To be clear on this, the ambiguity here is with regard to the domain="..."> case. In the case, you just do Tel URI > comparison. > > Thinking on this a little more, it looks like your use of the "domain" > parameter actually breaks with RFC 4745. According to RFC 4745, there must > be an exact match between the "domain" value provided by the using protocol > and the value in the "domain" parameter. I can't think of a way that this > document could define a way to extract a domain from a telephone number > that would meet the semantic you seem to be intending. > > So it seems like you need to do one of the following: > 1. Define a rule for how you compute a domain value from a tel: URI. > 2. Define a new element for use under (since lacks an > extension point) > 3. Drop support for excluding phone numbers by domain (you just have to > enumerate the exceptions individually) > > [CS] If we opt for Option 1, can we do the following: a. assume E.164 numbers always start with + sign, so we can use the digits after the + sign (after removing any visual separaters, as in the Tel URL comparison rules) as the presumed domain value. b. for local numbers (numbers that do not start with +), the "phone-context" contains the domain value. > [CS] It seems to me that how to enforce the rate/window/percent becomes >> more implementation specific, and these action items are what the rest of >> the WG documents (http://datatracker.ietf.org/wg/soc/) are using as >> well. The first paragraph of Section 7.4 also referenced RFC6357 on more >> details about these actions. Therefore, I am not sure what more concrete >> actions you are referring to, could you please elaborate a bit on this? >> > > I can live with this answer. > > [CS] OK > To be clear, the concern here isn't about a policy that combines two > actions in the same rule. The concern is when two rules match the same > call, in which case both actions must be applied. > > For example suppose you have the following rule set: > RULE 1: Reject all calls from example.com > -- Conditions: > -- Actions: 0 > RULE 2: Redirect all calls from alice@example.com > -- Conditions: > -- Actions: 0 > > It doesn't seem like there's a sensible way to combine those rules. In > principle, it seems like the simplest thing would be to say that a policy > MUST NOT specify two rules that could apply to the same SIP message. Would > people feel comfortable that you could efficiently check this exclusivity? > It does scale as the square of the number of rules. > > [CS] Very good point. We propose an easy "the first-match rule", i.e., the call is handled based on the first rule that matches. What do you think? > >> [CS] "simple drop" here means simply ignoring the request without doing >> anything. i.e., in the reliable transport case, it does not have to close >> the transport connection. It still saves some processing needed in sending >> out the rejection in reliable transport. But I am open to eleminating it if >> the group prefers so. >> > > It would help if you could add that clarification to "simple drop". > [CS] Will do. In addition, "Simple drop seems good for dealing with telephony DOS attacks" Thanks! Charles > > Thanks, > --Richard > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > --001a11c334aa12050004df8f628a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Richard, Thank you for the follow up, please see some comments below.
On Sat, Jun 15, 2013 at 4:32 AM, Richard B= arnes <rlb@ipv.sx> wrote:


[CS] How = about phrasing it as being applicable "within trusted intra-domain and= /or trusted inter-domain" scenarios?=C2=A0

We really need to = be clear here about what "trusted" means. =C2=A0("Trusted&qu= ot; is a word that makes Security ADs pounce :) ) =C2=A0What is each party = "trusted" not to do? =C2=A0If you look at RFC 3325, it lays out e= xactly what the parties need to be agree on before they use P-Asserted-ID. = =C2=A0 I think an analogous list of criteria is needed here.

[CS] It makes a lo= t of sense to adopt RFC3325/3324 notion of Trusted domains, I will work on = that.=C2=A0

=C2=A0
I agree, let's do option (2). =C2=A0Suggested text:
"""
This document does not define the content of S= UBSCRIBE bodies. =C2=A0Future specifications could define bodies for SUBSCR= IBE messages, for example to request specific types of load control event n= otifications.
"""

[CS] Will do.
=C2=A0

To be clear on this, the ambiguity here is = with regard to the <except domain=3D"..."> case. =C2=A0In t= he <one id=3D"..."> case, you just do Tel URI comparison.

Thinking on this a little more, it looks like your use = of the "domain" parameter actually breaks with RFC 4745. =C2=A0Ac= cording to RFC 4745, there must be an exact match between the "domain&= quot; value provided by the using protocol and the value in the "domai= n" parameter. =C2=A0I can't think of a way that this document coul= d define a way to extract a domain from a telephone number that would meet = the semantic you seem to be intending.

So it seems like you need to do one of the following:
1. Define a rule for how you compute a domain value from a tel: UR= I.
2. Define a new element for use under <many> (since <= except> lacks an extension point)
3. Drop support for excluding phone numbers by domain (you just have t= o enumerate the exceptions individually)


[CS] If we opt for Op= tion 1, can we do the following:

a. assume E.164 numbers always start with + sign, so we= can use the digits after the + sign (after removing any visual separaters,= as in the Tel URL comparison rules) as the presumed domain value.=C2=A0
b. for local numbers (numbers that do not start with +), the &quo= t;phone-context" contains the domain value.=C2=A0

=
=C2=A0
[CS] It seems to me that how to e= nforce the rate/window/percent becomes more implementation specific, and th= ese action items are what the rest of the WG documents (http://datatracker.ietf.org/= wg/soc/) are using as well. The first paragraph of Section 7.4 also ref= erenced RFC6357 on more details about these actions. Therefore, I am not su= re what more concrete actions you are referring to, could you please elabor= ate a bit on this?

I can live with th= is answer.


[CS] OK
=C2=A0
To be clear, the concern here isn't about a policy that combines = two actions in the same rule. =C2=A0The concern is when two rules match the= same call, in which case both actions must be applied.

For example suppose you have the following rule set:
RULE 1: Reject all calls from example.com=C2=A0
-- Conditions: <from><= identity><many domain=3D"example.com"/></identity></from>
-- Actions: <accept alt-action=3D"reject"><rate>= 0</rate></accept>
RULE 2: Redirect all calls from alice@example.com
-- Conditions: <from><identity><one id=3D"sip:alice@example.com= "/></identity></from>
-- Actions: <accept alt-action=3D"redirect" alt-target=3D= "sip:eve@ex= ample.com"><rate>0</rate></accept>
=
It doesn't seem like there's a sensible way to combine t= hose rules. =C2=A0In principle, it seems like the simplest thing would be t= o say that a policy MUST NOT specify two rules that could apply to the same= SIP message. =C2=A0Would people feel comfortable that you could efficientl= y check this exclusivity? =C2=A0It does scale as the square of the number o= f rules.


[CS] Very good point. We propose an=C2=A0easy "the first-match rule", i.e., the ca= ll is handled based on the first rule that matches.=C2=A0What do you think?=C2=A0=
=C2=A0

[CS] &q= uot;simple drop" here means simply ignoring the request without doing = anything. =C2=A0i.e., in the reliable transport case, it does not have to c= lose the transport connection. It still saves some processing needed in sen= ding out the rejection in reliable transport. But I am open to eleminating = it if the group prefers so.=C2=A0

It would help if y= ou could add that clarification to "simple drop". =C2=A0

[CS] Will do. In addi= tion, "Simple dr= op seems good for dealing with telephony DOS attacks"

Thanks!<= /div>

Charles<= /div>

=C2=A0

Thanks,
--Richard=C2=A0

_______________________________________________
sip-overload mailing list
sip-overload@iet= f.org
https://www.ietf.org/mailman/listinfo/sip-overload


--001a11c334aa12050004df8f628a--