RE: [Ieprep] Diffserv Code Point for Emergency calls

"Reinaldo Penno" <rpenno@juniper.net> Sun, 23 October 2005 06:40 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETZWi-000827-Bd; Sun, 23 Oct 2005 02:40:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETZWg-00080v-SY for ieprep@megatron.ietf.org; Sun, 23 Oct 2005 02:40:14 -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 CAA17796 for <ieprep@ietf.org>; Sun, 23 Oct 2005 02:40:01 -0400 (EDT)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETZjB-0002fQ-Pu for ieprep@ietf.org; Sun, 23 Oct 2005 02:53:10 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 07:40:05 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 23 Oct 2005 07:40:04 +0100
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 23 Oct 2005 02:40:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls
Date: Sun, 23 Oct 2005 02:40:03 -0400
Message-ID: <9BD5D7887235424FA97DFC223CAE3C2801667707@proton.jnpr.net>
Thread-Topic: [Ieprep] Diffserv Code Point for Emergency calls
Thread-Index: AcXXfzj1LZbZIC78ShWqzrNrsrh2QQAG+xCA
From: Reinaldo Penno <rpenno@juniper.net>
To: "James M. Polk" <jmpolk@cisco.com>, Steve Silverman <steves@shentel.net>
X-OriginalArrivalTime: 23 Oct 2005 06:40:03.0760 (UTC) FILETIME=[9959DB00:01C5D79C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964
Content-Transfer-Encoding: quoted-printable
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

Hello James,

I am not going to elaborate again but as I mentioned in the previous
email the DDOS HFC threat already exists today without emergency DSCP.

I can DDOS the local broadband segment with EF packets and prevent
emergency calls.

I would like to understand if there are any new threats that an
emergency DSCP bring to the game that do not exist today with EF DSCP.
And if there are new threats, do they outweigh the benefit of an
emergency DSCP?

On the same topic. Do you believe we should do something (not
necessarily DSCP) to prioritize emergency calls or not? 

Thanks,

Reinaldo

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Saturday, October 22, 2005 8:09 PM
> To: Steve Silverman; Reinaldo Penno
> Cc: ieprep@ietf.org; ken carlberg
> Subject: RE: [Ieprep] Diffserv Code Point for Emergency calls
> 
> 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?
[[Reinaldo]] 









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