Subject: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discussion request

From: Scott Bradner <[email-masked]>
Date: Sat, 2 Nov 2002 16:14:03 -0500 (EST)

ieprep-requirements-01requirements 6 - 10 

comments requested

Scott
-
  6 Emergency traffic should be able to transit multiple
    service providers.  The existence of service level
    agreements determines the extent by which this can be
    accomplished.

>> at one level this is a given (i.e. emergency services provided
>> over best effort IP services) but for any other service (e.g.,
>> a defined QoS service) it is not possible today - for both 
>> technical and business reasons - it does not seem to be a 
>> good idea to have requirements that just can not be met
>> note that "service level agreements", where they exist, are 
>> between customers of an ISP and that ISP, not between ISPs
>> so I do not know how SLAs relate to the proposed requirement

  7 Networks should be able to support a variety of user
    applications including telephony, video, database access,
    messaging, telemetry, and web browsing to support emergency
    operations.
   
>> I'm not sure what this means 

>> IP networks forward IP packets - they do not do anything
>> that is application specific unless they are running a
>> application server and even then there is no requirement for 
>> individual users to use the ISPs server, the users could have 
>> their own server or use a server provided by a 3rd party

>> by forwarding IP packets ISPs support all of these applications
>> and many other applications but never know what the applications
>> are so can not do any application-specific special handling

>> this requirement could be written that emergency services
>> should be defined at the IP-packet level so that any 
>> application can make use of them or it could be directed
>> at providers of application-level services (like web servers)
>> which, as a general rule, have no particular
>> relationship to an ISP (and certainly not to all ISPs 
>> between a user and the server they might be using)  

  8 Authorized emergency communications should be protected
    from intrusion or interference, such as, spoofing, change
    of content, and denial of service.  If the protection
    cannot be accomplished, then users must be able to detect
    this failure.

>> In IP applications these functions are normally done end-to-
>> end at the applications layer - the ISP is not involved -
>> so I'm not sure what specific requirement can be directed at 
>> ISPs here

  9 Users should have the option protecting certain sensitive
    traffic from eavesdropping and the source/destination of
    some traffic.
   
>> see #8 - protecting sensitive traffic is an application 
>> layer issue, not a network one - for example, the end to end 
>> traffic can be encrypted by the application itself

