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

From: Richard Barnes <[email-masked]>
Date: Fri, 14 Jun 2013 16:32:16 -0400

Hi Charles,

Responses inline, with areas of agreement trimmed.  Sorry for the delay.

On Sat, May 25, 2013 at 3:52 PM, Charles Shen <[email-masked]>wrote:

> Dear Richard,
>
> Thank you so much for the great review. I am so sorry for the much delayed
> response. Please see my comments inline.
>
> On Wed, Apr 17, 2013 at 1:53 PM, Richard Barnes <[email-masked]> wrote:
>
>> I have reviewed this document, and have a few questions before IETF LC:
>>
>> Major:
>>
>> In a few places, for example Section 5.3., the document suggests that
>> this event package could be used to communicate load filtering policies
>> between domains.  This seems like a bad idea for a few reasons.  First,
>> policies can be based on "P-Asserted-Identity", which is itself limited to
>> use within a trust domain / Spec(T).  It doesn't make sense to have
>> policies based on these identifiers outside of the domain in which they are
>> used.  Second, inter-domain policies can create subtle and dangerous
>> security risks.  For example, according to the current specification,
>> Domain A could tell Domain B to drop all calls between Domain B and Domain
>> C.  It's not clear how you would prevent these sorts of attacks, especially
>> where "tel:" URIs are involved.  I think both of these issues go away if
>> this event package is limited in a similar way to P-Asserted-Identity,
>> i.e., limited to use within a trust 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.

>  Section 6.3., "SUBSCRIBE Bodies" doesn't actually say anything about what
>> goes in the body of a SUBSCRIBE message.  On the one hand, it implies that
>> there could be a body (since the last sentence considers a request without
>> a body as a special case), but it doesn't say what goes in the body if
>> there is one.  Please either (1) define what may go in the body, (2)
>> explicitly say that this document does not specify what goes in SUBSCRIBE
>> bodies, or (3) require that the body be empty.
>>
>
> [CS] Earlier version of this document specifies that
>
> "A SUBSCRIBE request for the SIP load control event package MAY contain a
> body to filter the requested load control event notification. The details
> of the subscription filter specification are not yet defined."
>
> That sentence was later removed because it might cause confusion.   (
> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00866.html)
>
> I am OK going for your option (2) or option (3), although slightly prefer
> option (2).
>

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

 In Section 7.3.1, you need to specify how a "tel:" URI is matched against
>> a domain value starting with "+".  Your examples seem to indicate simple
>> string prefix matching, but I doubt that's what you actually want, since
>> non-digit characters can break things.  For example, "+1212" should match "
>> +1-212-555-1212".  Please specify a matching algorithm here.
>>
>>
> [CS]
>
> So there are a number of possible scenarios that I can think of:
>
> a) Matching based on Tel URI comparison:
>
> According to RFC 3966 Section 4. Tel URIs like +8135252324, +81-33525-2324,
> +81 33525 2324 all become 8135252324 during comparison because separators
> are removed, and they are therefore equivalent.
>
> b) Matching based on SIP URI comparison:
>
> Defined in RFC3261 Section 19.1.4
>
> c) Matching for Tel converted SIP URI. I am not sure if this is something
> we need to worry about.
>
> Since whitespace is not allowed in URI, Tel URIs like +8135252324,
> +81-33525-2324, +81 33525 2324 will yield
>
> +8135252324@host
> +81-33525-2324@host
>
> Which will be considered different (will it?). If it is not possible to
> identify which SIP URI is a Tel-converted SIP URI, then we need to specify
> both in the filter identity conditions, otherwise, we can decide to
> similarly remove the separators in the username, and make them the same
> URI.
>
> d) Prefix matching
>
> Is it sufficient to state that for prefix-based matching, regular
> expression and rules as determined by the provider of the applicable
> domains SHOULD be used?
>
> We've also dug around, and we have not found any algorithm in published
> RFC to match numbers such as +8135252324, +81-33525-2324, and +81 33525
> 2324. There's some note on DRINKS spec about applying regular expression
> to telephone number. But it just wrote that we could define regular
> expression for telephone number. It does not illustrate or specify any
> specific examples either.
>

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)

>  In Section 7.3.2, please change "Non-initial requests ... are not
>> subjected" to "Non-initial requests ... MUST NOT be subjected".
>>
>
> [CS] done
>
>
>>
>> Section 7.4. doesn't adequately define the actions to be taken.  Each of
>> the action elements (<rate>, <window>, <percent>) need to define a concrete
>> action that the proxy should take.
>>
>>
> [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.

>  RFC 4745 allows rules to combine when multiple rules match a given call.
>>  This document needs to define combination rules for the actions defined
>> here.
>>
>
> [CS] For a particular filter policy condition, I don't seem to see how/why
> an upstream server would send a filter policy action combining different
> action types (rate/window/percent) or combining multiple values for the
> same action type. Should we simply make it explicit that no combination is
> allowed, or do you have any combination scenario in mind?
>

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.

> What's the reason for having both the "drop" action and the "reject"
>> action?  It seems like the "drop" action is almost always harmful.  With
>> unreliable transport, it causes retransmits, and even with reliable
>> transport, it causes the client to wait unnecessarily until the connection
>> times out.  In any case, the "simple drop" action is underspecified.  For
>> example, does the server simply ignore the SIP message, or does it close
>> the transport connection?
>>
>>
> [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".

Thanks,
--Richard

---

From: Charles Shen <[email-masked]>
Date: Thu, 20 Jun 2013 13:40:05 +0800

Hi Richard, Thank you for the follow up, please see some comments below.

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

> request specific types of load control event notifications.

[CS] Will do.

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

>> 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?
>>
>
[CS] OK

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

> 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: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 19:00:29 -0400

Inline.  Areas of agreement snipped.

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

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

That seems pretty sensible.  I think the way to state this is add some text
to Section 7.4 defining the Combining Rule (to use the phrase from RFC
4745) for the <accept> action.

Thanks,
--Richard

---

From: Charles Shen <[email-masked]>
Date: Sun, 23 Jun 2013 12:50:17 +0800

Hi Richard, please see additional questions regarding "tel" URL grouping:

On Fri, Jun 21, 2013 at 7:00 AM, Richard Barnes <[email-masked]> wrote:

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

 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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Jun 2013 10:52:23 -0400

On Sun, Jun 23, 2013 at 12:50 AM, Charles Shen <[email-masked]>wrote:

>> 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
> "+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: Charles Shen <[email-masked]>
Date: Wed, 26 Jun 2013 08:40:31 +0800

This makes a lot of sense, fully agree. Thanks!

Charles

On Tue, Jun 25, 2013 at 10:52 PM, Richard Barnes <[email-masked]> wrote:

>>>>> 3. Drop support for excluding phone numbers by domain (you just have
>>>>> to enumerate the exceptions individually)
>>>>>
>>>>>
>>  I am absolutely fine adding another element, but just want to make sure
>> I indeed understand your concern before doing that.
>>
> 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