Subject: Re: [Ieprep] Requirements for Accounting

From: [email-masked]
Date: Tue, 12 Nov 2002 12:58:41 EST

In a message dated 11/12/2002 3:33:59 AM Eastern Standard Time, [email-masked] 
writes:

>    > If "Accounting" or "X" or "Y" is included in the IEPREP doc as a
>     > "requirement", it only means that some other WG must figure out a
>     > way to support it.
> 
> No, it _most certainly does not_ mean that.  And if you really think it
> does, get ready for them to toss you out on your ear again.
> 

[MAP] Perhaps I am blind, naive, or both. But I didn't think that I had been 
"tossed out on my ear" yet (by the WG). I haven't gotten any indication from 
the Chair or ADs that I was off-base. And if I did, I guess I could apply the 
procedure described by Ran 6 days ago as follows:

And attempts by any AD or WG Chair to stop one from doing that would 
certainly be
appealable (and such an AD action would be very likely to be overturned on 
appeal,
in my own reading of the tea leaves, on grounds that it is contrary to IETF 
openness
as a standards-body).

As Scott wrote on Oct 14:

the primary task on the WG's plate right now is to come to consensus 
on a requirements document to be forwarded to the sipping working group
(obviously that document needs to be  SIP-specific)

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 12 Nov 2002 10:00:30 -0800 (PST)

>>> way to support it.                              ^^^^
    >> No, it _most certainly does not_ mean that.

    > on a requirements document to be forwarded to the sipping working group

Do you really not see the (underlined for your convenience) difference
between these two statements?

                                -Bill

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

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 12 Nov 2002 15:20:35 -0500

Perhaps instead of accounting, we should call it call tracking?  (I don't
think the name is very important.) Would this be more acceptable to some
people?

I don't think that charging users for emergency calls is projected to become
a major source of income for any SP.
I would like to avoid the situation in which more money is spent billing
users than providing the desired service.

I view this as a requirement to track who uses a service especially in the
light of the recent DDOS attack with enough info to identify users
(especially those who make major demands).
Even if some network does not want to defend itself, I think we should
provide a mechanism so that a network CAN
protect itself from such attacks.  (I don't think any SP would deploy a
defenseless network in the future.)
I believe that this function requires that enough records be kept so that
some diagnostic work can be done after the fact. It seems as though the
world is becoming a nastier place and in such an environment, too much trust
does not work very well.

Steve Silverman

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 12 Nov 2002 12:26:49 -0800 (PST)

On Tue, 12 Nov 2002, Steve Silverman wrote:
    > Perhaps instead of accounting, we should call it call tracking?

I don't know that there's a problem with the name...  Accounting is a
widely-used and perfectly acceptable name for the procedure, and doesn't
inherently imply a billing relationship.

I think that the underlying issue vis-a-vis accounting is whether we're
looking for L3 accounting or L7 accounting.  As long as the definition is
L7, we've already got it, and everybody can go home happy, the work is
already done.  If you want L3 accounting, you're not going to get it, you
don't need it, nobody's specified a reason for doing it, and everybody's
going to go home upset.

>From a diagnostic point of view, as a system operator, I agree with this
whole-heartedly.  However it's my understanding that one of the drafts
currently specifies exactly the opposite...  that users be given the
opportunity to operate with anonymity, which seems to me to be a basic
conflict with the need for reliability.

    > I think we should provide a mechanism so that a network CAN
    > protect itself from such attacks.

For what value of "we?"  There are lots of smart people working in that
field, but it's typically an L3/L4 problem, not an L7 problem, and we
generally think of it as an operational practices and procedures problem
rather than a protocol one.

    > I don't think any SP would deploy a defenseless network in the
    > future.

Heh, heh.  I'll take that bet.  :-)

    > world is becoming a nastier place and in such an environment, too much trust

Yes, so we all save SIP proxy logs, and whatever you can get the SIP
product vendors to log, we'll have for a long, long time.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 12 Nov 2002 19:51:13 -0500

On Tuesday, Nov 12, 2002, at 15:20 America/Montreal, Steve Silverman 
> think the name is very important.) Would this be more acceptable to 

The name matters only to make the meaning clear.  Right now, I think
there are a bunch of different meanings in different heads on this
list.

