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

Shida Schubert <shida@ntt-at.com> Tue, 16 July 2013 02:49 UTC

Return-Path: <shida@ntt-at.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 19BF711E81C0 for <sip-overload@ietfa.amsl.com>; Mon, 15 Jul 2013 19:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.661
X-Spam-Level:
X-Spam-Status: No, score=-101.661 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 Jd3v5wp3KrjJ for <sip-overload@ietfa.amsl.com>; Mon, 15 Jul 2013 19:49:32 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE811E817B for <sip-overload@ietf.org>; Mon, 15 Jul 2013 19:49:31 -0700 (PDT)
Received: from [50.152.169.249] (port=51564 helo=[192.168.1.8]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from <shida@ntt-at.com>) id 1UyvKS-00019F-F2; Mon, 15 Jul 2013 21:49:28 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_073F8013-52D2-48B8-B426-CEBC8BC4E4F0"
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <CAPSQ9ZVRTZSyvp5crmwFS1xkfEVkGyNOkLv=Fyjk48kY6XKxSw@mail.gmail.com>
Date: Mon, 15 Jul 2013 19:49:27 -0700
Message-Id: <215A826D-A1A0-4EB2-9E07-7B19AF3783C1@ntt-at.com>
References: <CAL02cgQW3eJg+f0nwEwihJGRgE82o+B0gSx0LJ6vTP1M8F+n5w@mail.gmail.com> <CAPSQ9ZWuu5fS1jQw6XS4tyPt2ho2pkiCe0FKfboxNv8NrbsNZg@mail.gmail.com> <CAL02cgTD=EwVck90Je4Ou+9Te5aAnFMDMHfNMvBaGOK2EDUNxA@mail.gmail.com> <CAPSQ9ZVLVhepr59KjsjZUFk+C5=xxDuUYHa5CxhBD11Sni=4pQ@mail.gmail.com> <CAPSQ9ZVRTZSyvp5crmwFS1xkfEVkGyNOkLv=Fyjk48kY6XKxSw@mail.gmail.com>
To: Charles Shen <charles@cs.columbia.edu>
X-Mailer: Apple Mail (2.1283)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([192.168.1.8]) [50.152.169.249]:51564
X-Source-Auth: shida.schubert+tingle.jp
X-Email-Count: 4
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
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 <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: Tue, 16 Jul 2013 02:49:37 -0000

Hi Charles;

 Hmm.. As far as I can recall RFC3325 references Spec(T) BUT it doesn't 
reference it normatively. 

 Second paragraph of section 11. in RFC3325. 

  The remainder of this section presents an example Spec(T), which is
   not normative in any way.

 Actually security consideration in RFC3325 rather keeps the mechanism 
to secure the channels open. 

   The use of transport or
   network layer hop-by-hop security mechanisms, such as TLS or IPSec
   with appropriate cipher suites, can satisfy this requirement.

 I think most of the implementations that will comply to use this will not use 
TLS and mandating TLS doesn't make sense. I think text in the line of what 
RFC3325 should be sufficient for security consideration in the SOC-evnet-package 
as well.

 Regards
  Shida
 
On Jul 14, 2013, at 8:38 AM, Charles Shen wrote:

> Hi Richard, for your comment on "trusted domain" 
> 
> 
> 
> [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.
> 
> 
> 
> From RFC 3324/3325, "A key requirement is that the behavior of all nodes within a given Trust Domain 'T' is known to comply to a certain set of specifications known as 'Spec(T)'." Therefore, if we define the "Trusted Domain" for load control, we must define what Spec(T) means for this document. RFC 3325 listed the following for its use with "P-Asserted-Identity" 
> 
> 1. The manner in which users are authenticated 
> 2. The mechanisms used to secure the communication among nodes within the Trust Domain 
> 3. The mechanisms used to secure the communication between UAs and nodes within the Trust Domain 
> 4. The manner used to determine which hosts are part of the Trust Domain 
> 5. The default privacy handling when no Privacy header field is present 
> 6. That nodes in the Trust Domain are compliant to SIP [1] 
> 7. That nodes in the Trust Domain are compliant to this document 
> 8. Privacy handling for identity as described in Section 7. 
> 
> My revision in progress considers 2, 4, 6, 7 as applicable in our load control context - basically the UA and Privacy handling is not applicable in our case. 
> 
> Therefore, an example (non-nomative) Spec(T) for a trusted domain of load control can be as below
> 
> 1. Protocol requirements
> 
> The following specifications MUST be supported: 
> 1) RFC 3261 
> 2) RFC (this load control specification number)
> 
> 2. Security requirements
> 
> Connections between nodes within the Trust Domain in the Trust Domain MUST use TLS using a cipher suite of RSA_WITH_AES_128_CBC_SHA1. Mutual authentication between nodes in the trust domain MUST be performed and confidentiality MUST be negotiated.
> 
> 3. Scope of Trust Domain
> 
> The Trust Domain specified in this agreement consists of hosts which posses a valid certificate which is a) signed by examplerootca.org; b) whose subjectAltName ends with one of the following domain names:  trusted.div1.carrier-a.net,trusted.div2.carrier-a.net, sip.carrier-b.com; and c) whose domain name corresponds to the hostname in the subjectAltName in the certificate.
> 
> Is this OK with you or do you have any additional thoughts? 
> 
> thanks!
> 
> Charles
> 
> 
> 
> 
> On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen <charles@cs.columbia.edu> wrote:
> Hi Richard, Thank you for the follow up, please see some comments below.
> 
> On Sat, Jun 15, 2013 at 4:32 AM, Richard Barnes <rlb@ipv.sx> 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 <except domain="..."> case.  In the <one id="..."> 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 <many> (since <except> 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: <from><identity><many domain="example.com"/></identity></from>
> -- Actions: <accept alt-action="reject"><rate>0</rate></accept>
> RULE 2: Redirect all calls from alice@example.com
> -- Conditions: <from><identity><one id="sip:alice@example.com"/></identity></from>
> -- Actions: <accept alt-action="redirect" alt-target="sip:eve@example.com"><rate>0</rate></accept>
> 
> 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
> 
> 
> 
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload