Subject: Re: [Ieprep] IEPREP requirements for accounting

From: [email-masked]
Date: Wed, 23 Oct 2002 08:59:21 EDT

In a message dated 10/15/2002 4:44:29 PM W. Europe Daylight Time, 
[email-masked] writes:

> I do not believe this is a legitimate requirement to place on service 
> providers.
> 
> As long as the service provider has enough capacity to handle both 
> legitimate
> and non-legitimate calls, there is no functional need for the service 
> provider
> to detect or account for the non-legitimate uses/users.  This is a business 
> tradeoff
> between call capacity costs and accounting/detection costs.  Different 
> service
> providers might legitimately make different decisions for that tradeoff 
> based on
> differing cost structures.
> 

[MAP] Whether or not the service provider needs or wants to keep detailed 
call records is independent of whether or not they have "enough capacity". 
Besides, the whole subject here in IEPREP is for the case in which there is 
not enough capacity. So there is no "business tradeoff".

I am proposing that Accounting is a requirement for a very large service 
provider/network operator (US Defense Department). It is not proper to say 
that it is not a legitimate requirement to place on such a service provider. 
It is the service provider itself that demands this capability. My comment is 
that the IETF must take this functionality into account in the development of 
any protocol, not that every service provider must support it.

For the GETS case, which we are attempted to "convert" to the IP environment 
- if the US government says they need detailed call records, and they 
contract with the service provider to provide them, and they are willing to 
pay the additional cost associated with doing it, you can't say that it is 
not a legitimate requirement. Yes, it is up to the service provider if they 
want to do business with the government, but the standard needs to define how 
they must do it to comply.

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Oct 2002 09:22:11 -0400

It is not clear to me that this is a problem the IEPREP working group 
can solve, realistically. There are probably at least three sub-problems 
hiding behind the 'accounting' label:

(1) an overall architecture - who needs to deliver what data to whom 
with what timeliness and assurance;

(2) what protocols should be used in the transport of such data;

(3) the precise data formats for off-line or near-real-time exchange.

Clearly, there is very little agreement on (1), with advocates of 
web-services approaches, RADIUS, DIAMETER, "just ship tapes" and who 
knows what other architectures all having valid arguments. I doubt that 
IEPREP will have any more success than earlier efforts in picking a 
winner here, even assuming that it should.

(2) is mostly solved (within the IETF), with DIAMETER, but issues of how 
non-NAS applications use DIAMETER are still pending (see the various 
AAA-for-SIP drafts, say).

(3) See IPDR.org.

There are a number of on-going efforts in the SIPPING WG to define AAA 
requirements for SIP sessions, as well as obviously the more general 
on-going AAA work (DIAMETER WG). Unless there is a clear perception that 
IEPREP requirements differ in some fundamental way from these 
requirements, I wonder what value IEPREP can add to the discussion.

I believe the one useful contribution would be to highlight any major 
additional requirements that IEPREP-style services impose on accounting, 
regardless of the lower-level details, compared to ordinary commercial 
service. To be useful, this has to be more specific than variations on 
"IEPREP calls are more important, so accounting is more important" or 
general statements that accounting should be correct, trustable and all 
the other non-Enron properties.

>
> For the GETS case, which we are attempted to "convert" to the IP
> environment - if the US government says they need detailed call records,
> and they contract with the service provider to provide them, and they
> are willing to pay the additional cost associated with doing it, you
> can't say that it is not a legitimate requirement. Yes, it is up to the
> service provider if they want to do business with the government, but
> the standard needs to define how they must do it to comply.
>
> Mike Pierce
> Artel
>

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

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Oct 2002 05:11:59 -0400

On Wednesday, Oct 23, 2002, at 08:59 America/Montreal, [email-masked] 
wrote:
> Besides, the whole subject here in IEPREP is for the case in which 
> there is not enough capacity.

This is not my understanding from either the current drafts or from the 
WG Charter.
Perhaps Scott could clarify this further with respect to the WG Charter 
?

