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

From: Charles Shen <[email-masked]>
Date: Thu, 11 Jul 2013 23:21:50 +0800

Hi Richard,

After putting up more thoughts on this as I finalize the revision, I feel
that there are really two options:

Option 1:

<from>
    <many>
        <except prefix="+1-212-854"/>
        <except domain="manhattan.example.com"/>
    </many>
</from>

Option 2:

<from>
    <many>
        <except domain="manhattan.example.com"/>
    </many>
    <many-tel>
        <except-tel prefix="+1-212-854"/>
    </many-tel>
</from>

I also attach below the respective changes to the XML of these two options.
Both will require extended definition of the RFC4745 identity element
(unless we want to call it a different name), option 1 is cleaner in terms
of usage. but requires extended definition of not only the RFC4745
"identity", also RFC4745 "many" and "except", Option 2 requires extended
definition of RFC4745 "identity" but use separate names to extend "many"
and "except". Since "many-tel" is independent of "many", everytime we want
to include group of identities covering both sip and tel uris we have to
specify both "many" and "many-tel". Is there one option that you prefer
over the other?

Thanks!

Charles

OPtion 1: redefinition of identity / many / except

   <!-- SIP ID TYPE -->
   <xs:complexType name="sip-id-type">
     <xs:sequence>
     <element name="from" type="lc:identityType" minOccurs="0"/>
     <element name="to" type="lc:identityType" minOccurs="0"/>
     <element name="request-uri" type="lc:identityType" minOccurs="0"/>
     <element name="p-asserted-identity" type="lc:identityType"
           minOccurs="0"/>
     <any namespace="##other" processContents="lax" minOccurs="0"
           maxOccurs="unbounded"/>
     </xs:sequence>
     <anyAtrribute namespace="##other" processContents="lax"/>
   </xs:complexType>

    <!-- //conditions/identity -->
    <xs:complexType name="identityType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice  minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="one" type="cp:oneType"/>
                    <xs:element name="many" type="lc:manyType"/>
                    <xs:any namespace="##other" processContents="lax"/>
                </xs:choice>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

    <!-- //identity/many -->
    <xs:complexType name="manyType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element name="except" type="lc:exceptType"/>
                    <xs:any namespace="##other"
                    minOccurs="0" processContents="lax"/>
                </xs:choice>
                <xs:attribute name="domain"
                use="optional" type="xs:string"/>
                <xs:attribute name="prefix"
                use="optional" type="xs:string"/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

    <!-- //many/except -->
    <xs:complexType name="exceptType">
        <xs:attribute name="domain" type="xs:string" use="optional"/>
        <xs:attribute name="prefix" type="xs:string" use="optional"/>
        <xs:attribute name="id" type="xs:anyURI" use="optional"/>
    </xs:complexType>

OPtion 2: redefinition of identity plus defining additional many-tel /
except-tel

   <!-- SIP ID TYPE -->
   <xs:complexType name="sip-id-type">
     <xs:sequence>
     <element name="from" type="lc:identityType" minOccurs="0"/>
     <element name="to" type="lc:identityType" minOccurs="0"/>
     <element name="request-uri" type="lc:identityType" minOccurs="0"/>
     <element name="p-asserted-identity" type="lc:identityType"
           minOccurs="0"/>
     <any namespace="##other" processContents="lax" minOccurs="0"
           maxOccurs="unbounded"/>
     </xs:sequence>
     <anyAtrribute namespace="##other" processContents="lax"/>
   </xs:complexType>

    <!-- //conditions/identity -->
    <xs:complexType name="identityType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice  minOccurs="1" maxOccurs="unbounded">
                    <xs:element name="one" type="cp:oneType"/>
                    <xs:element name="many" type="cp:manyType"/>
                    <xs:element name="many-tel" type="lc:many-telType"/>
                    <xs:any namespace="##other" processContents="lax"/>
                </xs:choice>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    <!-- //identity/many-tel -->
    <xs:complexType name="many-telType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element name="exceptTel" type="lc:except-telType"/>
                    <xs:any namespace="##other"
                    minOccurs="0" processContents="lax"/>
                </xs:choice>
                <xs:attribute name="domain"
                use="optional" type="xs:string"/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>
    <!-- //many/except -->
    <xs:complexType name="except-telType">
        <xs:attribute name="prefix" type="xs:string" use="optional"/>
        <xs:attribute name="id" type="xs:anyURI" use="optional"/>
    </xs:complexType>

