Subject: [BEHAVE] Fwd: New Version Notification for draft-ietf-behave-syslog-nat-logging-03.txt

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Sep 2013 22:40:36 -0400

I have submitted an update, but THIS IS A PARTIAL UPDATE, CONSISTENT 
ONLY THROUGH SECTION 3. Section 4 is probably OK too, but I haven't 
reviewed it. While I propagate the changes through the rest of the 
document, I would appreciate any comments on Sections 1-3 as they stand.

Dave T., I'm afraid I didn't fold in the editorial changes you provided 
a link to in your pre-meeting review. Next update I'll look them over.

Tom Taylor

Major changes:

1. Adopted new definition of session (includes destination) from 
RFC6164. This distinguishes the session from BIB entries.

2. New Sec. 2.2 discusses realms and address pools. Beginning in this 
section, realigned terminology to talk about internal and external 
realms, addresses, and ports rather than various other terms. Realms are 
added as parameters of most of the event reports defined in Section 3.

3. New Sec. 2.3.1 introduces the generalized address in place of the 
subscriber site identifier. This is encoded as 
type-address-address/prefix length, but the types include IPv4, IPv6, 
and GW-initiated DS-Lite SWID. The GW-initiated DS-Lite context is 
characterized as a realm. In Section 3, got rid of the assumption that a 
mapping or session always involved a subscriber, where this was not 
necessary. Pulled the material that used to talk about subscriber site 
ID out of the introductory Section 3.

4. Got rid of the reporting device identifier optional parameter. 
Discussion on the OPSAWG list suggested we could get away with 
specifying that the HOSTNAME in the SYSLOG header always identifies the 
NAT device.

5. In Section 3.1, the session creation and deletion events always 
report destination address and port. The discussion of destination 
logging in Section 3.1.1 was modified to discourage destination logging 
but not forbid it. A proposal was added for a special study capability 
to enable destination logging only on a specified set of addresses.

6. BIB entry creation/deletion event added back in new Sec. 3.2, since 
it is now clearly distinguishable from sessions.

7. Port set allocation and deallocation in Sec. 3.4 now uses same 
notation as IPFIX, but I think Senthil and I have a basic disagreement 
on the semantics of that notation. The SYSLOG semantics are clearly 
spelled out in Sec. 3.4, with examples.

8. Took out the previous address exhausted and ports exhausted events 
(and the invalid port event, for other reasons) and replaced them with 
events based on the thresholds and limits in the NAT MIB. Hence new 
sections:
      3.5.  Address Pool High- and Low-Water-Mark Threshold Events  .  16
      3.6.  Global Address Mapping High-Water-Mark Threshold Event  .  17
      3.7.  Global Address Mapping Limit Exceeded . . . . . . . . . .  17
      3.8.  Global Transport Mapping High-Water-Mark Threshold Event   18
      3.9.  Global Transport Mapping Limit Exceeded . . . . . . . . .  18
      3.10. Subscriber-Specific Mapping Threshold Event . . . . . . .  19
      3.11. Global Limit On Number of Active Subscribers Exceeded . .  20
      3.12. Subscriber-Specific Limit On Number of Transport Mappings
            Exceeded  . . . . . . . . . . . . . . . . . . . . . . . .  21
      3.14. Global Limit On Number Of Fragments Pending Reassembly
            Exceeded

9. The Quota Exceeded event in Sec. 3.13 was simplified as suggested in 
the meeting.

-------- Original Message --------
Subject: New Version Notification for 
draft-ietf-behave-syslog-nat-logging-03.txt
Date: Fri, 20 Sep 2013 19:05:00 -0700
From: [email-masked]
To: Tina Tsou <[email-masked]>, T. Taylor 
<[email-masked]>, Tom Taylor <[email-masked]>, 
Cathy Zhou <[email-masked]>, Zhonghua Chen <[email-masked]>

A new version of I-D, draft-ietf-behave-syslog-nat-logging-03.txt
has been successfully submitted by Zhonghua Chen and posted to the
IETF repository.

Filename:	 draft-ietf-behave-syslog-nat-logging
Revision:	 03
Title:		 Syslog Format for NAT Logging
Creation date:	 2013-09-21
Group:		 behave
Number of pages: 38
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-behave-syslog-nat-logging-03.txt
Status: 
http://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging
Htmlized: 
http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-03
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-syslog-nat-logging-03

Abstract:
    With the wide deployment of Carrier Grade NAT (CGN) devices, the
    logging of NAT-related events has become very important for various
    operational purposes.  The logs may be required for troubleshooting,
    to identify a host that was used to launch malicious attacks, and/or
    for accounting purposes.  This document identifies the events that
    need to be logged and the parameters that are required in the logs
    depending on the context in which the NAT is being used.  It goes on
    to standardize formats for reporting these events and parameters
    using SYSLOG (RFC 5424).  A companion document specifies formats for
    reporting the same events and parameters using IPFIX (RFC 5101).
    Applicability statements are provided in this document and its
    companion to guide operators and implementors in their choice of
    which technology to use for logging.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tom Taylor <[email-masked]>
Date: Sat, 21 Sep 2013 11:45:24 -0400

I see I missed deleting reporting device identifier from a number of 
events. Will be done in -04 update.

> a link to in your pre-meeting review. Next update I'll look them over.
...
> specifying that the HOSTNAME in the SYSLOG header always identifies the
...

---

From: Tom Taylor <[email-masked]>
Date: Sun, 22 Sep 2013 11:48:32 -0400

Minor changes: on review, "triggering NAT procedure" didn't seem all 
that useful. Reverted to "reporting NAT type". Also replaced "transport 
mapping" with "BIB entry creation" in a number of places to make things 
a bit more consistent.

Bigger change: re-reading GI DS-Lite, I see I got the roles of CID and 
SWID reversed. The CID is actually the individual site identifier, and 
SWID the tunnel identifier between the gateway and the AFTR. So I'll 
identify SWID with the realm and use the value of CID with a stated bit 
length (since RFC 6674 only says it is "usually" 32 bits wide) as the 
generalized address.

...