Prologue to Bookkeeping Administration.


84 views
Uploaded on:
Description
The field of Accounting Management is worried with the accumulation of asset ... In archival bookkeeping, the objective is to gather all bookkeeping information, to ...
Transcripts
Slide 1

Prologue to Accounting Management RFC 2975 SIPPING IETF 53 Minneapolis, MN Thursday March 21, 2002

Slide 3

What is Accounting Management? The field of Accounting Management is worried with the accumulation of asset utilization information for the motivations behind limit and pattern investigation, cost distribution, inspecting, and charging.

Slide 4

Uses for Accounting Data Trend investigation and scope quantification. Objective: gauge of future use High unwavering quality normally not required, moderate parcel misfortune can be endured Billing Non-use touchy charging Does not require utilization data in principle all bookkeeping information can be lost without influencing the charging process. Use delicate charging Packet misfortune = Revenue misfortune Billing procedure may need to fit in with money related reporting and legitimate prerequisites An authentic bookkeeping methodology might be required. Evaluating The demonstration of confirming the rightness of a technique; regularly depends on bookkeeping information To allow a tenable review, the inspecting information gathering process must be in any event as solid as the element being examined. Taken a toll distribution Cost designation models frequently have significant behavioral and monetary effects. Because of budgetary and legitimate prerequisites, authentic bookkeeping practices are regularly required in this application.

Slide 5

What is Archival Accounting? In recorded bookkeeping, the objective is to gather all bookkeeping information, to recreate missing passages as most ideal as in the occasion of information misfortune, and to document information for an ordered time period. It is "usual and customary" for these frameworks to be built to be exceptionally strong against bookkeeping information misfortune. This is not only a "smart thought." Legal or money related prerequisites much of the time order recorded bookkeeping hones , and may frequently manage that information be kept secret, paying little respect to whether it is to be utilized for charging purposes or not.

Slide 6

Tools for Robust Accounting Non-unpredictable capacity Without non-unstable capacity, occasion driven frameworks will lose information once the transmission timeout has been surpassed, and clumping plans will encounter information misfortune once the inside memory utilized for bookkeeping information stockpiling has been surpassed. Break bookkeeping Useful just when deficient non-unpredictable capacity accessible on the customer Increases bookkeeping activity; between time interim must be set w/mind An all around planned bookkeeping framework won\'t require interval records to travel the wire Reliable transport Implies that the getting transport layer has assumed liability for conveying the information to the application, yet no insurances! Application-layer affirmation Tells you that the bookkeeping server has assumed liability for the information (e.g. kept in touch with stable stockpiling) Failover support

Slide 7

Tools for Secure Accounting Authentication Is the information being sent to the planned destination? Uprightness Protection Has the information been messed around with? Replay Protection Has the information been replayed? Privacy Can the information be acquired by a spy? Transmission versus object security May need to give the above administrations notwithstanding when there are intermediaries in the way

Slide 8

Issues with RADIUS Accounting (RFC 2866) Undefined retransmission conduct (UDP) "It is prescribed that the customer keep endeavoring to send the Accounting-Request parcel until it gets an affirmation, utilizing some type of backoff." Undefined failover conduct Application layer ACK – perhaps Accounting-Response bundle suggests that the Accounting-Request has been gotten and recorded effectively. Vague intermediary conduct "Compelling consideration ought to be utilized while actualizing an intermediary server that assumes liability for retransmissions so that its retransmission approach is hearty and adaptable." No mistake messages "If the RADIUS bookkeeping server can\'t effectively record the bookkeeping bundle it MUST NOT send an Accounting-Response affirmation to the customer." Can\'t say "circle fizzled" or "I\'m occupied" Result: the customer will retry as opposed to coming up short over

Slide 9

Security Issues Transport security Each bookkeeping parcel is verified and honesty ensured with the RADIUS shared mystery Authenticator helpless against disconnected from the net lexicon assault Don\'t pick a frail secret word! No privacy Replay insurance is an element of bookkeeping post-preparing, not the wire convention Fixes: keep running over IPsec (RFC 3162) Object security No assurance against untrusted intermediaries

Slide 10

RADIUS Accounting Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+-"The NAS and RADIUS bookkeeping server share a mystery. The Request Authenticator field in Accounting-Request parcels contains a restricted MD5 hash ascertained over a flood of octets comprising of the Code + Identifier + Length + 16 zero octets + demand characteristics + shared mystery (where + shows connection). The 16 octet MD5 hash worth is put away in the Authenticator field of the Accounting-Request parcel." Notice anything "intriguing" about this?

Slide 11

RADIUS Accounting Attributes 1-39 (allude to RADIUS record [2]) 40 Acct-Status-Type 41 Acct-Delay-Time 42 Acct-Input-Octets 43 Acct-Output-Octets 44 Acct-Session-Id 45 Acct-Authentic 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause 50 Acct-Multi-Session-Id 51 Acct-Link-Count 55 Event-Timestamp

Slide 12

Replay Protection Accounting ask for authenticator is not a nonce, as in RADIUS verification! Just wellspring of "liveness" in the Accounting parcel is the Acct-Session-Id and Event-Timestamp qualities Identifier is just a solitary octet, can wrap Acct-Session-Id MUST be incorporated into Accounting Request, not required to be transiently one of a kind Event-Timestamp characteristic is discretionary (RFC 2869) "The RADIUS server can distinguish a copy demand on the off chance that it has the same customer source IP address and source UDP port and Identifier inside a limited ability to focus time." Unless source UDP port is changed each 256 bundles, server will acknowledge a replay once the Identifier wraps Post-handling check for copy Acct-Session-Id to recognize replay Accounting server needs to timestamp the bundles

Slide 13

RFC 2975 Evaluation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage | Intra-space | Inter-area | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capacity | SNMPv3 & | SNMPv3 &<* | Planning | RADIUS #%@ | TACACS+ @ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Non-use | SNMPv3 & | SNMPv3 &<* | Sensitive | RADIUS #%@ | Billing | TACACS+ @ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage | Sensitive | Billing, | SNMPv3 &>$ | SNMPv3 &<>*$ | Cost | TACACS+ &$@ | Allocation & | Auditing | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time | Sensitive | SNMPv3 &>$ | No current | Billing, | convention | extortion | identification, | wandering | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key # = needs classification support * = needs information object security % = constrained power against parcel misfortune & = needs application layer affirmation (e.g. SNMP InformRequest) $ = requires non-unpredictable capacity @ = needs grouping support < = needs authentication bolster (KSM, work in advancement) > = needs bolster for substantial parcel sizes (TCP transport mapping exploratory)

Slide 14

Alternatives SNMP The most famous bookkeeping strategy Supports "surveying model" Bulk recovery best took care of over TCP Issues clarified in RFC 2975 Support for application layer ACK SNMP Responses to get, get-next, or get-mass solicitations give back the asked for information, or a mistake code showing the way of the blunder experienced. A noError SNMP Response to a SET charge shows that the solicitation assignments were made by the application. SNMP SETs are nuclear. Notices don\'t utilize affirmations to show that information has been prepared. The Inform warning returns an affirmation of receipt, however not of preparing, by configuration. "Push model" not plausible because of "reaction bloating" Security with SNMPv3

Slide 15

Alternatives, cont\'d Diameter Runs over dependable transport Failover bolster Interim bookkeeping Application layer ACK, blunder messages No reaction bloating "Push" or "Pul

Recommended
View more...