>> I'm not sure how one can do protection of source and
>> destination network-layer addresses since they are needed
>> to deliver the packets (there are some anonymizing technologies
>> that can be used at the application layer or even packet layer
>> but these are services run over IP networks not functions that
>> are part of an ISP (for example)

 10 Users should have the option of requesting degraded quality
    of service when normal or expected QoS cannot be achieved.

>> see previous set of requirements about QoS - this requirement 
>> is not specific enough - does it refer to an enterprise net
>> (such as the internal IP network at a telephone company), a
>> single ISP or the Internet

>> also - since there is not yet a clear definition as to what 
>> particular QoS technologies is implied by the QoS requirements 
>> it is hard to say what it means to ask for degraded service
>> - at one level, the user can always fall back to plain best
>> effort service 

>> it is not clear that this requirement is needed in many cases - 
>> if ieprep traffic is prioritized in some way, this degrading
>> will automatically happen if there is more emergency traffic
>> than network capacity allocated by the ISP to providing 
>> emergency services

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Rex Buddenberg <[email-masked]>
Date: 04 Nov 2002 10:21:43 -0800

> ieprep-requirements-01requirements 6 - 10 
Comments herewith; in line.
>     messaging, telemetry, and web browsing to support emergency

Some comments on this newsgroup indicate that we need to keep reminding
ourselves of this.  

Security

>     cannot be accomplished, then users must be able to detect
Good.  It may help if you abstract the security problem into three
categories:
  - data security (for which object level security solutions are
appropriate)
  - enclaving and resistance to denial of service attacks
  - link security issues such as traffic analysis, interceptability,
jammability

>     traffic from eavesdropping and the source/destination of

My experience in DoD says that stating the right requirement to the
wrong union is just as bad as stating the wrong requirement.

1.  Confidentiality is important in emergency traffic.  I'd rank
authenticity even higher (see spoofing in #8 above) -- if I were
building an application, I'd insist that all official business traffic
be authenticated.  But this tends to be no-nevermind because the
authenticity and confidentiality tools are the same at the application
layer.

> >> traffic can be encrypted by the application itself

2.  Authenticity and confidentiality requirements should be 
levied at Layer 7.  Part of applications, not plumbing. Good.

QoS control
>     of service when normal or expected QoS cannot be achieved.
'Degraded service' at the expense of _____?  No service?

Assuming voice app, if I'm in an emergency situation I don't care about
tonal quality -- the voice conversation needs to be intelligible.  If
the 'net is congested, I'll live with seconds of latency if the message
comes through such that I can understand it.  

The floor should be best effort service -- I may want routing options
that normal traffic might not take.  But this is an operations plan
issue (e.g. changing firewall and static routing tables, bringing up a
radio-based altroute, etc), not a standards one.  What's important is
that our extra plumbing (paid for by the emergency services) not
immediately get clogged with non-emergent traffic.  What makes this hard
is the EMS-customer (taxpayer) interface: what a minute ago was Woody's
revenue-generating gamer is no a citizen reporting a fire on a
neighbor's house and a legit user of a better-than-best-effort QoS.

You need three parts of a complete mechanism and they're not all
susceptible to protocol fixes:
  - the net must react appropriately (to use diff-serv as example,
routers must read the DS byte and enqueue properly)
  - applications must state their requirements (e.g. set the DS byte or,
to jump to app layer, tell the VOIP SIP server that this is an emergency
call)
  - some kind of bandwidth brokering system so that non-emergent traffic
doesn't abuse the emergency privs.  (Perish the thought, but this may
require a legal remedy similar to the laws proscribing false emergency
phone calls).

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 17:37:43 -0500

>   - link security issues such as traffic analysis, interceptability,

It is impossible to prevent denial-of-service attacks.  Terribly
sorry, but that is just the reality of the situation.  And it
won't be changing soon.

Given that, the earliest quoted text (not Rex's) is a lot like
one of Bill's "toast" comments.  Rex's suggestion is generally
on-target.  I would also like to see more clarity in which security
services are end-user responsibility (e.g. confidentiality) and
which (if any) are the VoIP/SIP/application-service-provider's
responsibility and which (if any) are the IP datgram forwarder's
responsibility.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 17:41:02 -0500

The general problem with most (all ?) of the listed "requirements"
is that they are what the IETF might call "goals" or "objectives".

Its true that in the DoD, such things are commonly called 
"requirements",
but that DoD-centric usage has clearly been causing a lot of grief here.

As "goals" or "objectives", some of the operator concerns are mitigated
because, for example, any implicit assumptions that real networks can 
violate
the laws of physics are made clear (and are removed from the document
reader's mind).

There really are problems with a number of the documents here.  In a 
whole
lot of cases, these problems are fixable with a heavy editorial pass.
At this point, I think we need to have such editing occur before the
group will be able to gauge consensus on moving forward.

Thanks,

Ran

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 6 Nov 2002 03:07:48 -0800 (PST)

On Sat, 2 Nov 2002, Scott  Bradner wrote:
    >     service providers.

All traffic should be able to transit multiple service providers, provided
that transit agreements exist between them.  Emergency traffic does not
differ from production traffic in this respect.

    >   6 The existence of service level agreements determines the extent
    >     by which this can be accomplished.

False.

    >     messaging, telemetry, and web browsing to support emergency

Yes, they should, and do.  This doesn't need to be in a requirements draft
any more than saying that ISPs should route IP, or diners should serve
breakfast, does.

    >     of content, and denial of service.

All traffic SHOULD be protected.  Again, emergency traffic does not differ
from production traffic in this regard.  Whether traffic is _actually_
protected in any particular way is a different matter, and dependent upon
the business model and product offerings of each ISP.

    >   6 If the protection cannot be accomplished, then users must be
    >     able to detect this failure.

I'm not sure how service providers are supposed to affect the
perceptiveness of users.  Selective-breeding programs have proven
ineffectual thus far.

You used the word MUST there, also...  was that an editorial mistake, or
are we supposed to take that at face value?

    >     traffic from eavesdropping and the source/destination of

If the destination of the traffic is anonymized, how am I supposed to get
this "emergency" message through when the system is broken?  I mean, how
do I deliver it, if nobody can tell me where it's supposed to go?

Oooooh, I get it...  This is a _joke_!  You'll tell me where to send the
packet, _but then you'll have to kill me!_  Ha!  Shoot the messenger with
the bad news!  Good one.

    >     of service when normal or expected QoS cannot be achieved.

I'll let my previous critique of this one stand, since my sense of irony
was about exhausted for the evening on #9.

                                -Bill