If one were proposing "call accounting inside SIP servers" and 
explicitly
NOT any form of accounting performed by IP-layer-only service providers,
then I would be a lot more comfortable with the proposal.  Is that in
fact what folks mean ?

> a major source of income for any SP.

I'd agree that is likely for ISPs, not sure about PSTN SPs.

> users than providing the desired service.

So would ISPs, particularly the majority of ISPs who only offer "best 
effort
IP-layer forwarding" as a service offering (and ignore whether the 
traffic
is VoIP or not, and ignore any attempts to request QoS).

> (especially those who make major demands).

We need to define clearly which "service" is meant by the above.
	IP access ?
	SIP server connection ?
	something else ?

> world is becoming a nastier place and in such an environment, too much 

The problem is that keeping records of some kinds of events CREATES new
vulnerabilities, which vulnerabilities I hope we agree would be a bad 
thing
to mandate or suggest for deployment.  Since IP networks are 
connectionless,
there is no record of connections normally available at the IP-layer.  
And
most ISPs only offer IP-layer services.  So I don't see where 
"accounting"
fits into the picture for ISPs.  Disagree ?

Also, Can we please define meanings more clearly (see questions above) ?

Thanks,

Ran
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 12 Nov 2002 21:24:47 -0500

"Auditing" has been mentioned in a number of (IETF) documents as one 
function of usage tracking; I assume the goal here is mostly to track 
usage of certain services, e.g., for system sizing or detection of abuse 
("Sergeant Shultz seems to be making a lot of emergency calls to a 
private number listed under Mary Smith"), not to send bills.

As a side-note, byte-based billing is apparently quite common in 
Australia and New Zealand, not to mention in wireless networks (GPRS). 
See http://www.bigpond.com/broadband/products/adsl/pricing.asp for an 
example of a volume-based plan.

Btw, once you charge per-byte on a wireless link, there is a good 
argument to be made that you need to charge for call setup, too. 
Otherwise, you end up encourage sending voice packets embedded in 
signaling messages... (ISDN UU had the same problem.)

RJ Atkinson wrote:
> 
> On Tuesday, Nov 12, 2002, at 15:20 America/Montreal, Steve Silverman wrote:
> 
> If one were proposing "call accounting inside SIP servers" and explicitly

> vulnerabilities, which vulnerabilities I hope we agree would be a bad thing
> there is no record of connections normally available at the IP-layer.  And
> most ISPs only offer IP-layer services.  So I don't see where "accounting"

Effectively, you do have "connections" at many access points, as long as 
there's an identifiable connection between some identifier (interface, 
PPP session, etc.) in a small number of places. Thus, this seems to be a 
question of granularity. Accounting within a backbone ISP for an 
individual modem user or user-level session doesn't make sense, but 
counting in/out bytes for the customer or peer ISP does.

Apparently, some universities have started per-user byte counts to more 
fairly allocate resources 
(http://www.riverstonenet.com/technology/accounting_for_profitability.shtml)
Indeed, there's the IPFIX WG...

Also, if there is resource reservation (recall the PacketCable DOCSIS 
remarks), you can easily count bytes or packets on a per-session basis.

The Internet is getting big enough that a tiny application niche can 
have more traffic than the whole Internet ten years ago :-)

Thus, I think we'd all avoid a lot of wasted discussion if "requirements 
for X" were silently or explicitly substituted by "If you decide to do 
X, these are things X should do to be useful". A second step is then the 
"applicability" part. There, the only real distinctions are "never, ever 
useful (and likely harmful)" or "a tool that has some use". Documenting 
the risks and costs of tools is clearly useful.

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 12 Nov 2002 19:30:36 -0800 (PST)

> Australia and New Zealand, not to mention in wireless networks (GPRS).

Yep, and pray that it doesn't spread, else you won't be able to afford to
web-browse anymore either.

                                -Bill

---

From: Rex Buddenberg <[email-masked]>
Date: 13 Nov 2002 08:46:50 -0800

Operational uses.

Law enforcement.  In the circuit-switched telephone system and in the
United States, the call detail records are readily available to law
enforcement.  Unlike wiretapping the content of a conversation (requires
probable cause), simply looking at the telephone numbers of who talks
with whom is open.  I've seen Customs investigators put together really
persuasive association charts of narcotics criminal enterprises using
this data (with the property tax records at the county treasurer as
corroboration).  
	In our terminology, this is Layer 7 accounting.  