On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <[email-masked]>wrote:

> This makes a lot of sense, fully agree. Thanks!
>
> Charles
>
>
> On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <[email-masked]> wrote:
>
>>
>>
>>
>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <[email-masked]>wrote:
>>
>>> Hi Richard, please see additional questions regarding "tel" URL grouping:
>>>
>>> On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes <[email-masked]> wrote:
>>>
>>>> Inline.  Areas of agreement snipped.
>>>>
>>>>
>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <[email-masked]>wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Are you sure that gives you the expressiveness you want?  It doesn't
>>>> allow you to exclude based on an arbitrary prefix.  For example, <except
>>>> domain="+1212"> would not match the URI "tel:+12125551212", because
>>>> the "domain" value for that URI would be "12125551212".
>>>>
>>>> It seems like (2) is the option that's most likely to give you what you
>>>> want.  Suggest defining something like a "<except-tel>" element, so that
>>>> you could say something like <except-tel prefix="+1212">.
>>>>
>>>
>>>  I am absolutely fine adding another element, but just want to make sure
>>> I indeed understand your concern before doing that.
>>>
>>> According to the current texts (paragraph 2, pg.18), when the specified
>>> domain value starts with a "+" sign, it denotes a number prefix, if its
>>> "+1-212", the prefix is "1212" (after removing any visual separaters,
>>> as in the Tel URL comparison rules, this needs to be added explicitly),
>>> and this prefix is used to match numbers (again after removing any visual
>>> separaters), therefore, it should match the number "1212551212" in the
>>> tel URL tel:+12125551212.
>>>
>>> Did I miss something here? thanks!
>>>
>>> Charles
>>>
>>
>> I think the concern here isn't with the definition, it's with the fact
>> that you're "re-interpreting" an existing field.  That's bad for
>> interoperability, since if one of these policies is provided to an
>> implementation that doesn't know about the reinterpretation, that
>> implementation with interpret the field incorrectly.  I agree that the risk
>> of misinterpretation is pretty low here (since it's buried in a
>> call-identity element), but it's best to be unambiguous.
>>
>> So I would just augment your existing schema to define a new element with
>> the same semantic you have described above.
>>
>> --Richard
>>
>>
>>
>>
>>
>>
>>
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 12 Jul 2013 14:57:00 -0400

Keep in mind that you're *extending*, not redefining the RFC 4745 schema
here.

Option 1 doesn't work.  The schema for <except> in RFC 4745 doesn't allow
for attributes other than "domain".

Option 2 is overkill.  You don't need to define a new <many> element, you
can just define a new exception element inside of <many>

Option 3:

<from>
  <many>

Then your extension schema is:

<xs:element name="except-tel" type="exceptTelType"/>
<xs:complexType name="exceptTelType">
  <xs:attribute name="prefix" type="xs:string" use="optional"/>
  <xs:attribute name="id" type="xs:anyURI" use="optional"/>
  <xs:anyAttribute>
</xs:complexType>

On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen <[email-masked]>wrote:

