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

[Richard Barnes <[e-mail]>]

Hi Charles,

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


On Sat, May 25, 2013 at 3:52 PM, Charles Shen <[e-mail]>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 <[e-mail]> 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 "
>> [phone]".  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 [phone], [phone],
> [phone] 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 [phone],
> [phone], [phone] will yield
>
> [phone]@host
> [phone]@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 [phone], [phone], 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 [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.



> 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