Emergency services.  A 'call back' capability is consistently needed and
for several purposes.  If someone calls in reporting some kind of
emergency, it's often necessary to reconnect with that person later --
more information, check for hoax, or simply to trace location so the
dispatcher can direct the ambulance (this is a data point that got lost
in the cellphone phenomenon and has lots of legislatures exercised in
trying to get it back).  
	This is also Layer 7 accounting.  It matters not how the call was
routed, only _where_ it was routed from.

Internet variant.  If you're investigating a child porn case over the
internet, you sieze one of the perps' computer and look at his mail
files.  In particular, look at the e-mail headers (which are routinely
masked off by most user agents these days -- but the data is still
there).  This tells you what MTAs the mail was routed through and can
tell you quite a bit of useful information about who's trading dirty
pictures with whom.  Again, Layer 7 accounting.

In all of these cases, I can find no reason to want to know the Layer 3
routing information -- that's entirely irrelevant.  

> "Auditing" has been mentioned in a number of (IETF) documents as one 

Both the SNMP and CMIP standards documents mention
	fault management
	security management
	performance management
	configuration management
	accounting management
as the abstract reasons for network management systems.  Once it's in
one of these base documents, the list is parroted and the original
definitions often get lost ... or changed.  You see this phenomenon in
the networking textbooks worst of all.  

Recommendation.  I'd find some practicing law enforcement and emergency
services folks and consult with them to find out what useful accounting
information they'd want.  Leaven with somebody who's familiar with both
the 1st and 4th Amendments.  Makes a lot of sense to do this before
rather than try to glue on some fixes later.

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 13 Nov 2002 12:24:50 -0500

On Tuesday, Nov 12, 2002, at 21:24 America/Montreal, Henning 
Schulzrinne wrote:
> Effectively, you do have "connections" at many access points, as long 
> as there's an identifiable connection between some identifier 
> (interface, PPP session, etc.) in a small number of places.

  You changed layers on me.  PPP itself is a link-layer technology.  PPP 
also
does not imply use of any kind of user login (e.g. PPP over SONET).

My claim remains valid -- the IP layer is connectionless and so does 
not have
connections that can be tracked.   Some other layers have some kinds of
connections, where the details materially differ depending on which 
layer
(and protocol) one considers.

What was the meaning of the original commenter that I replied to ?
That remains entirely unclear, making it hard to understand the
intended meaning and have a constructive conversation.

> Thus, this seems to be a question of granularity. Accounting within a 
> backbone ISP for an individual modem user or user-level session 
> doesn't make sense, but counting in/out bytes for the customer or peer 
> ISP does.

Counting in/out bytes on an *interface* or in/out packets on an 
*interface*
(where I mean the values precisely as defined in the widely implemented 
IETF
Interface MIB standards) is fine.

It is important that there is NO expection or requirement for 
finer-grained
byte/packet counting (e.g. per-flow is not available, per-end site is 
not
available, per IP-ToS-bit-pattern is not available).

> remarks), you can easily count bytes or packets on a per-session > basis.

	So far, PacketCable is vapour.  The cable folks (e.g. Cox) are 
currently actually
deploying their telephony services using a different technology that 
uses different
frequencies on the HFC, and is unrelated to IP, DOCSIS, or PacketCable. 
  PacketCable
or DOCSIS are also inherently access technologies.

	Most current cable network operators purchase IP transit from one or 
more larger
carriers and basically are Tier-2 ISPs.  Exceptions exist outside North 
America,
but are very few even outside North America.

> Thus, I think we'd all avoid a lot of wasted discussion if 
> "requirements for X" were silently or explicitly substituted by "If 
> you decide to do X, these are things X should do to be useful". A 
> second step is then the "applicability" part. There, the only real 
> distinctions are "never, ever useful (and likely harmful)" or "a tool 
> that has some use". Documenting the risks and costs of tools is 
> clearly useful.

It is still important to be very CLEAR about what is mean by X or by 
"things
X should do to be useful".  So far, clarity remains a big problem -- 
and your
note did not entirely clarify the original note's ambiguity.

Ran