From simon.perreault@viagenie.ca Mon Dec 2 06:17:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63961ACCEB for ; Mon, 2 Dec 2013 06:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 b1yfmxojf7UB for ; Mon, 2 Dec 2013 06:17:05 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88CD01A8028 for ; Mon, 2 Dec 2013 06:17:05 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:a026:cb8a:38b3:bc43]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0C5134038D for ; Mon, 2 Dec 2013 09:17:03 -0500 (EST) Message-ID: <529C965E.9080405@viagenie.ca> Date: Mon, 02 Dec 2013 09:17:02 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 14:17:08 -0000 Le 2013-11-30 23:37, Senthil Sivakumar (ssenthil) a écrit : > A new version that incorporates comments from Tom and others, please > review. > At this time, the only outstanding issue with respect to the ipfix and > syslog is the port block > Allocation and deallocation schemes and parameters, for which we need some > input from others. What are the issues or open questions? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Mon Dec 2 11:03:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E1B1AD94A for ; Mon, 2 Dec 2013 11:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 YBH-9jIyVlmv for ; Mon, 2 Dec 2013 11:03:13 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5D71AD8C4 for ; Mon, 2 Dec 2013 11:03:13 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so21143084ieb.22 for ; Mon, 02 Dec 2013 11:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ry/cJGvIF1a5XEZAnfwqdfpxHZUxLwppLAU60ZsNEd8=; b=Epf7FGbtYqrm12msoPlYiDY1HTfDvP88ZiZg2v6PXNTqh/+jZaXUgks3emuSUC61tU qrowP3u3BD/7MxToMmRHjdTJuIDJCHGkUf7xbRate5N4F9qXyj3ZbU3MoI/K8qWgrSLx QIrZXKF2E3EEsqX/zRVA+TVn1NtpFKWcEXcyUc0s+JwuQl22o1uUeQwv94XdJPqbXyF3 Vk8blUeGr2TNzvEYotHl0shqxBmkuI+L5xDQPnuPxr+/IRMNDSmy9PvAuGM7ELZZnnqJ wqFco5FRU6B1kxbz3QiwUXUxojFy1XDjI/P779rzx+OqNI0RJn5qV+jf/FwIchmG/Mwp aVVw== X-Received: by 10.50.110.74 with SMTP id hy10mr150471igb.0.1386010991104; Mon, 02 Dec 2013 11:03:11 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id da14sm27762121igc.1.2013.12.02.11.03.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 11:03:10 -0800 (PST) Message-ID: <529CD96C.6080602@gmail.com> Date: Mon, 02 Dec 2013 14:03:08 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Simon Perreault , behave@ietf.org, Senthil Sivakumar References: <529C965E.9080405@viagenie.ca> In-Reply-To: <529C965E.9080405@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:03:15 -0000 On 02/12/2013 9:17 AM, Simon Perreault wrote: > Le 2013-11-30 23:37, Senthil Sivakumar (ssenthil) a écrit : >> A new version that incorporates comments from Tom and others, please >> review. >> At this time, the only outstanding issue with respect to the ipfix and >> syslog is the port block >> Allocation and deallocation schemes and parameters, for which we need >> some >> input from others. > > What are the issues or open questions? > > Simon In going through the updated IPFIX draft and comparing it with the MIB and SYSLOG draft, I note the following issues: 1. Both the IPFIX draft and the SYSLOG draft have to be updated to report the NAT instance number/alias. Action: update both drafts. 2. Definition of session: taken from RFC 2663 in the IPFIX draft. The SYSLOG draft mistakenly says that is wrong. (Don't know how I misread that.) Action: change the SYSLOG draft to use the same reference. 3. vlanID and ingressVRFID appear in the list of IPFIX parameters, but not in the SYSLOG list. Please tell me definitively whether vlanID/ingressVRFID is implied by realm identifier or supplements it. Action: if the other two parameters are implied by realm identifier, remove them from IPFIX. If not, add them to SYSLOG. 4. By implication (since external realm is unspecified), IPFIX allows only one destination realm, hence does not support hairpinning between the same or different internal realms. SYSLOG and the MIB support multiple destination realms. Action: add destination realm to IPFIX. 5. IPFIX does not support identification of the subscriber site except in the case of simple NAT44 or NAT64. In particular, the source IPv4 address for DS-Lite will always be the same, regardless of which subscriber it comes from. Action: add explicit site identifier parameters, in the variants supported by SYSLOG: IPv4 address, IPv6 address, GRE key, MPLS label, IPv6 Flow Label. 6. IPFIX makes the destination data optional in the create and delete session events. I've already remarked on this -- it doesn't make sense, since by omitting the destination data you end up generating a whole lot of events that carry the same information as the corresponding BIB event (except for event type and timestamp) and therefore add little value. Action: make destination data mandatory in IPFIX session events? Otherwise, provide text on relationship between the session and BIB events and when type of event should be enabled vs. the other. 7. Editorial: natPoolName appears in Table 8 but not in Table 1 of the IPFIX document. Action: add to Table 1. 8. The IPFIX addresses exhausted event is pool-specific, where the MIB and SYSLOG events are based on a global limit on address mappings. These are obviously monitoring different resources (memory vs. addresses in a given pool). The MIB and SYSLOG monitor pool address-port utilization using threshold events, which IPFIX lacks. Action: agree on a common set of events and bring all three drafts into line. 9. The IPFIX ports exhausted event is specific to a given global IPv4 address. SYSLOG and the MIB have no equivalent. Action: as for the previous item. 10. Editorial: natLimitEvent appears in Table 10 but not in Table 1 of the IPFIX document. Action: add to Table 1. 11. No natEvent parameter to distinguish port allocation from port deallocation in IPFIX. Action: add parameter to Table 12 template. 12. IPFIX document lacks cross-reference to corresponding MIB objects. Action: add text giving corresponding cross-references. 13. Not sure how to interpret the IPFIX quota events: as threshold crossings or as hard limits. If the latter, IPFIX is missing the threshold events: -- address pool port utilization (already mentioned) -- BIB entries, global and per user Action: I think IPFIX has to add the threshold events. 14. IPFIX does not record limit on maximum active users or maximum pending fragments exceeded events. Action: I think the fragment event for sure is operationally useful and should be added to IPFIX. We can discuss the limit on active users, which came from the MIB. 15. The SYSLOG generalized quota event originally came out of my misunderstanding of the IPFIX quota event. I'm willing to drop it if it does not correspond to NAT reality. Action: discuss need for the event, and if we conclude it is unnecessary, delete it from SYSLOG and the MIB. Tom Taylor From simon.perreault@viagenie.ca Mon Dec 2 14:00:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C801A1ADF91 for ; Mon, 2 Dec 2013 14:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 p04a7xw7mzUd for ; Mon, 2 Dec 2013 14:00:05 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE21ADF8B for ; Mon, 2 Dec 2013 14:00:05 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:a026:cb8a:38b3:bc43]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BBBAA468EC; Mon, 2 Dec 2013 17:00:02 -0500 (EST) Message-ID: <529D02E2.2090303@viagenie.ca> Date: Mon, 02 Dec 2013 17:00:02 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tom Taylor , behave@ietf.org, Senthil Sivakumar References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> In-Reply-To: <529CD96C.6080602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:00:08 -0000 Thanks a lot for this list Tom! Replying to the few ones that I can help move forward... Le 2013-12-02 14:03, Tom Taylor a écrit : > 4. By implication (since external realm is unspecified), IPFIX allows > only one destination realm, hence does not support hairpinning between > the same or different internal realms. SYSLOG and the MIB support > multiple destination realms. > > Action: add destination realm to IPFIX. I don't follow the implication on hairpinning. The way I read the IPFIX draft, only the internal realm is recorded (natOriginatingAddressRealm). So the problem is that the external realm is missing. Is that it? > 6. IPFIX makes the destination data optional in the create and delete > session events. I've already remarked on this -- it doesn't make sense, > since by omitting the destination data you end up generating a whole lot > of events that carry the same information as the corresponding BIB event > (except for event type and timestamp) and therefore add little value. I don't follow this reasoning. Why would omitting information cause more logging events to be generated? In addition, CGN requirements [RFC6888] contain the following: REQ-12: A CGN SHOULD NOT log destination addresses or ports unless required to do so for administrative reasons. Justification: Destination logging at the CGN creates privacy issues. Furthermore, readers should be aware of logging recommendations for Internet-facing servers [RFC6302]. With compliant servers, the destination address and port do not need to be logged by the CGN. This can help reduce the amount of logging. > 8. The IPFIX addresses exhausted event is pool-specific, where the MIB > and SYSLOG events are based on a global limit on address mappings. Not sure I understand. The MIB has both global and pool-specific notifications. > These > are obviously monitoring different resources (memory vs. addresses in a > given pool). The MIB and SYSLOG monitor pool address-port utilization > using threshold events, which IPFIX lacks. > > Action: agree on a common set of events and bring all three drafts into > line. > > 9. The IPFIX ports exhausted event is specific to a given global IPv4 > address. SYSLOG and the MIB have no equivalent. > > Action: as for the previous item. Right, this has to be pool-specific and global. Nobody cares that a single external IP address is full. In addition, it looks like this even only handles external *IPv4* addresses. Can it be made version-agnostic? > 15. The SYSLOG generalized quota event originally came out of my > misunderstanding of the IPFIX quota event. I'm willing to drop it if it > does not correspond to NAT reality. > > Action: discuss need for the event, and if we conclude it is > unnecessary, delete it from SYSLOG and the MIB. I'd be fine with dropping it from the MIB. Let me know if we have consensus. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Mon Dec 2 14:51:35 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204C71ADF46 for ; Mon, 2 Dec 2013 14:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 S-WFjkC6PP8U for ; Mon, 2 Dec 2013 14:51:33 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 14F891ADDCA for ; Mon, 2 Dec 2013 14:51:33 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so22094753iec.41 for ; Mon, 02 Dec 2013 14:51:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FmrZ6hwlpQD1CSfHVhXiUQw/+CfJOOqfCkA7RSUeMrA=; b=MYzQl9GXXAiRguEMO4idKsVysQL6S3gqcYSKCB+3W6U6wzUWS1i7tZeSXjo6D96T9r uBqAzxkzKZE6HlRPXPYsw7230jkRMWcXTUMQdRHT9A56DKXPsvoB5+GfOeLGIyTjZ9c+ iZKS4+j20LMmmMGuBGzd6tF1NiQ6yzYnOHFGTvGsDCUbFQYa6kv1ddeGMf7Q14kGk7A+ acwNpHDl+I4jZMEaG5LsbsfG+bScPY15904pYvbMpBjskWpLkwEqMNW04PFtvmH6gaph qhne9pxHGZo63itho0VlK4PO+BhYHzU7Se7ygcrk6xNau4JG/6fsbeH/z4OJhu1AQCi5 GMgg== X-Received: by 10.50.1.102 with SMTP id 6mr20474535igl.0.1386024690570; Mon, 02 Dec 2013 14:51:30 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id a17sm33181571ign.2.2013.12.02.14.51.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 14:51:29 -0800 (PST) Message-ID: <529D0EEF.3090409@gmail.com> Date: Mon, 02 Dec 2013 17:51:27 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Simon Perreault , behave@ietf.org, Senthil Sivakumar References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529D02E2.2090303@viagenie.ca> In-Reply-To: <529D02E2.2090303@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:51:35 -0000 On 02/12/2013 5:00 PM, Simon Perreault wrote: > Thanks a lot for this list Tom! > > Replying to the few ones that I can help move forward... > > Le 2013-12-02 14:03, Tom Taylor a écrit : >> 4. By implication (since external realm is unspecified), IPFIX allows >> only one destination realm, hence does not support hairpinning between >> the same or different internal realms. SYSLOG and the MIB support >> multiple destination realms. >> >> Action: add destination realm to IPFIX. > > I don't follow the implication on hairpinning. The way I read the IPFIX > draft, only the internal realm is recorded (natOriginatingAddressRealm). > So the problem is that the external realm is missing. Is that it? [PTT] Agreed, the real problem is that external realm is missing. I was following through on one implication, but that isn't necessary. > >> 6. IPFIX makes the destination data optional in the create and delete >> session events. I've already remarked on this -- it doesn't make sense, >> since by omitting the destination data you end up generating a whole lot >> of events that carry the same information as the corresponding BIB event >> (except for event type and timestamp) and therefore add little value. > > I don't follow this reasoning. Why would omitting information cause more > logging events to be generated? > > In addition, CGN requirements [RFC6888] contain the following: > > REQ-12: A CGN SHOULD NOT log destination addresses or ports unless > required to do so for administrative reasons. > > Justification: Destination logging at the CGN creates privacy > issues. Furthermore, readers should be aware of logging > recommendations for Internet-facing servers [RFC6302]. With > compliant servers, the destination address and port do not need to > be logged by the CGN. This can help reduce the amount of logging. [PTT] My argument is that you shouldn't log session events at all unless they have destination data. Otherwise you are just duplicating the BIB events, except that you are providing a timestamp for each new session the user creates. I'm not sure that little bit of additional information is useful for anything. > >> 8. The IPFIX addresses exhausted event is pool-specific, where the MIB >> and SYSLOG events are based on a global limit on address mappings. > > Not sure I understand. The MIB has both global and pool-specific > notifications. [PTT] I'm talking about hard limits here. The pool-specific MIB notifications are threshold crossings, as I mention in the next sentence. > >> These >> are obviously monitoring different resources (memory vs. addresses in a >> given pool). The MIB and SYSLOG monitor pool address-port utilization >> using threshold events, which IPFIX lacks. >> >> Action: agree on a common set of events and bring all three drafts into >> line. >> >> 9. The IPFIX ports exhausted event is specific to a given global IPv4 >> address. SYSLOG and the MIB have no equivalent. >> >> Action: as for the previous item. > > Right, this has to be pool-specific and global. Nobody cares that a > single external IP address is full. > > In addition, it looks like this even only handles external *IPv4* > addresses. Can it be made version-agnostic? [PTT] I didn't mention that, but I was just reviewing conclusions out of the Berlin meeting and Dave Thaler's earlier comments and one item was to generalize the external address family. > >> 15. The SYSLOG generalized quota event originally came out of my >> misunderstanding of the IPFIX quota event. I'm willing to drop it if it >> does not correspond to NAT reality. >> >> Action: discuss need for the event, and if we conclude it is >> unnecessary, delete it from SYSLOG and the MIB. > > I'd be fine with dropping it from the MIB. Let me know if we have > consensus. > > Simon From ssenthil@cisco.com Mon Dec 2 17:51:25 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7C21AE020 for ; Mon, 2 Dec 2013 17:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3xQte6qG564s for ; Mon, 2 Dec 2013 17:51:23 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2757B1AE009 for ; Mon, 2 Dec 2013 17:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6991; q=dns/txt; s=iport; t=1386035481; x=1387245081; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ltRqYl7sPPxo1LVgGacnNRkrb2U5w8/13QvOqP0ZRp4=; b=hr1WrlIqNYlRjVwCaBDRLxnz7OkC/0g/E0HEgLBU00RLtH8VaUzpaAoG Y4FX4S8rvrAIIwu7O2mTZZQ0k5XfEl0lx3+NHUPxUtt3RvakMwXEGmmPO IfaUPR9OYLlj3gMosG0myptegkAH697lrVBBLM01Iv4tfhnUFGxY+FGvm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAF84nVKtJXG9/2dsb2JhbABPCoMHgQu4aIEaFnSCJQEBAQRyBRICAQgYLiERHAkCBAESh28DD7kiDYc7F4x3gTAFBQoaOoQzA5YpgWuMWoU5gWuBPoFpQQ X-IronPort-AV: E=Sophos;i="4.93,814,1378857600"; d="scan'208";a="288909785" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 03 Dec 2013 01:51:20 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB31pKQ7029819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 01:51:20 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 19:51:19 -0600 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt Thread-Index: AQHO75ErkWb2CnXqIEmBVl1xKoUBeZpBxeuA Date: Tue, 3 Dec 2013 01:51:19 +0000 Message-ID: References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> In-Reply-To: <529CD96C.6080602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.51.58] Content-Type: text/plain; charset="windows-1254" Content-ID: <419BF0733F83F54CAFC06B3458017C57@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 01:51:25 -0000 Thanks for the exhaustive list, please see inline. On 12/2/13 2:03 PM, "Tom Taylor" wrote: >On 02/12/2013 9:17 AM, Simon Perreault wrote: >> Le 2013-11-30 23:37, Senthil Sivakumar (ssenthil) a =E9crit : >>> A new version that incorporates comments from Tom and others, please >>> review. >>> At this time, the only outstanding issue with respect to the ipfix and >>> syslog is the port block >>> Allocation and deallocation schemes and parameters, for which we need >>> some >>> input from others. >> >> What are the issues or open questions? >> >> Simon > >In going through the updated IPFIX draft and comparing it with the MIB >and SYSLOG draft, I note the following issues: > >1. Both the IPFIX draft and the SYSLOG draft have to be updated to >report the NAT instance number/alias. > >Action: update both drafts. Ok, the instance number would be an optional logging parameter. =20 > >2. Definition of session: taken from RFC 2663 in the IPFIX draft. The >SYSLOG draft mistakenly says that is wrong. (Don't know how I misread >that.) > >Action: change the SYSLOG draft to use the same reference. > >3. vlanID and ingressVRFID appear in the list of IPFIX parameters, but >not in the SYSLOG list. Please tell me definitively whether >vlanID/ingressVRFID is implied by realm identifier or supplements it. > >Action: if the other two parameters are implied by realm identifier, >remove them from IPFIX. If not, add them to SYSLOG. The original intent of the realm identifier is to indicate the private/public Address domains and not to overload that with the VRFID/VlanIDs. I can remove the vlan/vrf from IPFIX but is there a way to identify the originator of the traffic was in private/public realm or that is to be somehow derived from the realm Ids? > >4. By implication (since external realm is unspecified), IPFIX allows >only one destination realm, hence does not support hairpinning between >the same or different internal realms. SYSLOG and the MIB support >multiple destination realms. > >Action: add destination realm to IPFIX. I would like to see that the destination realm be optional, the lack of destination realm will mean that the traffic was originated from private to public and there is only one public. Any issues with that? > >5. IPFIX does not support identification of the subscriber site except >in the case of simple NAT44 or NAT64. In particular, the source IPv4 >address for DS-Lite will always be the same, regardless of which >subscriber it comes from. > >Action: add explicit site identifier parameters, in the variants >supported by SYSLOG: IPv4 address, IPv6 address, GRE key, MPLS label, >IPv6 Flow Label. You mean in the IPFIX draft? I will have to re-read the syslog draft to see=20 What is done there. > >6. IPFIX makes the destination data optional in the create and delete >session events. I've already remarked on this -- it doesn't make sense, >since by omitting the destination data you end up generating a whole lot >of events that carry the same information as the corresponding BIB event >(except for event type and timestamp) and therefore add little value. It was already clarified in our old exchange, as below. /START > >7. IPFIX session event makes destination address and port information >optional. A session event without that information is identical to a BIB >event, so there is no point in reporting it. Shouldn't destination info >be mandatory? The destination information is not mandatory. There are nat44 implementations has a session database but doesn=B9t need to log the destination informatio= n. You can call that as BIB, but that is purely semantics on how you want to call that as. END/ > >Action: make destination data mandatory in IPFIX session events? >Otherwise, provide text on relationship between the session and BIB >events and when type of event should be enabled vs. the other. You either generate session or BIB if destination information is optional. I don=92t see why it causes additional events. I don=92t understand why it = is Confusing, but I will add some text here. > >7. Editorial: natPoolName appears in Table 8 but not in Table 1 of the >IPFIX document. > >Action: add to Table 1. Ok. > >8. The IPFIX addresses exhausted event is pool-specific, where the MIB >and SYSLOG events are based on a global limit on address mappings. These >are obviously monitoring different resources (memory vs. addresses in a >given pool). The MIB and SYSLOG monitor pool address-port utilization >using threshold events, which IPFIX lacks. > >Action: agree on a common set of events and bring all three drafts into >line. When would the global address exhausted event be generated by a NAT device? The address exhausted event is triggered when a subscriber/packet requires an address to be allocated and the subscribed/packet would be pointing to a single pool (based on some classification mechanism), if that pool is full, an address exhausted event is generated. There can be other pools that have addresses in them (or not) but a nat device doesn=92t check if all pools ar= e exhausted. > >9. The IPFIX ports exhausted event is specific to a given global IPv4 >address. SYSLOG and the MIB have no equivalent. > >Action: as for the previous item. I will make the ports exhausted specific to a pool in IPFIX draft. > >10. Editorial: natLimitEvent appears in Table 10 but not in Table 1 of >the IPFIX document. > >Action: add to Table 1. Ok. > >11. No natEvent parameter to distinguish port allocation from port >deallocation in IPFIX. > >Action: add parameter to Table 12 template. Ok. > >12. IPFIX document lacks cross-reference to corresponding MIB objects. > >Action: add text giving corresponding cross-references. > >13. Not sure how to interpret the IPFIX quota events: as threshold >crossings or as hard limits. If the latter, IPFIX is missing the >threshold events: >-- address pool port utilization (already mentioned) >-- BIB entries, global and per user > >Action: I think IPFIX has to add the threshold events. Hard limits. What is the assumption in syslog draft? Is it free flowing and you can add whichever threshold event? I know in mib we have threshold crossings. > >14. IPFIX does not record limit on maximum active users or maximum >pending fragments exceeded events. > >Action: I think the fragment event for sure is operationally useful and >should be added to IPFIX. We can discuss the limit on active users, >which came from the MIB. > >15. The SYSLOG generalized quota event originally came out of my >misunderstanding of the IPFIX quota event. I'm willing to drop it if it >does not correspond to NAT reality. > >Action: discuss need for the event, and if we conclude it is >unnecessary, delete it from SYSLOG and the MIB. Ok. > >Tom Taylor > From ssenthil@cisco.com Mon Dec 2 17:54:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3051AE026 for ; Mon, 2 Dec 2013 17:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ENpRPc6x1Ls0 for ; Mon, 2 Dec 2013 17:54:14 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id B0CBA1AE020 for ; Mon, 2 Dec 2013 17:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3555; q=dns/txt; s=iport; t=1386035652; x=1387245252; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZK4scCRqudJH3oTXkXykFVEs4gT20x0lSpdxzCixCSA=; b=coEMzN6qICS6aMiQ6MGXL5TUc+P37jJtCFO9Dec3W2vk9xjnieE4j9iN yB9doBQn8LR/RQ2Xf72fiQqfTeljM3P+xS17WOfo6KaLo/nvrsDg9fqy2 cxSGNm31TmSVpTs/Aa4AVkgIoVNvI13+KTrQwbg84QoRUFXUSTIqcIEst Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHU5nVKtJXG//2dsb2JhbABZgwc4U7hogRkWdIIlAQEBAwEnUBICAQhGMhwJAgQBEod7BsEDjjEKVIQzA4kKjwqBMJBjgWuBPoFpQQ X-IronPort-AV: E=Sophos;i="4.93,814,1378857600"; d="scan'208";a="3817311" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 03 Dec 2013 01:54:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB31sBoO004318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 01:54:11 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 19:54:11 -0600 From: "Senthil Sivakumar (ssenthil)" To: Simon Perreault , Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt Thread-Index: AQHO75ErkWb2CnXqIEmBVl1xKoUBeZpB2SYA///tl4A= Date: Tue, 3 Dec 2013 01:54:11 +0000 Message-ID: References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529D02E2.2090303@viagenie.ca> In-Reply-To: <529D02E2.2090303@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.51.58] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 01:54:16 -0000 On 12/2/13 5:00 PM, "Simon Perreault" wrote: >Thanks a lot for this list Tom! > >Replying to the few ones that I can help move forward... > >Le 2013-12-02 14:03, Tom Taylor a =E9crit : >> 4. By implication (since external realm is unspecified), IPFIX allows >> only one destination realm, hence does not support hairpinning between >> the same or different internal realms. SYSLOG and the MIB support >> multiple destination realms. >> >> Action: add destination realm to IPFIX. > >I don't follow the implication on hairpinning. The way I read the IPFIX >draft, only the internal realm is recorded (natOriginatingAddressRealm). >So the problem is that the external realm is missing. Is that it? > >> 6. IPFIX makes the destination data optional in the create and delete >> session events. I've already remarked on this -- it doesn't make sense, >> since by omitting the destination data you end up generating a whole lot >> of events that carry the same information as the corresponding BIB event >> (except for event type and timestamp) and therefore add little value. > >I don't follow this reasoning. Why would omitting information cause more >logging events to be generated? > >In addition, CGN requirements [RFC6888] contain the following: > > REQ-12: A CGN SHOULD NOT log destination addresses or ports unless > required to do so for administrative reasons. > > Justification: Destination logging at the CGN creates privacy > issues. Furthermore, readers should be aware of logging > recommendations for Internet-facing servers [RFC6302]. With > compliant servers, the destination address and port do not need to > be logged by the CGN. This can help reduce the amount of logging. > >> 8. The IPFIX addresses exhausted event is pool-specific, where the MIB >> and SYSLOG events are based on a global limit on address mappings. > >Not sure I understand. The MIB has both global and pool-specific >notifications. What is your understanding on when the global notification will be generated from a nat device? > >> These >> are obviously monitoring different resources (memory vs. addresses in a >> given pool). The MIB and SYSLOG monitor pool address-port utilization >> using threshold events, which IPFIX lacks. >> >> Action: agree on a common set of events and bring all three drafts into >> line. >> >> 9. The IPFIX ports exhausted event is specific to a given global IPv4 >> address. SYSLOG and the MIB have no equivalent. >> >> Action: as for the previous item. > >Right, this has to be pool-specific and global. Nobody cares that a >single external IP address is full. Agreed. > >In addition, it looks like this even only handles external *IPv4* >addresses. Can it be made version-agnostic? An external address is IPv6? Can you tell me what the feature we are talking about here? NAT66? > >> 15. The SYSLOG generalized quota event originally came out of my >> misunderstanding of the IPFIX quota event. I'm willing to drop it if it >> does not correspond to NAT reality. >> >> Action: discuss need for the event, and if we conclude it is >> unnecessary, delete it from SYSLOG and the MIB. > >I'd be fine with dropping it from the MIB. Let me know if we have >consensus. > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From ssenthil@cisco.com Mon Dec 2 19:42:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5946C1ADFD3 for ; Mon, 2 Dec 2013 19:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 LKS-FaTDN8OG for ; Mon, 2 Dec 2013 19:42:06 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id B3DB11ADFCF for ; Mon, 2 Dec 2013 19:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2761; q=dns/txt; s=iport; t=1386042124; x=1387251724; h=from:to:cc:subject:date:message-id:mime-version; bh=OEiuQaWsn20egU21dZzu2WOWFakNeomTeuRaMtyXRFE=; b=NN6IDTuY3tTNwOVHzqbS1Lm54qq6Frpalekb/KLTvk0HQyjcOtEA1Y1m yYlkjxUlQgWUGLXen4y2TE8puNQLdxjqmbwrfBT5dq6uxyFcnXyN7BjIg KmxGGFYM4HO+XQ486pVoNaY6lGe0qHvnYuyCZ/w5BJk6Y2yWInTP6c54k U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMGANNSnVKtJV2a/2dsb2JhbABZgkNEgQu1ZYMFgRoWbQeCLHkSAQx0JwQOiAbAZhePCIQ6A5gUkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208,217";a="3834290" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 03 Dec 2013 03:42:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB33g3b6014975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 03:42:03 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 21:42:03 -0600 From: "Senthil Sivakumar (ssenthil)" To: "behave@ietf.org" Thread-Topic: Logging drafts port block allocation/deallocation - feedback required Thread-Index: AQHO79mgs/xNws1NbkOgbVHy5pLltw== Date: Tue, 3 Dec 2013 03:42:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.51.58] Content-Type: multipart/alternative; boundary="_000_CEC2BD38CFABEssenthilciscocom_" MIME-Version: 1.0 Cc: Tom Taylor Subject: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 03:42:08 -0000 --_000_CEC2BD38CFABEssenthilciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Tom and I had some offline discussions on the port block allocation/dealloc= ation mechanics. We would like to solicit some feedback on this. Essentially, the questions boil down to these two: 1. If the non-contiguous ports are useful/necessary. What we mean is if 32 = ports are allocated for a user, can they be 1024, 1026, 1028=85. Etc? 2. If multiple ranges is to be logged in a single log event. For eg. Ports = 1024-1047 and 5000-5010 are allocated for a user, can we log them as two ev= ents. I think the answer to this question probably goes to if NAT implementations= would/should do this. Thanks Senthil --_000_CEC2BD38CFABEssenthilciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2D8EFFFE51778047A9AB64717F9C730F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Tom and I had some offline discussions on the port block allocation/dealloc= ation mechanics. We would like to solicit some feedback on this.
Essentially, the questions boil down to these two:
If the non-contiguous ports are useful/necessary.= What we mean is if 32 ports are allocated for a user, can they be 1024, 1026, 1028=85. Etc? 
2. If multiple ranges is to be logged in a single log event.= For eg. Ports 1024-1047 and 5000-5010 are allocated for a user, can we log= them as two events.
I think the answer to= this question probably goes to if NAT implementations would/should do this= . 

