Internet Engineering Task Force Z. Chen
Internet-Draft China Telecom
Intended status: Informational C. Zhou
Expires: January 4, 2013 Huawei Technologies
T. Tsou
Huawei Technologies (USA)
July 3, 2012
The Syslog Requirements to Support NAT Log in Traceback Solutions
draft-zhou-behave-syslog-nat-logging-00
Abstract
This document describes the syslog information that are required for
NAT logging. The document will define the NAT logging server which
supports traceback and explain the procedure of network location and
service support for traceback. The requirements of syslog interface
and Radius interface to support NAT log are introduced.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 4, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Chen, et al. Expires January 4, 2013 [Page 1]
Internet-Draft Syslog Requirements for NAT Log July 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Traceback Solutions . . . . . . . . . . . . . . . . . . . 3
1.2. The Log Server Function . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Requirements of Log Server Function . . . . . . . . . . . 4
4. The Log Server Interface Requirements . . . . . . . . . . . . 5
4.1. Syslog Interface . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Definition of HEADER Part . . . . . . . . . . . . . . 5
4.1.1.1. PRI . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1.2. VERSION . . . . . . . . . . . . . . . . . . . . . 7
4.1.1.3. TIMESTAMP . . . . . . . . . . . . . . . . . . . . 7
4.1.1.4. HOSTNAME . . . . . . . . . . . . . . . . . . . . . 7
4.1.1.5. APP-NAME . . . . . . . . . . . . . . . . . . . . . 7
4.1.1.6. PROCID . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1.7. MSGID . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Definition of MSG Part . . . . . . . . . . . . . . . . 8
4.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. The Radius Interface Requirements . . . . . . . . . . . . 9
5. The Performance Requirements of The Log Server . . . . . . . . 10
6. The Reliability Requirements of The Log Server . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Chen, et al. Expires January 4, 2013 [Page 2]
Internet-Draft Syslog Requirements for NAT Log July 2012
1. Introduction
1.1. Traceback Solutions
In the existing IPv6 transition technology, there are two ways of
address and port mapping:static mapping and dynamic mapping. Based
on this, we summarize four traceback solutions:
1. After the address and port mapping information is created, NAT
device (e.g.,Carrier Grade NAT) sends the syslog mapping
information to the log server. AAA system acquires the dynamic
address mapping information from the syslog server when receiving
traceback request.
2. NAT device reports the dynamic mapping information to AAA system
via radius protocol. AAA system will record the subscriber
online information and source session list. After traceback
request is received, AAA system will return the trackback result
with the subscriber online information and source session list
information.
3. NAT device reports the dynamic mapping information to the log
server through radius protocol. AAA system acquires the mapping
information from syslog server when receiving the traceback
request.
4. AAA system and NAT device send the parameters through network
configuration system and perform the same mapping algorithm to
generate address and port. In the traceback procedure, there is
no need for AAA system and NAT device to transmit the mapping
information.
In solution 1 and 3, the traceback log server will be a newly created
device.
1.2. The Log Server Function
The traceback log server receives, analyzes and stores the address/
port address mapping information sent by NAT devices. The logic
illustration of the log server is shown in Figure 1.
+----------+ A +----------+ B +----------------+
|NAT Device|--- |Log Server|---|Traceback System|
+----------+ +----------+ +----------------+
Figure 1: Location Of Log Server In The Network
The log server acquires dynamic address/port mapping information from
Chen, et al. Expires January 4, 2013 [Page 3]
Internet-Draft Syslog Requirements for NAT Log July 2012
the NAT device via interface A, and provides the mapping information
to the traceback system (or AAA) via interface B.
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 "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
:Logging information: In this document, this specifically means
dynamic address/port mapping logging information.
3. The Requirements of Log Server Function
This section defines the basic requirements for the log server.
o It MUST support The Syslog Protocol [RFC5424].
o It MUST support Transport Layer Security (TLS) Transport Mapping
forSyslog [RFC5425].
o It MUST support Transmission of Syslog Messages over UDP
[RFC5426]. The log server must support sending the syslog log
using standard UDP port 514, and support sending syslog log using
any one self-configured port of the user.
o It is suggested to support Reliable Delivery for Syslog [RFC3195].
o It MUST support the Radius message format defined in [RFC2865] or
[RFC2866].
o It MUST support acquiring user's dynamic address/port mapping
information from NAT device.
o It MUST support the functions of log query, storage, filter,
duplication removal, collection and statistic analysis.
o The storage information of the log server MUST include the
following information, but not limited to:
* Application name
* Hostname
Chen, et al. Expires January 4, 2013 [Page 4]
Internet-Draft Syslog Requirements for NAT Log July 2012
* Start time
* Original source IP
* Translated source IP
* Translated source start port
* Translated source stop port
4. The Log Server Interface Requirements
The log server MUST select one interface between syslog and radius to
communicate with NAT device. It MUST provide the query interface to
the traceback system.
4.1. Syslog Interface
The syslog message includes two parts: the HEADER and the MSG. The
packet records the device operation using ASCII text, and the length
of the packet should not exceed 1024 bytes. The minimum length of
the syslog message is not limited in this document.
4.1.1. Definition of HEADER Part
The HEADER part should include PRI,VERSION,TIMESTAMP,HOSTNAME,APP-
NAME,PROCID and MSGID. The PRI field indicates the log type. The
VERSION field denotes the version number of traceback log. The
HOSTNAME field identifies the device that originally sent the syslog
message. The TIMESTAMP field contains the timestamp of syslog
generation. The NAT device that generates the timestamp MUST use the
NTP protocol, to synchronize with other devices in the network. The
APP-NAME field identifies the device name that originated the log
message. The PROCID field is used to provide the log group which the
log belongs to. One log group indicates a group of operations
interrelated with each other, e.g., creating a translation table for
one session and removing this table. The MSGID field identifies the
type of the log messgae. The PRI,TIMESTAMP,HOSTNAME and MSGID are
mandatory fields, and the APP-NAME, PROCID are optional fields.
4.1.1.1. PRI
The PRI field is composed of Facility and Severity values. The
algorithm of PRI is defined as: PRI = Facility*8+Severity. The
definition of syslog function code (Facility) is shown in Figure 2.
Chen, et al. Expires January 4, 2013 [Page 5]
Internet-Draft Syslog Requirements for NAT Log July 2012
Code Value Facility
0 kernel messages
1 user-level messages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generated internally by syslog
6 line printer subsystem
7 network news subsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use 0 (local0)
17 local use 1 (local1)
18 local use 2 (local2)
19 local use 3 (local3)
20 local use 4 (local4)
21 local use 5 (local5)
22 local use 6 (local6)
23 local use 7 (local7)
Figure 2: Definition of Facility
In this document, the Facility value is denoted to be 16.
The definition of syslog severity code (Severity) is shown in
Figure 3.
Code Value Severity
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
Figure 3: Definition of Severity
In this document, the Severity value is denoted to be 6.
Chen, et al. Expires January 4, 2013 [Page 6]
Internet-Draft Syslog Requirements for NAT Log July 2012
4.1.1.2. VERSION
The VERSION filed is set to 1.
4.1.1.3. TIMESTAMP
The format of TIMESTAMP is as below:
< year> < mon> < day> < hh:mm:ss>
year indicates the year the operation happens, which must be four
digits, e.g., "2012". mon indicates month, and it could be one of the
following values:Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct,
Nov and Dec. day denotes the date, from 1 to 31. Hh, mm and ss
separately denote the hours, minutes and seconds.
4.1.1.4. HOSTNAME
The HOSTNAME field identifies the IPv4 address of the originating
device, which is in the format of the dotted decimal notation, e.g.,
10.1.1.1.
4.1.1.5. APP-NAME
The APP-NAME field identifies the name of the device that originated
the syslog message. It could be configured to the device by the
manager, denoting the type of device, deployment site and model.
4.1.1.6. PROCID
The PROCID field is used to provide the number for a log group (the
length of the number is suggested to be 16 bytes), which includes
digits and characters. It identifies the interrelated logs in one
device. The PROCID is allocated sequencely to the log group and
could be used repeatedly for the next allocation.
4.1.1.7. MSGID
The MSGID field identifies the type of the message. The format is
defined as: < device type>: < message type>. In the NAT444
environment, the device type is NAT444. In the DS-Lite environment,
the device type is DSLITE. The message type in MSGID includes:
o UserbasedA:this message is for user based log allocation.
o SessionbasedA:this message is for session based log allocation.
Chen, et al. Expires January 4, 2013 [Page 7]
Internet-Draft Syslog Requirements for NAT Log July 2012
o UserbasedW:this message is for user based log withdrawal.
o SessionbasedW:this message is for session based log withdrawal.
For example, the MSGID of user based log allocation for a DS-Lite
device is:DSLITE:userbasedA.
4.1.2. Definition of MSG Part
The MSG part uses the ASCII characters. It MUST include the
following contents:
o L4 application identification:1 indicates ICMP; 6 indicates TCP
and 17 indicates UDP.
o Original Source IP:Source IPv4 address before translation.
o Original Source IPv6:Source IPv6 address before translation.
o Translated Source IP:Source IPv4 address after translation.
o Original Port:Source port before translation.
o Translated First Source Port:The first source port after
translation, or source port after translation in session based
translation.
o Translated Last Source Port:The last source port after
translation.
The format of MSG part is:[<L4> < Original Source IP > < Original
Source IPv6> < Translated Source IP > < Original Port > < Translated
First Source Port > < Translated Last Source Port >]. for the
parameters not existed in certain type of devices, the "-" is used.
Two examples:
1. Session based UDP port mapping allocation in NAT444 case:[17
10.0.0.1 - 192.168.0.1 - 10000 11000].
2. Session based TCP port mapping allocation in DS-Lite case:[6 -
2001::1 192.168.1.1 80 80 -].
4.1.3. Examples
The following is an example of the syslog log message for user based
UDP allocation in NAT444 case: < 134> 1 2012 Jun 7 12:34:08 10.1.1.1
nat444-jiangsu - NAT444:userbasedA [17 10.0.0.1 - 192.168.0.1 - 10000
Chen, et al. Expires January 4, 2013 [Page 8]
Internet-Draft Syslog Requirements for NAT Log July 2012
11000].
4.2. The Radius Interface Requirements
The radius interface should use the Raidus message format defined in
[RFC2865] or [RFC2866]. for the first traceback solution introduced
above, there is no change to the radius interface. The syslog
message format is shown in section 4.1. for the solution 2, the
traceback information is carried in the radius Accounting-Request
packet. The attributes are extended as below:
| Sub-Attr|Sub-Attr|Maximum| Type|Description | Notes |
| Name |Number |Length | | | |
+---------+--------+-------+------+------------+----------------------+
| Vendor Extension:Vendor-ID is owned by each vendor |
+---------+--------+-------+------+------------+----------------------+
|USER-ADDR| 120 | 4 |Integ |Indicates |0-Public IPv4 user; |
|ESS-TYPE | | |er |users access|1-Private IPv4 user; |
| | | | |address type|2-Public DS user; |
| | | | | |3-Private DS user; |
| | | | | |4-DS-Lite user; |
| | | | | |5-Pure IPv6 user |
+---------+--------+-------+------+------------+----------------------+
|USER-ADDR| 121 | 253 |String|Stores |This field contains |
|ESS-LOG | | | |various log |mapping time, public |
| | | | |information |address,original port,|
| | | | |of NAT |destination port, |
| | | | |translation |user address, each |
| | | | | |separated by ":". |
| | | | | |Example: mapping time |
| | | | | |(YY/MM/DD/HH/MM/SS); |
| | | | | |public address (IPv4);|
| | | | | |user address (IPv4 or |
| | | | | |IPv6) |
+---------+--------+-------+------+------------+----------------------+
Figure 4: Attributes Extension
For the radius server, USER-ADDRESS-TYPE attribute should be carried
in the Accounting-Response message.
For the BRAS side: Vendor-ID is owned by each vendor. The sub-attr
name, sub-attr number and type could be defined by the vendor itself.
In the solution 2, the private attributes reported should be the
translated address and ports(source and destination).
In the traceback solution 3, NAT device reports the dynamic user
Chen, et al. Expires January 4, 2013 [Page 9]
Internet-Draft Syslog Requirements for NAT Log July 2012
address/port mapping information to the log server using Radius
message.
For the radius server, USER-ADDRESS-TYPE attribute should be carried
in the Accounting-Response message.
For the BRAS side: Vendor-ID is owned by each vendor. The sub-attr
name, sub-attr number and type could be defined by the vendor itself.
BRAS reports the user traceback information to AAA server, in a
delayed fixed time after sending the Accounting-Request message. Or
BARS sends the information to other ports of the AAA server for which
to collect the traceback information. In the solution 3, the private
attributes reported should be the user account, mapping time, private
address before translation, translated public address and
ports(source and destination).
5. The Performance Requirements of The Log Server
There are some requirements for the log server:
o The packet processing capability of a single log server to receive
syslog packet should not be less than 1,000 packets per second
(CPU occupation rate should not exceed 50%).
o The response time of a single log server to process syslog packet
should be less than or equal to 10 ms.
o The packet processing capability of a single log server to process
log packet using Radius message should not be less than 1,000
packets per second (CPU occupation rate should not exceed 50%)
o The response time of a single log server to process the log packet
using Radius should be less than or equal to 10 ms.
o The log should be stored in the storage system of the log server
for 6 months.
6. The Reliability Requirements of The Log Server
The requirements of reliability is listed as below:
o The system should meet or exceed 99.999% usability.
o The continuous work time without failure should be more than 100
thousand hours.
Chen, et al. Expires January 4, 2013 [Page 10]
Internet-Draft Syslog Requirements for NAT Log July 2012
o The failure recovery time should be less than 30 minutes.
o High reliability and stability. Main processor, main cache, power
and management interface should have hot standby capability.
o The server should have 1:1 backup.
o The blade system should support hot plug and pull.
7. IANA Considerations
No request to IANA.
8. Security Considerations
None.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog",
RFC 3195, November 2001.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
Security (TLS) Transport Mapping for Syslog", RFC 5425,
March 2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
RFC 5426, March 2009.
Chen, et al. Expires January 4, 2013 [Page 11]
Internet-Draft Syslog Requirements for NAT Log July 2012
Authors' Addresses
Zhonghua Chen
China Telecom
P.R. China
Phone:
Email: 18918588897@189.cn
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathy.zhou@huawei.com
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com
Chen, et al. Expires January 4, 2013 [Page 12]