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

>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: [email protected]
> > [mailto:[email protected]]On Behalf
> > Of Reinaldo Penno
> > Sent: Saturday, October 22, 2005 8:46 AM
> > To: James M. Polk
> > Cc: [email protected]; 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:[email protected]]
> > > Sent: Friday, October 21, 2005 11:02 PM
> > > To: Reinaldo Penno
> > > Cc: ken carlberg; [email protected]
> > > 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
> > > >[email protected]
> > > >https://www1.ietf.org/mailman/listinfo/ieprep
> > >
> > >
> > > cheers,
> > > James
> > >
> > >                                  *******************
> > >                  Truth is not to be argued... it is to be
> > presented.
> >
> > _______________________________________________
> > Ieprep mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/ieprep
> >


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.