Internet Accounting: Background
RFC 1272
| Document | Type | RFC - Informational (November 1991) | |
|---|---|---|---|
| Authors | |||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 1272
lt;/boot-image>
<configuration>
<!-- from ietf-system.yang -->
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<authentication>
<user>
<name>admin</name>
<ssh-key>
<name>admin's rsa ssh host-key</name>
<algorithm>ssh-rsa</algorithm>
<key-data>AAAAB3NzaC1yc2EAAAADAQABAAABAQDeJMV8zrtsi8CgEsR\
Watsen & Abrahamsson Expires October 8, 2016 [Page 35]
Internet-Draft Zero Touch April 2016
jCzfve2m6zD3awSBPrh7ICggLQvHVbPL89eHLuecStKL3HrEgXaI/O2Mw\
E1lG9YxLzeS5p2ngzK61vikUSqfMukeBohFTrDZ8bUtrF+HMLlTRnoCVc\
WAw1lOr9IDGDAuww6G45gLcHalHMmBtQxKnZdzU9kx/fL3ZS5G76Fy6sA\
vg7SLqQFPjXXft2CAhin8xwYRZy6r/2N9PMJ2Dnepvq4H2DKqBIe340jW\
EIuA7LvEJYql4unq4Iog+/+CiumTkmQIWRgIoj4FCzYkO9NvRE6fOSLLf\
gakWVOZZgQ8929uWjCWlGlqn2mPibp2Go1</key-data>
</ssh-key>
</user>
</authentication>
</system>
<!-- from ietf-netconf-server.yang -->
<netconf-server
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<call-home>
<application>
<name>config-mgr</name>
<ssh>
<endpoints>
<endpoint>
<name>east-data-center</name>
<address>11.22.33.44</address>
</endpoint>
<endpoint>
<name>west-data-center</name>
<address>55.66.77.88</address>
</endpoint>
</endpoints>
<host-keys>
<host-key>my-call-home-x509-key</host-key>
</host-keys>
</ssh>
</application>
</call-home>
</netconf-server>
</configuration>
</bootstrap-information>
</device>
7.2.4. Signed Bootstrap Information
The following example illustrates a device using the API to fetch its
bootstrapping data. In this example, the device receives signed
bootstrap information. This example is representative of a response
that bootstrap server might return if concerned the device might not
be able to authenticate its TLS certificate.
REQUEST
-------
Watsen & Abrahamsson Expires October 8, 2016 [Page 36]
Internet-Draft Zero Touch April 2016
['\' line wrapping added for formatting only]
GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:\
devices/device=123456 HTTP/1.1
HOST: example.com
Accept: application/yang.data+xml
RESPONSE
--------
HTTP/1.1 200 OK
Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server
Content-Type: application/yang.data+xml
<!-- '\' line wrapping added for formatting purposes only -->
<device
xmlns="urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server">
<unique-id>123456789</unique-id>
<bootstrap-information>
<boot-image>
<name>
boot-image-v3.2R1.6.img
</name>
<md5>
SomeMD5String
</md5>
<sha1>
SomeSha1String
</sha1>
<uri>
/path/to/on/same/bootserver
</uri>
</boot-image>
<configuration>
<!-- from ietf-system.yang -->
<system xmlns="urn:ietf:params:xml:ns:yang:ietf-system">
<authentication>
<user>
<name>admin</name>
<ssh-key>
<name>admin's rsa ssh host-key</name>
<algorithm>ssh-rsa</algorithm&5.2 An Extended (Campus or Facility-Wide) LAN
128.252.100.X 128.252.150.X 128.253.220.X
+----------------+ +----------------+ +----------------+
| | |
| | |
/ \ / \ / \
128.252.100.10 128.252.150.10 128.253.220.10
\ / \ / \ /
| | |
+--+-+----------------------+-+----------------------+-+-+
| | |
/ \ / \ / \
128.252.130.10 128.252.120.10 128.253.140.10
\ / \ / \ /
| | |
| | |
+-----------------+ +-----------------+ +----------------+
128.252.130.X 128.252.120.X 128.253.140.X
This is the first example in which the information that is germane
for service provider and consumer are not identical. The service
consumers are now the individual subnets and the service provider is
the facility-wide backbone. A service provider is interested in
knowing the contribution of individual subnets to the total traffic
of the backbone. In order to ascertain this, a meter on the backbone
(the longest line in the center of the illustration) can keep track
of flows between subnet pairs. Now the communications between
individual hosts on adjacent subnets are aggregated into a single
flow that measures activity between subnets.
The service consumers, or subnets, might in turn want to keep track
of the communications between individual hosts that use the services
of the backbone. An accounting system on the backbone could be
configured to monitor traffic among individual host pairs.
Alternately an accounting system on each individual subnet could keep
track of local and "non-local" traffic. The observed data of the two
sets of meters (one for the service provider and one for the service
consumers) should have reconcilable data.
Mills, Hirsh, & Ruth [Page 15]
RFC 1272 Internet Accounting: Background November 1991
5.3 A Regional Network
116.125
+-----------------+
|
+
/ \
116.125.10.10
\ /
/ + \
/ \
/ \
/ \
| + + |
| / \ / \ |
128.242 |----- 128.242.10.10 128.252.10.10 -----| 128.252
| \ / \ / |
| + + |
\ /
\ /
\ /
\ + /
/ \
124.110.10.10
\ /
+
+-----------------+
|
124.110
In this example we have a regional network consisting of a ring of
point-to-point links that interconnect a collection of campus-wide
LANs. Again service provider and consumer have differing interests
and needs for accounting data. The service provider, the regional
network, again will be interested in the contribution of each
individual network to the total traffic on the regional network.
This interest might extend to include measure of individual link
utilization, and not just total offered load to the network as a
whole. In this latter case the service provider will require that
meters be placed at one end or the other on each link. For the
service consumer, the individual campus, relevant measures would
include the contribution of individual subnets or hosts to the total
"outbound" traffic. Meter(s) placed in (or at) the router that
connects the campus- network to the regional network can perform the
necessary measurement.
Mills, Hirsh, & Ruth [Page 16]
RFC 1272 Internet Accounting: Background November 1991
5.4 A National Backbone
__________
|
+
| / \ |
|--+ 1 +--|
| \ / |
+
/ \
\ /
/ + \
/ \
_______ / \ _______
| / \ |
+ + + +
| / \ / \ / \ / \ |
|--+ 4 +----\ / 5 \ /-----+ 2 +-|
| \ / + + \ / |
+ \ / +
___|____ \ / ___|____
\ /
\ + /
/ \
\ /
+
| / \ |
|--+ 3 +--|
| \ / |
+
____|____
In this last case, the data that the service provider will want to
collect is the traffic between regional networks. The flow that
measures a regional network, or regional network pairs, is defined as
the union of all member-campus network address spaces. This can be
arrived at by keeping multiple individual network address flows and
developing the regional network contribution as post-processing
activity, or by defining a flow that is the union of all the relevant
addresses. (This is a cpu cycles for memory trade-off.) Note that
if the service provider measures individual network contributions,
then this data is, in large
measure, the data that the service consumers would require.
6. Future Issues
This last section is the collector for ancillary issues that are as
yet undefined or out of current scope.
Mills, Hirsh, & Ruth [Page 17]
RFC 1272 Internet Accounting: Background November 1991
APPLICATIONS standards: Recommendations for storage, processing and
reporting are left out for the moment. Storage and processing of
accounting information is dependent on individual network policy.
Recommendations for standardizing billing schemes would be premature.
QUOTAS are a form of closed loop feedback that represent an
interesting extension of usage reporting. But they will have to wait
until the basic accounting technology is reasonably defined and has
been the subject of a reasonable amount of experimentation.
SESSION ACCOUNTING: Detailed auditing of individual sessions across
the internet (at level four or higher) will not be addressed by
internet accounting. Internet accounting deals only with measuring
traffic at the IP level.
APPLICATION LEVEL ACCOUNTING: Service hosts and proxy agents have to
do their own accounting for services, since the network cannot
distinguish on whose behalf they are acting. Alternately, TCP/UDP
port numbers could become an optional field in a meter, since the
conjunction of a pair of IP addresses and port numbers occurring at a
particular time uniquely identifies a pair of communicating
processes.
The USER has not yet been defined, since an IP option would have to
be added to the IP header to provide for this. This option would
probably contain two parts - a subscriber identification and a user
sub-identification - to allow for the later introduction of quota
mechanisms which have both group and individual quotas. The
subscriber is the fiscally responsible entity, for example the
manager of a research group. In any case, routers must be able to
fall back to accounting by host, since there will most certainly be
hosts on the network which do not implement a new IP option in a
timely fashion.
7. References
International Standards Organization (ISO), "Management
Framework," Part 4 of Information Processing Systems Open Systems
Interconnection Basic Reference Model,ISO 7498-4, 1984.
International Standards Organization (ISO), "Security
Architecture," Part 2 of Information Processing Systems Open
Systems Interconnection Basic Reference Model,ISO 7498-2, 1984.
Mills, Hirsh, & Ruth [Page 18]
RFC 1272 Internet Accounting: Background November 1991
Security Considerations
Security issues are discussed in sections 2, 3 and 4.
Authors' Addresses
Cyndi Mills
Bolt, Beranek, and Newman
150 Cambridge Park Drive
Cambridge, MA 02140
Phone: 617-873-4143
Email: cmills@bbn.com
Donald Hirsh
Meridian Technology Corporation
11 McBride Corporate Center Drive
Suite 250
Chesterfield, MO 63005
Phone: 314-532-7708
Email: hirsh@meridian.uucp
Gregory Ruth
Bolt, Beranek, and Newman
150 Cambridge Park Drive
Cambridge, MA 02140
Phone: 617-873-3150
Email: gruth@bbn.com
Mills, Hirsh, & Ruth [Page 19]