One document matched: draft-ietf-midcom-requirements-00.txt
MIDCOM Working Group R P Swale
Internet Draft BTexaCT
Document: draft-ietf-midcom-requirements-00.txt P A Mart
Category: draft Marconi Communications
P Sijben
Lucent Technologies
Feb 2001
Requirements for the MIDCOM architecture and control language
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This document presents the requirements for the MIDCOM Architecture
and the associated control language.
Swale, Mart, Sijben Expires August 2001 1
MIDCOM Requirements February 2001
Table of Contents
1. Conventions used in this document...........................2
2. Definitions.................................................2
3. Requirements for the MIDCOM architecture....................2
3.1 MIDCOM Client...........................................4
3.2 MIDCOM Server...........................................4
3.3 MIDCOM Controller (MC)..................................5
3.4 MIDCOM Packet Processor (MPP)...........................5
3.5 MIDCOM Policy Server (MPS)..............................6
4. General Requirements for the MIDCOM Control Language........6
4.1 MIDCOM Control Protocol Requirements....................6
4.2 MIDCOM Authentication Protocol Requirements.............8
4.2.1 MIDCOM Client Authentication Protocol Requirements.8
4.2.2 MIDCOM Authentication Server Protocol Requirements.8
4.3 MIDCOM Policy Protocol Requirements.....................8
5. Performance Requirements for the MIDCOM Architecture........9
6. MIDCOM Control Language Actions and Attributes..............9
6.1 MIDCOM Control Action and Attribute Requirements........9
6.2 MIDCOM Authentication Action and Attribute Requirements.9
6.2.1 MIDCOM Client Authentication Action and Attribute
Requirements.............................................9
6.2.2 MIDCOM Authentication Server Action and Attribute
Requirements.............................................9
6.3 MIDCOM Policy Action and Attribute Requirements.........9
7. Security Considerations....................................11
8. References.................................................11
9. Acknowledgements...........................................12
10. Author's Addresses........................................12
1. Conventions used in this document
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 RFC-2119 [2].
2. Definitions
Flow a sequence of IP packets communicated from one host
and port to another host and port.
3. Requirements for the MIDCOM architecture
The MIDCOM architecture 8 elements are identified within the MIDCOM
environment:
application client: An application client is a function resident on
a host that represents the user of an application. It MAY require
Swale, Mart, Sijben Expires August 2001 2
MIDCOM Requirements February 2001
packet processing services to reach an application server where
middleboxes are deployed in the network path.
application server: An application server is a function resident on
a host that provides application functionality. It MAY require
packet processing services to reach an application client where
middleboxes are deployed in the network path.
MIDCOM Client: A MIDCOM Client is an entity that uses the MIDCOM
protocol to request operations on a MIDCOM Packet Processor to
enable specified end to end flows between application clients
and/or servers.
MIDCOM Server: A MIDCOM Server terminates requests for the use of
MIDCOM Packet Processing resources from a MIDCOM Client.
MIDCOM Agent (MA): A MIDCOM Agent is a server or stateful proxy
that controls a MIDCOM Packet Processor to enable specified end to
end flows between application clients and/or servers. A MIDCOM
Agent SHALL be a trusted client for the MIDCOM protocol. A MIDCOM
Agent MAY be either a MIDCOM Controller or a MIDCOM Application
Gateway, depending upon its role.
MIDCOM Controller (MC): A MIDCOM Controller establishes trust and
authorise requests for packet processing services. A MIDCOM
Controller comprises a MIDCOM Client, a MIDCOM Server and an
Authorisation function.
MIDCOM Application Gateway (MAG): A MIDCOM Application Gateway is a
trusted MIDCOM Client that requests packet processing services from
a MIDCOM Packet Processor in accordance with the needs of the
application it supports.
MIDCOM Packet Processor (MPP): A MIDCOM Packet Processor is the
kind of middlebox in the scope of MIDCOM. It forwards packets and
manipulates the headers of IP packets as directed by a MIDCOM
client.
Swale, Mart, Sijben Expires August 2001 3
MIDCOM Requirements February 2001
Figure 1 shows how the various elements of the MIDCOM achitecture
relate.
+------------------------------------------+
Policy description | +----------+ +------------------+ |
Language \| | | | | |
--------------------X | Policy \ / authentication | |
/| | |\ /| server | |
| +----------+ \ / +------------------+ |
+---------------\++/-----------------------+
||
||
+-------------+ +-------------------++---------------+ +-----------+
|+----------+ | |MIDCOM Controller || | |middlebox |
|| | | |+-------+ +-------++----+ +------+ | |+-------+ |
||client +-+-++server +--+authorisation+-+client+-+-++server | |
|| | | || | |function | | | | || | |
|+----------+ | |+-------+ +-+--------+--+ +------+ | |+-------+ |
| | | | | | | |
|+-----------+| | | | | | |
||credentials|| |+------------+--+ +--+----------+ | |+--------+ |
|| ++-++client | | credentials|--+-++client | |
|+-----------+| ||authentication | | | | ||authen- | |
| | |+---------------+ +-------------+ | ||tication| |
| | | | |+--------+ |
|+-----------+| +------------------------------------+ | |
|| || |+---------+|
||application++----------------------------------------++Packet ||
|+-----------+| ||Processor||
+-------------+ |+---------+|
+-----------+
Figure 1. Relationships between MIDCOM functions.
The remainder of this section declares requirements on each of the
elements in the architecture.
3.1 MIDCOM Client
A MIDCOM Client SHALL have either a Trusted or an Un-trusted
relationship with a MIDCOM Agent.
3.2 MIDCOM Server
A MIDCOM Server SHALL establish an appropriate level of trust with
any MIDCOM Clients with which it communicates. This MAY include
communication with un-trusted MIDCOM Clients if desired.
Where no trust relationship is maintained between a MIDCOM Client
and Server, each request received by the MIDCOM Server SHALL be
Swale, Mart, Sijben Expires August 2001 4
MIDCOM Requirements February 2001
authorised, including any necessary authentication, before the
MIDCOM Server takes any action on the request.
3.3 MIDCOM Controller (MC)
A MIDCOM Controller SHALL establish trust and authorise requests
for packet processing services. A MIDCOM Controller comprises a
MIDCOM Client, a MIDCOM Server and an Authorisation function.
Based upon the established identity of the requesting MIDCOM
Client, the Authorisation function SHALL authorise the request
based upon either local policies or policies from the MIDCOM Policy
Server.
Where no trust relationship is maintained between a MIDCOM Client
and MIDCOM Controller, each request received by the MIDCOM
Controller SHALL be authorised, including any necessary
authentication, before the MIDCOM Controller takes any action on
the request.
3.4 MIDCOM Packet Processor (MPP)
A MIDCOM Packet Processor is a kind of middlebox within the scope
of MIDCOM. It forwards packets and manipulates the headers of IP
packets as directed by a MIDCOM client.
The MPP SHALL NOT alter packet information unless they appear in
the packet header information
Other than the communication of control information between the
controlled MIDCOM Packet Processor device and the MIDCOM Controller
no packets will be allowed to flow across the MIDCOM Packet
Processor without prior instructions from the controller. i.e. the
default operation is that "no packets will be allowed".
On receipt of a request to allow a flow with a particular flow
specification the MIDCOM Packet Processor shall indicate whether or
not available resources allow the flow to be carried.
The MPP MAY report the observed behaviour of a nominated flow.
The MPP SHALL report or otherwise make information available to the
associated MIDCOM Client when a granted flow contravenes the
parameters agreed. The MPP SHALL not permit the flow of any packets
contravening a prior agreement.
The MIDCOM Packet Processor MAY provide QoS transport facilities
for the packet flows. For example setting of DS-bytes, MPLS
mappings
Swale, Mart, Sijben Expires August 2001 5
MIDCOM Requirements February 2001
The MIDCOM Packet Processor acts as a MIDCOM Server and SHALL only
accept requests from MIDCOM Clients with which it has a trust
relationship.
The MIDCOM Packet Processor shall support multiple simultaneous
MIDCOM clients. Each controller may be acting on behalf of one or
more applications. No relationship between controllers MAY be
assumed by the MIDCOM Packet Processor.
The MIDCOM Packet Processor shall support the forwarding of
signalling received to one, or more, appropriate destination
address/port combinations to the appropriate controllers, e.g. a
MIDCOM Application Gateway.
3.5 MIDCOM Policy Server (MPS)
The MIDCOM architecture SHALL include a policy function. Its
purpose SHALL be to determine the flows that MAY be supported
across one or more MIDCOM Packet Processors.
3.6 Distribution of MIDCOM elements
It SHALL be possible for the functional components within the
MIDCOM framework to be distributed.
4. General Requirements for the MIDCOM Control Language
4.1 MIDCOM Control Protocol Requirements
The MIDCOM Control Language SHALL be used between MIDCOM Clients
and MIDCOM Servers.
The MIDCOM Control Language SHALL describe the desired behaviour of
the MIDCOM Packet Processor for the purposes of a requested
flow(s).
The syntax and semantics of the MIDCOM Control Language SHALL be
independent of the application(s)requesting packet processing
services.
The syntax and semantics of the MIDCOM Control Language SHALL be
extensible.
Swale, Mart, Sijben Expires August 2001 6
MIDCOM Requirements February 2001
The protocol SHALL support time-constrained operation. This may
include, amongst other things, the use of short messages and
minimal messages per operation.
The protocol SHALL NOT assume 0 (zero) delay in communication
paths.
The protocol SHALL be capable of being used over low speed links.
The protocol SHALL provide per message acknowledgements, in order
to achieve reliable communication.
The protocol SHALL support unsolicited messages, for event
reporting and alarms.
The protocol SHALL permit the synchronisation of state machines
between peer entities by adding state information to messages in
normal operations or by the use of explicit query messages.
An operation SHALL be needed to permit a flow, with a given flow
specification and address translation, across the MIDCOM Packet
Processor. It shall be possible to indicate whether packets should
be carried or discarded when a given flow specification is
exceeded.
An operation SHALL be needed to stop a flow across the MIDCOM
Packet Processor.
The protocol SHALL include the association of a "Packet modifier"
to describe the required re- writing of header fields of accepted
packets. The "Packet modifier" MUST be able to change the following
protocol header fields
IPv4: IP addresses, TOS field
IPv6: IP addresses, traffic class field, flow label
UDP: port numbers
TCP: port numbers
Note that if modifiers are used then packet checksums MUST be
recalculated.
The protocol SHALL allow for the capability to carry attributes
from other protocols the MPP MAY support for the use by the MPP.
The protocol SHALL include failure reasons that allow the client
behaviour to be modified as a result of the information contained
in the reason. Failure reasons SHOULD be chosen such that they do
not make an attack on security easier.
Swale, Mart, Sijben Expires August 2001 7
MIDCOM Requirements February 2001
The protocol SHALL contain version inter-working capabilities. If a
peer does not understand an option it must be clear whether the
action required is to proceed without the unknown attribute being
taken into account or the request is to be rejected. Where
attributes MAY be ignored if not understood, a means MAY be
provided to inform the client about what has been ignored. This MAY
be provided as a version and capability exchange mechanism.
4.2 MIDCOM Authentication Protocol Requirements
4.2.1 MIDCOM Client Authentication Protocol Requirements
The MIDCOM Client Authentication Protocol SHALL be used between
MIDCOM Controllers and MIDCOM Clients.
The MIDCOM Client Authentication Protocol SHALL describe the
desired behaviour of the MIDCOM Packet Processor for the purposes
of a requested flow(s).
The syntax and semantics of the MIDCOM Client Authentication
Protocol SHALL be independent of the application(s)requesting
packet processing services.
The syntax and semantics of the MIDCOM Client Authentication
Protocol SHALL be extensible.
4.2.2 MIDCOM Authentication Server Protocol Requirements
The MIDCOM Authentication Server Protocol SHALL be used between
MIDCOM Controllers and MIDCOM Authentication Servers.
The MIDCOM Authentication Server Protocol SHALL describe the
desired behaviour of the MIDCOM Packet Processor for the purposes
of a requested flow(s).
The syntax and semantics of the MIDCOM Authentication Server
Protocol SHALL be independent of the application(s)requesting
packet processing services.
The syntax and semantics of the MIDCOM Authentication Server
Protocol SHALL be extensible.
4.3 MIDCOM Policy Protocol Requirements
The MIDCOM Policy Protocol SHALL be used between MIDCOM Agents and
MIDCOM Policy Servers.
The MIDCOM Policy Protocol SHALL describe the desired behaviour of
the MIDCOM Agent for the purposes authorising requested flow(s).
Swale, Mart, Sijben Expires August 2001 8
MIDCOM Requirements February 2001
The syntax and semantics of the MIDCOM Policy Protocol SHALL be
independent of the application(s)requesting packet processing
services.
The syntax and semantics of the MIDCOM Policy Protocol SHALL be
extensible.
5. Performance Requirements for the MIDCOM Architecture
To be done.....
6. MIDCOM Control Language Actions and Attributes
The following sub-sections present requirements that guide the
choice of MIDCOM Protocol(s).
To be done.....
6.1 MIDCOM Control Action and Attribute Requirements
To be done.....
6.2 MIDCOM Authentication Action and Attribute Requirements
To be done.....
6.2.1 MIDCOM Client Authentication Action and Attribute
Requirements
To be done.....
6.2.2 MIDCOM Authentication Server Action and Attribute
Requirements
To be done.....
6.3 MIDCOM Policy Action and Attribute Requirements
To avoid accumulation of stale rules, in case of controller
failures, rules MUST have an associated timer, which may be
set using the MIDCOM Policy Protocol. If a timer value is not
set a default value shall be used. The default value MUST be
the same for all systems that are capable of direct
interaction.
Swale, Mart, Sijben Expires August 2001 9
MIDCOM Requirements February 2001
The timer associated with a rule SHALL be reset on request
from the requesting client that established the rule.
The policies communicated SHALL permit rules to be specified
in terms of:
For IPv4: source and destination IP address or group
of them determined by a netmask, protocol
number, TOS field
IPv6: source and destination IP address or group
of them determined by a netmask, next
header fields (Note that multiple fields
may need to be traversed until a match is
found.), traffic class field
UDP: source and destination port numbers or
group of them
TCP: source and destination port numbers or
group of them, "SYN packets" permission
ICMP: type and code
IGMP: type
The protocol SHALL permit the expression of direction to be
associated with a rule. The direction SHALL be specified in
terms that apply to the client's view of the packet processor.
This directionality SHALL be expressed as "in", "out" or
"Loopback" (meaning both "in" and "out" of the same side of
the same controlled packet processor).
The protocol SHALL provide an ability to indicate desired
rule-processing precedence to enable controlled devices to
resolve conflicts between multiple applicable matching rules
in a predictable manner.
Default precedence SHALL be assigned by the MIDCOM Policy
Server when no precedence is specified for a rule. Multiple
rules MAY share a single precedence.
The protocol SHALL permit specification of an "Action" for a
rule. "Action" takes the values 'pass packets', 'drop packets
with or without ICMP notification'.
The protocol SHALL include the association of a "Packet
modifier" with a rule to describe the required re- writing of
header fields of accepted packets. The "Packet modifier" MUST
be able to change the following protocol header fields
Swale, Mart, Sijben Expires August 2001 10
MIDCOM Requirements February 2001
IPv4: IP addresses, TOS field
IPv6: IP addresses, traffic class field
UDP: port numbers
TCP: port numbers
Note that if modifiers are used packet checksums MUST be
recalculated.
7. Security Considerations
The MIDCOM architecture MUST enable a trust relationship to be
established between a client and a MIDCOM Controller or middlebox
for the purposes of permitting flows between the client and other
hosts that flow via a MIDCOM Packet Processor.
In the trusted case, the trust is derived from some aspect of the
session in which the trusted party is involved, for example the
security association. In the untrusted case, trust is derived from
the presentation and authentication of credentials that are offered
for each request.
Peers using this protocol must be authenticated in order for
message exchange to proceed.
Trust relationships within the MIDCOM architecture SHALL be
explicitly established. Automatic discovery mechanisms shall not be
permitted other than between mutually authenticated peers. This in
order to prevent hacking into the MIDCOM Packet Processor by
impersonating a controller.
The MIDCOM protocols SHALL permit strong encryption to be used to
protect the privacy on requests and responses.
The MIDCOM protocols must allow for strong encryption to be used to
protect the trustworthiness of the requests and responses. This in
order to prevent hacking into the MIDCOM Packet Processor by
intercepting communication.
8. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Swale, Mart, Sijben Expires August 2001 11
MIDCOM Requirements February 2001
9. Acknowledgements
Jiri Kuthan
Jonathan Rosenberg
Andrew Molitor
Pyda Srisuresh
10. Author's Addresses
Philip Mart Paul Sijben Richard Swale
Marconi Communications Lucent Technologies BTexaCT
Ltd. EMEA BV Adastral Park
Edge Lane Huizen Ipswich
Liverpool Netherlands United Kingdom
United Kingdom Email: Email:
Email: sijben@lucent.com richard.swale@bt.com
philip.mart@marconi.com
Swale, Mart, Sijben Expires August 2001 12
| PAFTECH AB 2003-2026 | 2026-04-24 04:55:17 |