Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A5C11E819F for ; Wed, 30 Oct 2013 14:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH6f9FtMMe9z for ; Wed, 30 Oct 2013 14:19:06 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.179.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1B80211E826B for ; Wed, 30 Oct 2013 14:19:03 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id E43F987988C65; Wed, 30 Oct 2013 16:18:52 -0500 (CDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by gateway14.websitewelcome.com (Postfix) with ESMTP id CB01A87988BFC for ; Wed, 30 Oct 2013 16:18:52 -0500 (CDT) Received: from [98.210.227.187] (port=51320 helo=[192.168.1.25]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VbdAM-0004Ij-Vv; Wed, 30 Oct 2013 16:19:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_8C0EBAF7-6FEF-4A5E-8AF3-53D0DDD55E93" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Shida Schubert In-Reply-To: Date: Wed, 30 Oct 2013 14:19:02 -0700 Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - agnada.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.25]) [98.210.227.187]:51320 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== X-Mailman-Approved-At: Thu, 31 Oct 2013 01:56:09 -0700 Cc: "sip-overload@ietf.org" , draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 21:19:12 -0000 --Apple-Mail=_8C0EBAF7-6FEF-4A5E-8AF3-53D0DDD55E93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Richard; The proposed text looks good to me..=20 Shida On Oct 29, 2013, at 12:08 PM, Richard Barnes wrote: > Dear authors, >=20 > Thanks for updating this document. It looks much better. Sorry for = the delay in my reply. >=20 > The one thing I don't think is quite adequately addressed by the = considerations around the use of the "redirect" action. =20 >=20 > The attack I'm worried about is something like the following:=20 > -- A bunch of proxies in a Trust Domain are using UDP, and configured = to get their policies from a central server. =20 > -- Attacker spoofs the server's address to send a bunch of NOTIFY = bodies telling proxies to send all calls to = victim@outside-of-trust-domain.com > -- Proxies redirect all calls to victim, who is now DoSed off of the = Internet >=20 > In order to address this threat, you need to either (1) remove the = "redirect" action, or (2) constrain redirects to a safe space. I assume = that the WG doesn't want to do (1) :) =20 >=20 > Proposed edits: > -- Add to the definition of a Trust Domain an agreement on the types = of calls that can be affected by load control. For example, and = element might be limited to specific domains; <*-tel> elements = might be limited to be within certain prefixes. > -- Add to the definition of a Trust Domain an agreement on the = destinations to which calls may be redirected. For example, the URI = might have to match a given set of domains. > -- Add text to the Security Considerations describing the above = attack, and REQUIREing that implementations enforce the limits described = in the definition of their Trust Domain. >=20 > Thanks, > --Richard >=20 >=20 >=20 >=20 >=20 >=20 > On Wed, Apr 17, 2013 at 1:53 PM, Richard Barnes wrote: > I have reviewed this document, and have a few questions before IETF = LC: >=20 > Major: >=20 > 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. >=20 > 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. = (Also, the first paragraph of this section seems out of place here, = since it also has nothing to do with the body.) >=20 > 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".) >=20 > 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. >=20 > In Section 7.3.2, please change "Non-initial requests ... are not = subjected" to "Non-initial requests ... MUST NOT be subjected". >=20 > Section 7.4. doesn't adequately define the actions to be taken. Each = of the action elements (, , ) need to define a = concrete action that the proxy should take.=20 >=20 > 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. =20 >=20 > 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? >=20 >=20 > Minor: >=20 > 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. >=20 > 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..." >=20 > 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 >=20 >=20 > Thanks, > --Richard >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --Apple-Mail=_8C0EBAF7-6FEF-4A5E-8AF3-53D0DDD55E93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 rlb@ipv.sx> wrote:
Dear authors,

Thanks for updating this = document.  It looks much better.  Sorry for the delay in my = reply.

The one thing I don't think is quite = adequately addressed by the considerations around the use of the = "redirect" action.  

The = attack I'm worried about is something like the = following: 
-- A bunch of proxies = in a Trust Domain are using UDP, and configured to get their policies = from a central server.  
-- Attacker spoofs the server's address to = send a bunch of NOTIFY bodies telling proxies to send all calls to victim@outside-of-trust= -domain.com
-- Proxies redirect all calls to victim, who = is now DoSed off of the Internet

In order to = address this threat, you need to either (1) remove the "redirect" = action, or (2) constrain redirects to a safe space.  I assume that = the WG doesn't want to do (1) :)  

Proposed = edits:
-- Add to the definition of a = Trust Domain an agreement on the types of calls that can be affected by = load control.  For example, <one> and <many> element = might be limited to specific domains; <*-tel> elements might be = limited to be within certain prefixes.
-- Add to the definition of a Trust Domain an = agreement on the destinations to which calls may be redirected. =  For example, the URI might have to match a given set of = domains.
-- Add text to the Security Considerations describing the above attack, = and REQUIREing that implementations enforce the limits described in the = definition of their Trust Domain.

Thanks,
--Richard






On Wed, Apr 17, 2013 at 1:53 PM, Richard = Barnes <rlb@ipv.sx> 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.
=
= 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.   = (Also, the first paragraph of this section seems out of place here, = since it also has nothing to do with the body.)
=
= 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".)
=
= 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.
=
= In Section 7.3.2, please change "Non-initial requests ... are not = subjected" to "Non-initial requests ... MUST NOT be = subjected".
=
= 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. 
=
= 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.  
=
= 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?
=
=
= 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.
=
= 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..."
=
= 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
=
=
= Thanks,
= --Richard

_______________________________________________
sip-overload mailing = list
sip-overload@ietf.org
https:/= /www.ietf.org/mailman/listinfo/sip-overload

= --Apple-Mail=_8C0EBAF7-6FEF-4A5E-8AF3-53D0DDD55E93--