One document matched: draft-riverstone-lfap-01.txt
Differences from draft-riverstone-lfap-00.txt
INTERNET-DRAFT Expires: December 2002 INTERNET-DRAFT
Network Working Group P. Calato
Request for Comments: M. MacFaden
Category: Informational Riverstone Networks Inc
Obsoletes: RFC 2124 June 2002
Category: Informational
Light-weight Flow Accounting Protocol Specification
Version 5.0
<draft-riverstone-lfap-01.txt>
Status of this Memo
This document is an Internet-Draft and is subject to
all provisions of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The Lightweight Flow Accounting Protocol (LFAP) is an operations
and management protocol that provides detailed information about
IPv4 and Ipv6 packets traversing a network element. The primary
function of LFAP is the reliable delivery of large volumes of
packet header derived information from a network element, termed
Connection Control Entity (CCE) to a Flow Accounting Server (FAS)
of current or historical flows for billing, capacity planning
security, or traffic engineering purposes.
Calato, MacFaden Informational [Page 1]
INTERNET-DRAFT LFAP V5.0 June 2002
Table of Contents
1. INTRODUCTION ......................................................4
2. SUMMARY OF OPERATION .............................................5
3. MESSAGE FORMAT ....................................................7
4. INFORMATION ELEMENTS (IE'S) FORMATS ...............................8
4.1 FAS IP ADDRESS IE ..............................................8
4.2 MULTIPLE RECORD IE .............................................9
5. INDIVIDUAL MESSAGE CONTENTS .......................................9
5.1 VERSION REQUEST (VR) MESSAGE ...................................9
5.2 VERSION REQUEST ACKNOWLEDGE (VRA) MESSAGE .....................10
5.3 CONNECTION REQUEST (CR) MESSAGE ...............................10
5.4 CONNECTION ACCEPTED NOTIFICATION (CAN) MESSAGE ................11
5.5 CONNECTION REJECTED NOTIFICATION (CRN) MESSAGE ................11
5.6 FLOW EXPORT READY (FER) MESSAGE ...............................11
5.7 FLOW ACCOUNTING REQUEST (FAR) MESSAGE .........................11
5.8 FLOW UPDATE NOTIFICATION (FUN) MESSAGE ........................12
5.9 ADMINISTRATIVE REQUEST (AR) MESSAGE ...........................12
5.10 ADMINISTRATIVE REQUEST ACKNOWLEDGE (ARA) MESSAGE .............12
5.11 KEEP ALIVE (KA) MESSAGE ......................................12
5.12 DISCONNECT REQUEST (DR) MESSAGE ..............................12
5.13 MESSAGE ID ERROR .............................................13
6. SESSION ESTABLISHMENT ............................................13
6.1 PROTOCOL NEGOTIATION ..........................................13
6.2 CONNECTION ESTABLISHMENT ......................................14
6.3 DATA NEGOTIATION ..............................................14
6.4 STATE DIAGRAMS ................................................14
6.5 PROTOCOL ERRORS ...............................................19
7. ERROR HANDLING ...................................................19
7.1 VRA RELATED ERROR HANDLING ....................................19
7.2 ARA RELATED ERROR HANDLING ....................................19
8. STATISTICS .......................................................19
8.1 COMMON STATISTICS .............................................20
8.2 CCE STATISTICS ................................................21
8.3 FAS STATISTICS ................................................22
9. SECURITY CONSIDERATIONS ..........................................22
9.1 LOWER LAYER SECURITY ..........................................23
9.2 LFAP SECURITY .................................................23
9.2.1. Extended LFAP Header ......................................23
9.2.2. Extended Header ID Exchange ...............................24
9.2.3. Level I Security ..........................................25
9.2.4. Level II Security .........................................25
9.2.5. Level III Security ........................................26
9.2.6. Level IV Security .........................................26
9.2.7. Security Configuration ....................................26
9.3 DENIAL OF SERVICE .............................................26
9.4 MESSAGE LOSS ..................................................26
9.5 RUNTIME CONFIGURATION CHANGES .................................27
10. MISCELLANEOUS CONSIDERATIONS ...................................27
Calato, MacFaden Informational [Page 2]
INTERNET-DRAFT LFAP V5.0 June 2002
11. AUTHOR'S ADDRESSES .............................................28
12. REFERENCES .....................................................29
Calato, MacFaden Informational [Page 3]
INTERNET-DRAFT LFAP V5.0 June 2002
1. Introduction
This document specifies Lightweight Flow Accounting Protocol (LFAP)
version 5. It replaces an earlier specification LFAP version 1 as
described in RFC 2124 [1]. It is intended to be deployed in a
network element such as a bridge or router as well as in a passive
network element such as a probe. This protocol specification and
its companion document "LFAP Data Definition Specification" [2]
define a method of flow export such that data collected may be used
for the purposes of billing, application diagnostics, traffic-
engineering, security and capacity planning.
LFAP defines two roles, one called Connection Control Entity and
the other Flow Accounting Server. Network elements that employ LFAP
for flow export are termed Connection Control Entities (CCE). Host
systems that receive and store LFAP data are termed Flow Accounting
Servers (FAS).
LFAP uses TCP [3] as its transport protocol. TCP MUST be present in
all network elements and hosts where LFAP is be employed. TCP meets
LFAP's transport requirements for sequenced flow-controlled
reliable delivery of large volumes of data. LFAP has been allocated
TCP port 3145 [IANA-WKP] for establishing its connections. A CCE
will establish a connection with a FAS in what is known as a "push"
model of data delivery.
This document is the first of three documents that describe LFAP
version 5. The other documents describe the encoding scheme for
data transmitted (LFAP Data Definition Specification[2]), and the
SNMP Management Information Base (MIB) Module to monitor LFAP at a
CCE or a FAS. Please send comments to the LFAP mailing list on
http://www.nmops.org (slate@nmops.org).
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.
Calato, MacFaden Informational [Page 4]
INTERNET-DRAFT LFAP V5.0 June 2002
2. Summary of Operation
Upon initialization, a CCE initiates a TCP connection to a FAS. The
CCE MUST be able to reach the FAS using standard IP connectivity. A
CCE is configured with one or more FAS IPv4 or IPv6 addresses.
After the TCP session is opened between the CCE and FAS, the FAS
enables a Message Response Timer that resets when a valid message
is received. The CCE sends a Version Request (VR) message
specifying the LFAP protocol version the CCE wishes to use. If the
version is supported the FAS responds with a VRA and a status of
SUCCESS otherwise it returns its highest supported version. Once
the protocol version is established, the CCE next sends a
Connection Request (CR) with the necessary information to make an
authorization check. The FAS sends a Connection Accepted
Notification (CAN), a Connection Rejected Notification (CRN) or a
Disconnect Request (DR). A DR message may also be sent at any point
after the session is established. When ready the FAS sends a Flow
Export Ready message (FER).
Either the CCE or the FAS may initiate a Administrative Request
(AR) message any time after the CAN message is received by the CCE.
The requested entity (FAS or CCE) replies with an Administrative
Request Acknowledge (ARA). The ARA is used to communicate status
information or any error conditions for a given AR.
Data transfer begins with Flow Accounting Request(FAR) messages
sent by a CCE to the FAS. These messages are sent when the CCE
identifies a new IP microflow. Information about the flow that does
not change over the life of the microflow such as the Source IP and
Destination IP is sent in the FAR message. Data, which changes over
the life of the flow such as the number of bytes and packets, are
sent in Flow Update Notification (FAR and FUN message contents are
defined in the companion document "LFAP Data Definition
Specification" [2]).
The FAS sends a Keep Alive (KA) message so the CCE can determine if
the connection or the end process/task is still intact. These
messages are sent at a regular interval, between 1 second and
MAX_INT seconds. The CCE should treat any message received from the
FAS as having the same semantics as receiving the KA
message. If the KA Wait Timer expires before any message is
received from the FAS, then the CCE MUSST terminate the TCP
connection and immediately enter Connect State as described in
section 6.2.
Calato, MacFaden Informational [Page 5]
INTERNET-DRAFT LFAP V5.0 June 2002
The following diagram represents which messages each side of the
LFAP protocol sends.
,----------------------------. ,-----------------------------.
| FAS | | CCE |
| | | |
`|---+--------|---|-----|----' `---|---|------------|---+----'
| ^ ^ | | ^ | ^ | ^ | ^ ^ | ^ ^
| | | | | | | | | | | | | | | |
| | | | | | | | VR | | | | | | | |
| | | | | | | `---------------' | | | | | | |
| | | | | | | VRA | | | | | | |
| | | | | | `--------------------' | | | | | |
| | | | | | CR | | | | | |
| | | | | `------------------------' | | | | |
| | | | | | | | | |
| | | | | CAN/CRN/DR | | | | |
| | | | `---------------------------------' | | | |
| | | | | | | |
| | | | FER | | | |
| | | `-----------------------------------------' | | |
| | | | | |
| | | FAR/FUN | | |
| | `-------------------------------------------------' | |
| | | |
| | AR/ARA | |
| `----------------------------------------------------------' |
| |
| KA |
`------------------------------------------------------------------'
Calato, MacFaden Informational [Page 6]
INTERNET-DRAFT LFAP V5.0 June 2002
3. Message Format
LFAP defines twelve messages: "Version Request", "Version Request
Acknowledge", "Connection Request", "Connection Accepted
Notification", "Connection Rejected Notification", "Flow Export
Ready", "Flow Accounting Request", "Flow Update Notification",
"Administrative Request", "Administrative Request Acknowledge",
"Keep Alive" and "Disconnect Request" (VR, VRA, CR, CAN, CRN, FER,
FAR, FUN, AR, ARA, KA, DR respectively).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Op Code | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Information Element (IE) Fields ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The general message format for all LFAP messages is as shown above.
This is version 5 and Op Codes are as follows:
VR - 1 # Code will never change in future revisions of LFAP
VRA - 2 # Code will never change in future revisions of LFAP
CR - 3
CAN - 4
CRN - 5
FER - 6
FAR - 7
FUN - 8
AR - 9
ARA - 10
KA - 11
DR - 12
The Status field serves as a Status on the overall message.
STATUS:
SUCCESS = 1
VERSION = 2 Used by the FAS to indicate it does Not
support the version of LFAP Used by the CCE.
Reserved is reserved for future expansion and must be zero.
The Message Length excludes the 8 octets of the message header.
Message ID is used to associate each original message with its
corresponding response and must be unique for the combination of
sender and responder while an original message is pending.
Calato, MacFaden Informational [Page 7]
INTERNET-DRAFT LFAP V5.0 June 2002
4. Information Elements (IE's) Formats
IE fields consist of 2-octet TYPE, 2-octet LENGTH and variable
length VALUE sub-fields. All IE's are even multiples of 4 octets in
length, left aligned and zero filled if necessary. Length is
computed excluding the 4 octet TYPE and LENGTH fields.
Individual IE's necessary for data formatting or to establish and
maintain a connection between the switch CCE and a FAS server are
described here. Additional IE's which may be sent are described by
the LFAP Data Definition Specification[2]. IE type codes 1 - 64 are
reserved for use by the LFAP Transport specification. IE type codes
65 - 60000 are used for defining additional IE's in the LFAP Data
Definition Specification. Type codes 60001 - 65535 are reserved for
future use. A type code of zero "0" is invalid.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = | LENGTH = |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1 FAS IP Address IE
This is the IP Address of a device running a Flow Accounting Server
that may or may not be reachable from the FAS. The CCE uses this IE
in the Connection Request message. IE format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Number | Address Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Address Length field contains the length of the address
excluding any pad of zeros used to align the address field.
Address Family Numbers include:
1 = IP (IP Version 4) as specified in RFC 1700
2 = IP6 (IP Version 6) as specified in RFC 1700
Calato, MacFaden Informational [Page 8]
INTERNET-DRAFT LFAP V5.0 June 2002
4.2 Multiple Record IE
The Multiple Record IE is composed of 4 parts. The record
descriptor, fixed information, record format IEs and individual
records. The record descriptor consist of two fields the first
field is the length of the fixed information field. The second is
the length of the Record format section. The fixed information is
the IE's that apply to all the records that follow. The Record
Format is the list of IE's that make up each record. The individual
record section contains the individual records that are being
reported in the format given by the Record Format section.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE = 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of fixed Information | Length of Record Format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Fixed Information ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Record Format ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Individual Record (1) |
| Individual Record (2) |
| Individual Record (3) |
| . |
~ . ~
| . |
| Individual Record (n) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Individual Message contents
5.1 Version Request (VR) Message
VR messages are sent only by the CCE to request a session with the
FAS under a specific version of the LFAP protocol. The VR message
may only be sent by a CCE while is in the Connect State. It must be
sent within the time specified by the Message Response Timer. A CCE
MUST NOT request the same version within a single TCP session
Calato, MacFaden Informational [Page 9]
INTERNET-DRAFT LFAP V5.0 June 2002
otherwise the FAS MUST disconnect the TCP session and the counter
Session Establishment Errors will be incremented.
5.2 Version Request Acknowledge (VRA) Message
VRA messages are sent only by a FAS in response to a VR when a new
TCP connection has been established and the FAS is in the Connect
State. The Message ID field is set to the value of the received VR
message. If a VR is not received within the given Message Response
Timer the TCP session is dropped and counter Session Establishment
Errors is incremented.
If the FAS supports the version requested in the VR message it also
copies the version number from the VR message to the VRA message
and status is set to SUCCESS in the VRA message. Upon the CCE
receiving this message protocol version negotiation is complete and
the CCE and FAS both transition to Connected State.
If the FAS does not support the version requested in the VR
message, the FAS places the highest version it supports in the
message header and sets the STATUS field to VERSION, which
indicates a version mismatch. The Version Mismatch Errors is
incremented.
The CCE MUST NOT request a version higher than the one returned in
the VRA otherwise the FAS MUST disconnect the TCP session and the
counter Session Establishment Errors will be incremented.
5.3 Connection Request (CR) Message
A single CR message is sent only by the CCE to request an
authorized connection. CR messages contain a mandatory IE that is
the FAS IP Address IE. There is one IE for each FAS the CCE has
been configured with in the order that the CCE will attempt to
connect with. Only one CR message is sent by a CCE and only when it
is in the Connected State. Status field must be set to SUCCESS.
If the FAS does not receive a CR message within the timeout
specified by the Message Response Timer, the TCP session MUST be
disconnected and the Session Establishments Rejected counter
incremented.
Mandatory IE's
FAS IP Address IE - the multiple record IE MUST be used to list
more than one FAS IP address
Calato, MacFaden Informational [Page 10]
INTERNET-DRAFT LFAP V5.0 June 2002
5.4 Connection Accepted Notification (CAN) Message
A single CAN message is sent only by a FAS when it is in the
Connected State and only in response to a CR message. A CAN message
is sent by the FAS to indicate the CCE is authorized to connect to
this FAS. CAN messages do not contain any mandatory IE's. Status is
set to SUCCESS.
If the CCE does not receive a CAN (or CRN/DR) message within the
timeout specified by the Message Response Timer, the TCP session
MUST be disconnected and the Session Establishments Rejected
counter incremented.
5.5 Connection Rejected Notification (CRN) Message
A single CRN message is sent only by a FAS when it is in the
Connected State and only in response to a CR message. A CRN message
is sent by the FAS to indicate the CCE is not authorized to connect
to this FAS. CRN messages do not contain any mandatory IE's. Status
is set to SUCCESS. A CCE will terminate the TCP connection upon
receipt. The FAS will terminate the TCP connection after the
message was transmitted successfully.
If the CCE does not receive a CRN (or CAN/DR) message within the
timeout specified by the Message Response Timer, the TCP session
MUST be disconnected and the Session Establishments Rejected
counter incremented.
5.6 Flow Export Ready (FER) Message
A single FER message is sent only by a FAS and only when it is in
the Data Negotiation state. FER messages are sent by the FAS to
indicate the FAS is ready to accept FAR and FUN messages. Only
AR,ARA and FER messages are allowed while in the Data Negotiation
state. FER messages do not contain any mandatory IE's. Status is
set to success.
If the CCE does not receive AR, ARA or an FER message within in the
timeout specified by the Message Response Timer, the TCP session
MUST be disconnected and the Session Establishments Rejected
counter incremented.
5.7 Flow Accounting Request (FAR) Message
FAR message contents are described in the LFAP Data
Definition RFC. FAR messages are only sent by a CCE
when the CCE is in Send State. The Status field is set
to SUCCESS in FAR messages.
Calato, MacFaden Informational [Page 11]
INTERNET-DRAFT LFAP V5.0 June 2002
5.8 Flow Update Notification (FUN) Message
FUN message contents are described in the LFAP Data
Definition RFC. FUN messages are only sent by a CCE
when the CCE is in Send state and are sent only after a
FAR has been sent for any data contained within the
FUN. Status is set to SUCCESS in FUN messages.
5.9 Administrative Request (AR) Message
AR's can be sent by CCE or FAS at any time when in the
Send or Data Negotiation State. Status is set to
SUCCESS in AR messages. AR message contents are
described in the LFAP Data Definition RFC.
5.10 Administrative Request Acknowledge (ARA) Message
ARA's can be sent by CCE or FAS at any time when in the Send or
Data Negotiation State in response to a specific AR. Status
reflects the result of the corresponding AR. Message ID is copied
from the AR message. ARA message contents are described in the LFAP
Data Definition RFC.
5.11 Keep Alive (KA) Message
KA messages do not contain any IE's. The FAS sends a Keep Alive
(KA) messge so the CCE can determine if the connection is still
intact while in the Send State. These messages are sent at a
regular interval, between 1 second and MAX_INT seconds. The CCE
should treat any message received from the FAS as having the same
semantics as receiving the KA message. Status is set to SUCCESS in
KA messages.
5.12 Disconnect Request (DR) Message
A DR message is sent only by the FAS to request the CCE disconnect.
It can be sent when the FAS is in the Send State or Connected
State. DR messages may contain one optional IE which is the FAS IP
Address IE. The FAS may suggest an alternative FAS by supplying the
FAS IP Address IE. Status is set to SUCCESS in DR messages.
The Optional IE that can be transmitted in a DR message is a:
FAS IP Address IE
Calato, MacFaden Informational [Page 12]
INTERNET-DRAFT LFAP V5.0 June 2002
5.13 Message ID Error
If the same Message ID is received in consecutive messages, all but
the first one is ignored and the counter Invalid Messages Received
is incremented.
6. Session Establishment
The CCE initiates a TCP connection to a FAS. Session establishment
happens in three phases following TCP connection establishment. In
the first phase the protocol version is exchanged and verified. In
the second phase, the FAS allows or denies the connection. The FAS
may deny the connection for a variety of reasons. For example, the
CCE may not be authorized to connect to this FAS. The third phase
allows setup information to be exchanged before flow export begins.
Messages received outside their specified state cause the session
to be aborted.
6.1 Protocol Negotiation
In this phase the FAS and the CCE negotiate the version of the LFAP
protocol to be used. The CCE initiates the process by sending a VR
message with the highest version it supports in the message header.
If the FAS supports the version it MUST respond with a VRA with the
same version number and a status of success. For example, a CCE may
request version 3 and the FAS may support version 3, 4, and 5. In
this case the FAS will respond with a VRA message with a version of
3 and status of success.
If the FAS does not support the version it MUST send a VRA message
with the highest version it supports and the status set to VERSION.
At this point the CCE MAY disconnect and try another FAS. Or, if
the CCE supports the version indicated by the FAS, the CCE MAY send
a new VR message with the indicated version number. For example, if
the CCE supports version 5 and 6, it will send a VR message to the
FAS with version 6. Since the FAS supports version 3, 4, and 5, it
responds with a VRA message with a version of 5 and a status of
VERSION (indicating it does not support version 6). The CCE may now
send another VR message, this time with version 5.
If the CCE supports a lower version than indicated in the ARA, it
MAY also send a VR with its lower version. The same version MUST
NOT be requested twice in a single TCP session. Additionally, once
the CCE receives an ARA it MUST NOT request a version higher than
the one received in the ARA.
Calato, MacFaden Informational [Page 13]
INTERNET-DRAFT LFAP V5.0 June 2002
6.2 Connection Establishment
Once the protocol version negotiation is complete, the FAS then
will either accept or reject the connection. First, the FAS MUST
receive from the CCE a Connection Request (CR) message with the
necessary data. In LFAP Version 5 the data consists of a list of
FAS IP addresses. After receiving the CR message the FAS MUST send
a Connection Accepted Notification, a Connection Rejected
Notification or a Disconnect Request. The DR message MAY contain a
server that should be used instead.
6.3 Data Negotiation
During this phase only AR and ARA messages may be exchanged. The
LFAP Data Definition specification [2] describes the message
contents. When complete, a FER message is sent from the FAS to the
CCE and the LFAP session is then fully established.
The normal sequence of events when a CCE and FAS start to talk would
be as follows:
_ The CCE opens a TCP socket
_ The CCE sends a VR message with the desired protocol version
_ The FAS sends a VRA response with its desired version.
_ The CCE sends a CR message assuming the two agree on a
version
_ The FAS sends a CAN message, Assuming the CCE is authorized
_ The FAS and CCE exchange AR and ARA messages
_ The FAS sends a FER
At this point the session is established and FAR/FUN messages will
begin along with Keep Alive messages.
6.4 State Diagrams
Two state diagrams, one from the CCE perspective and one from the
FAS perspective follow which describe the three phases of the
connection setup:
Calato, MacFaden Informational [Page 14]
INTERNET-DRAFT LFAP V5.0 June 2002
CCE State Machine for Connection Setup
Begin +-------------+ * master on/off switch
| | * FAS IP address list
| Init State | * server time-out
| | * keep alive
| | * server retry interval
+-------+-----+ * select first FAS IP address
|
|
+------>+-------V-------+
| +---->| | * if needed, TCP connect
| | +->| Connect State | * Send VR
| | |+>| |
| | || +---+---+-------+
| | ||(A) | | - receive VRA from FAS
| | |+-----+ |
| | | |
| | | +-------V-------+
| | | | Protocol | * evaluate VERSION
| | +--+ Negotiation |
| | (B)| State |
| | +-------+-------+
| | | - VRA Version matched
| | |
| | +-------V-------+
| | | | * Send CR
| +-----+Connected State|
| (C)| |
| +-------+-------+
| | - Received CAN
| |
| |
| +-------v-------+
| | | * Exchange AR/ARA
+-------+ Data |
| (D)| Negotiation |
| +-------+-------+
| | - Received FER
| |
| |
| +-------V-------+
|(E) | | * Send FAR/FUN
+-------+ Send State | * Send/Receive AR/ARA
| | * Receive KA/DR
+---------------+
Calato, MacFaden Informational [Page 15]
INTERNET-DRAFT LFAP V5.0 June 2002
(A) The error conditions that occur while the CCE is in the Connect
state include:
- No response to VR message, message Response Timer expired
- TCP connection failed to be established.
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(B) The error conditions that occur while the CCE is in the Protocol
Negotiation State include:
- NOT Supported Version - FAS and CCE do not agree on LFAP
version number. CCE can either try sending a VR with the
version the FAS sent if it is supported or it can disconnect
the TCP session and try another unique IP address of a FAS.
- TCP session disconnects - try next server in list
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(C) The error conditions that occur while the CCE is in the Connected
state include:
- No response to CR message, Message Response Timer expired then
drop connection, increment counter.
- Receive CRN message, disconnect current TCP session, select
next FAS IP address. If next FAS IP address in list is the
first one, wait for period specified in Retry FAS List Timer.
- DR message received from FAS. Disconnect and try next IP
server in list or use the server specified if in current list
- TCP session disconnects
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(D) The error conditions that occur while the CCE is in the Data
Negotiation state include:
- No AR, ARA or FER message, Message Response Timer expired then
drop connection, increment counter.
- TCP session disconnects
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(E) The error conditions that occur while CCE is in Send State include
- DR message received from FAS. Disconnect and try next IP
server or use server specified if in current list.
- KA Timer expired or ARA message not received to last CCE
issued AR, disconnect and try next server in list.
- TCP session disconnects - try next server in list
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
Calato, MacFaden Informational [Page 16]
INTERNET-DRAFT LFAP V5.0 June 2002
FAS State Machine
Begin +-------------+
| |
| Init State |
| |
| |
+-------+-----+
|
|
+------>+-------V-------+
| +---->| | * if needed, Await TCP connection
| | +->| Connect State | * Await VR message
| | |+>| |
| | || +---+---+-------+
| | ||(A) | | - receive VR from CCE
| | |+-----+ |
| | | |
| | | +-------V-------+
| | | | Protocol | * evaluate VERSION
| | +--+ Negotiation |
| | (B)| State |
| | +-------+-------+
| | | - Send VRA (version matched)
| | |
| | +-------V-------+
| | | | * Await CR
| +-----+Connected State|
| (C)| |
| +-------+-------+
| | - Send CAN
| |
| |
| +-------v-------+
| | | * Exchange AR/ARA messages
+-------+ Data |
| (D)| Negotiation |
| +-------+-------+
| | - send FER
| |
| |
| +-------V-------+
| (E)| | * Receive FAR/FUN
+-------+ Send State | * Send/receive AR/ARA
| | * Send KA messages
+---------------+ * Can send DR
Calato, MacFaden Informational [Page 17]
INTERNET-DRAFT LFAP V5.0 June 2002
(A) The error conditions that occur while the FAS is in the Connect
State include:
- No VR message, Message Response Timer expired then drop
connection, increment counter.
- TCP session disconnects
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(B) The error conditions that occur while the FAS is in the Protocol
Negotiation State include:
- NOT Supported Version - The FAS sends a VRA with its highest
supported version.
- TCP session disconnects
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(C) The error conditions that occur while the FAS is in the Connected
state include:
- No CR message, Message Response Timer expired then drop
connection, increment counter.
- Send CRN message, then disconnect TCP session.
- Send DR message, then disconnect TCP session.
- TCP session disconnects
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(D) The error conditions that occur while the FAS is in the Data
Negotiation state include:
- No ARA message in response to AR, Message Response Timer
expired then drop connection, increment counter.
- TCP session disconnects
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
(E) The error conditions that occur while FAS is in Send State include
- DR message sent, disconnect TCP session.
- No ARA message in response to AR, Message Response Timer
expired then drop connection, increment counter.
- TCP session disconnects.
- Protocol violation (the wrong message type was received),
disconnect and increment counter.
- Corrupted message received. Increment counter.
Calato, MacFaden Informational [Page 18]
INTERNET-DRAFT LFAP V5.0 June 2002
6.5 Protocol Errors
Any message received by either the CCE or FAS outside its specified
state will cause the TCP connection to be disconnected and the
Protocol Error counter will be incremented.
State Messages Allowed
--------------------- ----------------------------
Connect VR, VRA
Protocol Negotiation VR, VRA
Connected CR, CAN, CRN, DR
Data Negotiation AR, ARA, FER
Send FAR, FUN, AR, ARA, KA, DR
7. Error Handling
The receiver will ignore corrupted message contents - receipt of a
LFAP message that cannot be parsed. An error should be logged if
possible and the Corrupted Message counter should be incremented.
Other error handling is naturally associated with each message and
is listed in the following sections.
7.1 VRA Related Error Handling
If the FAS does not support the version requested in the VR
message, the FAS places the highest version it supports in the
message header and sets the STATUS field to VERSION, which
indicates a version error.
7.2 ARA Related Error Handling
Any AR messages with commands that result in an error may have the
error information returned via the ARA.
8. Statistics
Each implementation of the protocol must maintain various
statistics on the operation of the protocol. Statistics common to
both the CCE and FAS perspective are described first followed by
Calato, MacFaden Informational [Page 19]
INTERNET-DRAFT LFAP V5.0 June 2002
statistics that are role dependent.
8.1 Common Statistics
A FAS or CCE will maintain the following 32 bit counters for each
of the following messages that were sent and received correctly.
VR, VRA, CR, CAN, CRN, FER, FAR, FUN, AR, ARA, KA
The following 32 bit counters will be kept:
Version Mismatch Errors
Number of times CCE or FAS did not agree on LFAP version.
Session Establishments Accepted
Number of times either a CCE or FAS reached the Send State as
indicated in the state diagrams. In summary, a CCE receives a FER
message or a FAS sends an FER message.
Session Establishments Rejected
Number of times a CCE has received a CRN message or a FAS has sent
a CRN message.
Lost Contact
Number of times a CCE or FAS lost the session while in the Send
State. For a CCE, this includes Message timeout, Lost TCP session,
or KA timeout. For a FAS, it includes Message timeout and Lost TCP.
Active flows
On a CCE, number of current flows being tracked. On the FAS this
counter is kept per CCE and is the number of flows known to the FAS
for that CCE (note - on failover the FAS does not know about any
active flows on the CCE). This number is computed as follows.
Increment when FAR messages are created on the CCE or received by a
FAS. Decrement when a FUN with state of inactive is created on a
CCE or received by a FAS. If a FAS receives a FUN for a flow which
is unknown, it increments the active counter first and adds it to
the known list.
Bytes Sent
Number of bytes excluding written to TCP session since TCP session
was opened. FAS keeps this counter per CCE.
Packets Sent
Number of bytes excluding written to TCP session since TCP session
was opened. FAS keeps this counter per CCE.
Peak active flows
Watermark of most flows managed concurrently by the CCE. The FAS
keeps one counter for all currently connected CCEs.
Calato, MacFaden Informational [Page 20]
INTERNET-DRAFT LFAP V5.0 June 2002
Corrupted messages received
A count of any message received that could not be decoded.
Protocol Violations
A count of valid messages received but considered invalid in the
current CCE or FAS state.
8.2 CCE Statistics
Each of the following statistics must be maintained by a CCE as a
32 bit counter. These must be kept for the device and optionally
per configured LFAP server.
Session Establishment Errors
Number of times TCP connection was tried but failed.
Failed to establish a session to any server
A count of the number of times the CCE attempted to connect to each
of the FAS it was configured with in succession without success. It
includes cases where a DR with an alternate FAS was also tried.
Session establishment failed due to version mismatch
A count of the number of times the CCE negotiated LFAP version with
a FAS without agreement.
Dropped messages
A count of the number of FAR or FUN messages the CCE could not be
transmitted to the FAS while not in Send State.
Dropped messages while connected
A count of the number of FAR or FUN messages the CCE could not be
transmitted to the FAS while in Send State.
Number of bytes not accounted for due to dropped messages
A count of the number of bytes accounted for in FUN messages being
dropped that CCE could not transmit to the FAS while in Send State.
Number of packets not accounted for due to dropped messages
A count of the number of packets accounted for on the wire that CCE
could not transmit to the FAS while in Send State.
A timestamp will be kept for the following events: This timestamp
is the time in hundredths of a second since the system was last
restarted.
Time of last session status change in our out of the Send State
Time of last dropped message
Time of last dropped message while connected
Time of peak active flows
Calato, MacFaden Informational [Page 21]
INTERNET-DRAFT LFAP V5.0 June 2002
8.3 FAS Statistics
Each of the following statistics is a 32 bit counter
Number of CCE's connected
Number of active Flows being tracked by all CCEs
Timestamp of last Error to store any received FAR or FUN
Number of accounting bytes received but not stored
Number of accounting packets received but not stored
These stats are kept per CCE
Number of active flows
Timestamp when connection entered Send State
Version of protocol selected
Time left till next Keep Alive
9. Security Considerations
The LFAP protocol carries two types of sensitive data.
1) Micro-flow information gleaned from datagram headers such as IP
addresses, protocol, and TCP/UDP source/dest port numbers.
2) Information used for billing purposes, which in addition to flow
information, includes bytes and packets transmitted.
Four levels of security are defined.
Level I - No Security
The intent of level I is to allow the protocol to run with no
security overhead when there is no perceived threat or when some
other mechanism is in place.
Level II - No Unauthorized Sessions
The intent of level II is to protect against the establishment
of a session with an impersonated CCE or FAS.
Level III - Secure Transport
The intent of level III to provide a secure transport for LFAP
messages. Types of attacks to be prevented are listed below.
Level IV - Encrypted Transport
The intent of level IV is to prevent the reading of LFAP
messages by a third party.
The following attacks should be considered when evaluating any
security solution.
Calato, MacFaden Informational [Page 22]
INTERNET-DRAFT LFAP V5.0 June 2002
1) Message altering
2) Message replay
3) Message Insertion
4) Message reading (snooping)
5) Impersonation of a CCE or FAS
9.1 Lower Layer Security
Since LFAP runs over TCP, a lower layer protocol may provide the
necessary security. Two such lower layer protocols are IPSec[4] and
Transport Layer Security [5](TLS a.k.a. Secure Socket Layer - SSL).
Either of these security protocols operating under the LFAP
protocol can adequately accomplish the defined security levels and
address the attacks mentioned.
9.2 LFAP Security
In addition to IPSec and TLS to provide protection against the
attacks outlined, the base protocol has provisions to accomplish a
minimal base level of security within the protocol itself. LFAP
implementations MAY implement one or more levels of security via
the LFAP protocol. If a lower layer protocol is in use the CCE and
FAS can be set to level I.
9.2.1. Extended LFAP Header
Additional fields are needed in the LFAP message header to provide
the necessary security mechanisms. The enhanced header format is as
follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Op Code | Reserved |A|E| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | Sequence ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version, Op code, Status, Message ID and Message Length are the
same as described previously. Note - message Length excludes the
first 8 octets of the header, but includes the remaining header
octets when the extended header is used.
Calato, MacFaden Informational [Page 23]
INTERNET-DRAFT LFAP V5.0 June 2002
A = 1 - the message is authenticated
E = 1 - the message is encrypted
Authentication Data - a 96 bit field containing the Authentication
data. HMAC-MD5-96 RFC 2104[6] & RFC 1321[7] define the value of
this field.
Sender ID - the router ID for the CCE or the IP address for the
FAS. This value is used to determine which key to use for
authentication and encryption.
Session ID - starting number is picked at random, subsequent IDs
are increased by 1. Zero "0" is invalid.
Sequence ID - picked at random using the lower 36 bits of sequence
ID. Each subsequent message increases it by 1. Zero "0" is invalid.
When calculating Authentication Data, the field is set to zero in
the message and the value is calculated over the entire message.
Thus, all fields are protected. Messages with an invalid
Authentication Data field are discarded.
The sender ID and Session ID must match the corresponding IDs
established for the session or the message is discarded.
The Sequence field is incremented by the sender, the receiver
discards messages with an ID not equal to the last sequence ID + 1.
Only a successfully authenticated message causes the last sequence
ID to be updated.
An invalid Authentication Data field or incorrect ID fields (sender
ID, session ID and sequence ID) is considered to be a "Security
Violation". Messages that result in a security violation are
discarded. A new statistic is added called Security Violations. It
is incremented each time a Security violation is encountered.
The sequence ID is large enough that should the value roll over,
the amount of time elapsed would make any replay attack unlikely.
Note - on rollover, zero "0" MUST NOT be not used.
9.2.2. Extended Header ID Exchange
Some minor changes are necessary to exchange the IDs needed for the
extended LFAP header. The changes are outlined below.
When the CCE sends a VR with A = 1 it fills in the session ID and
sequence ID with the values the FAS can use in subsequent messages
Calato, MacFaden Informational [Page 24]
INTERNET-DRAFT LFAP V5.0 June 2002
to the CCE.
When the FAS sends a VRA with A = 1 it fills the session ID and
sequence ID with the values the CCE can use in subsequent messages
to the FAS. If the version requested is not supported by the FAS it
returns the VRA as if the VR did not have the "A" flag set.
At this point, the CCE sets its Last Received Sequence ID to the
value it, the CCE, set in the VR message. Similarly the FAS sets
its Last Received Sequence ID to the value it, the FAS, set in the
VRA.
From this point on when the FAS whishes to send a message which is
to be authenticated it sets the "A" flag in the header to 1 and it
sets the sender ID to its own ID. It sets the Session ID to the ID
supplied in the VR message. It then sets the Sequence ID to 1
greater than the one it received in the VR message. Subsequent
messages continue to increment the last Sequence ID by 1.
Similarly when the CCE wishes to send a message that is to be
authenticated it sets the "A" flag in the header to 1 and sets the
sender ID to its own ID. It sets the Session ID to the ID supplied
in the VRA. It then sets the Sequence ID to 1 greater than the one
it received in the VRA message. Subsequent messages continue to
increment the last Sequence ID by 1.
9.2.3. Level I Security
Level I security is the default. All implementation have this level
of security by definition.
9.2.4. Level II Security
To achieve level II security the LFAP Session establishment is
modified as follows.
CCE sends VR as described in the previous section
FAS sends VRA as described in the previous section
CCE sends CR with A = 1 and the Session ID from the VRA. The
Sequence ID from the VRA is incremented and used
FAS sends CAN with A = 1 and the Session ID from the VR. The
Sequence ID from the VR is incremented and used
CCE sends FAR/FUNs with A = 0
FAS sends message with A = 0
This will approach will not allow impersonation of a FAS or CCE
since they will not have the necessary secret key to compute the
Authentication Data field. It is however subject to attacks such as
replay of FAR/FUN messages after session establishment is complete.
Note - Messages received before the session is established
Calato, MacFaden Informational [Page 25]
INTERNET-DRAFT LFAP V5.0 June 2002
cause the connection to be aborted. Thus an attacker
cannot simply start by sending FAR/FUN messages.
9.2.5. Level III Security
Level III security is built on top of Level II security. The only
change is that with Level III security, all messages set the "A"
flag to 1 and fill in the extended LFAP header. This level of
security protects against each form of attack listed except for
message reading.
9.2.6. Level IV Security
Level IV security SHOULD use Level II security. To enable Level IV
security the "E" flag is set to 1 in the LFAP header. If the "A"
flag is 0 encryption begins after the LFAP header. If the "A" flag
is set to 1 then encryption begins after the Authenticated Data
field in the extended header. Note - if the "E" flag is set in the
VR and the FAS does not support the version, it sends the VRA as of
the "E" flag was not set.
Encryption is done using DES-CBC [FIPS-46-3][FIPS-74][FIPS-81].
9.2.7. Security Configuration
Both the FAS and CCE must be configured with the expected security
level, the default is level I. If the CCE or FAS does not receive
the expected level of security, it MUST disconnect the TCP session
and increment the Security Violations counter. Additionally the way
the FAS and CCE obtain the necessary keys is undefined.
9.3 Denial of Service
Since LFAP runs over TCP, both the CCE and FAS need to be protected
from TCP denial of service attacks. Defining how to protect against
TCP attacks is outside the scope of this document.
Additional steps can be taken to help protect against flooding of
invalid messages on an existing connection. If more than "n"
Security Violations occur or "n" corrupted messages are received,
the TCP connection MAY be terminated. In this case the previous
state diagrams are modified to include one extra error event
triggered when "n" is reached. "n" MUST be configurable from 1 to
MAX_INT.
9.4 Message Loss
There is one additional type of attacked that should be considered
and that is an attack that results in message loss.
There are a variety of ways that an attacker can cause messages to
be lost. For example, the message may be altered in such a way that
Calato, MacFaden Informational [Page 26]
INTERNET-DRAFT LFAP V5.0 June 2002
the application can no longer make use of the message when it is
delivered. The attacker may cause TCP to abort the connection or
cause the connection to get backed up. In such cases the data must
be stored by the application and re-sent if necessary.
There are two issues that make Message Loss a more difficult
problem to solve.
1) Identifying duplicate flow information when data is re-sent.
2) Limited storage space on most CCE devices.
The first problem poses technical challenges given the distributed
nature of the LFAP protocol. A single CCE can fail-over to several
servers and thus those servers must coordinate to identify and
eliminate any duplicate records. The solution must also take into
consideration the enormous volume of data generated by each CCE and
the practical implications of implementing any given solution.
Assuming the first problem us solved, the second problem will limit
its effectiveness under a sustained attack. Once the device runs
out of storage space, subsequent messages are not recoverable. This
makes the cost benefit ratio for solving the duplicate data problem
even less attractive.
Given the above consideration, there are no provisions in the LFAP
protocol to solve the Message Loss issue. However, there is support
to aide in quantifying the amount of loss sustained. Counters are
defined for the CCE and FAS which track the amount of data counted
and the amount of data lost. This will allow a management tool to
analyze the information and determine the scope of loss.
9.5 Runtime Configuration Changes
If a session is established when the initial CCE configuration is
changed, the session should only be dropped if the new FAS IP list
does not contain the existing IP address or the master off switch
has been applied.
10. Miscellaneous Considerations
The LFAP protocol may be used in a Network Address Translation
(NAT) environment, where the FAS is on one side of the NAT and the
CCE is on the other. There is however one caveat, if the FAS
attempts to contact any of the FAS's sent in the CR message,
reachability is not guaranteed. Therefore an LFAP server must not
depend reaching those FAS's.
Calato, MacFaden Informational [Page 27]
INTERNET-DRAFT LFAP V5.0 June 2002
11. Author's Addresses
Paul Calato
Phone: +1 (603) 557-6913
Email: calato@riverstonenet.com
Mike MacFaden
Phone: +1 (408) 878-6525
Email: mrm@riverstonenet.com
Riverstone Networks, Inc. is located at:
5200 Great America Parkway
Santa Clara, CA 95054
USA
Calato, MacFaden Informational [Page 28]
INTERNET-DRAFT LFAP V5.0 June 2002
12. References
[1] Cabletron's Light-weight Flow Admission Protocol
Specification version 1.0. Informational RFC 2124.
March 1997.
[2] "LFAP Data Definition Specification",
draft-riverstone-lfap-data-00.txt.
[3] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 7, RFC
793, DARPA, September 1981.
[IANA-WKP] http://www.iana.org/assignments/port-numbers
[4] Several documents are used to describe the IPsec
protocol suite. The interrelationship and
organization of the various documents covering the
IPsec protocol are discussed in RFC 2411, November
1998.
[5] "The TLS Protocol Version 1.0" RFC 2246, January 1999.
[6] "HMAC: Keyed-Hashing for Message Authentication" RFC
2104, February 1997.
[7] "The MD5 Message-Digest Algorithm" RFC 1321, April
1992.
[1700] "Assigned Numbers," RFC 1700, October 1994.
[FIPS-46-3] US National Bureau of Standards, "Data Encryption
Standard", Federal Information Processing Standard
(FIPS) Publication 46-3, October 1995,
http://www.itl.nist.gov/div897/pubs/fip46-3.htm
(supersedes FIPS-46-2).
[FIPS-74] US National Bureau of Standards, "Guidelines for
Implementing and Using the Data Encryption Standard",
Federal Information Processing Standard (FIPS)
Publication 74, April 1981,
http://www.itl.nist.gov/div897/pubs/fip74.htm.
[FIPS-81] US National Bureau of Standards, "DES Modes of
Operation", Federal Information Processing Standard
(FIPS) Publication 81, December 1980,
http://www.itl.nist.gov/div897/pubs/fip81.htm.
Expires December 2002
Calato, MacFaden Informational [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-24 01:24:18 |