Subject: Re: [Ieprep] Accounting

From: Rex Buddenberg <[email-masked]>
Date: 02 Dec 2002 09:12:57 -0800

On Fri, 2002-11-29 at 15:11, RJ Atkinson wrote:
> 
> On Friday, Nov 29, 2002, at 13:07 America/Montreal, [email-masked] 
> wrote:
> > [RJA] So I remain very confused about what the accounting advocates
> > are asking for.  I might be slower than most to puzzle some
> > stuff out, but what I got out of the Accounting presentation
> > was roughly this:
> >
> >     - Accounting is a requirement.
> >     - We don't mean that packet accounting is a requirement.
> >

> Mike's reply has been very helpful.  There are a couple of things that 
> I'd
> like folks to read/correct still.  And if anyone has different answers 
> than
> Mike had, please speak up and help me understand the differences.

Ran,  are you binning key management under accounting?

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

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Dec 2002 12:24:43 -0500

> Ran,  are you binning key management under accounting?

Hmm.  No.  Had not occurred to me that they were related.
Are they related ?

Ran

PS:	And I do think key management is its usual nightmare here, just as
it is in other places where one wants to do authentication of stuff.

---

From: Rex Buddenberg <[email-masked]>
Date: 02 Dec 2002 12:09:54 -0800

Authentication of data is a critical item for emergency services
networks.  If this isn't in lights in a requirements statement, it
should be.

Therefore key management has to go somewhere.  Agreed that it may be a
local item (and it's an end-end issue, not one for routers to worry
about) but from the customer's point of view, I'd think some coaching on
how to proceed would be a Good Thing to have ... to offset some of the
coaching I'd be getting from n vendors who are all in the mode of 'never
mind what your requirement is, we've got the solution'.

Given that key management is a necessary part of a Compleat Emergency
Services structure, where does it go on the tree?  Accounting management
sounds like as good an answer as any...

---

From: "Steve Silverman" <[email-masked]>
Date: Mon, 2 Dec 2002 15:53:00 -0500

I have to point out that if a call purports to be an emergency call,
it should be transmitted with or without
authentication.  I have pointed out the  need for enough accounting
info to detect misuse & DDOS attacks. But if the building is
burning, we do want to allow a kid to summon the appropriate
response even if he can't remember his password amidst the smoke or
other distractions.  Perhaps a limit on the number of high priority
calls from a location per minute?  And of course the call info is
saved for analysis.

Steve Silverman

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Rex Buddenberg
> Sent: Monday, December 02, 2002 3:10 PM
> To: RJ Atkinson
> Cc: ieprep
> Subject: Re: [Ieprep] Accounting
>
>

---

From: Rex Buddenberg <[email-masked]>
Date: 02 Dec 2002 13:33:54 -0800

On Mon, 2002-12-02 at 12:53, Steve Silverman wrote:
> authentication. 

Agreed; failure to authenticate is not a reason for denial of service;
it's a means for the receiver to judge the authenticity of the data.  

But if I'm going to build a neighborhood internet that my neighborhood
police (among many others) uses as it's comms system, I want those cops
to be able to know that they are talking with each other, not some
imposter.  I've bored far too many holes in the ocean on false alarms...

Quibling aside, an authentication mechanism needs to be part of the
infrastructure ... where do we say that?

As a data point, the Common Alerting Protocol working group is working
out this problem.  There is a plethora of warning systems out there --
lots of stovepipes.  One for emergency weather, another for attack
warning, ... and many are heavily media dependent -- feeds to the TV
system, etc.  CAP is working on the media-independent (and comms
independent, for that matter) data element standardization problem so
that warnings (and their modifications and cancellations) can be
distributed.  
	- authentication is a core requirement and recognized as such.  CAP is
XML-based so adopting a digital signature approach is fairly
straightforward as far as the protocols are concerned (Ran's point about
messy PKI administration acknowledged).  
	- anyone on the internet can originate a CAP message ... just pirate
the format and fill in the blanks (indeed the test version up now
encourages you to do just that).  No different than calling the fire
department on PSTN with a false alarm.

---

From: Rex Buddenberg <[email-masked]>
Date: 02 Dec 2002 16:22:31 -0800

I'm firmly convinced that the reason World War Three never happened is
that nobody could properly authenticate the mission order.

---

From: Scott Bradner <[email-masked]>
Date: Mon, 2 Dec 2002 20:25:04 -0500 (EST)

> As a data point, the Common Alerting Protocol working group is working

which working group?  (I do not see a "Common Alerting Protocol" working
group in the IETF)

Scott

---

From: Rex Buddenberg <[email-masked]>
Date: 03 Dec 2002 08:11:15 -0800

> which working group?  (I do not see a "Common Alerting Protocol" working

[email-masked]
http://www.incident.com/mailman/listinfo
"CAP-list" is an email list for discussion about concepts, requirements
and specifications for a Common Alerting Protocol.  It is not for
product announcements, advertising or advocacy.  For more information
about the Common Alerting Protocol, visit
<http://www.incident.com/cap/>.

... not part of IETF