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

[Charles Shen <[e-mail]>]

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?



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


> (Also, the first paragraph of this section seems out of place here, since
> it also has nothing to do with the body.)
>
>
[CS] removed, since the meaning of this paragraph has already been conveyed
elsewhere in the document [Section 5.3].


>  In Section 6.5., the last sentence is wrong.  The presence of an Accept
> header indicates that the response body should be one of the indicated
> types.  The indicated behavior would only be acceptable if the Accept
> header included "multipart/mixed".  Suggest deleting the last sentence.
>  (Also,  it would be clearer to change "the request body will contain" to
> "the request body MUST contain".)
>
>
[CS] Done.


>  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 [phone].
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.

 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?


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


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


>
> Minor:
>
> In Section 7.3, "we re-define" -- the document doesn't re-define any of
> the elements in RFC 4745 (that's good; redefinition is bad).  Instead, you
> should say you define new identity elements.
>
>
[CS] Done.

 In Section 7.3.1, please break up paragraph starting "To include the two
> forms..." for greater readability.  Suggested break points: Before "Note
> that the tradeoff...", and before "It should be noted..."
>

[CS] Done.


>
> In Section 7.3.3, it would be helpful to break up the paragraph starting
> "The following are two example...".  Break before "Usecase I" and "Usecase
> II".  Also, s/Usecase/Use case/g
>
>
[CS] Done.


Thanks!

Charles



>
> Thanks,
> --Richard
>
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>