> I also attach below the respective changes to the XML of these two
> options. Both will require extended definition of the RFC4745 identity
> element (unless we want to call it a different name), option 1 is cleaner
> in terms of usage. but requires extended definition of not only the RFC4745
>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <[email-masked]
>>>>> > wrote:
>>>>>
>>>>>>> 2. Define a new element for use under <many> (since <except> lacks
>>>>>>> an extension point)
>>>>> It seems like (2) is the option that's most likely to give you what
>>>>> you want.  Suggest defining something like a "<except-tel>" element, so
>>>>> that you could say something like <except-tel prefix="+1212">.
>>>>>
>>>>
>>>>  I am absolutely fine adding another element, but just want to make
>>>> sure I indeed understand your concern before doing that.
>>>>
>>>> domain value starts with a "+" sign, it denotes a number prefix, if
>>>> its "+1-212", the prefix is "1212" (after removing any visual
>>>> separaters, as in the Tel URL comparison rules, this needs to be added
>>>> explicitly), and this prefix is used to match numbers (again after
>>>> removing any visual separaters), therefore, it should match the number
>>>> "1212551212" in the tel URL tel:+12125551212.
>>>>
>>> So I would just augment your existing schema to define a new element
>>> with the same semantic you have described above.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

---

From: Charles Shen <[email-masked]>
Date: Sun, 14 Jul 2013 01:24:57 +0800

Hi Richard,

The reason I think we need to have <many-tel> is that we also want to
allow the situation when we only filter a group of phone numbers with
the same prefix "eg., +1-212-854", similar to filtering a group of sip
ids with the same domain, e.g., "sip.example.com", if we only use
<exclude-tel> we would have to list all available prefixes except that
one, which doesn't seem very plausible. it looks like <many> in
RFC4745 only accepts "domain" attribute, so we need a <many-tel> with
the following schema.

<xs:complexType name="manyTelType">
        <xs:complexContent>
            <xs:restriction base="xs:anyType">
                <xs:choice minOccurs="0" maxOccurs="unbounded">
                    <xs:element name="exceptTel" type="lc:exceptTelType"/>
                    <xs:any namespace="##other"
                    minOccurs="0" processContents="lax"/>
                </xs:choice>
                <xs:attribute name="prefix"
                use="optional" type="xs:string"/>
            </xs:restriction>
        </xs:complexContent>
    </xs:complexType>

Then we can say

<many-tel prefix="+1-212-854"/>

in a way similar to
<many domain="sip.example.com>

Is this something you would agree with?

Thanks!

Charles

On Sat, Jul 13, 2013 at 2:57 AM, Richard Barnes <[email-masked]> wrote:
>
> Keep in mind that you're *extending*, not redefining the RFC 4745 schema here.
>
> Option 1 doesn't work.  The schema for <except> in RFC 4745 doesn't allow for attributes other than "domain".
>
> Option 2 is overkill.  You don't need to define a new <many> element, you can just define a new exception element inside of <many>
>
> Option 3:
>
> <from>
>   <many>
> On Thu, Jul 11, 2013 at 11:21 AM, Charles Shen <[email-masked]> wrote:
>>
>> Hi Richard,
>>
>> After putting up more thoughts on this as I finalize the revision, I feel that there are really two options:
>>
>> Option 1:
>>
>> <from>
>>     <many>
>> I also attach below the respective changes to the XML of these two options. Both will require extended definition of the RFC4745 identity element (unless we want to call it a different name), option 1 is cleaner in terms of usage. but requires extended definition of not only the RFC4745 "identity", also RFC4745 "many" and "except", Option 2 requires extended definition of RFC4745 "identity" but use separate names to extend "many" and "except". Since "many-tel" is independent of "many", everytime we want to include group of identities covering both sip and tel uris we have to specify both "many" and "many-tel". Is there one option that you prefer over the other?
>>
>> Thanks!
>>
>> Charles
>>
>>
>>
>> OPtion 2: redefinition of identity plus defining additional many-tel / except-tel
>>
>>    <!-- SIP ID TYPE -->
>> On Wed, Jun 26, 2013 at 8:40 AM, Charles Shen <[email-masked]> wrote:
>>>
>>>> On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <[email-masked]> wrote:
>>>>>
>>>>>> On Thu, Jun 20, 2013 at 1:40 AM, Charles Shen <[email-masked]> wrote:
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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)
>>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> Are you sure that gives you the expressiveness you want?  It doesn't allow you to exclude based on an arbitrary prefix.  For example, <except domain="+1212"> would not match the URI "tel:+12125551212", because the "domain" value for that URI would be "12125551212".
>>>>>>
>>>>>> It seems like (2) is the option that's most likely to give you what you want.  Suggest defining something like a "<except-tel>" element, so that you could say something like <except-tel prefix="+1212">.
>>>>>
>>>>>
>>>>>  I am absolutely fine adding another element, but just want to make sure I indeed understand your concern before doing that.
>>>>>
>>>>> According to the current texts (paragraph 2, pg.18), when the specified domain value starts with a "+" sign, it denotes a number prefix, if its "+1-212", the prefix is "1212" (after removing any visual separaters, as in the Tel URL comparison rules, this needs to be added explicitly), and this prefix is used to match numbers (again after removing any visual separaters), therefore, it should match the number "1212551212" in the tel URL tel:+12125551212.
>>>>>
>>>> I think the concern here isn't with the definition, it's with the fact that you're "re-interpreting" an existing field.  That's bad for interoperability, since if one of these policies is provided to an implementation that doesn't know about the reinterpretation, that implementation with interpret the field incorrectly.  I agree that the risk of misinterpretation is pretty low here (since it's buried in a call-identity element), but it's best to be unambiguous.
>>>>
>>>> So I would just augment your existing schema to define a new element with the same semantic you have described above.
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Sat, 13 Jul 2013 16:04:06 -0400