Thanks
Senthil

--_000_CEC2BD38CFABEssenthilciscocom_-- From ssenthil@cisco.com Mon Dec 2 19:42:28 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2703B1ADFCF for ; Mon, 2 Dec 2013 19:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 PJDH29BEfUmp for ; Mon, 2 Dec 2013 19:42:26 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 85EA31AD698 for ; Mon, 2 Dec 2013 19:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=870; q=dns/txt; s=iport; t=1386042144; x=1387251744; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=d10gFbemhA1qmPGEValaGpyeAQlz2G9hSzVY3xyIzks=; b=C+XrL64vwf7T0IGB+W/UirA9cTfy7eaiBEYZ6P4dbDWkYi088Ibzve+/ dP4rTsiBJp5mn9m+qFRsyoHijT7D55sANQ6i8d5rJVHT4XrsqydbDDPMf /15OkyFqK+3ncc6jvLxXCPx4MeyKg8PgPXKe2DLX1u5J+pK7t+ath1daD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAAdSnVKtJXG9/2dsb2JhbABZgwc4U7gcToEaFnSCJQEBAQQBAQEkRwkSAgEIRicLHAkCBAESiAENwFMXjw+EMwOJCo8KgTCQY4FrgT6CKg X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208";a="3842619" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-8.cisco.com with ESMTP; 03 Dec 2013 03:42:23 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB33gNFD009036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 03:42:23 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 21:42:23 -0600 From: "Senthil Sivakumar (ssenthil)" To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt Thread-Index: AQHO79msN2d97foK3UuAiQAIt6C5+Q== Date: Tue, 3 Dec 2013 03:42:22 +0000 Message-ID: References: <529C965E.9080405@viagenie.ca> In-Reply-To: <529C965E.9080405@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.51.58] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 03:42:28 -0000 Started a separate thread for this.. On 12/2/13 9:17 AM, "Simon Perreault" wrote: >Le 2013-11-30 23:37, Senthil Sivakumar (ssenthil) a =E9crit : >> A new version that incorporates comments from Tom and others, please >> review. >> At this time, the only outstanding issue with respect to the ipfix and >> syslog is the port block >> Allocation and deallocation schemes and parameters, for which we need >>some >> input from others. > >What are the issues or open questions? > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Mon Dec 2 21:15:28 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5305E1AE040 for ; Mon, 2 Dec 2013 21:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ANgwBY1GKnzc for ; Mon, 2 Dec 2013 21:15:27 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id DE66A1AE03E for ; Mon, 2 Dec 2013 21:15:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=448; q=dns/txt; s=iport; t=1386047724; x=1387257324; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4knEs6uObWx9hF2Tz+VFC8P+9ExxVih3nsG5Kby9m3A=; b=VNQ9GG5NPHPot5eIA32ieEZls79nIWwjuoWtBrMmJgWEgLCAqsf7VHRz COh74CsRbM2z0PC7pnqEMRy5biL7CrNki1bLqbwo5Drcyiw5O01mh0MVU dQOrc2qJJ53sgSp87Xeq839XgiFpbZyqGu5DqbCIPNwGFznKUde4bwiJs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPRnnVKtJXG8/2dsb2JhbABZgweBC7hqgRsWdIIlAQEBBDo9EgIBCDYQMhwJAgQBiBPAZheOVTqEMwOYFJITgWuBPoIq X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208";a="3852996" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-4.cisco.com with ESMTP; 03 Dec 2013 05:15:24 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB35FO46003112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 05:15:24 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 23:15:24 -0600 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt Thread-Index: AQHO75ErkWb2CnXqIEmBVl1xKoUBeZpB/vSA Date: Tue, 3 Dec 2013 05:15:23 +0000 Message-ID: References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> In-Reply-To: <529CD96C.6080602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.51.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <8139DFDCC6251F43B78F37C744B8E801@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 05:15:28 -0000 > >10. Editorial: natLimitEvent appears in Table 10 but not in Table 1 of >the IPFIX document. Maybe there is some confusion surrounding this. This is how I see the natLimitEvent used. The log would be {timestamp, natEvent=3D11{QuotaExceeded), natLimitEvent=3D= 1 (maxsessionentries), sourceIPv4address=3D10.1.1.1} If I rename the quotaExceeded in table 2 to natLimitEvent, that should solve your concern, right? Thanks Senthil From jshivamu@cisco.com Mon Dec 2 21:54:53 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804681AE04F for ; Mon, 2 Dec 2013 21:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 aOrhJDhBA6kB for ; Mon, 2 Dec 2013 21:54:52 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id C04EB1AE038 for ; Mon, 2 Dec 2013 21:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5231; q=dns/txt; s=iport; t=1386050089; x=1387259689; h=from:to:cc:subject:date:message-id:mime-version; bh=5us4V+VoKypddU9eORe6msOZpOyUsSl9PixWW497HUE=; b=SxS9X3cS5xOK+jZYBo/D1svDXPifNY+CrBI6LMiHyNBcKZY005B4SGWl WkCWxbl60WB6CHnzwCdlunsY7qQhaJFgRC9el8FAnwf3inrVBd85pUrZF 7K7ijuYSPBe1FyIjlk2Z+vTdycPf9MMLeaQpikt67EdPHcKFUiHtbgbOx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFBxnVKtJXG//2dsb2JhbABZgkNEgQu4aYEbFnSCJQECBHkSAQgRAwECKCgRFAkKBAENBYdvAw+5Iw2HOxeMd4IAEYQ6A5YpgWuMWoU5gWuBPoIq X-IronPort-AV: E=Sophos;i="4.93,815,1378857600"; d="scan'208,217";a="3854260" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 03 Dec 2013 05:54:49 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB35sn6V006543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 05:54:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 23:54:48 -0600 From: "Jagadish Shivamurthy (jshivamu)" To: "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required Thread-Index: AQHO7+ws6fm7GdAqW0OyV1f+34hDGA== Date: Tue, 3 Dec 2013 05:54:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.184.124] Content-Type: multipart/alternative; boundary="_000_CEC36F63172FCjshivamuciscocom_" MIME-Version: 1.0 Cc: Tom Taylor Subject: Re: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 05:54:53 -0000 --_000_CEC36F63172FCjshivamuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Senthil, Based on our NAT implementations (CGNAT) - 1. Do not see a need to allocated non-contiguous blocks. 2. We allocated one block and allocate a second only when the first bloc= k is used up. So, again do not see a specific use case. If there is an use = case, it can always be handled using two events. Thanks Jagadish From: "Senthil Sivakumar (ssenthil)" > Date: Tuesday, 3 December 2013 9:12 AM To: "behave@ietf.org" > Cc: Tom Taylor = > Subject: [BEHAVE] Logging drafts port block allocation/deallocation - feedb= ack required Tom and I had some offline discussions on the port block allocation/dealloc= ation mechanics. We would like to solicit some feedback on this. Essentially, the questions boil down to these two: 1. If the non-contiguous ports are useful/necessary. What we mean is if 32 = ports are allocated for a user, can they be 1024, 1026, 1028=85. Etc? 2. If multiple ranges is to be logged in a single log event. For eg. Ports = 1024-1047 and 5000-5010 are allocated for a user, can we log them as two ev= ents. I think the answer to this question probably goes to if NAT implementations= would/should do this. Thanks Senthil --_000_CEC36F63172FCjshivamuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Senthil,
Based on our NAT implementations (CGNAT) -
  1. Do not see a need to allocated non-contiguous blocks.
  2. We alloca= ted one block and allocate a second only when the first block is used up. S= o, again do not see a specific use case. If there is an use case, it can al= ways be handled using two events.
