[BEHAVE] Fwd: [IANA #960326] [IANA]Re: AUTH48 [AC]: RFC 8158 <draft-ietf-behave-ipfix-nat-logging-13.txt> NOW AVAILABLE

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 10 August 2017 01:34 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE27132504 for <behave@ietfa.amsl.com>; Wed, 9 Aug 2017 18:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIRFcoRQV5NM for <behave@ietfa.amsl.com>; Wed, 9 Aug 2017 18:34:38 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC05E1324FD for <behave@ietf.org>; Wed, 9 Aug 2017 18:34:37 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id u207so50358648ywc.3 for <behave@ietf.org>; Wed, 09 Aug 2017 18:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OuNvDkoVKoVgZRiDlB+paoTPrBn2VlfdMII5w5RAebE=; b=VFH5O/rfVYt6W++oS3uuukL66iU5p0ZxCQHmGitX/pKANY5eiFQt339e3x0u3/C2br X3a15zoHujOOb9+WEWcVpzhgZfe68PIklL3MndWxXB4z1ulhmclJHjogrpVNGdvN//D9 25/opeEeWDPMMdeey87Dv/V0cMLdp3hdvblIxHm4J3XO5Nm3opIvIO//9Y6BaSEx2F6s 0GxIyKSmug3qjXg5b1wLJcQcO7H4gq8y3ci7DAtSGogwgB2B2p64mpoLzfnIv0VWd0ba 8wZYIeoCuwkqfOIawuVfw+SYqeGQjj9GmiLQftrn57vF1g8H3HQueLbduPQnfLgZVP8G HKcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OuNvDkoVKoVgZRiDlB+paoTPrBn2VlfdMII5w5RAebE=; b=Su2M6nXjzq64q3nfxAAA3kkdUSn1ECUz0RmRiBg4JaqZsD38kYgAH+vtnlsyOLNwdO 1oOrbeJc2oXUqSosZqrhs6Q9VGMLK9KhHcSKP1qIXxF/9CkPqS9FE5HizfpZHaeBqi6n Jw5xvqYv5qsehCOUzInjPcBXPa6JtWOY4jKwi+IL4Vdbfk7HL0CzcuFxPEqFs8pC7D0j NbrubZ+bYTR2ZYwKpAp8dneiC0lD2UHlK4IYe8S+Oix/ZqQu5k2EFc907JDxwNGECdO5 noZTpjcf+sSLdkzXBV423+OOgznkx278fVc6AZ8DLVHHamP9mbhTkFPHUbOpiYROxgeJ VRnQ==
X-Gm-Message-State: AHYfb5jRtRxACojyNFQBJS7r+eev/TE2GU5YO9ptL86WIDRHBvAS4oh4 JlBk6gu1JYmy6zsUhU1XZHY7NAJaTjpQ
X-Received: by 10.37.105.82 with SMTP id e79mr8239558ybc.39.1502328876788; Wed, 09 Aug 2017 18:34:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.52.79 with HTTP; Wed, 9 Aug 2017 18:34:36 -0700 (PDT)
In-Reply-To: <4C52614C-AB04-4C9C-95B9-7E2017FEFAC3@cisco.com>
References: <RT-Ticket-960326@icann.org> <20170426073142.17480B80D04@rfc-editor.org> <13D11F42-A841-49C4-BD93-B3EAA1E879A5@amsl.com> <6901FB90-8434-436D-A205-B3AFB0EB895D@cisco.com> <2EF41994-D2B7-4B56-88E8-C460BFD23882@cisco.com> <B229046B-CC7F-4466-8F67-873B9B87CD08@cisco.com> <323B2276-D33E-4481-A20B-487C68D1C60F@amsl.com> <rt-4.2.9-1306-1498684136-21.960326-9-0@icann.org> <2EAB88FF-9561-45F3-85BC-669D805C6980@cisco.com> <rt-4.2.9-1306-1498686375-1856.960326-9-0@icann.org> <rt-4.2.9-3439-1502126388-1057.960326-9-0@icann.org> <4C52614C-AB04-4C9C-95B9-7E2017FEFAC3@cisco.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 09 Aug 2017 20:34:36 -0500
Message-ID: <CAKKJt-cwMCdV5UsqpXNnTtgLBnVmE1XPVxZJ6EFruogN6L_-Wg@mail.gmail.com>
To: "behave@ietf.org" <behave@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c14e028099ec705565c3396"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/jMS5-Y2T_8JmsOIDQTu2qNrqumU>
Subject: [BEHAVE] Fwd: [IANA #960326] [IANA]Re: AUTH48 [AC]: RFC 8158 <draft-ietf-behave-ipfix-nat-logging-13.txt> NOW AVAILABLE
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2017 01:34:42 -0000

Dear Behavers,

The IE doctors have completed their review of this draft, and said the
configuredLimit IE was ambiguous because its meaning is context dependent,
and an unambiguous definition requires multiple IEs, one per limit.

Senthil has proposed an update that looks fine to me, but this is a
significant AUTH48 technical change, so I'd appreciate very much if other
interested parties would look it over as well.

Please reply with any feedback (and especially technical objections) on
this mailing list.

If I don't hear objections by Friday, August 18, I'll send the RFC Editor a
note approving the change.

And thank you all, of course.

The feedback from the IE doctors was this:

    The proposal provides no way to sanely represent more than one
    limit per flow. A flow containing more than one natconfiguredLimit
    element cannot be disambiguated.

    The proposed IE has no standalone meaning, but depends upon other
    IEs which cannot always be guaranteed to be present.

    The correct IPFIX solution requires multiple IEs, one per limit, so each
    has a unique meaning. Unfortunately this in turn means multiple
    templates, which makes the exporter implementation more difficult.

Senthil's requested change follows.

---------- Forwarded message ----------
From: Senthil Sivakumar (ssenthil) <ssenthil@cisco.com>
Date: Wed, Aug 9, 2017 at 10:43 AM
Subject: Re: [IANA #960326] [IANA]Re: AUTH48 [AC]: RFC 8158
<draft-ietf-behave-ipfix-nat-logging-13.txt> NOW AVAILABLE
To: "acerveny@amsl.com" <acerveny@amsl.com>
Cc: "spencerdawkins.ietf@gmail.com" <spencerdawkins.ietf@gmail.com>, "
rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "Reinaldo Penno
(repenno)" <repenno@cisco.com>


Dear RFC-Editors,
Given the IE-doctors have turned down the request to have a single
configuredLimit, I am requesting you to make the following changes to the
draft.
Majority of the changes are to the IANA section, to request the new IEs.
Please send me the updated version and I will review it before we resubmit
to IANA.

Thanks
Senthil

1. Section 4.6.7.1 Table 11:
a. Change configuredLimit to maxSessionEntries
2. Section 4.6.7.2 Table 12:
a. Change configuredLimit to maxBIBEntries
3. Section 4.6.7.3 Table 13
a. Change configuredLimit to maxEntriesPerUser
4. Section 4.6.7.4 Table 14
a. Change configuredLimit to maxSubscribers
5. Section 4.6.7.5 Table 15
a.      Change configuredLimit to maxFragmentsPendingReassembly
6. Section 4.6.8.1 Table 16:
a. Change configuredLimit to addressPoolHighThreshold/
addressPoolLowThreshold
7. Section 4.6.8.2 Table 17:
a. Change configuredLimit to addressPortMappingHighThreshold/
addressPortMappingLowThreshold
8. Section 4.6.8.3 Table 18:
a. Change configuredLimit to addressPortMappingHighThreshold/
addressPortMappingLowThreshold
9. Section 4.6.8.4 Table 19:
a. Change configuredLimit to globalAddressMappingHighThreshold
10. Section 4.2 Table 1:
a. Please add all the above new IEs to the end of the Table.
b. I noticed that the Table 1 is titled as “Template Format”. It should be
“NAT IE List”


Section 6 : IANA Considerations

6.1.7  maxSessionEntries

   ElementID: TBD

   Name: maxSessionEntries

   Description: This element represents the maximum session entries that
can be created by the NAT device.
   This limit is configured to prevent the resources of the device like
CPU, memory etc and to prevent any
   Denial of service attacks on the device. When the configured value is
reached a natQuotaExceeded event is
   generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.


6.1.8  maxBIBEntries

   ElementID: TBD

   Name: maxBIBEntries

   Description: This element represents the maximum BIB entries that can be
created by the NAT device.
   This limit is configured to prevent the resources of the device like
CPU, memory etc and to prevent any
   Denial of service attacks on the device. When the configured value is
reached a natQuotaExceeded event is
   generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.9  maxEntriesPerUser

   ElementID: TBD

   Name: maxEntriesPerUser

   Description: This element represents the maximum NAT entries that can be
created per user by the NAT device.
   This limit is configured to protect the resources of the device like
CPU, memory etc and to prevent any
   Denial of service attacks on the device. When the configured value is
reached a natQuotaExceeded event is
   generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.


6.1.10  maxSubscribers

   ElementID: TBD

   Name: maxSubscribers

   Description: This element represents the maximum subscribers or maximum
hosts that are allowed by the NAT device.
   This limit is configured to protect the resources of the device like
CPU, memory etc and to prevent any
   Denial of service attacks on the device. When the configured value is
reached a natQuotaExceeded event is
   generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.11  maxFragmentsPendingReassembly

   ElementID: TBD

   Name: maxFragmentsPendingReassembly

   Description: This element represents the maximum fragments that the NAT
device can store for reassembling the packet.
   This limit is configured to protect the resources of the device like
CPU, memory etc and to prevent any
   Denial of service attacks on the device. When the configured value is
reached a natQuotaExceeded event is
   generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.12  addressPoolHighThreshold

   ElementID: TBD

   Name: addressPoolHighThreshold

   Description: This element represents the high threshold value of the
number of public IP addresses in the address pool.
   This could serve as a warning message to the administrator that the
address pool is running out and the network
   administrator would have to take corrective action. When the configured
value is reached a natThresholdEvent event is generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.13  addressPoolLowThreshold

   ElementID: TBD

   Name: addressPoolLowThreshold

   Description: This element represents the low threshold value of the
number of public IP addresses in the address pool.
   This could serve as a warning message to the administrator that the
address pool is under-utilized and the network
   administrator would have to take corrective action. When the configured
value is reached a natThresholdEvent event
   is generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.14  addressPortMappingHighThreshold

   ElementID: TBD

   Name: addressPortMappingHighThreshold

   Description: This element represents the high threshold value of the
number of address and port mappings.
   A device doing NAPT uses ports in a public address to multiplex multiple
hosts, which results in address and port mapping
   representing a flow or connection. When high threshold is reached, it
could serve as a warning message
   to the administrator that the address pool is running out and the
network administrator would have to take corrective
   action. When the configured value is reached a natThresholdEvent event
is generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.15  addressPortMappingLowThreshold

   ElementID: TBD

   Name: addressPoolLowThreshold

   Description: This element represents the low threshold value of the
number of address and port mappings.
   A device doing NAPT uses ports in a public address to multiplex multiple
hosts, which results in address and port mapping
   representing a flow or connection. When low threshold is reached,  it
could serve as a warning message
   to the administrator that the address pool is under-utilized and the
network administrator may have to take corrective
   action. When the configured value is reached a natThresholdEvent event
is generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.16  addressPortMappingPerUserHighThreshold

   ElementID: TBD

   Name: addressPortMappingPerUserHighThreshold

   Description: This element represents the high threshold value of the
number of address and port mappings that a
   single user is allowed to create on a NAT device. A device doing NAPT
uses ports in a public address to multiplex multiple
   hosts, which results in address and port mapping representing a flow or
connection. When high threshold is reached,
   it could serve as a warning message to the administrator that a single
user has reached a threshold and the network
   administrator may have to take corrective action. When the configured
value is reached a natThresholdEvent event is generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes.

6.1.17  globalAddressMappingHighThreshold

   ElementID: TBD

   Name: globalAddressMappingHighThreshold

   Description: This element represents the high threshold value of the
number of address and port mappings that a
   single user is allowed to create on a NAT device in a paired address
pooling behavior. A device doing NAPT uses ports
   in a public address to multiplex multiple hosts, which results in
address and port mapping representing a flow or connection.
   When high threshold is reached, it could serve as a warning message to
the administrator that a single user has reached
   a threshold and the network administrator may have to take corrective
action. When the configured value is reached
   a natThresholdEvent event is generated.

   Abstract Data Type: unsigned32

   Data Type Semantics: identifier

   Reference:
   See [RFC3022] for the definition of NAT.  See [RFC3234] for the
   definition of middleboxes. See [RFC4787] for the definition of
   paired address pooling behavior