One document matched: draft-fessi-nsis-m-nslp-framework-01.txt
Differences from draft-fessi-nsis-m-nslp-framework-00.txt
Network Working Group A. Fessi
Internet-Draft University of Tuebingen
Expires: January 21, 2006 C. Kappler
C. Fan
Siemens AG
F. Dressler
University of Erlangen
A. Klenk
University of Tuebingen
July 20, 2005
Framework for Metering NSLP
<draft-fessi-nsis-m-nslp-framework-01.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document motivates and describes an architectural framework for
a new NSLP, which allows the dynamic configuration of Metering
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 1]
Internet-Draft M-NSLP Framework July 2005
Entities on the data path to record monitoring and measurement data
and report it to a data collector. Different scenarios are described
where such a path-coupled configuration of the Metering Entities can
be useful. Currently, the focus is on three scenarios: metering for
accounting, QoS measurement and monitoring for network security.
Moreover, this document suggests the appropriate parameters to be
configured for each scenario. Furthermore, it gathers requirements
for a path-coupled configuration protocol of Metering Entities.
Finally, the applicability of the NSIS architecture for this purpose
is discussed.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 2]
Internet-Draft M-NSLP Framework July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Scenario Description . . . . . . . . . . . . . . . . . 7
4.1.2 Required Parameters . . . . . . . . . . . . . . . . . 9
4.2 QoS Monitoring . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Scenario Description . . . . . . . . . . . . . . . . . 11
4.2.2 Configuration Parameters . . . . . . . . . . . . . . . 14
4.3 Monitoring for Network Security . . . . . . . . . . . . . 15
4.3.1 Scenario Description . . . . . . . . . . . . . . . . . 15
4.3.2 Required Parameters . . . . . . . . . . . . . . . . . 17
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1 General requirements . . . . . . . . . . . . . . . . . . . 18
5.1.1 Extensibility . . . . . . . . . . . . . . . . . . . . 18
5.1.2 Scalability . . . . . . . . . . . . . . . . . . . . . 19
5.1.3 Security . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Flexible metering model . . . . . . . . . . . . . . . . . 19
5.3 Distinguishing flows . . . . . . . . . . . . . . . . . . . 19
5.4 Flexible data collection . . . . . . . . . . . . . . . . . 20
5.5 Location of Metering Entities . . . . . . . . . . . . . . 20
5.6 Location of the Collectors . . . . . . . . . . . . . . . . 20
5.7 Configuration protocol . . . . . . . . . . . . . . . . . . 20
5.7.1 Configuration of Metering Entities . . . . . . . . . . 21
5.7.2 Selection of Metering Entities . . . . . . . . . . . . 21
5.7.3 Metering Configuration State installation and
removal . . . . . . . . . . . . . . . . . . . . . . . 21
5.7.4 Initiation and maintenance of metering tasks . . . . . 21
5.7.5 Reaction to Route Changes . . . . . . . . . . . . . . 21
5.7.6 Collection of information on available Metering
Entities . . . . . . . . . . . . . . . . . . . . . . . 21
5.7.7 Scoping of configuration . . . . . . . . . . . . . . . 21
5.8 Metering across domains . . . . . . . . . . . . . . . . . 22
6. Applicability of the NSIS Architecture . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 3]
Internet-Draft M-NSLP Framework July 2005
9.1 Normative References . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 27
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 4]
Internet-Draft M-NSLP Framework July 2005
1. Introduction
Monitoring, metering and accounting of packets is an important
functionality in many networks today. Several working groups are
working on mechanisms for collecting and reporting usage data, flow
or packet information. For example, the IPFIX (IP Flow Information
Export) Working Group defines a protocol to collect and report flow
information ([I-D.ietf-ipfix-protocol]). The PSAMP (Packet SAMPling)
Working Group focuses on reporting per packet information for further
processing ([I-D.ietf-psamp-framework]).
However, it is also necessary to configure and coordinate the
entities doing the metering. If we are interested in one or more
Metering Entities to meter a specific flow, then all potential
candidates for this task are on the path used by this particular
flow. They can easily be addressed by sending a configuration
message along the path of the flow. If more than one Metering Entity
is required, all of them can potentially be configured with a single
message along the path.
The Metering Entities can do either statistics on these flows, packet
sampling or some other special treatment for the packets, for
example, examining the packet payload. The Metering Entities can be
configured and can be coordinated to achieve a certain goal together,
which can be, for example, accounting, QoS monitoring or monitoring
for network security.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Furthermore, this document uses the terms "Metering Data", "Metering
Record", "Monitoring Probe", "Metering Entity", "Collector", as
defined in [I-D.dressler-nsis-metering-nslp].
3. Problem Statement
There is a need in industry and the Internet research community to
collect and export information on data flows. We call such
information Metering Records. Metering Records are useful in
mediation systems, accounting systems, and network management systems
to facilitate services such as Internet research, measurement,
accounting, billing, QoS monitoring, intrusion detection, and traffic
profiling/engineering. In recognition of the need for such metering
the IPFIX WG was founded.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 5]
Internet-Draft M-NSLP Framework July 2005
While the purpose for collecting Metering Records in each case is
different, the basic architecture of such metering systems is usually
identical, cf. Figure 1. Measurement data is collected by a
Monitoring Probe, and from there reported to a Metering Entity. The
Metering Entity produces Metering Data from the measurement data or
additional data such as session information. Monitoring Probe and
Metering Entity are co-located. One Metering Entity may control
several Monitoring Probes; in any event the Monitoring Probe is
controlled by a Metering Entity. The Metering Entity transmits its
Metering Data to the actual Collector. The Collector correlates
Metering Data relating to the same event from different Metering
Entities and produces a Metering Record. There might be more than
one Collector depending on the actual tasks.
+-----------------+
| Collector |
| +-------------+ |
| | Met. Record | |
| +-------------+ |
+-----------------+
^ ^ ^ ^ ^
*** * ***
*** * ***
*** * ***
*** * ***
+-------------+ +-----------+ +-------------+
| +-----+ | | +-----+ | | +-----+ |
| | ME | | | | ME | | | | ME | |
| +-----+ | | +-----+ | | +-----+ |
===>| ^ ^ |===>| ^ |===>| ^ ^ |
| / \ | | | | | / \ |
--->| / \ |--->| | |--->| / \ |
|+----+ +----+| | +----+ | |+----+ +----+|
|| MP | | MP || | | MP | | || MP | | MP ||
|+----+ +----+| | +----+ | |+----+ +----+|
+-------------+ +-----------+ +-------------+
+---+
|ME |= Metering === = Meter. Configuration --- = Data Flow
+---+ Entity Signaling Messages
+----+
| MP | = Monitoring *** = other
+----+ Probe Signaling Messages
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 6]
Internet-Draft M-NSLP Framework July 2005
Figure 1: Schematic Metering Architecture
In this context two problems need to be solved:
o Measurement data need to be reported from the Monitoring Probes to
the Metering Entities and Metering Data need to be transported
from the Metering Entities to the Collector. IPFIX is, for
example, a protocol suitable for this task.
o The Metering Entities need to be configured and coordinated. This
document suggests path-coupled signaling for this purpose.
In a flexible environment, it must be possible to dynamically
configure and coordinate Metering Entities rather than hardwiring
them. Configuration and coordination includes, for example, what
entities do the metering for a particular flow or session, providing
triggers to start or stop metering, distribution of identifiers for
the Collector, flows or user, and so forth. The IPFIX WG has
identified the needs for such configurations but has defined the work
currently as "out of the scope" [RFC3917]. The configuration can be
performed, for example, using RADIUS ([RFC2138]) or DIAMETER
([RFC3588]). The PSAMP (Packet Sampling) WG is also currently
developing a MIB module for configuring packet sampling ([I-D.ietf-
psamp-mib]). Nevertheless, all these alternatives allow only the
configuration of single Metering Entities, and assume that the
location of the Metering Entities to be configured is known before.
Configuration and coordination of distributed Metering Entities is
not supported.
Since the most appropriate Metering Entities for metering a specific
flow are located along the same path as the flow itself, a path-
coupled signaling protocol for distributing the configuration
information seems useful.
4. Scenarios
This section describes three scenarios for the usage of path-coupled
configuration of Metering Entities: accounting, QoS monitoring, and
monitoring for network security.
4.1 Accounting
4.1.1 Scenario Description
Flexible usage-based charging is mainly a problem in 3G mobile
telecommunication networks. But with the advent of IP in these
networks and with 3GPP's All-IP perspective, there is also an
increasing need for IP technology to provide such functionality.
When starting an application session, for example, a video streaming,
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 7]
Internet-Draft M-NSLP Framework July 2005
usually there are several possible Metering Entities on the data
path, for example, the application server, the WLAN access point, the
ingress nodes of several transit networks or any router on the path
with metering capabilties.
An example of such a scenario is illustrated in Figure 2 where a data
receiver expects data from a data sender via two routers Router 1 and
Router 2. The application server (i.e., data sender) may or may not
(as in Figure 2) belong to the administrative domain.
+-------------------------+
Data Receiver | Router 1 Router 2 | Data Sender
+-----------+ | +-----+ +-----+ | +-----------+
| |<-----| |<----| |<----------|Application|
|Application| | |+---+| |+---+| | | +---+ |
| | | ||ME ||<===>||ME ||<=========>| |ME | |
+-----------+ | |+---+| |+---+| | | +---+ |
| +-----+ +-----+ | +-----------+
| Administrative Domain |
+-------------------------+
+---+
|ME | = Metering === = Signaling --- = Data Flow
+---+ Entity Messages
Figure 2: Signaling to configure metering for accounting
As a prerequisite to charging, one or more Metering Entities collect
Metering Records independently for the same session. Existing
accounting concepts handle multiple Metering Entities by statically
configuring them. Some of those Metering Entities always generate
Metering Records, which will be discarded anyway later. For example,
in the case of a pure content charging scheme, only the Metering
Entity at the Data Sender (Application Server) needs to perform
metering. All other Metering Entities do not need to perform any
metering since their Metering Data will be discarded anyway.
Therefore, a flexible mechanism is required to distribute this
information to the Metering Entities along the path and to find the
appropriate Metering Entity on the path depending on the charging
scheme.
In the case where a mixed content and access charging should be
applied, not only the content accessed but also the data volume is
relevant for the metering process. In this case, the Metering Entity
at the Data Sender should be configured to account the content
accessed, and one of the other Metering Entities along the path, for
example, Router 1 or Router 2 must be configured to count bytes.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 8]
Internet-Draft M-NSLP Framework July 2005
Furthermore, Metering Records need to be correlated at the Collector
in order to match them to the same session. In current accounting
concepts, data correlation is performed by hardwiring one of Metering
Entities to generate a correlation ID, and by manually configuring a
chain of Metering Entities to which this correlation ID is
distributed. This is very inflexible and leads to unnecessary
overhead.
Using a path-coupled configuration protocol, this correlation ID can
be distributed at the configuration.
When a handover occurs other Metering Entities become involved, for
example the new WLAN access point. Metering Data collected by the
different Metering Entities needs to be correlated and aggregated in
order to avoid the user pays duplicate fees.
Furthermore, Metering Entities need to know to which Collector they
must send their Metering Data. This information can be also be
distribued dynamically during the signaling for configuration.
Configuring Metering Entities dynamically along the path has
potentially also an other advantage. It allows to benefit from the
capabilities of the Metering Entities along the path and not to
restrict the metering tasks to few nodes that are statistically
configured. This will help to avoid scalability problems, where few
Metering Entities might not able to handle the load caused by a large
number of metering tasks.
4.1.2 Required Parameters
In a client/server environment the Application Server (for example, a
video streaming server) acts as signaling initiator. It sends a
CONFIGURE message towards the user terminal. The Metering Entities
along the path evaluates this message.
Given that the user terminal can not be seen as a trusted network
function, the signaling will travel until the last router before the
user terminal which might be, for instance, a WLAN access point.
This router acts as a signaling responder.
The parameters that need to be configured with the CONFIGURE message
are the following:
Correlation ID
This parameter refers to an ID which is unique for each service.
It will be used by the Collector to assign different accounting
records to the same service.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 9]
Internet-Draft M-NSLP Framework July 2005
Flow ID
This parameter identifies the data flow(s) that need(s) to be
accounted. Here, the flow information from the NTLP can be used.
However, several entries SHOULD be possible for this parameter to
enable configuring the Metering Entities to perform accounting for
several flows (for instance audio and video) using a single M-NSLP
message. Note here that multiple entries for the Flow ID are also
possible in both the QoS NSLP and the NAT/FW NSLP. (In the NAT/FW
NSLP, it is the "Number of Ports" in the "Extended Flow
Information Object")
Metered Objects
This parameter contains a list of the objects that need to be
accounted for the considered data flow. Potential objects are:
1. Flow Properties: These are dynamic properties of the data
stream to be metered:
+ number of observed packets of the flow
+ number of observed octets of the flow
+ timestamp of first observation of a packet of the flow.
+ timestamp of last observation of a packet of the flow.
2. Events: service invocation, loss of bearer, insertion of
advertisements and other app events.
Note that in the timestamps, the absolute time might be required
since the tariffs might depend on the time of the day.
Reporting Interval
In order to reduce the number of export messages sent to the
Collector, it is advantageous not to send accounting data
immediately but to wait until the message is filled with a certain
amount of data. This parameter indicates the maximum time to wait
for more data until an exported data set is sent. Long living
flows are reported regularly in interval no longer than specified
by this parameter. When the flow is reported, all counters and
time stamp values are reset.
Flow Expiration Time
If no packets are observed for the specified amount of time
interval, the flow is considered as expired and it is reported.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 10]
Internet-Draft M-NSLP Framework July 2005
Collector ID
This parameter specifies where the accounting records need to be
sent to.
Reporting Protocol
This parameter specifies which protocol to use to report the
accounting data, for example, IPFIX, Netflow5 or Netflow9.
SelectionOfMeteringEntities
This parameter determines how the Metering Entities that should
perform the accounting of the considered data flow are selected.
For the accounting scenario, possible options for this parameter
are:
* ANY: any Metering Entity on the path that is capable of
performing accounting with the requested objects in the
parameter "Metered Objects" should do it. In the extreme case,
this could be the signaling initiator itself.
* Function_X: in some cases, a Metering Entity is required with a
certain function or capability "Function_X".
For the latter case, an abstract language to characterize the type
of Metering Entities can be used. Using this abstract language,
the path-coupled metering configuration protocol can evaluate if
the Metering Entity is of type "Fucntion_X" without knowing what
actually "Function_X" is. Note also, that the abstract language
can be, for example, proprietary.
Such an abstract language is required, for example, in 3G and
beyond networks where the signaling can be used to find a node
with a special function, for example, a SGSSN (Serving GPRS
Support Node), a GGSN (Gateway GPRS Support Node), a RNC (Radio
Network Controller) or the Application Server.
4.2 QoS Monitoring
4.2.1 Scenario Description
For a network user, it may be interesting at any time to check the
QoS for a certain service. The service of interest can be coarse
grained, for example, the QoS parameters provided by the link to the
edge router (access point) or fine grained, for example, the QoS
provided by a UDP data stream received from a video server. In any
case, the first step of analysis that the user can perform is
measuring the rates of sent and received traffics (including a
consideration of re-transmissions).
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 11]
Internet-Draft M-NSLP Framework July 2005
If such cases, local measurement indicates a non-satisfactory
situation. A next step of analysis would be QoS measurement along
the data path of the service of interest. A measurement of packet
bit rate, packet loss, jitter and other QoS parameters at several
points of the data path could identify the cause of unsatisfactory
QoS and locate where it is caused.
A similar, probably more important scenario is an ISP that detects
that the QoS it provides to a customer does not match the service
level agreement for this service. Then a measurement at several
locations along the data path of the service of interest would be
desirable for identifying the cause and location of QoS degradation.
Both cases described above (and a huge range of related cases) could
be solved by massive deployment of metering technology, for example,
by measuring all flows at all routers in the network. Then, in case
of a problem (or of a regular check) the information for a certain
flow of interest can be retrieved from the huge amount of collected
metering data. This approach is oversized, scales badly, and the
benefit gained is most likely not worth the investment and the
operational costs.
Configuring available Metering Entities on the data path appears to
be a more appropriate solution. In such a scenario, the requesting
party would configure some or all available Metering Entities along
the path of a service of interest in order to meter the particular
service and report the metered data.
Such configuration can be performed in a traditional way by
individually, one by one, configuring all Metering Entities. This
requires knowledge about the path taken by the service of interest,
knowledge about the available Metering Entities on this path and a
communication with each of them using an agreed (preferably
standardized) protocol.
The approach suggested by this document simplifies this task. By
using path-coupled configuration of traffic measurement, a requesting
party that is located on the path of interest does just need to send
a single configuration request along the path in order to communicate
with all available Metering Entities on this particular path.
Since different measurements are required for different QoS
parameters, the request sent along the path varies. This is
illustrated by two example scenarios, one for loss metering and one
for delay metering.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 12]
Internet-Draft M-NSLP Framework July 2005
+---------------------------------------------------------+
| |
| Administrative Domain |
| |
| ingress internal internal egress |
| node node 1 node 2 node |
| +-------+ +-------+ +-------+ +-------+ |
| | |<====>| |<====>| |<====>| | |
| | | | | | | | | |
---->| ME |----->| ME |----->| ME |----->| ME |---->
| | | | | | | | | |
| +-------+ +-------+ +-------+ +-------+ |
| |
+---------------------------------------------------------+
+---+
|ME | = Metering === = Signaling --- = Data Flow
+---+ Entity Messages
Figure 3: Signaling to configure metering for QoS monitoring
Figure 3 shows a data stream passing a domain. Let's assume that at
the ingress node a problem with the data stream is detected and that
it wants to initiate traffic measurement for the data stream along
the path it takes through the domain. Then the ingress node sends a
signaling message along the path in order to configure available
Metering Entities.
If packet loss in the domain is the target of this investigation,
then all available Metering Entities on the path will be requested to
participate in the measurement. All will be requested to measure the
number of packets observed for the data stream of interest and to
report the results to either the requesting ingress node or to
another Collector of traffic metering data. Then the collected data
can be analyzed in order to identify locations in the domain where
packet loss occurs.
In a similar way delay can be analyzed. Different to loss metering,
delay measurement require per packet reporting from the Metering
Entities. For each observed packet belonging to the data stream of
interest, the Metering entity needs to report a hash value of the
packet header and a timestamp. In order to reduce the number of
reports, reporting can be restricted to a certain range of hash
values. Then the Collector of metered data can again analyze the
sources of delay within the domain.
If less detailed metering is required, for example, if loss and delay
only needs to be measured for the entire domain, then not all
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 13]
Internet-Draft M-NSLP Framework July 2005
Metering Entities need to participate. For the example it is
sufficient if just the ingress and the egress node perform metering.
Metering at internal nodes is not required. Per-domain packet loss
and per-domain delay can be derived from packet counters and time
stamped packet hash values metered at ingress and egress nodes.
4.2.2 Configuration Parameters
Very similar to the accounting scenario in Section 4.1.2, the
signaling initiator sends a CONFIGURE message along the data path.
The responder returns a RESPONSE message. The parameters that need
to be configured with the CONFIGURE message are the following:
Correlation ID
Similar to the accounting scenario, this is an ID that identifies
this measurement. It can be used by the Collector for identifying
incoming reports that belong to the same measurement.
Flow ID
Same as for the accounting scenario
Metered Objects
The objects to be measured:
1. Flow Properties: same as for the accounting scenario.
2. Packet Properties:
+ hash value
+ number of octets
+ time stamp
Reporting Interval
Same as for the accounting scenario
Flow Expiration Time
Same as for the accounting scenario
Collector ID
Same as for the accounting scenario
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 14]
Internet-Draft M-NSLP Framework July 2005
Reporting Protocol
Same as for the accounting scenario
SelectionOfMeteringEntities
This parameter specifies the requirement for Metering Entities
along the data path. Among the required values for this parameter
are
* first: only the first available Metering Entity on the path is
requested to perform metering. In the extreme case, this
request is served by the signaling initiator itself.
* last: only the last available Metering Entity on the path is
requested to perform metering. In the extreme case, this
request is served by the signaling responder.
* all: all available Metering Entities on the path are requested
to perform metering.
* first and last: only the first and the last available Metering
Entities on the path are requested to perform metering.
4.3 Monitoring for Network Security
4.3.1 Scenario Description
Basically, the prevention of various threats in the Internet is based
on the detection of an ongoing malicious activity and the
configuration of appropriate firewall rules. In order to limit the
load of all involved systems, i.e. monitoring probes, intrusion
detection systems (IDS) and firewalls, only active attacks should be
blocked. Therefore, distributed monitoring is required scanning for
particular malicious flows. In case of IP address spoofing, IP
traceback mechanisms are employed to locate the source of such flows.
Based on well-known flow information, appropriate monitoring entities
should be identified and configured. A path-coupled signaling
protocol for configuring the metering entities seems adequate for
this task.
Most network security mechanisms such as intrusion detection are
based on the capability to monitor the network behavior. Network
monitoring involves:
o statistics, i.e. collection of statistical measures, such as
packet rate, bit rate, number of connections, etc.
o packet sampling, i.e. collection of complete packets based on
rules (filters) and sampling algorithms
The gathered information about the network traffic can be used for an
analysis of packet's payload for known attack/intrusion patterns as
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 15]
Internet-Draft M-NSLP Framework July 2005
well as for anomaly detection mechanisms.
It is desirable that monitoring devices can be re-configured
dynamically, depending on the state of the network to know more about
a specific data flow when an attack is being assumed. Note here,
that the attack might be of a different nature, for example, SYN
flood or ICMP flood.
Figure 4 depicts such as scenario. A potential victim or a network
intrusion detection system (NIDS) sends a notification to an attack
detection system that an attack is assumed (this can be triggered at
the victim or at the NIDS by internal means). The attack detection
system instructs the ingress points of the network to perform
metering for the traffic designated to the victim and initiate
signaling towards the victim for metering configuration. The ingress
point can be either identified directly by using attack pattern or
indirectly using IP traceback mechanisms.
+-----------------------------------------------------------+
| |
| Administrative Domain A |
| |
| +----------------------------+ |
| | Attack Detection System | |
| +----------------------------+ |
| ^ ^ ^ ^ |
| ** * * # |
| ** * * # |
| ** * * # |
| ** * * # |
| Ingress Node A probe 1 probe 2 |
| +-----------+ +----+ +----+ +-----------+ |
| | |=====>| |=====>| |=====>| | |
| | | | | | | | | |
---->| ME |----->| ME |----->| ME |----->| victim |---->
| | | | | | | | | |
| +-----------+ +----+ +----+ +-----------+ |
| |
+-----------------------------------------------------------+
+---+
|ME |= Metering === = Meter. Configuration --- = Data Flow
+---+ Entity Signaling Messages ## other protocol
Figure 4: Signaling to configure metering for attack detection
In the figure above, the Metering Entities along the data path from
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 16]
Internet-Draft M-NSLP Framework July 2005
the ingress point A to the victim can be configured to meter/monitor
the packets belonging to a particular data flow. Metering Data is
transferred to the according attack detection system for further
analysis.
4.3.2 Required Parameters
Very similar to the accounting scenario in Section 4.1.2, the
signaling initiator sends a CONFIGURE message along the data path.
The responder returns a RESPONSE message. The parameters that need
to be configured with the CONFIGURE message are the following:
Correlation ID
Similar to the accounting scenario, this is an ID that identifies
this measurement. It can be used by the Collector for identifying
incoming reports that belong to the same measurement.
Flow ID
Same as for the accounting scenario
Metered Objects
The objects to be measured:
1. Flow Properties: same as for the accounting scenario.
2. Packet Properties:
+ header information
+ parts of the packet
+ complete packets
Reporting Interval
Same as for the accounting scenario
Flow Expiration Time
Same as for the accounting scenario
Collector ID
Same as for the accounting scenario
Reporting Protocol
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 17]
Internet-Draft M-NSLP Framework July 2005
Same as for the accounting scenario in case of requested flow
statistics or PSAMP for reporting complete per packet information.
SelectionOfMeteringEntities
This parameter specifies the requirement for Metering Entities
along the data path. Among the required values for this parameter
are
* first: only the first available Metering Entity on the path is
requested to perform metering. In the extreme case, this
request is served by the signaling initiator itself.
* last: only the last available Metering Entity on the path is
requested to perform metering. In the extreme case, this
request is served by the signaling responder.
* all: all available Metering Entities on the path are requested
to perform metering.
* first and last: only the first and the last available Metering
Entities on the path are requested to perform metering.
* optimum: selection of an optimal fitting Metering Entity based
on current load, location, amount of Metering Data
5. Requirements
This section describes the requirements for a path-coupled signaling
for the configuration of Metering Entities. We assume existing
protocols or other means for transferring
1. captured packet information from the Monitoring Probes to the
Metering Entities and
2. Metering Data from the Metering Entities to Collectors.
Note that the Monitoring Probes and the Metering Entities are co-
located.
5.1 General requirements
5.1.1 Extensibility
The specification of the metering configuration protocol should be
extensible to future technologies. This includes the extensibility
of the configuration of the Metering Entities.
Extensibility is also required concerning the information model.
This relates to the parameter exchange between the Metering Entities.
Moreover, the metering configuration protocol should bridge between
different existing metering solutions, for example, those defined in
3GPP. The communication may be organized using proxy or agent based
systems.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 18]
Internet-Draft M-NSLP Framework July 2005
5.1.2 Scalability
A Metering Entity needs to keep state and perform metering actions
for each accepted metering task. Handling high numbers of metering
tasks need to be provided by the Metering Entity implementation and
is not subject of a signaling protocol. However, the protocol design
should provide scalability for state keeping and refresh for a large
number of concurrent metering tasks.
5.1.3 Security
The process of configuring an Internet-wide metering system is a
sensitive task. Therefore, arrangements should be taken to secure
this process. Signaling messages might cross domain boundaries which
raises authorization concerns. Administrators of other domains might
not be willing to allow data traffic to be sent and redirected to a
Collector outside the domain. This might severely impact the users
trust perception about the attached domain.
Furthermore, a domain might not want to allow entities from other
domains to control network entities with respect to metering. The
currently deployed charging in the Internet is based on the
relationship between neighboring domains making end user charging for
data traffic (or services) by non-neighboring domains impossible.
The advantage of this model makes allows each domain to control its
pricing and charging policy.
This document does not aim to change the existing Internet charging
model in any way.
5.2 Flexible metering model
The metering configuration protocol should support a flexible
metering model. Depending on the metering scenario, different
information must be exchanged between the Metering Entities.
5.3 Distinguishing flows
A primary capability of the metering function is the identification
of data packets belonging to different applications or users. The
configuration of the Metering Entities should take this parameter
into account. During the data flow life-time, statistics describing
the properties of this data flow are gathered and exported to a
Collector. The metering configuration should be flexible to allow
the description of multiple services and associated flows.
Flows belonging to one application: the metering configuration should
allow the aggregation of Metering Records for streams belonging to a
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 19]
Internet-Draft M-NSLP Framework July 2005
particular application, for example, a multimedia transmission with
associated data transfers (web pages).
Flows belonging to one user: the accounting configuration should
allow the aggregation of Metering Data for all streams belonging to
an individual user regardless of the used applications.
5.4 Flexible data collection
After the gathering of Metering Data, it has to be transferred to the
appropriate Collector(s). The protocol for configuring Metering
Entities MUST be independent of the protocol used for transferring
Metering Data. One possible protocol is IPFIX [I-D.ietf-ipfix-
protocol]. The IPFIX information model ([I-D.ietf-ipfix-info]) is
very flexible for extensions and, therefore, adequate for this
application.
5.5 Location of Metering Entities
The Metering Entities are located on the data path, i.e., on the path
of the data that should be metered. It is an open problem how the
initiator and receiver of the metering configuration signaling are
determined.
Metering Entities can be located anywhere along the data path, for
example, only in a subset of the path, or only at start and end point
etc.
5.6 Location of the Collectors
The Metering Data need to be transferred to one or eventually several
Collectors. The process of discovering which Collector is interested
in which Metering Data is out of scope. It is assumed that the
signaling initiator knows the location of the Collectors by different
means.
In case a Collector itself is located on the data path it SHOULD use
the metering configuration protocol to inform all involved Metering
Entities about its location.
A Collector MAY be changed during the metering process. The handover
process will be not handled. The identification of the new Collector
SHOULD be done using the same mechanisms as for the first
identification.
5.7 Configuration protocol
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 20]
Internet-Draft M-NSLP Framework July 2005
5.7.1 Configuration of Metering Entities
The protocol MUST be able to configure Metering Entities, for
example, to control which information needs to be collected and which
entities are allocated which task.
Protocol messages need to be interpreted only by Metering Entities.
5.7.2 Selection of Metering Entities
The protocol MUST provide functionality to select Metering Entities
that become part of a metering process by specifying, for example,
their type, position or total number.
5.7.3 Metering Configuration State installation and removal
The protocol MUST be able to install metering state and also to
remove it. Furthermore, metering state SHOULD be soft state in order
to cope with rerouting and device failure.
5.7.4 Initiation and maintenance of metering tasks
The protocol MAY be able to transport a trigger to start and stop of
collection of Metering Data, a correlation identifier that allows the
Collector to correlate Metering Data received from different Metering
Entities, and a trigger to send off Metering Data to the Collector.
5.7.5 Reaction to Route Changes
The protocol MUST be able to react to rerouting of the packets that
are to be metered. Rerouting may imply including new Metering
Entities and removing some. This requirement is important especially
for the accounting scenario: if routes change unnoticed the user will
use the service for free.
5.7.6 Collection of information on available Metering Entities
The protocol SHOULD be able to collect information on Metering
Entities and their capabilities without actually installing any
state. This feature SHOULD at least be available for Metering
Entities that are involved in performing a requested metering task.
5.7.7 Scoping of configuration
The protocol SHOULD be able to scope messages. For example, the
scope could be the domain of an operator. Another important type of
scope is up to a particular type of Metering Entity. An example is a
scope that terminates a signaling message originating in the core of
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 21]
Internet-Draft M-NSLP Framework July 2005
the network at the access router in order to both save resources on
the air interface and to hide monitoring or charging configuration
data from the user. Another example is scoping the signaling, for
example, to the responsible UMTS GGSN (Gateway GPRS Support Node: a
router that serves as a gateway between mobile networks and packet
data networks) because it is known that Metering Entities beyond the
GGSN are of no interest for this particular metering configuration.
5.8 Metering across domains
Metering configuration SHOULD be possible across administrative
domains. There are challenging security aspects in this goal.
6. Applicability of the NSIS Architecture
According to the NSIS framework [I-D.ietf-nsis-fw], the NSIS protocol
suite can support various signaling applications that need to install
or manipulate state in NSIS-aware network nodes (NEs) along the path
of a data flow. The NSLP messages do not need to run all the way
between the data flow endpoints. Rather, the NSIS initiating NE and
the NSIS receiving NE can be located anywhere along the data path.
The problem of path-coupled signaling to configure Metering Entities
seems to be well suited to be solved with a novel NSIS signaling
application, the Metering NSLP. The Metering NSLP can run on top of
the NTLP similarly to the QoS NSLP [I-D.ietf-nsis-qos-nslp] and the
NAT/Firewall NSLP [I-D.ietf-nsis-nslp-natfw]
The Metering NSLP needs to be able to install, modify and remove
metering configuration related state. Furthermore, signaling for
metering configuration needs the flexibility provided by NSIS to
start and end on arbitrary Metering Entities. Any Metering Entity on
the data path is able to initiate metering configuration signaling.
The selection of signaling initiator and receiver depends on the
configuration and on the specific application environment.
A Metering NSLP, similar to QoS NSLP, would be independent of the
actual configuration information it carries. Hence, it can be used
for any metering application. Finally, the semantic of some of the
QoS NSLP messages can be reused in the Metering NSLP (RESERVE (i.e.
CONFIGURE), RESPONSE, QUERY and NOTIFY).
Possible inter-working between the Metering NSLP and the QoS NSLP
needs to be investigated. In some cases it seems to make sense that
a reservation of resources via the QoS NSLP would trigger the
configuration and initiation of metering for usage of these
resources. Furthermore, accounting can be terminated as soon as the
QoS reservation is torn down.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 22]
Internet-Draft M-NSLP Framework July 2005
7. Security Considerations
The process of configuring entities to start and stop metering and to
transmit collected Metering Data to a third party introduces security
challenges.
For example, in the accounting scenario if a malicious user is able
to stop metering of requested services then fraud is possible. It
must be not possible to configure Metering Entities in such a way
that other users are charged for the usage of a service which they
have not used.
Second, if the scope of the configuration signaling should go beyond
the borders of a single domains, the ISPs need to be authorized to
perform M-NSLP signaling across other domains and to collect metering
and monitoring data. A high degree of trust is required. Customer
privacy comes into question. Service Provides have also their
privacy, since the Metering Records will reveal their network
topology and will provide statistics about their traffic.
Moreover, the introduced mechanisms allow a number of entities to
configure Metering Entities. This might introduce some weaknesses
compared to a centralized approach where a single entity (or a few
selected entities) are authorized to perform this action. The
authorization configuration of a decentralized approach is more
difficult to secure since a single malicious entity is able to start/
stop/modify the process of Metering Record collection within a single
domain or even beyond this domain.
8. Contributors
This document is the result of the effort of a Metering NSLP team
that has been built. Except the individuals listed in the author
list, the team includes also Juergen Quittek and Hannes Tschofenig.
Furthermore, the authors would like to thank Ralph Kuehne for his
input on the description of the accounting scenario.
9. References
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.dressler-nsis-metering-nslp]
Dressler, F., "NSLP for Metering Configuration Signaling",
draft-dressler-nsis-metering-nslp-01 (work in progress),
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 23]
Internet-Draft M-NSLP Framework July 2005
February 2005.
[I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06
(work in progress), May 2005.
[I-D.ietf-ipfix-protocol]
Claise, B., "IPFIX Protocol Specification",
draft-ietf-ipfix-protocol-17 (work in progress),
July 2005.
9.2 Informative References
[RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S.
Willens, "Remote Authentication Dial In User Service
(RADIUS)", RFC 2138, April 1997.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)",
RFC 3917, October 2004.
[I-D.ietf-ipfix-info]
Quittek, J., "Information Model for IP Flow Information
Export", draft-ietf-ipfix-info-09 (work in progress),
July 2005.
[I-D.ietf-nsis-fw]
Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-07 (work in progress), December 2004.
[I-D.ietf-nsis-qos-nslp]
Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-06
(work in progress), February 2005.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in
progress), May 2005.
[I-D.ietf-psamp-framework]
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 24]
Internet-Draft M-NSLP Framework July 2005
Duffield, N., "A Framework for Packet Selection and
Reporting", draft-ietf-psamp-framework-10 (work in
progress), January 2005.
[I-D.ietf-psamp-mib]
Dietz, T., "Definitions of Managed Objects for Packet
Sampling", draft-ietf-psamp-mib-04 (work in progress),
February 2005.
[3GPP.32.240]
3GPP, "Telecommunication management; Charging management;
Charging architecture and principles", 3GPP TS 32.240
6.0.0, September 2004.
Authors' Addresses
Ali Fessi
University of Tuebingen
Wilhelm-Schickard-Institute for Computer Science
Auf der Morgenstelle 10C
Tuebingen 71076
Germany
Phone: +49 7071 29-70534
Email: fessi@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/
Cornelia Kappler
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Phone: +49 30 386-32894
Email: cornelia.kappler@siemens.com
Changpeng Fan
Siemens AG
Siemensdamm 62
Berlin 13627
Germany
Phone: +49 30 386-36361
Email: changpeng.fan@siemens.com
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 25]
Internet-Draft M-NSLP Framework July 2005
Falko Dressler
University of Erlangen
Department of Computer Science 7
Martensstr. 3
Erlangen 91058
Germany
Phone: +49 9131 85-27914
Email: dressler@informatik.uni-erlangen.de
URI: http://www7.informatik.uni-erlangen.de/
Andreas Klenk
University of Tuebingen
Wilhelm-Schickard-Institute for Computer Science
Auf der Morgenstelle 10C
Tuebingen 71076
Germany
Phone: +49 7071 29-70535
Email: klenk@informatik.uni-tuebingen.de
URI: http://net.informatik.uni-tuebingen.de/
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 26]
Internet-Draft M-NSLP Framework July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Fessi, et al. draft-fessi-nsis-m-nslp-framework-01.txt [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-23 20:04:24 |