Thanks
Jagadish


From: "Senthil Sivakumar (ssen= thil)" <ssenthil@cisco.com>
Date: Tuesday, 3 December 2013 9:12= AM
To: "behave@ietf.org" <= behave@ietf.org>
Cc: Tom Taylor <tom.taylor.stds@gmail.com>
Subject: [BEHAVE] Logging drafts po= rt block allocation/deallocation - feedback required

Tom and I had some offline discussions on the port block allocation/dealloc= ation mechanics. We would like to solicit some feedback on this.
Essentially, the questions boil down to these two:
If the non-contiguous ports are useful/necessary.= What we mean is if 32 ports are allocated for a user, can they be 1024, 1026, 1028=85. Etc? 
2. If multiple ranges is to be logged in a single log event.= For eg. Ports 1024-1047 and 5000-5010 are allocated for a user, can we log= them as two events.
I think the answer to= this question probably goes to if NAT implementations would/should do this= . 

Thanks
Senthil

 --_000_CEC36F63172FCjshivamuciscocom_-- From tom.taylor.stds@gmail.com Tue Dec 3 06:10:35 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36B61ADF32 for ; Tue, 3 Dec 2013 06:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 GgjnKokVaPlJ for ; Tue, 3 Dec 2013 06:10:33 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 803571AE08F for ; Tue, 3 Dec 2013 06:10:33 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so23270846iec.19 for ; Tue, 03 Dec 2013 06:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ltBoqU3p5ZZVu7YK/yiwMz1hORC9/fy5cvMpmkDAsiA=; b=v7ANSBEmZq/6qX+mmtfxX9wssbkycYHZ5WWAPHphVw3CtRKdbwiHeUk30KHPNl+O6B 7zbV+/2feXmpsxlEtAuaGWQwR9emthAQrPlhdXbxa0klrS0bdm00UShIOA7rHgRcjR8C QVwks0VSXuo1x5YhcmIbRkwvGSFn+U2pQCc/qkAsh/C1sbVAobXA9BBxg7K+jDSPkEqZ xkG4XVHOLMmZefYVx5thZ7BsJry654ufmebieT6lc8J+nI6hG7DhFxT8fz+kM0EvFCxD pO5aUQcDLsAQaJLnWJKwjy2c2Mu056a1o4cLzeghF2CYpw59EbifqaQawHfKeQd4AZ2D X5EA== X-Received: by 10.50.115.35 with SMTP id jl3mr2698402igb.37.1386079830731; Tue, 03 Dec 2013 06:10:30 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id y10sm3226948igl.4.2013.12.03.06.10.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 06:10:30 -0800 (PST) Message-ID: <529DE652.6000603@gmail.com> Date: Tue, 03 Dec 2013 09:10:26 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Jagadish Shivamurthy (jshivamu)" , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:10:35 -0000 Even with non-contiguous allocations, we only needed three parameters, not four, to describe the allocation. I was too bound up with MAP, which is irrelevant here, when I set up the SYSLOG scheme. I propose that both SYSLOG and IPFIX go with a two-parameter description: minimum and maximum port numbers in the allocated range. Tom On 03/12/2013 12:54 AM, Jagadish Shivamurthy (jshivamu) wrote: > Hi Senthil, > Based on our NAT implementations (CGNAT) - > > 1. Do not see a need to allocated non-contiguous blocks. > 2. We allocated one block and allocate a second only when the first block is used up. So, again do not see a specific use case. If there is an use case, it can always be handled using two events. > > Thanks > Jagadish > > > From: "Senthil Sivakumar (ssenthil)" > > Date: Tuesday, 3 December 2013 9:12 AM > To: "behave@ietf.org" > > Cc: Tom Taylor > > Subject: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required > > Tom and I had some offline discussions on the port block allocation/deallocation mechanics. We would like to solicit some feedback on this. > Essentially, the questions boil down to these two: > 1. If the non-contiguous ports are useful/necessary. What we mean is if 32 ports are allocated for a user, can they be 1024, 1026, 1028…. Etc? > 2. If multiple ranges is to be logged in a single log event. For eg. Ports 1024-1047 and 5000-5010 are allocated for a user, can we log them as two events. > I think the answer to this question probably goes to if NAT implementations would/should do this. > > Thanks > Senthil > > From simon.perreault@viagenie.ca Tue Dec 3 06:20:50 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190351ADBE5 for ; Tue, 3 Dec 2013 06:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 7fYql7qcfWbc for ; Tue, 3 Dec 2013 06:20:48 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 152141ADF0F for ; Tue, 3 Dec 2013 06:20:48 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2d71:2167:859d:507d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 302694038A; Tue, 3 Dec 2013 09:20:45 -0500 (EST) Message-ID: <529DE8BC.8010908@viagenie.ca> Date: Tue, 03 Dec 2013 09:20:44 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tom Taylor , behave@ietf.org, Senthil Sivakumar References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529D02E2.2090303@viagenie.ca> <529D0EEF.3090409@gmail.com> In-Reply-To: <529D0EEF.3090409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:20:50 -0000 Le 2013-12-02 17:51, Tom Taylor a écrit : >>> 6. IPFIX makes the destination data optional in the create and delete >>> session events. I've already remarked on this -- it doesn't make sense, >>> since by omitting the destination data you end up generating a whole lot >>> of events that carry the same information as the corresponding BIB event >>> (except for event type and timestamp) and therefore add little value. >> >> I don't follow this reasoning. Why would omitting information cause more >> logging events to be generated? >> >> In addition, CGN requirements [RFC6888] contain the following: >> >> REQ-12: A CGN SHOULD NOT log destination addresses or ports unless >> required to do so for administrative reasons. >> >> Justification: Destination logging at the CGN creates privacy >> issues. Furthermore, readers should be aware of logging >> recommendations for Internet-facing servers [RFC6302]. With >> compliant servers, the destination address and port do not need to >> be logged by the CGN. This can help reduce the amount of logging. > > [PTT] My argument is that you shouldn't log session events at all unless > they have destination data. Otherwise you are just duplicating the BIB > events, except that you are providing a timestamp for each new session > the user creates. I'm not sure that little bit of additional information > is useful for anything. Agreed. Either you log sessions with all their parameters, or you don't. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Tue Dec 3 06:42:20 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448061ADF30; Tue, 3 Dec 2013 06:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 SbiI0_PwASc8; Tue, 3 Dec 2013 06:42:18 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F91ADBE5; Tue, 3 Dec 2013 06:42:18 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id x13so23785939ief.38 for ; Tue, 03 Dec 2013 06:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Hg8nIhPkkKtyqxzWoLjnnBEuWxyg0cEqPnV6KhBX0cE=; b=uKdJR/co/VRz5cRr/aQQ91UAh7j+8CuvSvGJfSr8YdhvzGnOLXj5LGPvbozS2j0HsY 9ykMo0AcGyOdkOY/s3JzlKLAKYOgFCBoyV7M57mwxq6kak9CqYSQiINtxONxkAwoHvdd Z+0QaVAF9tndF1eE7M+MiTkZCLfcxSbPphMTn6ulU157O8XXQjopmP7V3on2t1ZEmtti bs97IxNi+qfmmdpJIUEsIpklpZMXVXQHBQT1y/5JS05uWVYtgCm8JKGJBDwIUhsHgkg2 IX9Gc+ZeVQGnMnbxSU80nEqfY/+Z56xQrzUcMMqP5GkodzM7Io33VAeTXGl6A86oLhX0 AVtQ== X-Received: by 10.50.61.205 with SMTP id s13mr2849562igr.29.1386081735588; Tue, 03 Dec 2013 06:42:15 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id x6sm3370984igb.3.2013.12.03.06.42.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 06:42:14 -0800 (PST) Message-ID: <529DEDC4.1010404@gmail.com> Date: Tue, 03 Dec 2013 09:42:12 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Simon Perreault , "behave@ietf.org" , "opsawg@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: [BEHAVE] Logging of sessions vs. BIB entrry creation -- operators please comment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:42:20 -0000 I've isolated this one issue in hopes that we can get operator input. Please note the cross-posting to OPSAWG. We are talking about the session creation event as reported by draft-ietf-behave-ipfix-nat-logging-02 versus draft-ietf-behave-syslog-nat-logging-05. The IPFIX document makes destination address and port optional in that report. Tom Taylor On 02/12/2013 8:51 PM, Senthil Sivakumar (ssenthil) wrote: ... > > On 12/2/13 2:03 PM, "Tom Taylor" wrote: > ... >> IPFIX makes the destination data optional in the create and delete >> session events. I've already remarked on this -- it doesn't make sense, >> since by omitting the destination data you end up generating a whole lot >> of events that carry the same information as the corresponding BIB event >> (except for event type and timestamp) and therefore add little value. > > It was already clarified in our old exchange, as below. > > /START >> >> 7. IPFIX session event makes destination address and port information >> optional. A session event without that information is identical to a BIB >> event, so there is no point in reporting it. Shouldn't destination info >> be mandatory? > > The destination information is not mandatory. There are nat44 > implementations > has a session database but doesn¹t need to log the destination information. > You can call that as BIB, but that is purely semantics on how you want to > call that as. > END/ > > > >> >> Action: make destination data mandatory in IPFIX session events? >> Otherwise, provide text on relationship between the session and BIB >> events and when type of event should be enabled vs. the other. > > You either generate session or BIB if destination information is optional. > I don’t see why it causes additional events. I don’t understand why it is > Confusing, but I will add some text here. > > [PTT] My point here is not the semantics, but the frequency of logging. A BIB entry is created when an address mapping is associated with a port mapping. A session entry is created every time a new destination is contacted, which could be many times for the same BIB entry (virtual or real, depending on the implementation). Thus if you enable session logging you may get many times the volume of logs you would get just logging BIB entry creation, and these would differ only in the timestamp value contained in them. Now, I can see that matching up timestamps could give you a fairly good traceback capability if the destination is able to provide a log of source address and port for the incoming packets, so maybe this is acceptable. It might not stand up in a court of law in cases of abuse, since it relies on clock synchronization between the source and destination. So it would be nice if an operator or two could comment on the issue. ... From simon.perreault@viagenie.ca Tue Dec 3 06:48:32 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296451ADFC2 for ; Tue, 3 Dec 2013 06:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ShHSLg5F3n7w for ; Tue, 3 Dec 2013 06:48:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 16ACF1AD9AB for ; Tue, 3 Dec 2013 06:48:30 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2d71:2167:859d:507d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3E9024038A; Tue, 3 Dec 2013 09:48:27 -0500 (EST) Message-ID: <529DEF3A.6090606@viagenie.ca> Date: Tue, 03 Dec 2013 09:48:26 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:48:32 -0000 Le 2013-12-02 20:51, Senthil Sivakumar (ssenthil) a écrit : >> 3. vlanID and ingressVRFID appear in the list of IPFIX parameters, but >> not in the SYSLOG list. Please tell me definitively whether >> vlanID/ingressVRFID is implied by realm identifier or supplements it. >> >> Action: if the other two parameters are implied by realm identifier, >> remove them from IPFIX. If not, add them to SYSLOG. > > The original intent of the realm identifier is to indicate the > private/public > Address domains and not to overload that with the VRFID/VlanIDs. > I can remove the vlan/vrf from IPFIX but is there a way to identify the > originator of the traffic was in private/public realm or that is to be > somehow derived from the realm Ids? We need to be careful with terminology. Realms are "internal" and "external". That's relative to the NAT function, not with the source of a flow that created a dynamic NAT mapping. Only "implicit dynamic mappings" [RFC6887] are created as a result of a flow. Therefore the terms "originator" only applies to those mappings. For example, if an IPFIX event is triggered by an explicit dynamic mapping creation (e.g., through PCP), there's no flow and there's no flow originator. But there's still internal and external realms, IP addresses, and port numbers. We also don't use "private" or "public" since any kind of address can be used internally or externally. Now, back to your question: how to determine the "originator" of the traffic. Based on the previous explanation, this only applies to a subset of the NAT mappings created. Question: won't this originator be logged as part of regular IPFIX logging? I mean, a NAT creates mappings, but regular flow routing would still be logged with IPFIX as any regular router, wouldn't it? If it's logged normally, then would that be sufficient? If it's not sufficient, can we add a "pointer" from the NAT event to the regular flow creation event? >> 4. By implication (since external realm is unspecified), IPFIX allows >> only one destination realm, hence does not support hairpinning between >> the same or different internal realms. SYSLOG and the MIB support >> multiple destination realms. >> >> Action: add destination realm to IPFIX. > > I would like to see that the destination realm be optional, the lack of > destination realm will mean that the traffic was originated from private > to public > and there is only one public. Any issues with that? Argh! The terminology! It hurts! ;) Yes this is a big issue. Any NAT mapping always has an external and an internal realm by definition. They may be the same. This has nothing to do with the direction of a flow. > /START >> >> 7. IPFIX session event makes destination address and port information >> optional. A session event without that information is identical to a BIB >> event, so there is no point in reporting it. Shouldn't destination info >> be mandatory? > > The destination information is not mandatory. There are nat44 > implementations > has a session database but doesn¹t need to log the destination information. > You can call that as BIB, but that is purely semantics on how you want to > call that as. > END/ Again, careful with the terminology. "Session", "binding", "BIB", and "session table" are defined in RFC 6164. Some NATs only have a BIB. Some NATs only have a session table. Some NATs have both a BIB and a session table. Therefore: - Sending BIB events has to be optional. - Sending session table events has to be optional. - A binding refers to a 3-tuple (transport protocol, internal address, internal port). - A session refers to a 5-tuple (transport protocol, internal address, internal port, external address, external port). I think those semantics can apply to any NAT type. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Dec 3 06:55:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C081AE13B for ; Tue, 3 Dec 2013 06:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 CR5vLwf2JP-w for ; Tue, 3 Dec 2013 06:55:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 773C41AE0C5 for ; Tue, 3 Dec 2013 06:55:56 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2d71:2167:859d:507d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 57CDC4038A; Tue, 3 Dec 2013 09:55:53 -0500 (EST) Message-ID: <529DF0F9.1060705@viagenie.ca> Date: Tue, 03 Dec 2013 09:55:53 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529D02E2.2090303@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:55:58 -0000 Le 2013-12-02 20:54, Senthil Sivakumar (ssenthil) a écrit : >>> 8. The IPFIX addresses exhausted event is pool-specific, where the MIB >>> and SYSLOG events are based on a global limit on address mappings. >> >> Not sure I understand. The MIB has both global and pool-specific >> notifications. > What is your understanding on when the global notification will be > generated from a nat device? natNotifMappings NOTIFICATION-TYPE OBJECTS { natMappingCreations, natMappingRemovals } STATUS current DESCRIPTION "This notification is generated when the number of active mappings exceeds the value of natMappingsNotifyThreshold." ::= { natMIBNotifications 4 } >> In addition, it looks like this even only handles external *IPv4* >> addresses. Can it be made version-agnostic? > > An external address is IPv6? Can you tell me what the feature we are > talking about here? > NAT66? Feature? What is this, a product design meeting? ;) Seriously, we need to write our protocols in a version-agnostic manner so that they support any kind of NATxy. You don't want to have to write a new RFC when your product team comes up with a new NATxy feature. You want to be able to apply the existing RFC to any kind of NAT. Makes sense? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Tue Dec 3 06:59:34 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E94F1AE16E for ; Tue, 3 Dec 2013 06:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 44-WOPaUAaPc for ; Tue, 3 Dec 2013 06:59:32 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE51AE15B for ; Tue, 3 Dec 2013 06:59:32 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so24422508ieb.3 for ; Tue, 03 Dec 2013 06:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=NQQodHnkTfAfV0hBlC9g32ziP+dviHny4X5ZPLUNe8I=; b=gdH14sNab7VPgW+/cmsCCF9rnMV057+0YgmyKkY4nPF6mIeFzwzymUVmrsqmfxQF+l KZNHX3rDdk3mznzavJj5cIJ+qASAjGBELU9cGiSw4U5HKUO1hQM1YBhFmhtJdCiwG+Vx VnmKGmz5LjCazdhhkUNkmvoExzCjkrrhVtgPoyNJQ7+VvpqAJ4HwG5nWywbz17ndGOhg D9/JPgPyk0Y3b+upeJVK6qFWZQmVUfXlrH8nJPCNIri26NFs6ucHyRjGz9/fD1PCqrJ1 QZ7r56j59ji6HLRPqWpeqyviLkWahqhd4+r4ZLG+86I3Fa8pDJHToswrPotZxXO1BQ6S q6pw== X-Received: by 10.42.222.68 with SMTP id if4mr1389234icb.62.1386082769830; Tue, 03 Dec 2013 06:59:29 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id da14sm3457467igc.1.2013.12.03.06.59.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 06:59:29 -0800 (PST) Message-ID: <529DF1CD.1000805@gmail.com> Date: Tue, 03 Dec 2013 09:59:25 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Simon Perreault , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:59:34 -0000 On 02/12/2013 8:51 PM, Senthil Sivakumar (ssenthil) wrote: > Thanks for the exhaustive list, please see inline. > > On 12/2/13 2:03 PM, "Tom Taylor" wrote: > >> On 02/12/2013 9:17 AM, Simon Perreault wrote: ... >> 3. vlanID and ingressVRFID appear in the list of IPFIX parameters, but >> not in the SYSLOG list. Please tell me definitively whether >> vlanID/ingressVRFID is implied by realm identifier or supplements it. >> >> Action: if the other two parameters are implied by realm identifier, >> remove them from IPFIX. If not, add them to SYSLOG. > > The original intent of the realm identifier is to indicate the > private/public > Address domains and not to overload that with the VRFID/VlanIDs. > I can remove the vlan/vrf from IPFIX but is there a way to identify the > originator of the traffic was in private/public realm or that is to be > somehow > derived from the realm Ids? > [PTT] I assume that information comes from the realm ID. We can perhaps agree that if the NAT supports only one internal realm, the internal realm ID is optional. >> >> 4. By implication (since external realm is unspecified), IPFIX allows >> only one destination realm, hence does not support hairpinning between >> the same or different internal realms. SYSLOG and the MIB support >> multiple destination realms. >> >> Action: add destination realm to IPFIX. > > I would like to see that the destination realm be optional, the lack of > destination realm will mean that the traffic was originated from private > to public > and there is only one public. Any issues with that? > [PTT] I agree, and will make it so in SYSLOG. >> ... >> >> 6. IPFIX makes the destination data optional in the create and delete >> session events. I've already remarked on this -- it doesn't make sense, >> since by omitting the destination data you end up generating a whole lot >> of events that carry the same information as the corresponding BIB event >> (except for event type and timestamp) and therefore add little value. > > It was already clarified in our old exchange, as below. > > /START >> >> 7. IPFIX session event makes destination address and port information >> optional. A session event without that information is identical to a BIB >> event, so there is no point in reporting it. Shouldn't destination info >> be mandatory? > > The destination information is not mandatory. There are nat44 > implementations > has a session database but doesn¹t need to log the destination information. > You can call that as BIB, but that is purely semantics on how you want to > call that as. > END/ > > > >> >> Action: make destination data mandatory in IPFIX session events? >> Otherwise, provide text on relationship between the session and BIB >> events and when type of event should be enabled vs. the other. > > You either generate session or BIB if destination information is optional. > I don’t see why it causes additional events. I don’t understand why it is > Confusing, but I will add some text here. > [PTT] Separate E-mail sent. > >> ... >> >> 8. The IPFIX addresses exhausted event is pool-specific, where the MIB >> and SYSLOG events are based on a global limit on address mappings. These >> are obviously monitoring different resources (memory vs. addresses in a >> given pool). The MIB and SYSLOG monitor pool address-port utilization >> using threshold events, which IPFIX lacks. >> >> Action: agree on a common set of events and bring all three drafts into >> line. > > When would the global address exhausted event be generated by a NAT device? > The address exhausted event is triggered when a subscriber/packet requires > an address to be allocated and the subscribed/packet would be pointing to a > single pool (based on some classification mechanism), if that pool is full, > an address exhausted event is generated. There can be other pools that have > addresses in them (or not) but a nat device doesn’t check if all pools are > exhausted. > [PTT] The SYSLOG events are all driven by the MIB, so let's use the MIB as reference. The MIB has two categories of administratively-set limits: hard limits, above which packets are dropped, and thresholds, which trigger reporting only. Some of these are conditional on particular NAT behaviour. The hard limits are on: -- number of address mapping entries created (NOT address exhaustion as such) -- global number of BIB entries created (i.e., associations between address mapping and port mapping) -- subscriber-specific number of BIB entries created -- total number of active subscribers -- number of fragments awaiting reassembly. The thresholds are: -- address pool utilization, high and low water marks -- global BIB entry high water mark -- subscriber-specific BIB entry high water mark SYSLOG has implemented events for all of these. I would expect the same of IPFIX, unless we decide that some of the limits are superfluous and should be dropped. The only one I myself would question is the global limit on number of active subscribers. One question I have is whether your IPFIX quota events represent hard limits or soft limits. If the former, you need to add a couple of sub-event types. In any case, what you specify in IPFIX should match what is in the MIB. >> ... >> >> 13. Not sure how to interpret the IPFIX quota events: as threshold >> crossings or as hard limits. If the latter, IPFIX is missing the >> threshold events: >> -- address pool port utilization (already mentioned) >> -- BIB entries, global and per user >> >> Action: I think IPFIX has to add the threshold events. > > Hard limits. What is the assumption in syslog draft? Is it free flowing > and you can add whichever > threshold event? I know in mib we have threshold crossings. > [PTT] See above. >> ... From simon.perreault@viagenie.ca Tue Dec 3 06:59:35 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A681E1AE171; Tue, 3 Dec 2013 06:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GaiqCiCKHjy0; Tue, 3 Dec 2013 06:59:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 792C51AE15B; Tue, 3 Dec 2013 06:59:34 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2d71:2167:859d:507d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A3B194038A; Tue, 3 Dec 2013 09:59:31 -0500 (EST) Message-ID: <529DF1D3.5030706@viagenie.ca> Date: Tue, 03 Dec 2013 09:59:31 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tom Taylor , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" , "opsawg@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529DEDC4.1010404@gmail.com> In-Reply-To: <529DEDC4.1010404@gmail.com> Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Logging of sessions vs. BIB entrry creation -- operators please comment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:59:35 -0000 Le 2013-12-03 09:42, Tom Taylor a écrit : >> You either generate session or BIB if destination information is >> optional. >> I don’t see why it causes additional events. I don’t understand why it is >> Confusing, but I will add some text here. >> >> > [PTT] My point here is not the semantics, but the frequency of logging. > A BIB entry is created when an address mapping is associated with a port > mapping. A session entry is created every time a new destination is > contacted, which could be many times for the same BIB entry (virtual or > real, depending on the implementation). Thus if you enable session > logging you may get many times the volume of logs you would get just > logging BIB entry creation, and these would differ only in the timestamp > value contained in them. Yes, and this fact has been noted in RFC 6888: REQ-12: A CGN SHOULD NOT log destination addresses or ports unless required to do so for administrative reasons. Justification: Destination logging at the CGN creates privacy issues. Furthermore, readers should be aware of logging recommendations for Internet-facing servers [RFC6302]. With compliant servers, the destination address and port do not need to be logged by the CGN. This can help reduce the amount of logging. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Dec 3 07:01:23 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1916E1AE123 for ; Tue, 3 Dec 2013 07:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wB78PyKIpQiu for ; Tue, 3 Dec 2013 07:01:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 859851ADFA2 for ; Tue, 3 Dec 2013 07:01:21 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2d71:2167:859d:507d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B95D44038A; Tue, 3 Dec 2013 10:01:18 -0500 (EST) Message-ID: <529DF23E.7090208@viagenie.ca> Date: Tue, 03 Dec 2013 10:01:18 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Tom Taylor , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529DF1CD.1000805@gmail.com> In-Reply-To: <529DF1CD.1000805@gmail.com> Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:01:23 -0000 Le 2013-12-03 09:59, Tom Taylor a écrit : >> The original intent of the realm identifier is to indicate the >> private/public >> Address domains and not to overload that with the VRFID/VlanIDs. >> I can remove the vlan/vrf from IPFIX but is there a way to identify the >> originator of the traffic was in private/public realm or that is to be >> somehow >> derived from the realm Ids? >> > [PTT] I assume that information comes from the realm ID. We can perhaps > agree that if the NAT supports only one internal realm, the internal > realm ID is optional. I disagree. See my other mail. >>> 4. By implication (since external realm is unspecified), IPFIX allows >>> only one destination realm, hence does not support hairpinning between >>> the same or different internal realms. SYSLOG and the MIB support >>> multiple destination realms. >>> >>> Action: add destination realm to IPFIX. >> >> I would like to see that the destination realm be optional, the lack of >> destination realm will mean that the traffic was originated from private >> to public >> and there is only one public. Any issues with that? >> > [PTT] I agree, and will make it so in SYSLOG. I disagree. See my other mail. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Tue Dec 3 07:07:03 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F204E1AE187 for ; Tue, 3 Dec 2013 07:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 TKoSPkvgNwV1 for ; Tue, 3 Dec 2013 07:07:00 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9E47F1AE16F for ; Tue, 3 Dec 2013 07:07:00 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so23986059iec.16 for ; Tue, 03 Dec 2013 07:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Gl9f7fRRavY82S0RH9HCuSUf30pqhAmGuCa3fRL8BBA=; b=Ktp/GAWbo5puHt/Ki1I1m9md90BkUlr7038tk2+uADsB+9SscfGNoqWfMV9skAXYtB PM4/uBbhTuLsOWfYYeLO1ioakjktTwdzNgFcUhVfMu8a8Yux6m97foD5FhAY/rJhfRJo V4sTzQS4MD5sStG0ZDl67hGExUGIqXbZY8ba+RGUSbUVbXQ3eQNf92LURwC6vDHtwkz5 0WGMOpGsN6VPlTpF9wXufnP/qNQTyo+rYPHD2D3CQucyVunMYsaO33gY8ajyzBYAUBI7 fBTI8exIYecl32FSjKFk8lT0OblDd+YE+EPd7oFjjfiuN5bVmO9U6b2QqntLa2UCUn6l Ly2w== X-Received: by 10.42.142.129 with SMTP id s1mr46271787icu.30.1386083217866; Tue, 03 Dec 2013 07:06:57 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id f5sm3476803igc.4.2013.12.03.07.06.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 07:06:57 -0800 (PST) Message-ID: <529DF38E.4090402@gmail.com> Date: Tue, 03 Dec 2013 10:06:54 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Simon Perreault , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:07:03 -0000 I thought the purpose of Table 1 was to list all the parameters that could appear in any of the templates you define. Your example clearly shows natLimitEvent as such a parameter. My original remark stands. On 03/12/2013 12:15 AM, Senthil Sivakumar (ssenthil) wrote: > >> >> 10. Editorial: natLimitEvent appears in Table 10 but not in Table 1 of >> the IPFIX document. > > Maybe there is some confusion surrounding this. This is how I see the > natLimitEvent used. > The log would be {timestamp, natEvent=11{QuotaExceeded), natLimitEvent=1 > (maxsessionentries), sourceIPv4address=10.1.1.1} > > If I rename the quotaExceeded in table 2 to natLimitEvent, that should > solve your concern, right? > > Thanks > Senthil > > From simon.perreault@viagenie.ca Tue Dec 3 07:11:14 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFAC1AE125 for ; Tue, 3 Dec 2013 07:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IV5KBzUBfMxo for ; Tue, 3 Dec 2013 07:11:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A87AA1AE12A for ; Tue, 3 Dec 2013 07:11:11 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:2d71:2167:859d:507d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E7314401F1 for ; Tue, 3 Dec 2013 10:11:08 -0500 (EST) Message-ID: <529DF48C.6000403@viagenie.ca> Date: Tue, 03 Dec 2013 10:11:08 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:11:14 -0000 I vividly remember an exchange about this very topic in the BEHAVE meeting at IETF 87. But it's not in the minutes. I bet you could find it by listening to the audio: http://www.ietf.org/audio/ietf87/ietf87-charlottenburg1-20130729-1300-pm.mp3 It should be in the fist ~10 minutes. Simon Le 2013-12-02 22:42, Senthil Sivakumar (ssenthil) a écrit : > Tom and I had some offline discussions on the port block > allocation/deallocation mechanics. We would like to solicit some > feedback on this. > Essentially, the questions boil down to these two: > 1. If the non-contiguous ports are useful/necessary. What we mean is if > 32 ports are allocated for a user, can they be 1024, 1026, 1028…. Etc? > 2. If multiple ranges is to be logged in a single log event. For eg. > Ports 1024-1047 and 5000-5010 are allocated for a user, can we log them > as two events. > I think the answer to this question probably goes to if NAT > implementations would/should do this. -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Tue Dec 3 07:32:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9FD1AE05B for ; Tue, 3 Dec 2013 07:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 fEUvgSQ-AF6b for ; Tue, 3 Dec 2013 07:32:11 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id ED70A1ADBC7 for ; Tue, 3 Dec 2013 07:32:10 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so24520546iec.30 for ; Tue, 03 Dec 2013 07:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1xRnHMNOgkZ9rdNMitJN+cr7jbJifUiKPuHv55+kxEU=; b=Mfv4YW7Ii3J1wpCy4VSeT2joZBMSOxXYBYlmgLNDYy568zKvjIF9CNCGpO56jV0L5p 9COU9gpQh8AXzryyo+msHr3goVyjg2HoEEOH47lovJ46KMzRndtLkFHAkXJYT2VrxSKC GQIQpxHWCQ9VnN2HZlpVYbxDJu+kFbJVnMo0rbZfyNrBqyxtKjNQedP6jTEClGzfy/Bl ETCRUiHp0JKgN3UBhpGjYvtp1/QWYy2IqkSTHudQsjv2LZRjtXE6mnDkbQxLfz0EfIt0 Z4G4WPom5bC/HtKoT9ZZ7RYDo3Moo8kiT8Wfi9GhUZerNKBxsyktmBz2rTJl6yX+6EAQ pWhA== X-Received: by 10.50.138.72 with SMTP id qo8mr3272014igb.4.1386084728199; Tue, 03 Dec 2013 07:32:08 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id u1sm3597164ige.1.2013.12.03.07.32.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 07:32:07 -0800 (PST) Message-ID: <529DF974.4000202@gmail.com> Date: Tue, 03 Dec 2013 10:32:04 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Simon Perreault , behave@ietf.org References: <529DF48C.6000403@viagenie.ca> In-Reply-To: <529DF48C.6000403@viagenie.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:32:13 -0000 It was the final issue discussed. The conclusion I recorded was to use IPFIX encoding. What we have had up to now is a difference in interpretation of that encoding. I also recorded that we would look at two use cases: single contiguous range, and sequence of equally-spaced, equal-length ranges. I'm not sure I trust that latter observation without listening again to the audio, but I'm prepared to accept that the second use case is unrealistic. Tom On 03/12/2013 10:11 AM, Simon Perreault wrote: > I vividly remember an exchange about this very topic in the BEHAVE > meeting at IETF 87. But it's not in the minutes. I bet you could find it > by listening to the audio: > > http://www.ietf.org/audio/ietf87/ietf87-charlottenburg1-20130729-1300-pm.mp3 > > > It should be in the fist ~10 minutes. > > Simon > > Le 2013-12-02 22:42, Senthil Sivakumar (ssenthil) a écrit : >> Tom and I had some offline discussions on the port block >> allocation/deallocation mechanics. We would like to solicit some >> feedback on this. >> Essentially, the questions boil down to these two: >> 1. If the non-contiguous ports are useful/necessary. What we mean is if >> 32 ports are allocated for a user, can they be 1024, 1026, 1028…. Etc? >> 2. If multiple ranges is to be logged in a single log event. For eg. >> Ports 1024-1047 and 5000-5010 are allocated for a user, can we log them >> as two events. >> I think the answer to this question probably goes to if NAT >> implementations would/should do this. > From ssenthil@cisco.com Tue Dec 3 18:56:46 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E01ADFC5 for ; Tue, 3 Dec 2013 18:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 QJFEjfeKKcCr for ; Tue, 3 Dec 2013 18:56:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5004F1ADFAD for ; Tue, 3 Dec 2013 18:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2030; q=dns/txt; s=iport; t=1386125803; x=1387335403; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PADbsHe+lom+SJQEMngKy//P6Kkal+f0638BKD8FcZM=; b=Vz5BoIgE+XZWPdU112EblqinvVBS35uxm/+Aw5m/22mqHTYcR7GM2bfh ZBiBU4/m6QXAZGjeC7JBWTvQtQ6ErFQ60VotKwwEa7l5Utd/BFnoRwIxH qCdQpJZPxxR6ALHcRWmcu7QsNOXCzzn7liAdyP/XfHDFStdN1oEipcMQO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALeZnlKtJXHB/2dsb2JhbABagweBC7hzgSEWdIIlAQEBBIEJAgEIEQMBAgEnByERFAkIAgQBEodvAw+5fg2HMReMbYIYhDMDlimBa4xahTmBa4E+gio X-IronPort-AV: E=Sophos;i="4.93,821,1378857600"; d="scan'208";a="289240841" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 04 Dec 2013 02:56:42 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB42ugib017683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 02:56:42 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 20:56:42 -0600 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "Jagadish Shivamurthy (jshivamu)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required Thread-Index: AQHO7+ws6fm7GdAqW0OyV1f+34hDGJpC55AAgACCRAA= Date: Wed, 4 Dec 2013 02:56:42 +0000 Message-ID: References: <529DE652.6000603@gmail.com> In-Reply-To: <529DE652.6000603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.61.220] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Logging drafts port block allocation/deallocation - feedback required X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 02:56:46 -0000 Ok, I agree, the next rev of IPFIX draft will have just the two parameters. On 12/3/13 9:10 AM, "Tom Taylor" wrote: >Even with non-contiguous allocations, we only needed three parameters, >not four, to describe the allocation. > >I was too bound up with MAP, which is irrelevant here, when I set up the >SYSLOG scheme. > >I propose that both SYSLOG and IPFIX go with a two-parameter >description: minimum and maximum port numbers in the allocated range. > >Tom > >On 03/12/2013 12:54 AM, Jagadish Shivamurthy (jshivamu) wrote: >> Hi Senthil, >> Based on our NAT implementations (CGNAT) - >> >> 1. Do not see a need to allocated non-contiguous blocks. >> 2. We allocated one block and allocate a second only when the first >>block is used up. So, again do not see a specific use case. If there is >>an use case, it can always be handled using two events. >> >> Thanks >> Jagadish >> >> >> From: "Senthil Sivakumar (ssenthil)" >>> >> Date: Tuesday, 3 December 2013 9:12 AM >> To: "behave@ietf.org" >>> >> Cc: Tom Taylor=20 >>> >> Subject: [BEHAVE] Logging drafts port block allocation/deallocation - >>feedback required >> >> Tom and I had some offline discussions on the port block >>allocation/deallocation mechanics. We would like to solicit some >>feedback on this. >> Essentially, the questions boil down to these two: >> 1. If the non-contiguous ports are useful/necessary. What we mean is if >>32 ports are allocated for a user, can they be 1024, 1026, 1028=8A. Etc? >> 2. If multiple ranges is to be logged in a single log event. For eg. >>Ports 1024-1047 and 5000-5010 are allocated for a user, can we log them >>as two events. >> I think the answer to this question probably goes to if NAT >>implementations would/should do this. >> >> Thanks >> Senthil >> >> From ssenthil@cisco.com Tue Dec 3 19:42:34 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232A91AE192 for ; Tue, 3 Dec 2013 19:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zX9XrFNEWP44 for ; Tue, 3 Dec 2013 19:42:32 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 95F011ADF91 for ; Tue, 3 Dec 2013 19:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2123; q=dns/txt; s=iport; t=1386128550; x=1387338150; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JRCmfZMkT38G299WkKiFQtUPk5+pp05nynF1ib1nPpw=; b=KAftzOsdb8SmQ7La4OM2qgsIk4q978Dm3lV7N7qudxjqarScuvv9j8QM Gx7r6sRpKYMyI2DwyFkjRFSDHZUDlUBxIDk/E/PSfUuq2y0yuEzON9kEY M/lNc6CP7Z4htHTxLsqJTtq6qozJy71w91Dz3zGfqRBWOrUWl3WVX/rBT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAMKjnlKtJV2Z/2dsb2JhbABagwc4U7hzgSEWdIIlAQEBBCdQEgIBCEYyHAkCBAESiAHBT44nXoQzA4kKjwqBMJBjgWuBPoFpQQ X-IronPort-AV: E=Sophos;i="4.93,822,1378857600"; d="scan'208";a="289234394" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 04 Dec 2013 03:42:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB43gTft017266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 03:42:29 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 21:42:29 -0600 From: "Senthil Sivakumar (ssenthil)" To: Simon Perreault , Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt Thread-Index: AQHO75ErkWb2CnXqIEmBVl1xKoUBeZpB2SYA///tl4CAAS48gIAAgloA Date: Wed, 4 Dec 2013 03:42:28 +0000 Message-ID: References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529D02E2.2090303@viagenie.ca> <529DF0F9.1060705@viagenie.ca> In-Reply-To: <529DF0F9.1060705@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.61.220] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <50E48A47781AD14085759D33D9288D16@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 03:42:34 -0000 On 12/3/13 9:55 AM, "Simon Perreault" wrote: >Le 2013-12-02 20:54, Senthil Sivakumar (ssenthil) a =E9crit : >>>> 8. The IPFIX addresses exhausted event is pool-specific, where the MIB >>>> and SYSLOG events are based on a global limit on address mappings. >>> >>> Not sure I understand. The MIB has both global and pool-specific >>> notifications. >> What is your understanding on when the global notification will be >> generated from a nat device? > > natNotifMappings NOTIFICATION-TYPE > OBJECTS { natMappingCreations, natMappingRemovals } > STATUS current > DESCRIPTION > "This notification is generated when the number of active > mappings exceeds the value of natMappingsNotifyThreshold." > ::=3D { natMIBNotifications 4 } > > >>> In addition, it looks like this even only handles external *IPv4* >>> addresses. Can it be made version-agnostic? >> >> An external address is IPv6? Can you tell me what the feature we are >> talking about here? >> NAT66? > >Feature? What is this, a product design meeting? ;) Really, feature is a word banned in IETF? I thought it was a generic term, did you=20 Check our MIB draft on the usage of the word feature :-)) > >Seriously, we need to write our protocols in a version-agnostic manner >so that they support any kind of NATxy. You don't want to have to write >a new RFC when your product team comes up with a new NATxy feature. You >want to be able to apply the existing RFC to any kind of NAT. > >Makes sense? Not really. In general, I would agree that you want write a protocol version agnostic way, But in this particular case, the NAT external address being an IPv6 address, I don=B9t see a use case. Designing for something that would never happen is called over-engineering?? (Did someone say never say never? :-)) > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From ssenthil@cisco.com Tue Dec 3 19:45:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79071ADBE8 for ; Tue, 3 Dec 2013 19:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GdI7q69769Oh for ; Tue, 3 Dec 2013 19:45:35 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE41ADF91 for ; Tue, 3 Dec 2013 19:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4771; q=dns/txt; s=iport; t=1386128732; x=1387338332; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UrSfWBpEwN1bZt9Wiv7D9q3gX1qMTSu95OJFfAEVtYE=; b=XOrpZ9OvQj+B2VYqyqMg5Ak5X6hfD2S8klerTJHkUOEDpPVrDQ+BBI20 UD5dx/HMJWPN+6QndM6uZvqPfUW8bVvHiXCWbiBLx/fgwfaPDnDhlPQ2t jjFbhfAwNNf3wUz3BQqZgZ+UaefwhZbzB6s7FOz3tJj1S9HDMvGDTXPSH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAM6knlKtJV2b/2dsb2JhbABQCoMHOFO4c4EhFnSCJQEBAQQnUBICAQhGMhwJAgQBEhuHZsFQjiJjhDMDmBSBMJBjgWuBPoIq X-IronPort-AV: E=Sophos;i="4.93,822,1378857600"; d="scan'208";a="289300242" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 04 Dec 2013 03:45:32 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB43jW1O022960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 03:45:32 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.181]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 21:45:31 -0600 From: "Senthil Sivakumar (ssenthil)" To: Simon Perreault , Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt Thread-Index: AQHO75ErkWb2CnXqIEmBVl1xKoUBeZpBxeuAgAEs+QCAAIVJgA== Date: Wed, 4 Dec 2013 03:45:31 +0000 Message-ID: References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529DEF3A.6090606@viagenie.ca> In-Reply-To: <529DEF3A.6090606@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.61.220] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 03:45:37 -0000 On 12/3/13 9:48 AM, "Simon Perreault" wrote: >Le 2013-12-02 20:51, Senthil Sivakumar (ssenthil) a =E9crit : >>> 3. vlanID and ingressVRFID appear in the list of IPFIX parameters, but >>> not in the SYSLOG list. Please tell me definitively whether >>> vlanID/ingressVRFID is implied by realm identifier or supplements it. >>> >>> Action: if the other two parameters are implied by realm identifier, >>> remove them from IPFIX. If not, add them to SYSLOG. >> >> The original intent of the realm identifier is to indicate the >> private/public >> Address domains and not to overload that with the VRFID/VlanIDs. >> I can remove the vlan/vrf from IPFIX but is there a way to identify the >> originator of the traffic was in private/public realm or that is to be >> somehow derived from the realm Ids? > >We need to be careful with terminology. > >Realms are "internal" and "external". That's relative to the NAT >function, not with the source of a flow that created a dynamic NAT >mapping. > >Only "implicit dynamic mappings" [RFC6887] are created as a result of a >flow. Therefore the terms "originator" only applies to those mappings. > >For example, if an IPFIX event is triggered by an explicit dynamic >mapping creation (e.g., through PCP), there's no flow and there's no >flow originator. But there's still internal and external realms, IP >addresses, and port numbers. > >We also don't use "private" or "public" since any kind of address can be >used internally or externally. > >Now, back to your question: how to determine the "originator" of the >traffic. Based on the previous explanation, this only applies to a >subset of the NAT mappings created. > >Question: won't this originator be logged as part of regular IPFIX >logging? I mean, a NAT creates mappings, but regular flow routing would >still be logged with IPFIX as any regular router, wouldn't it? Not always, it depends if the logging is turned on for all the flows. > >If it's logged normally, then would that be sufficient? >If it's not sufficient, can we add a "pointer" from the NAT event to the >regular flow creation event? We need to make the log events self contained, adding dependencies to other=20 mechansims is not the best way to design the solution, IMO. Maybe we need to ask the question of, do we need to have the intelligence of Originating address realm in logging. > >>> 4. By implication (since external realm is unspecified), IPFIX allows >>> only one destination realm, hence does not support hairpinning between >>> the same or different internal realms. SYSLOG and the MIB support >>> multiple destination realms. >>> >>> Action: add destination realm to IPFIX. >> >> I would like to see that the destination realm be optional, the lack of >> destination realm will mean that the traffic was originated from private >> to public >> and there is only one public. Any issues with that? > >Argh! The terminology! It hurts! ;) > >Yes this is a big issue. Any NAT mapping always has an external and an >internal realm by definition. They may be the same. > >This has nothing to do with the direction of a flow. The most common use case, lets take CGN, a subscriber in internal realm Tries to access internet. Why do we have to log external realm for every flow? Senthil > >> /START >>> >>> 7. IPFIX session event makes destination address and port information >>> optional. A session event without that information is identical to a >>>BIB >>> event, so there is no point in reporting it. Shouldn't destination info >>> be mandatory? >> >> The destination information is not mandatory. There are nat44 >> implementations >> has a session database but doesn=B9t need to log the destination >>information. >> You can call that as BIB, but that is purely semantics on how you want >>to >> call that as. >> END/ > >Again, careful with the terminology. "Session", "binding", "BIB", and >"session table" are defined in RFC 6164. > >Some NATs only have a BIB. >Some NATs only have a session table. >Some NATs have both a BIB and a session table. > >Therefore: >- Sending BIB events has to be optional. >- Sending session table events has to be optional. >- A binding refers to a 3-tuple (transport protocol, internal address, >internal port). >- A session refers to a 5-tuple (transport protocol, internal address, >internal port, external address, external port). > >I think those semantics can apply to any NAT type. > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Dec 4 05:43:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E4E1AE216 for ; Wed, 4 Dec 2013 05:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PtIIHBF9WUJs for ; Wed, 4 Dec 2013 05:43:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C07C1AE14E for ; Wed, 4 Dec 2013 05:43:34 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:9924:4792:a388:be96]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4B7DF40387; Wed, 4 Dec 2013 08:43:31 -0500 (EST) Message-ID: <529F3183.3060103@viagenie.ca> Date: Wed, 04 Dec 2013 08:43:31 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529D02E2.2090303@viagenie.ca> <529DF0F9.1060705@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-ietf-behave-ipfix-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 13:43:36 -0000 Le 2013-12-03 22:42, Senthil Sivakumar (ssenthil) a écrit : >> Seriously, we need to write our protocols in a version-agnostic manner >> so that they support any kind of NATxy. You don't want to have to write >> a new RFC when your product team comes up with a new NATxy feature. You >> want to be able to apply the existing RFC to any kind of NAT. >> >> Makes sense? > > Not really. In general, I would agree that you want write a protocol > version agnostic way, > But in this particular case, the NAT external address being an IPv6 > address, I don¹t see > a use case. Designing for something that would never happen is called > over-engineering?? Well, it already exists. There are a number of NAT?6 implementations out there, Linux 3.7+ being one of them. As an example, the NAT MIB has been IP version agnostic since the start (RFC 4008). IMHO it's not really over-engineering because the additional complexity is very very low. The draft is already version-agnostic in other parts, so we know how to do it. Finally, it wouldn't surprise me if IESG insisted on any new RFC being IP version agnostic (if not IPv6-only), in the spirit of RFC 6540... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Dec 4 05:48:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE621AE26B for ; Wed, 4 Dec 2013 05:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 37SwXemPqviI for ; Wed, 4 Dec 2013 05:48:41 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 398961AE11B for ; Wed, 4 Dec 2013 05:48:41 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:9924:4792:a388:be96]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0941A46902; Wed, 4 Dec 2013 08:48:37 -0500 (EST) Message-ID: <529F32B5.60409@viagenie.ca> Date: Wed, 04 Dec 2013 08:48:37 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529DEF3A.6090606@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: [BEHAVE] Logging realms X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 13:48:42 -0000 Le 2013-12-03 22:45, Senthil Sivakumar (ssenthil) a écrit : > Maybe we need to ask the question of, do we need to have the intelligence > of Originating address realm in logging. I don't know. What I do know is that we need both the internal and external realm in logging. > The most common use case, lets take CGN, a subscriber in internal realm > Tries to access internet. Why do we have to log external realm for every > flow? Because when you read the logs you want to be able to distinguish that common use case from other cases where the realms differ. Now, if you ask further "Why log realms if there is only ever one case, and the realms are always the same?" The answer would be: we can make realms optional in the protocol. But then you would need a boolean indicating if the realm is present. I'm not sure it would save much space, and it certainly would increase complexity. Easier to just always log the realm (could be "0" for simple NATs). Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tom.taylor.stds@gmail.com Wed Dec 4 06:03:18 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D413D1AE254 for ; Wed, 4 Dec 2013 06:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 94ayKPXreOL7 for ; Wed, 4 Dec 2013 06:03:17 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id BA9E41AE262 for ; Wed, 4 Dec 2013 06:03:16 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so27034642iej.12 for ; Wed, 04 Dec 2013 06:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=U+70XiJyb1nyI79a56exlWjsN9n1w+JY+V/hFZKjZ8M=; b=vTmwxH1vFdTgmXKP1Y+BtHurneyVbo4+ULjfbc7DYGfSPcH+qhSPPZBuZCCJfiok1W isGchFtBqqjEKAb9prObsgJA/0q3BkG2Qf10xtu8O67MsHdlUFSMDZQF/tLy/vz8N51d Bujp32DPoU1FHQ4zj0bPxzNh8Ae/AmDbNVzOPNhV17kJLBkekLYp8717j0kznJ1IHJDH pryolBuf0lin2kDf+QsBvIZZ2hvKC0HBiRBEHKfBoRRCw/BkCBdlehT7kbtG7D1t0p+T jiFgbfvgBTK9Wp2xic+mt9aUXkZKVOkIdJJYUM1q/0WXWnkfSky4sEcuRcqUyhTgdrQ/ oU0w== X-Received: by 10.43.145.197 with SMTP id jv5mr49992653icc.2.1386165793726; Wed, 04 Dec 2013 06:03:13 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id p14sm4298718igr.7.2013.12.04.06.03.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 06:03:13 -0800 (PST) Message-ID: <529F361E.4030002@gmail.com> Date: Wed, 04 Dec 2013 09:03:10 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Simon Perreault , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" References: <529C965E.9080405@viagenie.ca> <529CD96C.6080602@gmail.com> <529DEF3A.6090606@viagenie.ca> <529F32B5.60409@viagenie.ca> In-Reply-To: <529F32B5.60409@viagenie.ca> Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Logging realms X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:03:19 -0000 On 04/12/2013 8:48 AM, Simon Perreault wrote: > Le 2013-12-03 22:45, Senthil Sivakumar (ssenthil) a écrit : >> Maybe we need to ask the question of, do we need to have the intelligence >> of Originating address realm in logging. > > I don't know. > > What I do know is that we need both the internal and external realm in > logging. > >> The most common use case, lets take CGN, a subscriber in internal realm >> Tries to access internet. Why do we have to log external realm for every >> flow? > > Because when you read the logs you want to be able to distinguish that > common use case from other cases where the realms differ. > > Now, if you ask further "Why log realms if there is only ever one case, > and the realms are always the same?" The answer would be: we can make > realms optional in the protocol. But then you would need a boolean > indicating if the realm is present. I'm not sure it would save much > space, and it certainly would increase complexity. Easier to just always > log the realm (could be "0" for simple NATs). > > Simon In the SYSLOG case, omitting a realm (because there is only one possibility) would save 7 bytes. But I see your complexity argument. An implementation is likely to use predefined templates where the values just have to be inserted, and any optional elements mean either multiple templates or additional text manipulation. Tom From tom.taylor.stds@gmail.com Sat Dec 21 10:52:30 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382AD1AE00A; Sat, 21 Dec 2013 10:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 bQZI55N11zmd; Sat, 21 Dec 2013 10:52:28 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 37F671ADFF7; Sat, 21 Dec 2013 10:52:28 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id uy17so9985469igb.4 for ; Sat, 21 Dec 2013 10:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zQJwjSAUrpiQmBS6AWhTr7ohXS90TPSRLRGI6FHKEbo=; b=lBS3jQ6kbl2RdF0/SeExezDs0v/rRwR9Da16HYVL8Tto+q5b/LisMd0ffaYUUiD0uv /Hvn50jAWdK5DZHamIQcNp0sHMVoTq5ZlT4Th+t/2WI28Yk2DCfZSN7xogRhyafXszjn qhDHJkadVM8bvRp4/M2eVZUiUfm92FJutaVfT9lxHCFoL9TsQgCR4gPuR3FZ6e4k/FKw uO7curr+mQtL0y81jZIG+dY3aJ8X41YzfxmlgkOycJTzMb4cv0v4426d91eoGdzQsJ1S cHwaWLpRtl1emkJOtn6c9r0o8aBkjFEQAYRT0/LYjZs8n3OFOgpr85zDlcVJaHacchym WXZQ== X-Received: by 10.43.140.77 with SMTP id iz13mr10569101icc.47.1387651945460; Sat, 21 Dec 2013 10:52:25 -0800 (PST) Received: from [192.168.97.185] ([67.210.160.130]) by mx.google.com with ESMTPSA id nh7sm16168110igb.7.2013.12.21.10.52.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Dec 2013 10:52:24 -0800 (PST) Message-ID: <52B5E367.2090901@gmail.com> Date: Sat, 21 Dec 2013 13:52:23 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 18:52:30 -0000 I know there is minimal chance of a response at this time of year, but it would be nice to get on with this work. Up to now, the SYSLOG-based NAT logging document has identified individual subscriber sites using identifiers the nature of which is indicated in the text below. In addition, it has used realm identifiers. We are now proposing to rationalize the situation by having the realm absorb all of the other information. In the case of DS-Lite, however, this has an operational impact: administrative action is required to assign a realm identifier to every individual subscriber site served by a DS_Lite tunnel. Is this reasonable, or should realms apply at a more aggregate level? The text that follows would replace existing text in the SYSLOG NAT document talking about realms and subscriber site identifiers. The MIB and IPFIX logging documents would also align themselves with this text. Tom Taylor --------------------- A realm identifies an IP numbering space. A NAT session always maps between an interior and an exterior realm. In simple NAT configurations, it may be possible to identify a default interior realm and/or a default exterior realm for all sessions. Address pools are associated with specific exterior realms. It is necessary to define multiple realms when multiple IP numbering spaces exist. A NAT may distinguish realms in its mapping tables in different ways, depending on implementation and deployment. Examples follow shortly. For external presentation, however, logging will use the realm number. The NAT MIB [reference] provides a mapping between realm number and an administratively-provided realm name, and may provide further information relating that to other information corresponding more closely to the representation by the NAT in its internal tables. A NAT recognizes the incoming realm by three basic means: - at the physical level, by incoming interface; - at layer 2, by incoming VLAN, VLAN stack, or VPN; - at layer 3: -- by PE-based VPN based on incoming destination address and possibly other packet header information and forwarded using VPNs based either on BGP/MPLS or Virtual Routers, or -- by incoming tunnel, typical of various transition technologies. [RFC 4026] is useful to sort out the various VPN concepts. The rest of this description deals with specific cases of layer 3 tunnels associated with transition technologies. The administrator has to be aware of these descriptions for the purpose of assigning realm names to the entities involved, while the NAT designer needs to understand how to implement both NAT operation in the cases described and the mapping between the identifiers concerned and the realm identifier. DS-Lite is an IPv4-over-IPv6 technology described in [RFC 6333]. It features an encapsulating/decapsulating service combined with a very large scale NAT44 in the provider network (the Address Family Transitional Router, AFTR). Every outbound IPv4 packet has a source address within the reserved 192.0.0.0/29 range. As a result, Section 6.6 of [RFC 6333] has the following advice on NAT operation for DS-Lite: "6.6. Extended Binding Table The NAT binding table of the AFTR element is extended to include the source IPv6 address of the incoming packets. This IPv6 address is used to disambiguate between the overlapping IPv4 address space of the service provider customers." In the DS-Lite case, therefore, the NAT identifies realm from the IPv6 address of the encapsulating tunnel from the customer device. Gateway-Initiated DS-Lite is a modification of DS-Lite described in [RFC 6674]. It is based primarily on the aggregation of traffic from a particular access gateway through a single softwire to the AFTR. Within that tunnel, a context identifier identifies the flow of traffic from a particular customer device. The IPv4 source address in outbound packets thus becomes irrelevant for routing, whether or not it is unique. In summary, for Gateway-Initiated DS-Lite the NAT identifies realm from the combination of softwire identifier and context identifier. Section 6 of [RFC 6674] describes the combinations of identifiers that might be deployed, depending on the operator circumstances. Sections 3 and 4 of [RFC 6674] go into the details of NAT operation for Gateway-Initiated DS-Lite. From rajiva@cisco.com Sat Dec 21 18:24:20 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355281AE142; Sat, 21 Dec 2013 18:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 PVwQCD0JpX_9; Sat, 21 Dec 2013 18:24:18 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A61341AE141; Sat, 21 Dec 2013 18:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5243; q=dns/txt; s=iport; t=1387679055; x=1388888655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=93BrR2hTpXxCSzxcxgLij+hHl64QQ8MvDgIAT2urhNI=; b=Vv8M5RkoRok9hpvWjzJX4yhPwC1XdL9FHggVP7WnPQbYsbVylheeankb XQh21LM/QGIsFfryjyka24Iot2BxHiI1tlt93Faxqw4i1e3+RSEfAFlXk v3Kaa5fqzWwRrj3dge9RE+SD0gN+ol8fDGoKGSsMog53/E88jflJnVcfq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAPdMtlKtJXG8/2dsb2JhbABOCoMLOLlGT4ESFnSCJQEBAQMBAQEBNzQLBQsCAQg2ECEGCyUCBA4Fh3ADCQgNw38NhlITBI0SgTcpMweDI4ETBJYrgWyMWoU6gy0 X-IronPort-AV: E=Sophos;i="4.95,529,1384300800"; d="scan'208";a="8416541" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 22 Dec 2013 02:24:03 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBM2O3A6016713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Dec 2013 02:24:03 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.165]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Sat, 21 Dec 2013 20:24:03 -0600 From: "Rajiv Asati (rajiva)" To: Tom Taylor Thread-Topic: [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging Thread-Index: AQHO/n3T84s7bgy1Okq7+apKkTaFvJpffMe4 Date: Sun, 22 Dec 2013 02:24:03 +0000 Message-ID: <2ED40241-86C0-4BB4-BECD-0D1BC1C5B756@cisco.com> References: <52B5E367.2090901@gmail.com> In-Reply-To: <52B5E367.2090901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 02:24:20 -0000 > In the case of DS-Lite, however, this has an operational impact: administ= rative action is required to assign a realm identifier to every individual = subscriber site served by a DS_Lite tunnel. Reading section 6, the incoming realm identifier refers/includes the IPv6 a= ddress of the encapsulating tunnel (from the customer device). Why is an ad= min action required? Cheers, Rajiv Sent from my Phone On Dec 22, 2013, at 12:22 AM, "Tom Taylor" wrot= e: > I know there is minimal chance of a response at this time of year, but it= would be nice to get on with this work. >=20 > Up to now, the SYSLOG-based NAT logging document has identified individua= l subscriber sites using identifiers the nature of which is indicated in th= e text below. In addition, it has used realm identifiers. We are now propos= ing to rationalize the situation by having the realm absorb all of the othe= r information. In the case of DS-Lite, however, this has an operational imp= act: administrative action is required to assign a realm identifier to ever= y individual subscriber site served by a DS_Lite tunnel. >=20 > Is this reasonable, or should realms apply at a more aggregate level? >=20 > The text that follows would replace existing text in the SYSLOG NAT docum= ent talking about realms and subscriber site identifiers. The MIB and IPFIX= logging documents would also align themselves with this text. >=20 > Tom Taylor >=20 > --------------------- >=20 > A realm identifies an IP numbering space. A NAT session always maps betwe= en an interior and an exterior realm. In simple NAT configurations, it may = be possible to identify a default interior realm and/or a default exterior = realm for all sessions. >=20 > Address pools are associated with specific exterior realms. >=20 > It is necessary to define multiple realms when multiple IP numbering spac= es exist. A NAT may distinguish realms in its mapping tables in different w= ays, depending on implementation and deployment. Examples follow shortly. F= or external presentation, however, logging will use the realm number. The N= AT MIB [reference] provides a mapping between realm number and an administr= atively-provided realm name, and may provide further information relating t= hat to other information corresponding more closely to the representation b= y the NAT in its internal tables. >=20 > A NAT recognizes the incoming realm by three basic means: > - at the physical level, by incoming interface; > - at layer 2, by incoming VLAN, VLAN stack, or VPN; > - at layer 3: > -- by PE-based VPN based on incoming destination address and > possibly other packet header information and forwarded > using VPNs based either on BGP/MPLS or Virtual Routers, or > -- by incoming tunnel, typical of various transition technologies. > [RFC 4026] is useful to sort out the various VPN concepts. >=20 > The rest of this description deals with specific cases of layer 3 tunnels= associated with transition technologies. The administrator has to be aware= of these descriptions for the purpose of assigning realm names to the enti= ties involved, while the NAT designer needs to understand how to implement = both NAT operation in the cases described and the mapping between the ident= ifiers concerned and the realm identifier. >=20 > DS-Lite is an IPv4-over-IPv6 technology described in [RFC 6333]. It featu= res an encapsulating/decapsulating service combined with a very large scale= NAT44 in the provider network (the Address Family Transitional Router, AFT= R). Every outbound IPv4 packet has a source address within the reserved 192= .0.0.0/29 range. As a result, Section 6.6 of [RFC 6333] has the following a= dvice on NAT operation for DS-Lite: >=20 > "6.6. Extended Binding Table >=20 > The NAT binding table of the AFTR element is extended to include the > source IPv6 address of the incoming packets. This IPv6 address is > used to disambiguate between the overlapping IPv4 address space of > the service provider customers." >=20 > In the DS-Lite case, therefore, the NAT identifies realm from the IPv6 ad= dress of the encapsulating tunnel from the customer device. >=20 > Gateway-Initiated DS-Lite is a modification of DS-Lite described in [RFC = 6674]. It is based primarily on the aggregation of traffic from a particula= r access gateway through a single softwire to the AFTR. Within that tunnel,= a context identifier identifies the flow of traffic from a particular cust= omer device. The IPv4 source address in outbound packets thus becomes irrel= evant for routing, whether or not it is unique. >=20 > In summary, for Gateway-Initiated DS-Lite the NAT identifies realm from t= he combination of softwire identifier and context identifier. Section 6 of = [RFC 6674] describes the combinations of identifiers that might be deployed= , depending on the operator circumstances. Sections 3 and 4 of [RFC 6674] g= o into the details of NAT operation for Gateway-Initiated DS-Lite. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Sun Dec 22 08:56:23 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8A1AE660; Sun, 22 Dec 2013 08:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 IzBChNAkKE2t; Sun, 22 Dec 2013 08:56:22 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5A54F1AE725; Sun, 22 Dec 2013 08:56:22 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so19302079igb.0 for ; Sun, 22 Dec 2013 08:56:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=puk/gJqjpmKqCaEYFRWSEWHc7I4Jlis9F+ms0Bf2Lps=; b=rDGgk4x14bRJsb7C6DjAbaLNYayFdcd6HTPHaLzQOLbrq6gL7CADriR/bLx4rJlKzr AUejS1/qCqakJaDRwca7mcK0bSVgxYwCnNX3ZOpdMuelxEs0Vud828PXoXUGHOF2hjb7 /TOQdeYyZ74RCCJeg+VLgAmZMdPun7fxIYe7thMLUxUvRYpochFijp5K3yQAg/QKY/aP eWh8rZdtFxHYkq1dGpBke1p0SrBj+kdt63SEB/JPPZVSKXligrY0bTDNXU6ft2wi2QE9 4GvwV/dnwtE3Gs/NxxXeaKLzU6u+TMftrC/8hyxbTUnmPzIhWSs6np9wTQJJ4v9snlKK 53Yg== X-Received: by 10.50.21.2 with SMTP id r2mr10800046ige.13.1387731379355; Sun, 22 Dec 2013 08:56:19 -0800 (PST) Received: from [192.168.97.185] ([67.210.160.130]) by mx.google.com with ESMTPSA id kb10sm20121717igb.6.2013.12.22.08.56.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Dec 2013 08:56:18 -0800 (PST) Message-ID: <52B719B2.5000706@gmail.com> Date: Sun, 22 Dec 2013 11:56:18 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <52B5E367.2090901@gmail.com> <2ED40241-86C0-4BB4-BECD-0D1BC1C5B756@cisco.com> In-Reply-To: <2ED40241-86C0-4BB4-BECD-0D1BC1C5B756@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 16:56:24 -0000 Sorry, section 6 of which document? Section 2.3.1 of the SYSLOG document http://www.ietf.org/id/draft-ietf-behave-syslog-nat-logging-05.txt is the most relevant to this discussion. What is termed a generalized internal address in that section represents the prior point of view: that the realm has to be qualified with further information to identify the subscriber site uniquely. The fact is that the characterization in that section is incomplete -- the qualifying information required can also include VLAN and VRF identifiers. I guess the proposed new text effectively incorporates the generalized internal address information into the realm name, so the administrative action required would be something that does that automatically. Tom On 21/12/2013 9:24 PM, Rajiv Asati (rajiva) wrote: >> In the case of DS-Lite, however, this has an operational impact: >> administrative action is required to assign a realm identifier to >> every individual subscriber site served by a DS_Lite tunnel. > > Reading section 6, the incoming realm identifier refers/includes the > IPv6 address of the encapsulating tunnel (from the customer device). > Why is an admin action required? > > Cheers, Rajiv > > Sent from my Phone > .... From tom.taylor.stds@gmail.com Wed Dec 25 06:05:33 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2C51ADF58; Wed, 25 Dec 2013 06:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 nxEkWnrs293I; Wed, 25 Dec 2013 06:05:31 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E8E121AE28B; Wed, 25 Dec 2013 06:05:30 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id hl1so25736656igb.5 for ; Wed, 25 Dec 2013 06:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=x2fx6fsnsWI87RjHO080vUeAmspHjEjFOff0DQrXg6w=; b=kuffMGkT24tgYMocSSaS8koP4YkNXiFK2xBQLGt2hOt9OPClXI9aFiiv5cG11yotnY Jy74rOE9KUClWij9ku6b8uIVF4IqlZoS+2U12b9BfvqDNKWeIsnIcNZX5ghEYuMorMyV 93QIGeWEhgX/3TTHHTnm+hZkz6HR3NudSn8ZaLK/owJdFZ4F38QCY8DnTWVXMBFXdXF0 0B+rw4NZHasxQRC7tQYhDxZeErWOc43sRf4a92UNF6RQOWktnqfj8pUBvNbd4eaI+TEI woUt8Z4hWtROqHcY4hIEfbBHhvpGex6bpOsv81e9vZcDE4djcLLXn1Lkbc9u0HCKjcgg LYPw== X-Received: by 10.42.171.69 with SMTP id i5mr164693icz.82.1387980326880; Wed, 25 Dec 2013 06:05:26 -0800 (PST) Received: from [192.168.1.67] ([64.56.250.4]) by mx.google.com with ESMTPSA id l7sm33177774igx.2.2013.12.25.06.05.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Dec 2013 06:05:26 -0800 (PST) Message-ID: <52BAE626.8070604@gmail.com> Date: Wed, 25 Dec 2013 09:05:26 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" References: <52B5E367.2090901@gmail.com> In-Reply-To: <52B5E367.2090901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Cancel: Re: Realm identifiers vs. subscriber site identifiers in logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 14:05:33 -0000 Further analysis shows it was a foolish idea to try to save a few bytes per log at the expense of other complications. Sorry for the noise. Tom Taylor On 21/12/2013 1:52 PM, Tom Taylor wrote: > I know there is minimal chance of a response at this time of year, but > it would be nice to get on with this work. > > Up to now, the SYSLOG-based NAT logging document has identified > individual subscriber sites using identifiers the nature of which is > indicated in the text below. In addition, it has used realm identifiers. > We are now proposing to rationalize the situation by having the realm > absorb all of the other information. In the case of DS-Lite, however, > this has an operational impact: administrative action is required to > assign a realm identifier to every individual subscriber site served by > a DS_Lite tunnel. > > Is this reasonable, or should realms apply at a more aggregate level? > > The text that follows would replace existing text in the SYSLOG NAT > document talking about realms and subscriber site identifiers. The MIB > and IPFIX logging documents would also align themselves with this text. > > Tom Taylor > > --------------------- > > A realm identifies an IP numbering space. A NAT session always maps > between an interior and an exterior realm. In simple NAT configurations, > it may be possible to identify a default interior realm and/or a default > exterior realm for all sessions. > > Address pools are associated with specific exterior realms. > > It is necessary to define multiple realms when multiple IP numbering > spaces exist. A NAT may distinguish realms in its mapping tables in > different ways, depending on implementation and deployment. Examples > follow shortly. For external presentation, however, logging will use the > realm number. The NAT MIB [reference] provides a mapping between realm > number and an administratively-provided realm name, and may provide > further information relating that to other information corresponding > more closely to the representation by the NAT in its internal tables. > > A NAT recognizes the incoming realm by three basic means: > - at the physical level, by incoming interface; > - at layer 2, by incoming VLAN, VLAN stack, or VPN; > - at layer 3: > -- by PE-based VPN based on incoming destination address and > possibly other packet header information and forwarded > using VPNs based either on BGP/MPLS or Virtual Routers, or > -- by incoming tunnel, typical of various transition technologies. > [RFC 4026] is useful to sort out the various VPN concepts. > > The rest of this description deals with specific cases of layer 3 > tunnels associated with transition technologies. The administrator has > to be aware of these descriptions for the purpose of assigning realm > names to the entities involved, while the NAT designer needs to > understand how to implement both NAT operation in the cases described > and the mapping between the identifiers concerned and the realm identifier. > > DS-Lite is an IPv4-over-IPv6 technology described in [RFC 6333]. It > features an encapsulating/decapsulating service combined with a very > large scale NAT44 in the provider network (the Address Family > Transitional Router, AFTR). Every outbound IPv4 packet has a source > address within the reserved 192.0.0.0/29 range. As a result, Section 6.6 > of [RFC 6333] has the following advice on NAT operation for DS-Lite: > > "6.6. Extended Binding Table > > The NAT binding table of the AFTR element is extended to include the > source IPv6 address of the incoming packets. This IPv6 address is > used to disambiguate between the overlapping IPv4 address space of > the service provider customers." > > In the DS-Lite case, therefore, the NAT identifies realm from the IPv6 > address of the encapsulating tunnel from the customer device. > > Gateway-Initiated DS-Lite is a modification of DS-Lite described in [RFC > 6674]. It is based primarily on the aggregation of traffic from a > particular access gateway through a single softwire to the AFTR. Within > that tunnel, a context identifier identifies the flow of traffic from a > particular customer device. The IPv4 source address in outbound packets > thus becomes irrelevant for routing, whether or not it is unique. > > In summary, for Gateway-Initiated DS-Lite the NAT identifies realm from > the combination of softwire identifier and context identifier. Section 6 > of [RFC 6674] describes the combinations of identifiers that might be > deployed, depending on the operator circumstances. Sections 3 and 4 of > [RFC 6674] go into the details of NAT operation for Gateway-Initiated > DS-Lite. From wwwrun@rfc-editor.org Tue Dec 31 02:22:04 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AD81AE194 for ; Tue, 31 Dec 2013 02:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 SKgmGHqzxIrn for ; Tue, 31 Dec 2013 02:22:03 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 776871AE0AB for ; Tue, 31 Dec 2013 02:22:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3A1BB7FC175; Tue, 31 Dec 2013 02:21:57 -0800 (PST) To: rohan@ekabal.com, philip_matthews@magma.ca, jdrosen@jdrosen.net, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, dwing@cisco.com, dthaler@microsoft.com From: RFC Errata System Message-Id: <20131231102157.3A1BB7FC175@rfc-editor.org> Date: Tue, 31 Dec 2013 02:21:57 -0800 (PST) Cc: toyvenu.tech@gmail.com, behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Editorial Errata Reported] RFC5766 (3854) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 10:22:04 -0000 The following errata report has been submitted for RFC5766, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5766&eid=3854 -------------------------------------- Type: Editorial Reported by: Venu Section: 11 Original Text ------------- 0x4000 through 0x7FFF: These values are the allowed channel numbers (16,383 possible values). Corrected Text -------------- 0x4000 through 0x7FFF: These values are the allowed channel numbers (16,384 possible values). Notes ----- Section 11.2: The channel number is in the range 0x4000 through 0x7FFE (inclusive); Since both the values are inclusive it should be 16384 = (0x7FFF-0x4000 + 1) Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5766 (draft-ietf-behave-turn-16) -------------------------------------- Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Publication Date : April 2010 Author(s) : R. Mahy, P. Matthews, J. Rosenberg Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG