Internet DRAFT - draft-zhou-behave-syslog-nat-logging
draft-zhou-behave-syslog-nat-logging
Internet Engineering Task Force Z. Chen
Internet-Draft China Telecom
Intended status: Standards Track C. Zhou
Expires: March 10, 2013 Huawei Technologies
T. Tsou
Huawei Technologies (USA)
T. Taylor
Huawei Technologies
September 6, 2012
Syslog Format for NAT Logging
draft-zhou-behave-syslog-nat-logging-01
Abstract
Under some circumstances operators will need to maintain a dynamic
record of external address and port assignments made by a Carrier
Grade NAT (CGN), and will find it feasible and convenient to create
such records using SYSLOG (RFC 5424). The present document
standardizes a SYSLOG format to meet that recording requirement. It
specifies a number of fields that could be a part of the log report,
leaving it up to operators to select the fields needed for their
specific circumstances.
[*** Subject to discussion*** The log format presented here may also
be used by PCP server implementations to log the mappings they
implement.]
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 March 10, 2013.
Copyright Notice
Chen, et al. Expires March 10, 2013 [Page 1]
Internet-Draft Syslog Format for NAT Logging September 2012
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
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. SYSLOG Record Format For NAT Logging . . . . . . . . . . . . . 4
2.1. SYSLOG HEADER Fields . . . . . . . . . . . . . . . . . . . 4
2.2. STRUCTURED-DATA Fields . . . . . . . . . . . . . . . . . . 5
2.2.1. Incoming IP Source Address Parameter . . . . . . . . . 5
2.2.2. Outgoing IP Source Address Parameter . . . . . . . . . 5
2.2.3. Incoming Source Port Parameter . . . . . . . . . . . . 5
2.2.4. Outgoing Source Port Parameter . . . . . . . . . . . . 5
2.2.5. Number of Port Numbers Parameter . . . . . . . . . . . 5
2.2.6. Highest Outgoing Port Number Parameter . . . . . . . . 5
2.2.7. Protocol Parameter . . . . . . . . . . . . . . . . . . 6
2.2.8. Subscriber Identifier Parameter . . . . . . . . . . . . 6
2.2.9. NAT Identifier Parameter . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Chen, et al. Expires March 10, 2013 [Page 2]
Internet-Draft Syslog Format for NAT Logging September 2012
1. Introduction
Operators already need to record the addresses assigned to
subscribers at any point in time, for operational and regulatory
reasons. When operators introduce Carrier Grade NATs (CGNs) into
their network, both addresses and ports on the external side of the
CGN are shared amongst subscribers. To trace back from an external
address and port observed at a given point in time to a specific
subscriber requires additional information: a record of which
subscriber was assigned that address and port by the NAT.
Address-port assignment strategies present a tradeoff between the
efficiency with which available external addresses are used, the cost
of maintaining a trace back capability, and the need to make port
assignments unpredictable to counter the threat of session hijacking.
At one extreme, the operator could make a one-time assignment of an
external address and a set of ports to each subscriber. Traceback
would then be a matter of retrieving configuration information from
the NAT. Even in this situation, it is possible that a request for
legal interception is placed against a specific subscriber, such that
each session involving that subscriber is recorded.
At the opposite extreme, a carrier could assign external addresses
and ports to subscribers on demand, in totally random fashion. Such
a strategy is not really practical, both because of the volume of
records that would be required to support a traceback capability, and
because the apparent gain in efficiency with which address-port
combinations would be utilized would be attenuated by the need to
leave address-port assignments idle for some minimum amount of time
after last observed use to make sure they weren't still being used.
Between these extremes, operators may choose to assign specific
addresses and specific blocks of ports to subscribers when they log
on to the network, releasing the assignments when they drop off.
Such a strategy could be desirable in networks with mobile
subscribers, in particular. Compared with the fully dynamic
strategy, this strategy reduces the number of times that assignments
have to be recorded by orders of magnitude.
The point just made is that under some circumstances operators need
to record allocations of external address-port combinations in the
NAT dynamically, and the volume of information contained in those
records is manageable. Various means are available to create such
records. This document assumes that for some operators, the most
convenient mechanism to do so will be event logging using SYSLOG
[RFC5424], where the SYSLOG records are generated either by the NAT
itself or by an off-line device.
Chen, et al. Expires March 10, 2013 [Page 3]
Internet-Draft Syslog Format for NAT Logging September 2012
The next section specifies a SYSLOG record format for logging of NAT
address and port assignments and the format of fields that could be
used within such a record. It is up to individual operators to
choose the fields that match their specific operating procedures.
1.1. 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].
2. SYSLOG Record Format For NAT Logging
This section describes the SYSLOG record format for NAT logging in
terms of the field names used in [RFC5424] and specified in Section 6
of that document. In particular, this section specifies values for
the APP-NAME and MSGID fields in the record header, the SD-ID
identifying the STRUCTURED-DATA section, and the PARAM-NAMEs and
PARAM-VALUE types for the individual possible parameters within that
section.
2.1. SYSLOG HEADER Fields
Within the HEADER portion of the SYSLOG record, the priority (PRI)
level is subject to local policy, but a default value of 86 is
suggested, representing a Facility value of 10 (security/
authorization) and a Severity level of 6 (informational). Depending
on where the SYSLOG record is generated, the HOSTNAME field may
identify the NAT or an offline logging device. In the latter case,
it may be desirable to identify the NAT using the NID field in the
STRUCTURED-DATA section (see below). The value of the HOSTNAME field
is subject to the preferences given in Section 6.2.4 of [RFC5424].
The values of the APP-NAME and MSGID fields in the record header
determine the semantics of the record. The RECOMMENDED APP-NAME
value "NAT" indicates that the record relates to an assignment made
autonomously by the NAT itself. [*** Subject to discussion*** The
RECOMMENDED APP-NAME "PCP" indicates that the assignment to which the
record refers was the result of a Port Control Protocol (PCP)
[I-D.PCP-Base] command.] The RECOMMENDED MSGID value "ADD" indicates
that the assignment took effect at the time indicated by the record
timestamp. The RECOMMENDED MSGID value "DEL" indicates that the
assignment was deleted at the time indicated by the record timestamp.
Chen, et al. Expires March 10, 2013 [Page 4]
Internet-Draft Syslog Format for NAT Logging September 2012
2.2. STRUCTURED-DATA Fields
This document specifies a value of "asgn" (short for "assignment")
for the SD-ID field identifying the STRUCTURED-DATA section of the
record. In addition it specifies the following parameters for use
within that section. All of these parameters are OPTIONAL. All
values that are IP addresses are written as a text string in dotted-
decimal form (IPv4) or as recommended by [RFC5952] (IPv6).
2.2.1. Incoming IP Source Address Parameter
PARAM-NAME: iSA. PARAM-VALUE: the incoming IP source address of the
packet(s) to which the assignment described by this record applies.
2.2.2. Outgoing IP Source Address Parameter
PARAM-NAME: oSA. PARAM-VALUE: the outgoing IP source address of the
packet(s) to the assignment described by which this record applies.
2.2.3. Incoming Source Port Parameter
PARAM-NAME: iSP. PARAM-VALUE: the incoming IP source port of the
packet(s) to the assignment described by which this record applies.
2.2.4. Outgoing Source Port Parameter
PARAM-NAME: oSP. PARAM-VALUE: the outgoing IP source port of the
packet(s) to which the assignment described by this record applies.
If the record pertains to the assignment of a range of ports, this
parameter gives the lowest port number in the range. In the case of
a range, either parameter oSPct or parameter oSPmx SHOULD also be
present in the log record.
2.2.5. Number of Port Numbers Parameter
PARAM-NAME: oSPct. PARAM-VALUE: used when the record pertains to the
assignment of a range of ports (either consecutive or generated by a
known algorithm). This parameter gives the number of port numbers in
the range.
2.2.6. Highest Outgoing Port Number Parameter
PARAM-NAME: oSPmx. PARAM-VALUE: used when the record pertains to the
assignment of a range of ports (either consecutive or generated by a
known algorithm). This parameter gives the highest port number in
the range.
Chen, et al. Expires March 10, 2013 [Page 5]
Internet-Draft Syslog Format for NAT Logging September 2012
2.2.7. Protocol Parameter
PARAM-NAME: Pr. PARAM-VALUE: an integer indicating the value of the
Protocol header field (IPv4) or Next Header field (IPv6) in the
incoming packet(s) to which the assignment described by this record
applies.
2.2.8. Subscriber Identifier Parameter
PARAM-NAME: SID. PARAM-VALUE: an arbitrary UTF-8 string identifying
the subscriber to which this assignment applies. This is intended to
provide flexibility when the incoming source address will not be
unique. The value could be a tunnel identifier, layer 2 address, or
any other value that is convenient to the operator and associated
with incoming packets.
2.2.9. NAT Identifier Parameter
PARAM-NAME: NID. PARAM-VALUE: an arbitrary UTF-8 string identifying
the NAT making the assignment to which this record applies. Needed
only if the necessary identification is not provided by the HOSTNAME
parameter in the log record header.
3. IANA Considerations
This document requests IANA to make the following assignments to the
SYSLOG Structured Data ID Values registry. RFCxxxx refers to the
present document when approved.
+----------------+--------------------+-----------------+-----------+
| Structured | Structured Data | Required or | Reference |
| Data ID | Parameter | Optional | |
+----------------+--------------------+-----------------+-----------+
| asgn | | OPTIONAL | RFCxxxx |
| | iSA | OPTIONAL | RFCxxxx |
| | oSA | OPTIONAL | RFCxxxx |
| | iSP | OPTIONAL | RFCxxxx |
| | oSP | OPTIONAL | RFCxxxx |
| | oSPct | OPTIONAL | RFCxxxx |
| | oSPmx | OPTIONAL | RFCxxxx |
| | Pr | OPTIONAL | RFCxxxx |
| | SID | OPTIONAL | RFCxxxx |
| | NID | OPTIONAL | RFCxxxx |
+----------------+--------------------+-----------------+-----------+
Table 1
Chen, et al. Expires March 10, 2013 [Page 6]
Internet-Draft Syslog Format for NAT Logging September 2012
4. Security Considerations
When logs are being recorded for regulatory reasons, preservation of
their integrity and authentication of their origin is essential. To
achieve this result, it is RECOMMENDED that the operator deploy
[RFC5848].
Access to the logs defined here while the reported assignments are in
force could improve an attacker's chance of hijacking a session
through port-guessing. Even after an assignment has expired, the
information in the logs SHOULD be treated as confidential, since, if
revealed, it could help an attacker trace sessions back to a
particular subscriber or subscriber location. It is therefore
RECOMMENDED that these logs be transported securely, using [RFC5425],
for example, and that they be stored securely at the collector.
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog
Messages", RFC 5848, May 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
Authors' Addresses
Zhonghua Chen
China Telecom
P.R. China
Phone:
Email: 18918588897@189.cn
Chen, et al. Expires March 10, 2013 [Page 7]
Internet-Draft Syslog Format for NAT Logging September 2012
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
T. Taylor
Huawei Technologies
Ottawa,
Canada
Phone:
Email: tom.taylor.stds@gmail.com
Chen, et al. Expires March 10, 2013 [Page 8]
