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

[Charles Shen <[e-mail]>]

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