RE: [Ieprep] Diffserv Code Point for Emergency calls
"James M. Polk" <jmpolk@cisco.com> Sun, 23 October 2005 03:09 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETWEx-0004R7-D5; Sat, 22 Oct 2005 23:09:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETWEu-0004Qn-S9 for ieprep@megatron.ietf.org; Sat, 22 Oct 2005 23:09:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11095 for <ieprep@ietf.org>; Sat, 22 Oct 2005 23:09:28 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETWRL-0005ii-Qo for ieprep@ietf.org; Sat, 22 Oct 2005 23:22:34 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2005 20:09:29 -0700
X-IronPort-AV: i="3.97,241,1125903600"; d="scan'208"; a="355548243:sNHT27960484"
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9N39E9C020667; Sat, 22 Oct 2005 20:09:26 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Oct 2005 20:09:22 -0700
Received: from jmpolk-wxp.cisco.com ([10.21.80.233]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Oct 2005 20:09:20 -0700
Message-Id: <4.3.2.7.2.20051022215749.03ae19c8@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 22 Oct 2005 22:09:20 -0500
To: Steve Silverman <steves@shentel.net>, Reinaldo Penno <rpenno@juniper.net>
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls
In-Reply-To: <CIEELMKPOOAMCIAKANLBOEFOFGAA.steves@shentel.net>
References: <9BD5D7887235424FA97DFC223CAE3C2801667705@proton.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-OriginalArrivalTime: 23 Oct 2005 03:09:21.0232 (UTC) FILETIME=[29D12D00:01C5D77F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Cc: ken carlberg <carlberg@g11.org.uk>, ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
At 09:11 AM 10/22/2005 -0400, Steve Silverman wrote: >If calls to a locally pre-specified emergency number (e.g., 911) are >given high priority, it is no great exposure. "a locally pre-specified number".. hmmm several comments: - is a URI a number in this context? as SIP is defining a URI, not a number, for emergency calls - How many routers that will have a PHB on this DSCP are between you and the local PSAP? could be 5, could be 10 - that impact is greater than the local Class 5 switch from old telco designs - If you DDOS the local broadband segment, you eliminate the possibility of anyone on that segment from making a emergency call. single HFC segments can be as far away as 100 miles, is that local anymore? >One would think such calls would have locally routable destinations >and couldn't travel very far or be used for DDOS attacks. (Except >against the actual emergency systems. How we protect them is another >problem. ) How do you protect a layer 3 packet that has a layer 3 marking and no authorization indication in that packet? >In the absence of limited addressing or strong user authentication (as >the DOD uses) giving Joe Hacker the ability to get extra high priority >seems like a bad idea to me. > >It would be helpful if someone (probably ITU rather than IETF) could >standardize on a limited number of local emergency calling numbers. see http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-00.txt >Steve Silverman > > > > -----Original Message----- > > From: ieprep-bounces@ietf.org > > [mailto:ieprep-bounces@ietf.org]On Behalf > > Of Reinaldo Penno > > Sent: Saturday, October 22, 2005 8:46 AM > > To: James M. Polk > > Cc: ieprep@ietf.org; ken carlberg > > Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls > > > > > > Your point is well taken James. > > > > I guess the risk is no different from what we face nowadays > > with doom > > packets marked with EF DSCP. The solution as well is no > > different from > > what we have today to deal with those packets. Usually > > independently of > > the DSCP an endpoint might put in a packet, the edge router perform > > classification and if necessary remarks the packet with > > whatever DSCP it > > should have. > > > > Therefore, if we just continue with just EF for normal and emergency > > voice calls, the risk is the same, the drawback that I see > > is that we > > cannot prioritize emergency over normal calls. > > > > So, in general an edge device that can perform SIP parsing and mark > > emergency calls with the emergency DSCP and others with EF DSCP. > > Alternatively, in a decomposed gateway scenario the SIP > > Proxy can let > > the router know that a certain call is an emergency and > > that it should > > be marked differently. > > > > Regards, > > > > Reinaldo > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: Friday, October 21, 2005 11:02 PM > > > To: Reinaldo Penno > > > Cc: ken carlberg; ieprep@ietf.org > > > Subject: Re: [Ieprep] Diffserv Code Point for Emergency calls > > > > > > Reinaldo > > > > > > Adding fuel to a discussion that has churned on many > > lists over the > > last > > > several years, I'd really want to understand the threat anaylsis > > observed > > > by such a proposal (for a emergency DSCP) to ensure it > > could not be > > used > > > for a fairly trivial to generate DDOS on the network - > > even all the > > way to > > > the PSAP, or just used by neighbors wanting the very best > > throughput > > for > > > their game of Doom. > > > > > > At 10:57 AM 10/21/2005 -0400, ken carlberg wrote: > > > >Hello Reinaldo, > > > > > > > >>I read > > > > > >>http://www.ietf.org/internet-drafts/draft-ietf-ieprep-fram > > ework-10.txt > > > >>and was somewhat puzzled at section 4.1.2. I understand that the > > IETF > > > >>wants to be conservative in standardizing new DSCP, but > > it seems to > > an > > > >>emergency call DSCP would be accepted by the community (am I > > wrong?). > > > > > > > >well, from my own take, I would say that the "community" is not > > > >against an emergency call DSCP per se, but rather awaits specific > > > >proposals with a cautious mindset. Recall from that > > section 4.1.2 > > > >that there is a need to define a behavior in addition to > > identifying > > > >a code point. So if you want a code point of 1 or more bits for > > > >"emergency", what would be its defined forwarding behavior? > > > > > > > >one such proposal, primarily aimed at MLPP, is called Multi-Level > > > >Expedited Forwarding (MLEF) and can be found at: > > > > > >ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-silverman- > > > >tsvwg-mlefphb-03.txt > > > > > > > >I would also suggest reading a counter proposal that > > avoids defining > > > >a new DSCP: > > > > > >ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg- > > > >mlpp-that-works-02.txt > > > >you can dig around the TSVWG archives over the past 2 > > months for some > > > >comments on the draft. > > > > > > > >-ken > > > > > > > > > > > >_______________________________________________ > > > >Ieprep mailing list > > > >Ieprep@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/ieprep > > > > > > > > > cheers, > > > James > > > > > > ******************* > > > Truth is not to be argued... it is to be > > presented. > > > > _______________________________________________ > > Ieprep mailing list > > Ieprep@ietf.org > > https://www1.ietf.org/mailman/listinfo/ieprep > > cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep
- [Ieprep] Diffserv Code Point for Emergency calls Reinaldo Penno
- Re: [Ieprep] Diffserv Code Point for Emergency ca… ken carlberg
- Re: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Steve Silverman
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… James M. Polk
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Janet P Gunn
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Steve Silverman
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Dolly, Martin C, ALABS
- Re: [Ieprep] Diffserv Code Point for Emergency ca… Fred Baker
- RE: [Ieprep] Diffserv Code Point for Emergency ca… Reinaldo Penno
- RE: [Ieprep] Diffserv Code Point for Emergency ca… GOLDMAN, STUART O (STUART)
- [Ieprep] A suggestion to the chairs Fred Baker
- Re: [Ieprep] Diffserv Code Point for Emergency ca… Fred Baker