I see.  That makes sense.  If the WG approves, I would be OK with Option 2.
--Richard

On Sat, Jul 13, 2013 at 1:24 PM, Charles Shen <[email-masked]>wrote:

> > Option 1 doesn't work.  The schema for <except> in RFC 4745 doesn't
> allow for attributes other than "domain".
> >
> > Option 2 is overkill.  You don't need to define a new <many> element,
> you can just define a new exception element inside of <many>
> >
> > Option 3:
> >
> > <from>
> >   <many>
> >>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 3. Drop support for excluding phone numbers by domain (you just
> have to enumerate the exceptions individually)
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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.
> >>>>>> Are you sure that gives you the expressiveness you want?  It
> doesn't allow you to exclude based on an arbitrary prefix.  For example,
> <except domain="+1212"> would not match the URI "tel:+12125551212",
> because the "domain" value for that URI would be "12125551212".
> >>>>>>
> >>>>> According to the current texts (paragraph 2, pg.18), when the
> specified domain value starts with a "+" sign, it denotes a number prefix,
> if its "+1-212", the prefix is "1212" (after removing any visual
> explicitly), and this prefix is used to match numbers (again after removing
> any visual separaters), therefore, it should match the number "1212551212"
> in the tel URL tel:+12125551212.
> >>>>>
> >>>> I think the concern here isn't with the definition, it's with the
> fact that you're "re-interpreting" an existing field.  That's bad for

---

From: Charles Shen <[email-masked]>
Date: Sun, 14 Jul 2013 23:27:48 +0800

Great and thank you!

On Sun, Jul 14, 2013 at 4:04 AM, Richard Barnes <[email-masked]> wrote:

>> >>>>>> It seems like (2) is the option that's most likely to give you
>> what you want.  Suggest defining something like a "<except-tel>" element,
>> so that you could say something like <except-tel prefix="+1212">.
>> >>>>>
>> >>>>>

---