With  respect to drafts, if the above is the authors' intent then such 
needs
to be made MUCH MUCH more clear.

> I am proposing that Accounting is a requirement for a very large 
> service provider/network operator (US Defense Department). It is not 
> proper to say that it is not a legitimate requirement to place on such 
> a service provider. It is the service provider itself that demands 
> this capability. My comment is that the IETF must take this 
> functionality into account in the development of any protocol, not 
> that every service provider must support it.

It MUST NOT be a requirement levied on other carriers (e.g. commercial 
firms
that choose to offer an IEprep service on a contractual basis).

If DoD does require this (and your lack of identification of affiliation
begs the question of whether you speak officially on the record for the
entire DoD), then I believe what you want is more like these words
(no doubt some editing required since I'm writing in haste).

	The IEprep Architecture should not preclude an operator from performing
	accounting if that operator chooses to do so, though there is no
	IEprep requirement that an operator deploy an ability to perform
	accounting or actually perform such accounting.

 From conversations with DoD employees close to the DISN, which people 
actually are
the operators of the DISA IP networks, I do not hear that they have any 
such requirement.
 From conversations with USAF/USN/USA employees close to their 
service-specific
networks, I also do not hear that they have any such requirement.

If DISA/NCS has such a US-specific requirement, it needs to be resolved
contractually (by paying money and finding agreeable commercial vendors)
rather than by slipping an unfunded mandate into a global IETF standard.

> environment - if the US government says they need detailed call 
> records, and they contract with the service provider to provide them, 
> and they are willing to pay the additional cost associated with doing 
> it, you can't say that it is not a legitimate requirement. Yes, it is 
> up to the service provider if they want to do business with the 
> government, but the standard needs to define how they must do it to 
> comply.

Not at all.  Such can and must be defined in contract terms without 
necessarily being
part of the *global* standard.  Per-call accounting is NOT a global 
requirement.

Your attempt to insert US-centrism into a global standard is noted and
is also very inappropriate behaviour on an IETF list.

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Thu, 24 Oct 2002 10:08:37 -0400 (EDT)

> Perhaps Scott could clarify this further with respect to the WG Charter 

this WG does have to think about the case where there is not enough
capacity in the IP network on the path that a data stream will use

the lack of capacity might be restricted to tail circuits, as might
be the general case in US wireline ISPs, or in the infrastructure - the
WG should not worry about the case where the IP path spans multiple ISPs

but the current deliverable is to say what in this space can be
supported using existing IP protocols - it is not to invent new ones

Scott

---

From: "Steve Silverman" <[email-masked]>
Date: Thu, 24 Oct 2002 15:57:22 -0400

This week there was a large DDoS attack on the DNS system of the Internet.
One would think that any system we specified would collect enough
information to help stop such attacks.  While I do not (unfortunately) own
any TELCOs or ISPs, if I did, I wouldn't invest much money on a network that
couldn't protect itself. Since one possible attack would involve zombies
making emergency phone calls (or any other prioritized call), some sort of
tracking info (I would call it accounting info) must be collected by any
supporting service provider even if no billing is intended.

It probably doesn't pay to charge for emergency calls but that sort of
decision is not made by engineers.

Steve Silverman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> RJ Atkinson
> Sent: Thursday, October 24, 2002 5:12 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ieprep] IEPREP requirements for accounting
>
>
>
...

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Oct 2002 20:41:18 -0400

On Thursday, Oct 24, 2002, at 10:08 America/Montreal, Scott Bradner 
> supported using existing IP protocols - it is not to invent new ones

Current IP protocols generally do not support detailed accounting 
records
as part of the protocols.  Some implementations of RADIUS happen to 
support
some level of accounting -- but it isn't part of the RADIUS protocol
specification that accounting is required -- to give one example.

So, based on Scott's comment above, creating a requirement for detailed 
accounting
seems inappropriate unless a *specific* existing IP protocol can be 
identified
where that IETF protocol specification already requires that accounting 
support
be implemented.  If someone has such a specific example, it would be 
helpful
to cite RFC, Section, and page to this list.

