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

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
>
>