From: Charles Shen <[email-masked]>
Date: Sun, 14 Jul 2013 23:38:25 +0800

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 <[email-masked]>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 <[email-masked]> 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.
>
>
>>
>> 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.
>>
> 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.
>>  [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 [email-masked]
>> -- Conditions: <from><identity><one id="sip:[email-masked]
>> "/></identity></from>
>> -- Actions: <accept alt-action="redirect" alt-target="sip:[email-masked]
>> "><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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sip-overload
>>
>>
>

---

From: Shida Schubert <[email-masked]>
Date: Mon, 15 Jul 2013 19:49:27 -0700

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:

> [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" 
> 
> 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 
> 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
> 
> 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.
> 
> On Thu, Jun 20, 2013 at 1:40 PM, Charles Shen <[email-masked]> 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. 
> 
>  
> 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.
>  
> 
> [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?
> 
> 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.
> 
> -- Conditions: <from><identity><many domain="example.com"/></identity></from>
> -- Conditions: <from><identity><one id="sip:[email-masked]"/></identity></from>
> -- Actions: <accept alt-action="redirect" alt-target="sip:[email-masked]"><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. 
> 
> [CS] Will do. In addition, "Simple drop seems good for dealing with telephony DOS attacks"
> 
> Thanks!
> 
> Charles
> 
>  
> 
> Thanks,
> --Richard 
>

---

From: Charles Shen <[email-masked]>
Date: Sat, 20 Jul 2013 03:11:16 +0800

Hi Shida, I agree that we do not have to mandate TLS. How about adding the
following texts about "Trust Domain" to the current document, without
describing more specific details?

"This specification MUST be applied inside a 'Trust Domain'. The concept of
a Trust Domain is similar to that defined in [RFC3324]. A Trust Domain for
the purpose of SIP load filtering is a set of entities such as SIP proxy
servers that are trusted to exchange load filtering policies defined in
this document. In the simplest case, a Trust Domain is a network of SIP
entities belonging to a single owner/operator who deploys it and accurately
knows the behaviour of those SIP entities. Such simple Trust Domains may be
joined to form larger Trust Domains by bi-lateral agreements between the
owners/operators of the SIP entities.

A key requirement of the Trust Domain for the purpose of SIP load filtering
is that the behavior of all SIP entities within a given Trust Domain 'T' is
known to comply to the following set of specifications known as 'Spec(T)'.

1. The mechanisms used to secure the communication among SIP entities
within the Trust Domain
2. The manner used to determine which SIP entities are part of the Trust
Domain
3. That SIP entities in the Trust Domain are compliant to SIP [RFC3261]
4. That SIP entities in the Trust Domain are compliant to this document "

Thanks

Charles

On Tue, Jul 16, 2013 at 10:49 AM, Shida Schubert <[email-masked]> wrote:

> 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:
>>>  [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?
>>>>
>>>
>>> -- Actions: <accept alt-action="redirect" alt-target="
>>> sip:[email-masked]"><rate>0</rate></accept>
>>>

---

From: Shida Schubert <[email-masked]>
Date: Mon, 22 Jul 2013 09:11:23 -0700

Hi Charles;

 Below looks good. 

 Thanks
  Shida

On Jul 19, 2013, at 12:11 PM, Charles Shen wrote:

> Hi Shida, I agree that we do not have to mandate TLS. How about adding the following texts about "Trust Domain" to the current document, without describing more specific details? 
> 
> "This specification MUST be applied inside a 'Trust Domain'. The concept of a Trust Domain is similar to that defined in [RFC3324]. A Trust Domain for the purpose of SIP load filtering is a set of entities such as SIP proxy servers that are trusted to exchange load filtering policies defined in this document. In the simplest case, a Trust Domain is a network of SIP entities belonging to a single owner/operator who deploys it and accurately knows the behaviour of those SIP entities. Such simple Trust Domains may be joined to form larger Trust Domains by bi-lateral agreements between the owners/operators of the SIP entities.
> 
> A key requirement of the Trust Domain for the purpose of SIP load filtering is that the behavior of all SIP entities within a given Trust Domain 'T' is known to comply to the following set of specifications known as 'Spec(T)'. 
> 
> 1. The mechanisms used to secure the communication among SIP entities within the Trust Domain 
> 2. The manner used to determine which SIP entities are part of the Trust Domain