Regards,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Oct 2002 20:47:08 -0400

On Thursday, Oct 24, 2002, at 15:57 America/Montreal, Steve Silverman 
wrote:

> information to help stop such attacks.

	By the way, adding accounting actually would create a new vulnerability
to DDOS attacks, rather than reducing the vulnerability, because it
creates a new attack vector without mitigating any existing attack
vector.

	Consider for example the 20+ year old (and widely published,
so I'm not revealing any new data here) external attacks on servers
by performing minor attacks which cause SYSLOG to fill the disk
and then the full disk causes the server to crash.

>  Since one possible attack would involve zombies

No.  If a Tier-1 operator has more core capacity than theoretical
max offered load, then they are fairly immune from traffic-based DDOS
attacks (though the downstream Tier-2 ISPs uplink would not necessarily
be immune) and so the Tier-1 would not need to do any form of accounting
(indeed, doing such accounting might create a vulnerability for them).

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Thu, 24 Oct 2002 20:53:25 -0400 (EDT)

> seems inappropriate unless a *specific* existing IP protocol can be 

I'm sorry but I do not follow that

(specifically not commenting on the question about a requirement for 
accounting)

I do not see anything in the charter that restricts this WG to 
only producing requirements that describe existing IP protocol functions

the charter says:
  In particular the working group will devlop a Requirements for Internet
  Emergency Preparedness in the Internet RFC which will detail the specific
  functions and technologies needed to provide support for Emergency
  Preparedness systems in the Internet.

if this WG comes to consensus that a "function or technlogy" that
does not curremtly exist is needed to support Internet Emergency
Preparedness then this group should state the requirement.  To do 
otherwise would be to produce an incomplete document

This group is quite specifically not chartered to develop any new 
functions or technology.

Scott

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 25 Oct 2002 01:19:56 -0400

On Thursday, Oct 24, 2002, at 20:53 America/Montreal, Scott Bradner 
> I'm sorry but I do not follow that

Then we aren't communicating clearly, so more details help. :-)

> This group is quite specifically not chartered to develop any new

OK.  So then (as an example) this WG can't tell SIP how to add labels 
to SIP
or any implementation/deployment details, but could say that some form 
of label
is needed that will solve problems X and Y.  (Scott, is that right or 
wrong ?)

It would be good if there were a common understanding on the charter 
question.

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Fri, 25 Oct 2002 07:26:49 -0400 (EDT)

> is needed that will solve problems X and Y.  (Scott, is that right or 

how about "sorta right" :-)

this group can say that there are problems X & Y that need to be
solved for ieprep to work with SIP - it can not tell SIPPING
(which gets the requirement 1st)  that solving the problems means 
that a new header is needed - i.e., defining how to meet the requirement is
not IEPREP's job 

SIPPING  will then take a look at the requirement to see if it:
1/ can be met in some way with SIP as-is that the ieprep did not figure out,
   even if the solution is not as "efficient" as IEPREP might like
2/ can be combined with other resuirements that SIPPING has received
   from other WGs or individuals, and can be reworked to make the requirement
   more general to solve a wider class of problems, (SIPPING
   might on its own do this w/o the need for specific other requirements
   being submitted)
3/ does not make sense
4/ deals with too narrow a situation to warrent changing SIP ("you can't
   always get what you want, but you generally get what you need")
5/ makes sense as-is

in case 1 SIPPING responds to ieprep - 'here is how to do it'
in case 3 it sends back a "huh?" message
in case 4 it sends back a 'no, and here is why' messgae
in case 2 & 5 SIPPING sends the requirement on to SIP which
then figures out how best to meet the requirement

IEPREP can make a suggestion on how to meet the requirement but SIP
can reject the suggestion if SIP thinks that the ieprep
suggestion is the wrong way to meet the requirement (I do not suggest that
IEPREP should spend time coming up with such suggestions)

Scott