From tireddy@cisco.com Tue Sep 3 04:53:27 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74E21E809E; Tue, 3 Sep 2013 04:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2EoHrAiS86g; Tue, 3 Sep 2013 04:53:22 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1AB11E816F; Tue, 3 Sep 2013 04:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2394; q=dns/txt; s=iport; t=1378209202; x=1379418802; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=mpzl6UVVshJWPVFloDmiMciGZnalcQSbO5wo9uSH6O8=; b=V3qtdTnOO2jMQo393qGeSwoWjjU+fhdY35u/gE7Oz8rPoH9zWq+b5Pt+ oFtYJftZNq3HGaE7gQLtIaq3d09WnPBMJnj/1iq6lFo7RkVTwKyg9o7Ve rkxDyg2tm3EtSQLijJ7rTb6X3iniWhHZuXPziWaWOwQYw/SL/VFfUnFsc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAH7MJVKtJXHA/2dsb2JhbABagwc1SwaDJ71MF4EVFnSCJAEBAQQjEToJDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEARIIAYd5BwWnJpINgSmOHBYogmM0gQADmSSQN4Mggio X-IronPort-AV: E=Sophos;i="4.89,1013,1367971200"; d="scan'208";a="254906790" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 03 Sep 2013 11:53:21 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r83BrLVR011707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 11:53:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.153]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 3 Sep 2013 06:53:21 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Behave@ietf.org" , "pntaw@ietf.org" Thread-Topic: New Version Notification for draft-reddy-behave-turn-auth-03.txt Thread-Index: AQHOqHBfKBFggWu4mEK/F3kVFKcO8Zmzj//A Date: Tue, 3 Sep 2013 11:53:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1904E373@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:53:27 -0000 W0luY2x1ZGluZyBwbnRhdyBtYWlsaW5nIGxpc3RdDQoNClRoaXMgZHJhZnQgZGlzY3Vzc2VzIHRo ZSBpc3N1ZXMgd2l0aCBTVFVOIEF1dGhlbnRpY2F0aW9uIGZvciBUVVJOLiBDb21tZW50cyBhbmQg c3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuIEluIEJFSEFWRSBXRyB0aGVyZSB3ZXJlIGRpc2N1c3Np b25zIHRvIHNvbHZlIHRoZSBwcm9ibGVtIG1lbnRpb25lZCBpbiB0aGUgZHJhZnQgdXNpbmcgdGVj aG5pcXVlcyBsaWtlIFRVUk4gb3ZlciBEVExTLCBkcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVz dC0wMC4NCg0KLVRpcnUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K U2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAzLCAyMDEzIDEyOjEwIFBNDQpUbzogUmFtIE1vaGFu IFIgKHJtb2hhbnIpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBNdXRodSBBcnVsIE1v emhpIFBlcnVtYWwgKG1wZXJ1bWFsKTsgQWxwZXIgWWVnaW47IFJhbSBNb2hhbiBSIChybW9oYW5y KTsgQWxwZXIgRS4gWWVnaW47IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LWJlaGF2ZS10 dXJuLWF1dGgtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJlZGR5LWJl aGF2ZS10dXJuLWF1dGgtMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0K DQpGaWxlbmFtZToJIGRyYWZ0LXJlZGR5LWJlaGF2ZS10dXJuLWF1dGgNClJldmlzaW9uOgkgMDMN ClRpdGxlOgkJIFByb2JsZW1zIHdpdGggU1RVTiBBdXRoZW50aWNhdGlvbiBmb3IgVFVSTg0KQ3Jl YXRpb24gZGF0ZToJIDIwMTMtMDktMDMNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJlZGR5LWJlaGF2ZS10dXJuLWF1dGgtMDMudHh0DQpTdGF0 dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVkZHkt YmVoYXZlLXR1cm4tYXV0aA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1yZWRkeS1iZWhhdmUtdHVybi1hdXRoLTAzDQpEaWZmOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJlZGR5LWJlaGF2ZS10dXJuLWF1 dGgtMDMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBzb21lIG9mIHRo ZSBpc3N1ZXMgd2l0aCBTVFVOIGF1dGhlbnRpY2F0aW9uDQogICBmb3IgVFVSTiBtZXNzYWdlcy4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From tom.taylor.stds@gmail.com Sun Sep 8 12:28:28 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA41F21E80C3 for ; Sun, 8 Sep 2013 12:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbJBwz2FSWOa for ; Sun, 8 Sep 2013 12:28:28 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1456221E80BE for ; Sun, 8 Sep 2013 12:28:27 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so11286228ieb.28 for ; Sun, 08 Sep 2013 12:28:27 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=Q6I35eshGZzgrDzQ8mRVbONK9o9QqPrcMzk+Cw+J1Ls=; b=f4gtLDXd/OCxZlFKbSWTkgmU//bHgvkSCuDW6jrgIaxRHAwjuA7XgDCeSW+EtZvzbr fYLSsnJfCa+T890AmFp7Fg5CIEuZWnAG7XwOa2rltgD6a3EdIsoqlyrTFvLGo2BvXS2N +9LH12AVNSjkdLMKL804++I1H2PYZ46jQulgrCHtJXsjZ1jXU6iCAfyaFG/NkISlGpQY gW9y3MTVmBpO+yz5XYAAc5WBUB/AtQwaEMd4boovZen52wmrwFO4MmOBFRIkFYMDNE5c rckLTU5p2Jv+JH7zChyIFZThWL8CoEs3IaVYIOkiSgTIUNdEiikSo4g+yWc001mY1kDk AbYA== X-Received: by 10.50.115.103 with SMTP id jn7mr6397829igb.1.1378668507614; Sun, 08 Sep 2013 12:28:27 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-171-98.tor.primus.ca. [173.206.171.98]) by mx.google.com with ESMTPSA id p10sm11686740igx.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Sep 2013 12:28:26 -0700 (PDT) Message-ID: <522CCFD8.4070207@gmail.com> Date: Sun, 08 Sep 2013 15:28:24 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Co-authors Subject: [BEHAVE] Action items: draft-..-syslog-nat-logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2013 19:28:29 -0000 Sorry to be slow on this: I've spent a lot of time sleeping since the meeting, while my new immune system takes hold. Comments welcome on the proposed actions and especially on the issues. Tom Taylor Prior to the meeting we had Dave Thaler's comments: http://www.ietf.org/mail-archive/web/behave/current/msg11043.html He raised the following points: 1. Logging/MIB reconciliation regarding quotas vs. high-water-marks. Discussed further in the meeting (Issue 4). See below. 2. Use of UTF-8 strings for identifiers. Action: Should probably revert to ASCII -- will check with operators. 3. Use of single "internal" and "external" realm. Outcome covered by meeting discussion (Issue 2). See below. 4. Device type registry. Outcome covered by meeting discussion (Issue 3). See below. 5. Mechanism should not be limited to cases where external address is IPv4. Action: make consistent with capabilities of PCP (as most general known case). The following actions and issues arise out of the meeting. These are organized by issue number in the presentation charts, which are at http://www.ietf.org/proceedings/87/slides/slides-87-behave-0.pdf. Issue 1: Destination logging ---------------------------- Agreed on list that destination logging would be restored as an optional capability. Action: update the session create/delete event. Update the earlier text in Section 3.1.1 discussing the issue. Issue: does this mean the BIB entry create/delete event needs to be restored? Note that when destination logging is not enabled there is still no difference between BIB entry creation and session creation. Issue: definition of configuration needed to enable/disable destination logging. Propose to add a Management Considerations section that discusses configuration for this and other aspects of logging. Issue 2: Subscriber site identifier ----------------------------------- Simon Perrault pointed out that the MIB uses the realm as an identifier. Further, both the internal and external realms should be logged. This ties in with Dave Thaler's point 3 above. Dave pointed out that realm and address are separate pieces of information, both of which are needed. (But things get a little confused at the subscriber site as opposed to an external address.) Agreed that there should be a mapping table between internal realm ID (which can be per subscriber site), and details such as VLAN ID. Above all, Dave seeks consistency between the SYSLOG, IPFIX, and MIB drafts. Action: update the SYSLOG and IPFIX drafts to include internal and external realm identifiers. In the SYSLOG draft (and perhaps in IPFIX), the internal realm identifier takes the place of the subscriber site ID. Add cross-reference to mapping table in the MIB document. Action: add mapping table to the MIB document, providing per-subscriber mapping of realm ID to provisioned IPv4 address, IPv6 prefix, Gateway-initiated DS-Lite CID/SWID combination. Issue: Where do VLANId/VRFId fit in? Additional item(s) in the mapping table? Issue 3: Device Type -------------------- Agreed this should be a non-registered free-form field for optional operator use. Corresponds to Dave Thaler's point 4 above. Action: delete proposed registry and proposed values. Update definition. Rename the field. Proposal: NAT Type? Provide for enabling/disabling of field in Management Considerations section. Issue: the same device may provide multiple types of NAT. Perhaps the value of the string will be implementation-dependent, determined by the processing logic for the triggering packet. Comments? Issue 4: Warning levels ----------------------- Agreed that high/low-water-mark threshold crossings as defined by the MIB should be logged. Related to Dave Thaler's point 1 above. Action: add high/low-water mark threshold crossing event. Cross-reference to MIB entry. In MIB, add cross-reference to logging document(s). Issue: Dave Thaler prefers not to have both MIB notifications and logging. Need to consult operators. Issue 5: Complexity of quota violation event -------------------------------------------- Simon Perrault made the point that quotas are very implementation-dependent. Agreed that log should only identify the quota and details of the triggering packet. Interpretation depends on the implementation. Action: update the quota violation event per agreement. Identify the quota by its entry in the MIB? Issue 6: Reporting port allocation/deallocation ----------------------------------------------- Preference for single encoding. IPFIX approach much more compact for large ranges, should use it. Action: revise SYSLOG to use IPFIX encoding. Provide clear explanation of the encoding for the two cases: single contiguous range, sequence of equally-spaced equal-length contiguous ranges. Issue: should port allocation events report cumulative allocations (as in syslog-nat-logging-02) or incremental allocations (as in IPFIX)? If cumulative, should probably allow for reporting of multiple allocated port sets. Issue 7: Invalid port event --------------------------- Replace with per-subscriber counters in the MIB. Action: delete event from SYSLOG. Add to MIB. From Tina.Tsou.Zouting@huawei.com Sun Sep 8 13:12:43 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257D911E815B for ; Sun, 8 Sep 2013 13:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 tagged_above=-999 required=5 tests=[AWL=-1.926, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEKXvvlbQQu8 for ; Sun, 8 Sep 2013 13:12:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6121F9CE2 for ; Sun, 8 Sep 2013 13:12:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AXB87418; Sun, 08 Sep 2013 20:12:35 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 8 Sep 2013 21:12:31 +0100 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 8 Sep 2013 21:12:33 +0100 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.42]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0146.000; Sun, 8 Sep 2013 13:12:30 -0700 From: Tina TSOU To: Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] Action items: draft-..-syslog-nat-logging Thread-Index: AQHOrMme3UbVmEfq1UCxZpIBRbtHbJm8RB7A Date: Sun, 8 Sep 2013 20:12:29 +0000 Message-ID: References: <522CCFD8.4070207@gmail.com> In-Reply-To: <522CCFD8.4070207@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.144] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Co-authors Subject: Re: [BEHAVE] Action items: draft-..-syslog-nat-logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 08 Sep 2013 20:12:43 -0000 RGVhciBUb20sDQpUaGFuayB5b3UgZm9yIHB1dHRpbmcgdGhlc2UgdG9nZXRoZXIuDQpUaGUgYWN0 aW9ucyBsb29rIGdvb2QgdG8gbWUuDQoNClRoYW5rIHlvdSwNClRpbmENCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGJlaGF2ZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBUb20gVGF5bG9yDQo+ IFNlbnQ6IDIwMTPE6jnUwjjI1SAxMjoyOA0KPiBUbzogYmVoYXZlQGlldGYub3JnDQo+IENjOiBD by1hdXRob3JzDQo+IFN1YmplY3Q6IFtCRUhBVkVdIEFjdGlvbiBpdGVtczogZHJhZnQtLi4tc3lz bG9nLW5hdC1sb2dnaW5nDQo+IA0KPiBTb3JyeSB0byBiZSBzbG93IG9uIHRoaXM6IEkndmUgc3Bl bnQgYSBsb3Qgb2YgdGltZSBzbGVlcGluZyBzaW5jZSB0aGUNCj4gbWVldGluZywgd2hpbGUgbXkg bmV3IGltbXVuZSBzeXN0ZW0gdGFrZXMgaG9sZC4NCj4gDQo+IENvbW1lbnRzIHdlbGNvbWUgb24g dGhlIHByb3Bvc2VkIGFjdGlvbnMgYW5kIGVzcGVjaWFsbHkgb24gdGhlIGlzc3Vlcy4NCj4gDQo+ IFRvbSBUYXlsb3INCj4gDQo+IA0KPiBQcmlvciB0byB0aGUgbWVldGluZyB3ZSBoYWQgRGF2ZSBU aGFsZXIncyBjb21tZW50czoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2JlaGF2ZS9jdXJyZW50L21zZzExMDQzLmh0bWwNCj4gDQo+IEhlIHJhaXNlZCB0aGUgZm9sbG93 aW5nIHBvaW50czoNCj4gDQo+IDEuIExvZ2dpbmcvTUlCIHJlY29uY2lsaWF0aW9uIHJlZ2FyZGlu ZyBxdW90YXMgdnMuIGhpZ2gtd2F0ZXItbWFya3MuDQo+IERpc2N1c3NlZCBmdXJ0aGVyIGluIHRo ZSBtZWV0aW5nIChJc3N1ZSA0KS4gU2VlIGJlbG93Lg0KPiANCj4gMi4gVXNlIG9mIFVURi04IHN0 cmluZ3MgZm9yIGlkZW50aWZpZXJzLg0KPiANCj4gQWN0aW9uOiBTaG91bGQgcHJvYmFibHkgcmV2 ZXJ0IHRvIEFTQ0lJIC0tIHdpbGwgY2hlY2sgd2l0aCBvcGVyYXRvcnMuDQo+IA0KPiAzLiBVc2Ug b2Ygc2luZ2xlICJpbnRlcm5hbCIgYW5kICJleHRlcm5hbCIgcmVhbG0uIE91dGNvbWUgY292ZXJl ZCBieQ0KPiBtZWV0aW5nIGRpc2N1c3Npb24gKElzc3VlIDIpLiBTZWUgYmVsb3cuDQo+IA0KPiA0 LiBEZXZpY2UgdHlwZSByZWdpc3RyeS4gT3V0Y29tZSBjb3ZlcmVkIGJ5IG1lZXRpbmcgZGlzY3Vz c2lvbiAoSXNzdWUgMykuDQo+IFNlZSBiZWxvdy4NCj4gDQo+IDUuIE1lY2hhbmlzbSBzaG91bGQg bm90IGJlIGxpbWl0ZWQgdG8gY2FzZXMgd2hlcmUgZXh0ZXJuYWwgYWRkcmVzcyBpcw0KPiBJUHY0 Lg0KPiANCj4gQWN0aW9uOiBtYWtlIGNvbnNpc3RlbnQgd2l0aCBjYXBhYmlsaXRpZXMgb2YgUENQ IChhcyBtb3N0IGdlbmVyYWwga25vd24NCj4gY2FzZSkuDQo+IA0KPiANCj4gVGhlIGZvbGxvd2lu ZyBhY3Rpb25zIGFuZCBpc3N1ZXMgYXJpc2Ugb3V0IG9mIHRoZSBtZWV0aW5nLiBUaGVzZSBhcmUN Cj4gb3JnYW5pemVkIGJ5IGlzc3VlIG51bWJlciBpbiB0aGUgcHJlc2VudGF0aW9uIGNoYXJ0cywg d2hpY2ggYXJlIGF0DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODcvc2xpZGVz L3NsaWRlcy04Ny1iZWhhdmUtMC5wZGYuDQo+IA0KPiBJc3N1ZSAxOiBEZXN0aW5hdGlvbiBsb2dn aW5nDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEFncmVlZCBvbiBsaXN0 IHRoYXQgZGVzdGluYXRpb24gbG9nZ2luZyB3b3VsZCBiZSByZXN0b3JlZCBhcyBhbiBvcHRpb25h bA0KPiBjYXBhYmlsaXR5Lg0KPiANCj4gQWN0aW9uOiB1cGRhdGUgdGhlIHNlc3Npb24gY3JlYXRl L2RlbGV0ZSBldmVudC4gVXBkYXRlIHRoZSBlYXJsaWVyIHRleHQNCj4gaW4gU2VjdGlvbiAzLjEu MSBkaXNjdXNzaW5nIHRoZSBpc3N1ZS4NCj4gDQo+IElzc3VlOiBkb2VzIHRoaXMgbWVhbiB0aGUg QklCIGVudHJ5IGNyZWF0ZS9kZWxldGUgZXZlbnQgbmVlZHMgdG8gYmUNCj4gcmVzdG9yZWQ/IE5v dGUgdGhhdCB3aGVuIGRlc3RpbmF0aW9uIGxvZ2dpbmcgaXMgbm90IGVuYWJsZWQgdGhlcmUgaXMN Cj4gc3RpbGwgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIEJJQiBlbnRyeSBjcmVhdGlvbiBhbmQgc2Vz c2lvbiBjcmVhdGlvbi4NCj4gDQo+IElzc3VlOiBkZWZpbml0aW9uIG9mIGNvbmZpZ3VyYXRpb24g bmVlZGVkIHRvIGVuYWJsZS9kaXNhYmxlIGRlc3RpbmF0aW9uDQo+IGxvZ2dpbmcuIFByb3Bvc2Ug dG8gYWRkIGEgTWFuYWdlbWVudCBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRoYXQNCj4gZGlzY3Vz c2VzIGNvbmZpZ3VyYXRpb24gZm9yIHRoaXMgYW5kIG90aGVyIGFzcGVjdHMgb2YgbG9nZ2luZy4N Cj4gDQo+IElzc3VlIDI6IFN1YnNjcmliZXIgc2l0ZSBpZGVudGlmaWVyDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBTaW1vbiBQZXJyYXVsdCBwb2ludGVkIG91 dCB0aGF0IHRoZSBNSUIgdXNlcyB0aGUgcmVhbG0gYXMgYW4gaWRlbnRpZmllci4NCj4gRnVydGhl ciwgYm90aCB0aGUgaW50ZXJuYWwgYW5kIGV4dGVybmFsIHJlYWxtcyBzaG91bGQgYmUgbG9nZ2Vk LiBUaGlzDQo+IHRpZXMgaW4gd2l0aCBEYXZlIFRoYWxlcidzIHBvaW50IDMgYWJvdmUuIERhdmUg cG9pbnRlZCBvdXQgdGhhdCByZWFsbQ0KPiBhbmQgYWRkcmVzcyBhcmUgc2VwYXJhdGUgcGllY2Vz IG9mIGluZm9ybWF0aW9uLCBib3RoIG9mIHdoaWNoIGFyZQ0KPiBuZWVkZWQuIChCdXQgdGhpbmdz IGdldCBhIGxpdHRsZSBjb25mdXNlZCBhdCB0aGUgc3Vic2NyaWJlciBzaXRlIGFzDQo+IG9wcG9z ZWQgdG8gYW4gZXh0ZXJuYWwgYWRkcmVzcy4pIEFncmVlZCB0aGF0IHRoZXJlIHNob3VsZCBiZSBh IG1hcHBpbmcNCj4gdGFibGUgYmV0d2VlbiBpbnRlcm5hbCByZWFsbSBJRCAod2hpY2ggY2FuIGJl IHBlciBzdWJzY3JpYmVyIHNpdGUpLCBhbmQNCj4gZGV0YWlscyBzdWNoIGFzIFZMQU4gSUQuIEFi b3ZlIGFsbCwgRGF2ZSBzZWVrcyBjb25zaXN0ZW5jeSBiZXR3ZWVuIHRoZQ0KPiBTWVNMT0csIElQ RklYLCBhbmQgTUlCIGRyYWZ0cy4NCj4gDQo+IEFjdGlvbjogdXBkYXRlIHRoZSBTWVNMT0cgYW5k IElQRklYIGRyYWZ0cyB0byBpbmNsdWRlIGludGVybmFsIGFuZA0KPiBleHRlcm5hbCByZWFsbSBp ZGVudGlmaWVycy4gSW4gdGhlIFNZU0xPRyBkcmFmdCAoYW5kIHBlcmhhcHMgaW4gSVBGSVgpLA0K PiB0aGUgaW50ZXJuYWwgcmVhbG0gaWRlbnRpZmllciB0YWtlcyB0aGUgcGxhY2Ugb2YgdGhlIHN1 YnNjcmliZXIgc2l0ZSBJRC4NCj4gQWRkIGNyb3NzLXJlZmVyZW5jZSB0byBtYXBwaW5nIHRhYmxl IGluIHRoZSBNSUIgZG9jdW1lbnQuDQo+IA0KPiBBY3Rpb246IGFkZCBtYXBwaW5nIHRhYmxlIHRv IHRoZSBNSUIgZG9jdW1lbnQsIHByb3ZpZGluZyBwZXItc3Vic2NyaWJlcg0KPiBtYXBwaW5nIG9m IHJlYWxtIElEIHRvIHByb3Zpc2lvbmVkIElQdjQgYWRkcmVzcywgSVB2NiBwcmVmaXgsDQo+IEdh dGV3YXktaW5pdGlhdGVkIERTLUxpdGUgQ0lEL1NXSUQgY29tYmluYXRpb24uDQo+IA0KPiBJc3N1 ZTogV2hlcmUgZG8gVkxBTklkL1ZSRklkIGZpdCBpbj8gQWRkaXRpb25hbCBpdGVtKHMpIGluIHRo ZSBtYXBwaW5nDQo+IHRhYmxlPw0KPiANCj4gSXNzdWUgMzogRGV2aWNlIFR5cGUNCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+IEFncmVlZCB0aGlzIHNob3VsZCBiZSBhIG5vbi1yZWdpc3Rl cmVkIGZyZWUtZm9ybSBmaWVsZCBmb3Igb3B0aW9uYWwNCj4gb3BlcmF0b3IgdXNlLiBDb3JyZXNw b25kcyB0byBEYXZlIFRoYWxlcidzIHBvaW50IDQgYWJvdmUuDQo+IA0KPiBBY3Rpb246IGRlbGV0 ZSBwcm9wb3NlZCByZWdpc3RyeSBhbmQgcHJvcG9zZWQgdmFsdWVzLiBVcGRhdGUgZGVmaW5pdGlv bi4NCj4gUmVuYW1lIHRoZSBmaWVsZC4gUHJvcG9zYWw6IE5BVCBUeXBlPyBQcm92aWRlIGZvciBl bmFibGluZy9kaXNhYmxpbmcgb2YNCj4gZmllbGQgaW4gTWFuYWdlbWVudCBDb25zaWRlcmF0aW9u cyBzZWN0aW9uLg0KPiANCj4gSXNzdWU6IHRoZSBzYW1lIGRldmljZSBtYXkgcHJvdmlkZSBtdWx0 aXBsZSB0eXBlcyBvZiBOQVQuIFBlcmhhcHMgdGhlDQo+IHZhbHVlIG9mIHRoZSBzdHJpbmcgd2ls bCBiZSBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQsIGRldGVybWluZWQgYnkgdGhlDQo+IHByb2Nl c3NpbmcgbG9naWMgZm9yIHRoZSB0cmlnZ2VyaW5nIHBhY2tldC4gQ29tbWVudHM/DQo+IA0KPiBJ c3N1ZSA0OiBXYXJuaW5nIGxldmVscw0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g QWdyZWVkIHRoYXQgaGlnaC9sb3ctd2F0ZXItbWFyayB0aHJlc2hvbGQgY3Jvc3NpbmdzIGFzIGRl ZmluZWQgYnkgdGhlDQo+IE1JQiBzaG91bGQgYmUgbG9nZ2VkLiBSZWxhdGVkIHRvIERhdmUgVGhh bGVyJ3MgcG9pbnQgMSBhYm92ZS4NCj4gDQo+IEFjdGlvbjogYWRkIGhpZ2gvbG93LXdhdGVyIG1h cmsgdGhyZXNob2xkIGNyb3NzaW5nIGV2ZW50Lg0KPiBDcm9zcy1yZWZlcmVuY2UgdG8gTUlCIGVu dHJ5LiBJbiBNSUIsIGFkZCBjcm9zcy1yZWZlcmVuY2UgdG8gbG9nZ2luZw0KPiBkb2N1bWVudChz KS4NCj4gDQo+IElzc3VlOiBEYXZlIFRoYWxlciBwcmVmZXJzIG5vdCB0byBoYXZlIGJvdGggTUlC IG5vdGlmaWNhdGlvbnMgYW5kDQo+IGxvZ2dpbmcuIE5lZWQgdG8gY29uc3VsdCBvcGVyYXRvcnMu DQo+IA0KPiBJc3N1ZSA1OiBDb21wbGV4aXR5IG9mIHF1b3RhIHZpb2xhdGlvbiBldmVudA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gU2ltb24g UGVycmF1bHQgbWFkZSB0aGUgcG9pbnQgdGhhdCBxdW90YXMgYXJlIHZlcnkNCj4gaW1wbGVtZW50 YXRpb24tZGVwZW5kZW50LiBBZ3JlZWQgdGhhdCBsb2cgc2hvdWxkIG9ubHkgaWRlbnRpZnkgdGhl IHF1b3RhDQo+IGFuZCBkZXRhaWxzIG9mIHRoZSB0cmlnZ2VyaW5nIHBhY2tldC4gSW50ZXJwcmV0 YXRpb24gZGVwZW5kcyBvbiB0aGUNCj4gaW1wbGVtZW50YXRpb24uDQo+IA0KPiBBY3Rpb246IHVw ZGF0ZSB0aGUgcXVvdGEgdmlvbGF0aW9uIGV2ZW50IHBlciBhZ3JlZW1lbnQuIElkZW50aWZ5IHRo ZQ0KPiBxdW90YSBieSBpdHMgZW50cnkgaW4gdGhlIE1JQj8NCj4gDQo+IElzc3VlIDY6IFJlcG9y dGluZyBwb3J0IGFsbG9jYXRpb24vZGVhbGxvY2F0aW9uDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBQcmVmZXJlbmNlIGZvciBzaW5nbGUg ZW5jb2RpbmcuIElQRklYIGFwcHJvYWNoIG11Y2ggbW9yZSBjb21wYWN0IGZvcg0KPiBsYXJnZSBy YW5nZXMsIHNob3VsZCB1c2UgaXQuDQo+IA0KPiBBY3Rpb246IHJldmlzZSBTWVNMT0cgdG8gdXNl IElQRklYIGVuY29kaW5nLiBQcm92aWRlIGNsZWFyIGV4cGxhbmF0aW9uDQo+IG9mIHRoZSBlbmNv ZGluZyBmb3IgdGhlIHR3byBjYXNlczogc2luZ2xlIGNvbnRpZ3VvdXMgcmFuZ2UsIHNlcXVlbmNl IG9mDQo+IGVxdWFsbHktc3BhY2VkIGVxdWFsLWxlbmd0aCBjb250aWd1b3VzIHJhbmdlcy4NCj4g DQo+IElzc3VlOiBzaG91bGQgcG9ydCBhbGxvY2F0aW9uIGV2ZW50cyByZXBvcnQgY3VtdWxhdGl2 ZSBhbGxvY2F0aW9ucyAoYXMNCj4gaW4gc3lzbG9nLW5hdC1sb2dnaW5nLTAyKSBvciBpbmNyZW1l bnRhbCBhbGxvY2F0aW9ucyAoYXMgaW4gSVBGSVgpPyBJZg0KPiBjdW11bGF0aXZlLCBzaG91bGQg cHJvYmFibHkgYWxsb3cgZm9yIHJlcG9ydGluZyBvZiBtdWx0aXBsZSBhbGxvY2F0ZWQNCj4gcG9y dCBzZXRzLg0KPiANCj4gSXNzdWUgNzogSW52YWxpZCBwb3J0IGV2ZW50DQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gUmVwbGFjZSB3aXRoIHBlci1zdWJzY3JpYmVyIGNvdW50 ZXJzIGluIHRoZSBNSUIuDQo+IA0KPiBBY3Rpb246IGRlbGV0ZSBldmVudCBmcm9tIFNZU0xPRy4g QWRkIHRvIE1JQi4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gQmVoYXZlIG1haWxpbmcgbGlzdA0KPiBCZWhhdmVAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCg== From internet-drafts@ietf.org Mon Sep 9 06:53:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9D021F9EBE; Mon, 9 Sep 2013 06:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjhW0KZ4CJ1w; Mon, 9 Sep 2013 06:53:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C17221F9D21; Mon, 9 Sep 2013 06:50:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130909135056.22162.10550.idtracker@ietfa.amsl.com> Date: Mon, 09 Sep 2013 06:50:56 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-sctpnat-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 13:53:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Addr= ess Translation Author(s) : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-behave-sctpnat-09.txt Pages : 25 Date : 2013-09-09 Abstract: Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-sctpnat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-sctpnat-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-sctpnat-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tom.taylor.stds@gmail.com Thu Sep 12 09:55:10 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039AD21E811F for ; Thu, 12 Sep 2013 09:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDhwdfbBQqeJ for ; Thu, 12 Sep 2013 09:55:09 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C1A5221E80E9 for ; Thu, 12 Sep 2013 09:55:08 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id gq1so60880obb.31 for ; Thu, 12 Sep 2013 09:55:08 -0700 (PDT) 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=D5qvWPl4/6nrzPFJx8W27UDBRVKRTA1DlbvYdgIgeNw=; b=TuFCFMAVS/Z+eYXvBNru+26f5Dwo0+j/KqiGLbXbgmSxTfJBB/imdY9IjtDLYF8pgv 00mNMafTcYGBBtss3bv9A+Wq0wh0hBvslWdtANGOZcmJgfaIRZCrVCHSzdMX45CO9Qg4 icrrS2B0Zg98zY5vOOGxePSy8jnNn7ur/5RBFrpAZfJGRIj51Q7yy90hu+v2rC4vCsKL 7c3ZqK01sw6GI0bsu1dMl9QUxmuFef811bJz73C5X2ol3ydmb3hSyyh5VyUEsFWuFvG4 /XRc1Fch385+bNnsy5iJ7DAPeq8osJqExQCJlcaMLnFFJA+dbaJxzv15s8zw20L1gj9A /ouA== X-Received: by 10.182.24.105 with SMTP id t9mr1987756obf.86.1379004908278; Thu, 12 Sep 2013 09:55:08 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-171-98.tor.primus.ca. [173.206.171.98]) by mx.google.com with ESMTPSA id rr6sm7070126oeb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 09:55:07 -0700 (PDT) Message-ID: <5231F1E8.5040904@gmail.com> Date: Thu, 12 Sep 2013 12:55:04 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" , Senthil Sivakumar , 'Simon Perreault' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Logging action items: realm and subscriber site ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:55:10 -0000 Reading over the MIB document, I see that I got the wrong idea about realm. Basically to identify a specific subscriber site we need both the realm and the subscriber site ID as described in draft-ietf-behave-syslog-nat-logging-02, section 3. Issue: the MIB provides only for an IP address. This fails to accommodate Gateway-Initiated DS-Lite [RFC6674]. Does the MIB need to be extended? And it will be interesting to decide how SYSLOG should do it. Rather than the generic string in the current version, perhaps we should go back to explicit distinction between IPv4, IPv6, and a CID/SWID combination. Tom Taylor From tom.taylor.stds@gmail.com Thu Sep 12 13:50:55 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B06311E813B for ; Thu, 12 Sep 2013 13:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lL14sk5N6Q1 for ; Thu, 12 Sep 2013 13:50:53 -0700 (PDT) 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 560A411E80F4 for ; Thu, 12 Sep 2013 13:50:53 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so816101iej.10 for ; Thu, 12 Sep 2013 13:50:52 -0700 (PDT) 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=7YBl4gyiXhSWHtkavKcSXt0xOg/vkBmPuoiN1qJCz6g=; b=m1dajKyHMur0vuK22NQZ0ZhtdaxwSOHrL0hU6akCiQLbKKEBHjK2l4BlJ7O2QSadKs wWFhwWWwkH0P8Ujum8KY0TCmws7/kQHaXIMUeHu8C6GqQi/Nldp1I9dVjg/yXfXtuqTK JBYICm6ghAQffagOKHkr8P1vuQGH7n1nN7cIX1vyu3rbjPEqivcJVK/hf9eRda+V9g6Z 5hBIpdrHem/oi1ePHVbnFRN8f/5s65eblM3t+whZtcw/DCMUW8fVdpidPuOZeozwKqBd +3pcpFTN3Qi9uKuLqdQZCkD822hoMe9LQ1XNa/5cOBcBed1NwON2TuvzbFvLJFNywVKx cwbQ== X-Received: by 10.50.6.71 with SMTP id y7mr13782840igy.8.1379019052837; Thu, 12 Sep 2013 13:50:52 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-171-98.tor.primus.ca. [173.206.171.98]) by mx.google.com with ESMTPSA id p10sm6415637igx.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 13:50:52 -0700 (PDT) Message-ID: <52322929.2080702@gmail.com> Date: Thu, 12 Sep 2013 16:50:49 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" , Senthil Sivakumar , 'Simon Perreault' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:50:55 -0000 1. The descriptions for some of the notifications say that they are triggered when the value is <= or >= the threshold, where for others they only talk about when the threshold is exceeded. Should this be made consistent? 2. Should the descriptions for natResourceError, natProtocolResourceErrors and natSubscriberResourceErrors exclude quota drops as well as out-of-port errors? 3. There is a major discrepancy between the pool watermark notification descriptions (which talk about addresses) and the objects in natPoolEntry, which talk about ports. I imagine the latter descriptions need updating. 4. The contents of natMapIntAddrEntry include only one address type. What if the external address type is different from the internal one? 5. For logging purposes, it would be good to have a quota identifier. From the MIB point of view, would it make sense to have a quota table presenting an SnmpAdminString identifier and a counter for the quota violations? Tom Taylor From dthaler@microsoft.com Thu Sep 12 17:55:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A6711E815B for ; Thu, 12 Sep 2013 17:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zSVAVRsBdF9 for ; Thu, 12 Sep 2013 17:55:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 9764F11E80FD for ; Thu, 12 Sep 2013 17:55:38 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 13 Sep 2013 00:55:36 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.249]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.249]) with mapi id 15.00.0775.005; Fri, 13 Sep 2013 00:55:36 +0000 From: Dave Thaler To: Tom Taylor , "behave@ietf.org" , Senthil Sivakumar , 'Simon Perreault' Thread-Topic: [BEHAVE] Comments on the NAT MIB Thread-Index: AQHOr/nLFIxW8FqD6kKq9LOGdWo6rJnC16ZQ Date: Fri, 13 Sep 2013 00:55:36 +0000 Message-ID: <887f63ff85d94464a79fc2327db74a10@BY2PR03MB269.namprd03.prod.outlook.com> References: <52322929.2080702@gmail.com> In-Reply-To: <52322929.2080702@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::4] x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(199002)(189002)(51704005)(74316001)(63696002)(81542001)(76482001)(31966008)(69226001)(77982001)(74706001)(59766001)(74502001)(65816001)(79102001)(80022001)(74662001)(33646001)(74876001)(54316002)(56776001)(4396001)(74366001)(50986001)(47446002)(46102001)(51856001)(53806001)(76786001)(81816001)(56816003)(76576001)(77096001)(19580395003)(80976001)(81686001)(47736001)(47976001)(54356001)(81342001)(76796001)(83072001)(49866001)(83322001)(19580405001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 00:55:45 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: Thursday, September 12, 2013 1:51 PM > To: behave@ietf.org; Senthil Sivakumar; 'Simon Perreault' > Subject: [BEHAVE] Comments on the NAT MIB >=20 > 1. The descriptions for some of the notifications say that they are trigg= ered > when the value is <=3D or >=3D the threshold, where for others they only = talk > about when the threshold is exceeded. Should this be made consistent? >=20 > 2. Should the descriptions for natResourceError, natProtocolResourceError= s > and natSubscriberResourceErrors exclude quota drops as well as out-of-por= t > errors? >=20 > 3. There is a major discrepancy between the pool watermark notification > descriptions (which talk about addresses) and the objects in natPoolEntry= , > which talk about ports. I imagine the latter descriptions need updating. >=20 > 4. The contents of natMapIntAddrEntry include only one address type. > What if the external address type is different from the internal one? >=20 > 5. For logging purposes, it would be good to have a quota identifier. > From the MIB point of view, would it make sense to have a quota table > presenting an SnmpAdminString identifier and a counter for the quota > violations? As with the ipfix vs syslog discussion, if the MIB is going to include any notifications at all (I'm not sure it's a requirement to have any), then it either needs to be consistent with the ipfix and syslog docs, or get WG consensus on any difference. -Dave From hangzhou.chenxin@huawei.com Fri Sep 13 01:59:20 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3F711E8190 for ; Fri, 13 Sep 2013 01:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQtIVxc8i1+B for ; Fri, 13 Sep 2013 01:59:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 519D821F9FA3 for ; Fri, 13 Sep 2013 01:59:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ18733; Fri, 13 Sep 2013 08:59:09 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 09:58:00 +0100 Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 13 Sep 2013 09:58:14 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0146.000; Fri, 13 Sep 2013 16:58:10 +0800 From: "Chenxin (Xin)" To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-chenxin-behave-turn-websocket-01.txt Thread-Index: AQHOsBxwFiDKw3EhkkO2riGGyVcg6JnDXUjA Date: Fri, 13 Sep 2013 08:58:08 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> In-Reply-To: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 08:59:20 -0000 SGkgYWxsLA0KCVdlIGhhdmUgYmVlbiB3b3JraW5nIG9uIGEgbmV3IHZlcnNpb24gb2YgdGhlIFRV Uk4gb3ZlciBXZWJzb2NrZXQgZHJhZnQsIHdoaWNoIGlzIG5vdyBhdmFpbGFibGUgYXQ6DQoNCglo dHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29ja2V0 LTAxLnR4dA0KDQoJV2UgYmVsaWV2ZSB0aGF0IGl0IGlzIHZlcnkgd2VsbCBhbGlnbmVkIHdpdGgg dGhlIHNwaXJpdCBvZiBkcmFmdC1odXR0b24tcnRjd2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0 aW9ucyBhbmQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgdG8gYmUgZW5kb3JzZWQgYnkgV2ViUlRDLg0K DQoJQWxzbywgaW4gb3JkZXIgdG8gYWRkcmVzcyB0aGUgY29uY2VybnMgYWJvdXQgdGhlIGltcGFj dCBvbiBUVVJOIHNlcnZlcnMgd2Ugd2lsbCBiZSB3b3JraW5nIGluIHByb3ZpZGluZyBhIHdvcmtp bmcgcHJvdG90eXBlIG92ZXIgdGhlIGZvbGxvd2luZyB3ZWVrcyBieSBhZGRpbmcgYSBwcmVsaW1p bmFyeSBzdXBwb3J0IG9mIFRVUk4gb3ZlciB3ZWJzb2NrZXRzIGludG8gdGhlIHJmYzU3NjYtdHVy bi1zZXJ2ZXIuDQoNCglBbnkga2luZCBvZiBmZWVkYmFjayB3b3VsZCBiZSB2ZXJ5IHdlbGNvbWUu DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj5TZW50OiBGcmlkYXks IFNlcHRlbWJlciAxMywgMjAxMyA4OjU5IEFNDQo+VG86IFNlcmdpbyBHYXJjaWEgTXVyaWxsbzsg Q2hlbnhpbiAoWGluKTsgVmljdG9yIFBhc2N1YWw7IE9sZWcgTW9za2FsZW5rbzsNCj5Mb3Jlbnpv IE1pbmllcm87IENoZW54aW4gKFhpbikNCj5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQo+ZHJhZnQtY2hlbnhpbi1iZWhhdmUtdHVybi13ZWJzb2NrZXQtMDEudHh0DQo+DQo+ DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNoZW54aW4tYmVoYXZlLXR1cm4td2Vic29j a2V0LTAxLnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGluIENoZW4g YW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+RmlsZW5hbWU6CSBkcmFm dC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldA0KPlJldmlzaW9uOgkgMDENCj5UaXRsZToJ CSBXZWJTb2NrZXQgUHJvdG9jb2wgYXMgYSBUcmFuc3BvcnQgZm9yIFRyYXZlcnNhbCBVc2luZyBS ZWxheXMNCj5hcm91bmQgTkFUIChUVVJOKQ0KPkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA5LTEyDQo+ R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+TnVtYmVyIG9mIHBhZ2VzOiAxMA0KPlVS TDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaGVueGluLWJl aGF2ZS10dXJuLXdlYnNvY2tldC0wMS50eA0KPnQNCj5TdGF0dXM6DQo+aHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldA0KPkh0 bWxpemVkOg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW54aW4tYmVoYXZl LXR1cm4td2Vic29ja2V0LTAxDQo+RGlmZjoNCj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1jaGVueGluLWJlaGF2ZS10dXJuLXdlYnNvY2tldC0wMQ0KPg0KPkFic3RyYWN0 Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gdGhlIFRyYXZlcnNh bCBVc2luZyBSZWxheXMNCj4gICBhcm91bmQgTkFUIChUVVJOKSBwcm90b2NvbCwgaW4gb3JkZXIg dG8gYWxsb3cgaXQgdG8gcnVuIG92ZXIgYQ0KPiAgIFdlYlNvY2tldCBjaGFubmVsLiAgVGhpcyB3 aWxsIGFsbG93IGNsaWVudHMgaW4gcmVzdHJpY3RpdmUgbmV0d29ya3MNCj4gICB0byB0cmF2ZXJz ZSB0aGVtIGFuZCBlZmZlY3RpdmVseSBleGNoYW5nZSBhbmQgcmVsYXkgbWVkaWEgb3IgZGF0YQ0K PiAgIG92ZXIgV2ViU29ja2V0cy4NCj4NCj4NCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+ dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From simon.perreault@viagenie.ca Fri Sep 13 02:23:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D211E818A; Fri, 13 Sep 2013 02:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOF3BFQXT-Zx; Fri, 13 Sep 2013 02:23:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8211E8187; Fri, 13 Sep 2013 02:23:49 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B462041485; Fri, 13 Sep 2013 05:23:47 -0400 (EDT) Message-ID: <5232D9A2.8050800@viagenie.ca> Date: Fri, 13 Sep 2013 11:23:46 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: behave@ietf.org, "rtcweb@ietf.org" References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 09:23:52 -0000 Le 2013-09-13 10:58, Chenxin (Xin) a écrit : > We have been working on a new version of the TURN over Websocket draft, which is now available at: > > http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt There are two major things missing in this draft: - How are TURN UDP "channels" supported? (See RFC 5766 section 2.5.) - How are TURN TCP "data connections" supported? (See RFC 6062 section 3.) I think the answers to these questions will greatly affect the overall design of TURN-over-WebSocket. 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 Fri Sep 13 05:47:06 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A96021F9FD5 for ; Fri, 13 Sep 2013 05:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhaYlmxsMFDC for ; Fri, 13 Sep 2013 05:47:05 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C013B21F9FCF for ; Fri, 13 Sep 2013 05:47:05 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C597E41485; Fri, 13 Sep 2013 08:47:01 -0400 (EDT) Message-ID: <52330944.3080202@viagenie.ca> Date: Fri, 13 Sep 2013 14:47:00 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dave Thaler References: <52322929.2080702@gmail.com> <887f63ff85d94464a79fc2327db74a10@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <887f63ff85d94464a79fc2327db74a10@BY2PR03MB269.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 12:47:06 -0000 Le 2013-09-13 02:55, Dave Thaler a écrit : > As with the ipfix vs syslog discussion, if the MIB is going to include any > notifications at all (I'm not sure it's a requirement to have any), then it > either needs to be consistent with the ipfix and syslog docs, or get > WG consensus on any difference. Unless anyone steps up with a need for SNMP notifications, they will be removed in the next revision. 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 Fri Sep 13 06:09:19 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DB711E81ED for ; Fri, 13 Sep 2013 06:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWWJXSe1OY6k for ; Fri, 13 Sep 2013 06:09:18 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7968011E818E for ; Fri, 13 Sep 2013 06:09:18 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ht10so911011vcb.10 for ; Fri, 13 Sep 2013 06:09:16 -0700 (PDT) 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=jUunI5+p/WOZvMgjFUPmRnZS0Z0RDHrH9Di2YdJJuaM=; b=mlW9SEe5Mzsi2oh71XVspEvauF7euWyBoicC8fZ9bcWGjABN86qXyF0Js6PLu12vua rN4TbNGwcIkn+EazGPDzI0x+kseklWIPFUUATNrg/qEC1xWaobtHsfxsE+RoPq05R4Gm VF6ePQEOv+IV5OWoLRQqnm0CpoyKzrrfSc9DribdR1T5w5XTNaIbhB8TEYb8jpXYe5t5 0akwAX+wlgYzvsKPbIc6hxxvWVB95qy/phASSF9PYLS9uZWMnzLuuNOZAcAsi+6xvOZ8 YWSpSMvP2vNHxYgcfp+ntCS8UCaM2liWEwI2K4kuFvVJSzh8JJUp11y2gupmY6J7ma1g kqvA== X-Received: by 10.58.168.205 with SMTP id zy13mr10006908veb.19.1379077756774; Fri, 13 Sep 2013 06:09:16 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-171-98.tor.primus.ca. [173.206.171.98]) by mx.google.com with ESMTPSA id z4sm8191680vdj.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 06:09:15 -0700 (PDT) Message-ID: <52330E7A.9020902@gmail.com> Date: Fri, 13 Sep 2013 09:09:14 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" , Senthil Sivakumar Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Address bindings, BIB entries, sessions X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:09:19 -0000 I have discovered the source of something that has confused me regarding the difference between Binding Information Base (BIB) and session entries. The problem was that I took my definition of session from RFC2663, where it is defined as a mapping between source and target transport addresses. This is the same as the definition of binding (as in BIB entry) in RFC6146. What I had not taken into account was that RFC6146 also redefines session to be a relation between two hosts (i.e., something that includes the destination). So using the definition of session from RFC2663 is inconsistent with this. My conclusion is that: -- we should go with the RFC6146 definitions all the way, since that is really what the IPFIX document is already based on -- the session creation/deletion events should be reported only if destination logging is enabled. In that case, BIB entry creation/deletion events should not be reported, since the information in them would overlap with the information in the session events. -- the reverse holds if destination logging is not enabled. I have no problem understanding address binding events as a separate issue. Tom Taylor From tom.taylor.stds@gmail.com Fri Sep 13 06:27:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC08621E80AD for ; Fri, 13 Sep 2013 06:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKzf-TXXFO3Z for ; Fri, 13 Sep 2013 06:27:49 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1956921E8055 for ; Fri, 13 Sep 2013 06:27:49 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id kw10so954046vcb.1 for ; Fri, 13 Sep 2013 06:27:48 -0700 (PDT) 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=DT+cPuHSl0ye+Oj7hcFlXvGe+62qmAC4WrnqDI79rqw=; b=ebPch9J7nwGGiz0clKKipC8E/h0Pn5XJvBBhJbLYxCuvxQKfttzoZqeA02iYJSBv4I aXMrhgyx2EHtsp+59FHfuuIZ4s3y9sobP9TDNBWEPqLOPOVn8reMgHEAMUsbPy/YQ58n 1LX/QZNkuf8/mYh+ugT7LC2OEk9JOMH+9Jea5w4kwzSK8VL/tc12vKHpAujhKmewoufa wSMe6dCMtulZW9p17JJcCQ9IDSKO6+wiFPyZIbsD/Cik/6VlO6zfWkm2AXc/+sbrSCVi i+I3Em8tdu3AR1ENJcr1u8xaV0oJt9uuq0xkhuj3gtyAOEKBSoeiaxU0l18bQwDKj+49 TiIw== X-Received: by 10.52.98.66 with SMTP id eg2mr10112248vdb.24.1379078868494; Fri, 13 Sep 2013 06:27:48 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-171-98.tor.primus.ca. [173.206.171.98]) by mx.google.com with ESMTPSA id fh2sm8298666vdb.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 06:27:47 -0700 (PDT) Message-ID: <523312D1.7010903@gmail.com> Date: Fri, 13 Sep 2013 09:27:45 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <52322929.2080702@gmail.com> <887f63ff85d94464a79fc2327db74a10@BY2PR03MB269.namprd03.prod.outlook.com> <52330944.3080202@viagenie.ca> In-Reply-To: <52330944.3080202@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , Dave Thaler Subject: Re: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:27:49 -0000 On 13/09/2013 8:47 AM, Simon Perreault wrote: > Le 2013-09-13 02:55, Dave Thaler a écrit : >> As with the ipfix vs syslog discussion, if the MIB is going to include >> any >> notifications at all (I'm not sure it's a requirement to have any), >> then it >> either needs to be consistent with the ipfix and syslog docs, or get >> WG consensus on any difference. > > Unless anyone steps up with a need for SNMP notifications, they will be > removed in the next revision. > > Simon I was going to pass this by OPSAWG to see if operators wanted a choice. Guess I'd better hurry up. Tom Taylor From ssenthil@cisco.com Fri Sep 13 06:45:41 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931C711E8118 for ; Fri, 13 Sep 2013 06:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyK6hg8TVlmw for ; Fri, 13 Sep 2013 06:45:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE9F11E80EA for ; Fri, 13 Sep 2013 06:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1429; q=dns/txt; s=iport; t=1379079935; x=1380289535; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=eL5f6HbVQzsAKLoaznCmVtf3j259pgtmRnEfZtCjXpI=; b=NGfURb3rpowntqewHFcT6fVU4kd1zamZj7ccqQDrLXkoPgQk3QPUlElq jac8hnAo/y4yEAmhI/bw3HlJubGZPwt1L9BZ77tR5ThP8RDQWNch9KPmF W/WbJDqoJkSvjqp2kgodI2rH28oCSkhoSPx2ZI9jzcdw8iGch4R2aAR8U 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADsWM1KtJXG+/2dsb2JhbABbgwc4UsBqgRwWdIInAQQnUhIBCCJWJQIEAQ0FCId7uhyPQDEHgx6BAAOJAJApkEWDJIIq X-IronPort-AV: E=Sophos;i="4.90,898,1371081600"; d="scan'208";a="259323699" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 13 Sep 2013 13:45:29 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8DDjTap016785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 13:45:29 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 08:45:28 -0500 From: "Senthil Sivakumar (ssenthil)" To: Simon Perreault , Dave Thaler Thread-Topic: [BEHAVE] Comments on the NAT MIB Thread-Index: AQHOr/nLW88oarsrUUeGn6TVZ1pwFZnDK8cAgADGxAD//81GgA== Date: Fri, 13 Sep 2013 13:45:28 +0000 Message-ID: In-Reply-To: <52330944.3080202@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5227B72738D8F8458CE5781A269FDFD4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:45:41 -0000 I believe the notifications have value and use in real deployments. A lot of times our customers ask for Setting thresholds and getting notified when the threshold is hit. The usual requests are: - I want to know when would I need to add more addresses in the nat pool. - I want to know when a single user uses excessive resources (excessive is subject to change and configurable). Resources here can be addresses, ports, memory, bandwidth etc I am fine if the answer is MIB is not the right place to add this, but would like to understand what would be the right place to do this. I assume to leave the notifications in if the logging drafts are in line with the MIB? Thanks Senthil On 9/13/13 8:47 AM, "Simon Perreault" wrote: >Le 2013-09-13 02:55, Dave Thaler a =E9crit : >> As with the ipfix vs syslog discussion, if the MIB is going to include >>any >> notifications at all (I'm not sure it's a requirement to have any), >>then it >> either needs to be consistent with the ipfix and syslog docs, or get >> WG consensus on any difference. > >Unless anyone steps up with a need for SNMP notifications, they will be >removed in the next revision. > >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 Fri Sep 13 06:53:43 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E891111E8212 for ; Fri, 13 Sep 2013 06:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXhwoFrSIUu3 for ; Fri, 13 Sep 2013 06:53:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1DF21F9981 for ; Fri, 13 Sep 2013 06:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1828; q=dns/txt; s=iport; t=1379080418; x=1380290018; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=WnDvU/0JfCGQ/HC1lTstiqBrGiRVt1P5hbqiHFLyMe8=; b=PJGQ49STT2/oGPfAodzuzuWGGPneUTdj70IEmmI2JvH9r68/P30irYtu Q/lWJuwPRCr1F27bhWR7IEiulDnlEbiHZVE/2iWnIeJIAEOZcl7vddH2Z X1RJeQXfgLa85z3d8SpurWJ7HqHmAYjIcks+2fR0QiTxfRm87bSPXPb+R Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI8YM1KtJXG9/2dsb2JhbABbgweBCsBqgRwWdIInAQRyGQEIIgs6ESUCBAESCIdpAw+wUw2JNI0DgSOBGjgKgxSBAAOJAI0RjiqFM4MkgWhC X-IronPort-AV: E=Sophos;i="4.90,898,1371081600"; d="scan'208";a="259374315" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 13 Sep 2013 13:53:28 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8DDrRA5028790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 13:53:27 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 13 Sep 2013 08:53:27 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "behave@ietf.org" Thread-Topic: Address bindings, BIB entries, sessions Thread-Index: AQHOsIJ6R4yBHI0TKUK2CwF2ebj9oJnDwPsA Date: Fri, 13 Sep 2013 13:53:27 +0000 Message-ID: In-Reply-To: <52330E7A.9020902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Address bindings, BIB entries, sessions X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:53:44 -0000 On 9/13/13 9:09 AM, "Tom Taylor" wrote: >I have discovered the source of something that has confused me regarding >the difference between Binding Information Base (BIB) and session >entries. The problem was that I took my definition of session from >RFC2663, where it is defined as a mapping between source and target >transport addresses. This is the same as the definition of binding (as >in BIB entry) in RFC6146. > >What I had not taken into account was that RFC6146 also redefines >session to be a relation between two hosts (i.e., something that >includes the destination). So using the definition of session from >RFC2663 is inconsistent with this. > >My conclusion is that: >-- we should go with the RFC6146 definitions all the way, since that is >really what the IPFIX document is already based on I agree, not just because the IPFIX document is based on that, but because NAT implementations have both session and BIB databases and as you noted, they are different. >-- the session creation/deletion events should be reported only if >destination logging is enabled. In that case, BIB entry >creation/deletion events should not be reported, since the information >in them would overlap with the information in the session events. Agreed. >-- the reverse holds if destination logging is not enabled. > >I have no problem understanding address binding events as a separate >issue. I have also seen protocol independent BIB implementation (aka address binding) that is not Captured in 6146, but a binding of an address to a subscriber (no address sharing). And in those cases, the session/BIB doesn=B9t need to be created. In those scenarios, the=20 Address binding create/delete event should be logged. Thanks Senthil > >Tom Taylor From simon.perreault@viagenie.ca Fri Sep 13 23:02:48 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F7C11E80E8; Fri, 13 Sep 2013 23:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcOIhkooFT1I; Fri, 13 Sep 2013 23:02:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E140611E80D1; Fri, 13 Sep 2013 23:02:47 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D43924149F; Sat, 14 Sep 2013 02:02:44 -0400 (EDT) Message-ID: <5233FC04.7040509@viagenie.ca> Date: Sat, 14 Sep 2013 08:02:44 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sergio Garcia Murillo References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> In-Reply-To: <52337505.9000109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , behave@ietf.org Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 06:02:48 -0000 Le 2013-09-13 22:26, Sergio Garcia Murillo a écrit : > So, at the end, the ChannelData message is just another TURN message, so > it will be encapsulated inside a websocket frame. If you feel it is not > clear, we can add more details about it in next draft. You're right, I was mistaken about this. Thanks for the detailed explanation. No need for more details. > Regarding RFC 6062, we had some internal discussion regarding if we > should add websocket support at all to it or not. Mainly, because AFAIK, > webrtc will use RFC 5766 and not 6062. Anyone please correct me if I am > wrong. I think a better justification would be "because WebRTC data channel will use SCTP over DTLS". > I agree with you that this has not been well covered in the draft. In > order to make the minimun changes possible, and align it with the > general view of changing just the turn client to turn server > encapsulation protocol, I would propose to extend websockets usage only > for the turn control connection in RFC 6062 but keep turn data > connections on TCP. So with an HTTP proxy the control would be over websockets and the data would be through the CONNECT method? Yuck... > That, or drop RFC 6062 extension altogether and just > focus on 5766. What do you feel it would be best? I say focus on 5766. I have a new question: what does the TURN server put in the XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's address? Can TURN over WebSockets be used to gather server-reflexive candidates? 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 hangzhou.chenxin@huawei.com Sat Sep 14 01:53:44 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9269321F9DDE; Sat, 14 Sep 2013 01:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVPLBMFQ8-Tj; Sat, 14 Sep 2013 01:53:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF5DC21F9DDB; Sat, 14 Sep 2013 01:53:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU05003; Sat, 14 Sep 2013 08:53:33 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 09:53:13 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 09:53:29 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0146.000; Sat, 14 Sep 2013 16:53:22 +0800 From: "Chenxin (Xin)" To: Simon Perreault , Sergio Garcia Murillo Thread-Topic: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt Thread-Index: AQHOsL+XhyORzIvU1ESsGxOV4IuYl5nEOHMAgACbzYA= Date: Sat, 14 Sep 2013 08:53:21 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> In-Reply-To: <5233FC04.7040509@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 08:53:44 -0000 Hi Simon, >> I agree with you that this has not been well covered in the draft. In >> order to make the minimun changes possible, and align it with the >> general view of changing just the turn client to turn server >> encapsulation protocol, I would propose to extend websockets usage only >> for the turn control connection in RFC 6062 but keep turn data >> connections on TCP. > >So with an HTTP proxy the control would be over websockets and the data >would be through the CONNECT method? Yuck... Or using websocket multiplexing http://tools.ietf.org/html/draft-ietf-hybi-= websocket-multiplexing-11 .=20 > >> That, or drop RFC 6062 extension altogether and just >> focus on 5766. What do you feel it would be best? > >I say focus on 5766. > >I have a new question: what does the TURN server put in the >XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's >address?=20 The proxy's address. I do not think this attribute will help ICE process.=20 Can TURN over WebSockets be used to gather server-reflexive >candidates? Yes, It could do as UDP and TCP. But when there is a http proxy. I think th= e server reflexive candidates will be the address of proxy, which means not= hing for the peer. But if there is only NAT, the server reflexive candidate= s is possible to work in the ICE. Best Regard, Xin > >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 >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From simon.perreault@viagenie.ca Sat Sep 14 02:14:11 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F0521E812C; Sat, 14 Sep 2013 02:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE+k8t+uSHIT; Sat, 14 Sep 2013 02:14:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 90BE311E8147; Sat, 14 Sep 2013 02:14:10 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2C2C1403CF; Sat, 14 Sep 2013 05:13:56 -0400 (EDT) Message-ID: <523428D2.8050505@viagenie.ca> Date: Sat, 14 Sep 2013 11:13:54 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Chenxin (Xin)" References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> In-Reply-To: <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , Sergio Garcia Murillo , "behave@ietf.org" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 09:14:11 -0000 Le 2013-09-14 10:53, Chenxin (Xin) a écrit : >> I have a new question: what does the TURN server put in the >> XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's >> address? > > The proxy's address. I do not think this attribute will help ICE process. > > Can TURN over WebSockets be used to gather server-reflexive >> candidates? > > Yes, It could do as UDP and TCP. But when there is a http proxy. I think the server reflexive candidates will be the address of proxy, which means nothing for the peer. Isn't this a big problem? I mean, if the client cannot trust the value of the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and everything else? 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 hangzhou.chenxin@huawei.com Sat Sep 14 03:25:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E55921E81B6; Sat, 14 Sep 2013 03:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMjOLv3iGZts; Sat, 14 Sep 2013 03:25:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 240A221E81AD; Sat, 14 Sep 2013 03:25:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVK01983; Sat, 14 Sep 2013 10:25:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 11:23:32 +0100 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 14 Sep 2013 11:23:49 +0100 Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.96]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0146.000; Sat, 14 Sep 2013 18:23:44 +0800 From: "Chenxin (Xin)" To: Simon Perreault Thread-Topic: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt Thread-Index: AQHOsSrDIYEbSyC+fUOCPacmrLHxDJnE/cCw Date: Sat, 14 Sep 2013 10:23:43 +0000 Message-ID: <9E34D50A21D1D1489134B4D770CE03976807F3C1@SZXEMA504-MBX.china.huawei.com> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> In-Reply-To: <523428D2.8050505@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.41.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "rtcweb@ietf.org" , Sergio Garcia Murillo , "behave@ietf.org" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 10:25:49 -0000 Hi Simon, >>> I have a new question: what does the TURN server put in the >>> XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's >>> address? >> >> The proxy's address. I do not think this attribute will help ICE process= . >> >> Can TURN over WebSockets be used to gather server-reflexive >>> candidates? >> >> Yes, It could do as UDP and TCP. But when there is a http proxy. I think= the >server reflexive candidates will be the address of proxy, which means noth= ing for >the peer. > >Isn't this a big problem? I mean, if the client cannot trust the value >of the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE >and everything else? > Thanks for your question. You are right about it. We should consider more a= bout gathering the server reflexive candidates in turn over websocket. I have checked the RFC 5766 again: Reflexive Transport Address: A transport address learned by a client that identifies that client as seen by another host on an IP network, typically a STUN server. When there is an intervening NAT between the client and the other host, the reflexive transport address represents the mapped address allocated to the client on the public side of the NAT. Reflexive transport addresses are learned from the mapped address attribute (MAPPED-ADDRESS or XOR- MAPPED-ADDRESS) in STUN responses. Which restricts that the "Reflexive Transport Address" should be obtained f= rom NAT. It will be semantic problem if this address is from proxy. In ICE, I have not found out the harmful scenario yet. It will be possible = to make ICE Connectivity Checks failed, but it will be possible to be usefu= l.=20 I am still thinking about how to handle it. Should we just leave it to for = the usage of gathering candidate from NAT? OR totally forbid it in the turn= over websocket? What is your suggestion? >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 sergio.garcia.murillo@gmail.com Fri Sep 13 13:26:48 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ABC21E80AA; Fri, 13 Sep 2013 13:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFkq1zmm4Vyr; Fri, 13 Sep 2013 13:26:48 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB511E80D3; Fri, 13 Sep 2013 13:26:47 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cb5so1493469wib.5 for ; Fri, 13 Sep 2013 13:26:46 -0700 (PDT) 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=zEAFsAknO6Ny6IEJMIFaHrzOSyYDIfQx3frVMqUYlaU=; b=nin+xzPGu/jYGn2zHrQkpvrIdbvNVjSYBFOXbWPJCIR173mSWurqGeKF1L5A6B8TzC 3TKZvreDZCFbFDowrfsvbe3lWnuzHtcXrtA/dAzr8L8ofiXNv6m6j5rfETNEbzS7TC3J epqhBICkTSDC13NpUF/VaFiEAkVeJb01hw+NJdlk2IgkvZqBuoWAPAES9P7ookg21JqI oqwDiCLFOmbSdVkSYi5iGx0d5BdBRe0Gsh5gnuhz6Azl3Hy4pIu7vki88rhFzQuQe5OV XBEf2zidPII/86HQqNrR3Yy4xu03yNFqQFvAjS5cMnp5KHE5n6Ds7svo+5IopyMg8EQn VVJQ== X-Received: by 10.180.206.180 with SMTP id lp20mr3986899wic.48.1379104006702; Fri, 13 Sep 2013 13:26:46 -0700 (PDT) Received: from [192.168.1.55] (76.Red-88-6-196.staticIP.rima-tde.net. [88.6.196.76]) by mx.google.com with ESMTPSA id gp9sm5887800wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 13:26:46 -0700 (PDT) Message-ID: <52337505.9000109@gmail.com> Date: Fri, 13 Sep 2013 22:26:45 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> In-Reply-To: <5232D9A2.8050800@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 14 Sep 2013 22:08:22 -0700 Cc: "rtcweb@ietf.org" , behave@ietf.org Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:26:48 -0000 El 13/09/2013 11:23, Simon Perreault escribió: > Le 2013-09-13 10:58, Chenxin (Xin) a écrit : >> We have been working on a new version of the TURN over Websocket >> draft, which is now available at: >> >> http://www.ietf.org/id/draft-chenxin-behave-turn-websocket-01.txt > > There are two major things missing in this draft: > > - How are TURN UDP "channels" supported? (See RFC 5766 section 2.5.) > > - How are TURN TCP "data connections" supported? (See RFC 6062 section > 3.) > > I think the answers to these questions will greatly affect the overall > design of TURN-over-WebSocket. > > Hi Simon, As per RFC 5766: For some applications (e.g., Voice over IP), the 36 bytes of overhead that a Send indication or Data indication adds to the application data can substantially increase the bandwidth required between the client and the server. To remedy this, TURN offers a second way for the client and server to associate data with a specific peer. This second way uses an alternate packet format known as the ChannelData message. The ChannelData message does not use the STUN header used by other TURN messages, but instead has a 4-byte header that includes a number known as a channel number. So, at the end, the ChannelData message is just another TURN message, so it will be encapsulated inside a websocket frame. If you feel it is not clear, we can add more details about it in next draft. Regarding RFC 6062, we had some internal discussion regarding if we should add websocket support at all to it or not. Mainly, because AFAIK, webrtc will use RFC 5766 and not 6062. Anyone please correct me if I am wrong. I agree with you that this has not been well covered in the draft. In order to make the minimun changes possible, and align it with the general view of changing just the turn client to turn server encapsulation protocol, I would propose to extend websockets usage only for the turn control connection in RFC 6062 but keep turn data connections on TCP. That, or drop RFC 6062 extension altogether and just focus on 5766. What do you feel it would be best? Best regards Sergio From sergio.garcia.murillo@gmail.com Sat Sep 14 13:30:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1543921E80C8; Sat, 14 Sep 2013 13:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNMNejYtxm-a; Sat, 14 Sep 2013 13:30:35 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 41F1421E80B1; Sat, 14 Sep 2013 13:30:35 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj3so2040532wib.1 for ; Sat, 14 Sep 2013 13:30:34 -0700 (PDT) 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=BDm1u7UZbTOoNyP6lLXlswSqTnYyzx0KPUInCFFCEtk=; b=K/Vr+CjAdm9WUUHMrq15eZDwkteMsGlm/fGY7hf/B6p6mpd3SunR+hXjcrn6s2CDm/ iV1vdl4noqBZEf2Hjix4Qx4dYsLwt2R8PYqIlyjgqFp/jz85Q6B1LjZSx5DfaBJYHCYx zlqSPgRuaY6At6+HuZJCM4ca6fy7UFVjol4TTd4t4OpxEaYr+zigqG4Mj+GGx1LjOoQO LFpNroDoNyM+VWi9PhsSuXynJ8UGTd/HX0GQuzUqIqzM26gZ/3aIxZwCrY/Jubfv4Sjr +ig/KkEagNXuUJ+2ajdDk2NvHynElwXGe65GvEi2WBdApyfZFqht2FU5wG2qV0w5qb8s mUlQ== X-Received: by 10.180.77.68 with SMTP id q4mr7506580wiw.4.1379190634453; Sat, 14 Sep 2013 13:30:34 -0700 (PDT) Received: from [192.168.1.55] (76.Red-88-6-196.staticIP.rima-tde.net. [88.6.196.76]) by mx.google.com with ESMTPSA id gp9sm12285932wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 13:30:33 -0700 (PDT) Message-ID: <5234C773.3090409@gmail.com> Date: Sat, 14 Sep 2013 22:30:43 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> In-Reply-To: <5233FC04.7040509@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 14 Sep 2013 22:08:22 -0700 Cc: "rtcweb@ietf.org" , behave@ietf.org Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 20:30:36 -0000 El 14/09/2013 8:02, Simon Perreault escribió: > > I have a new question: what does the TURN server put in the > XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's > address? Can TURN over WebSockets be used to gather server-reflexive > candidates? > > From my point of view, the value of the XOR-MAPPED-ADDRESS should be the same as when using TURN over TLS on the same scenario (if it happens to work), that would be either the HTTP proxy address or any NAT happening after it. Best regards Sergio From simon.perreault@viagenie.ca Sun Sep 15 00:24:31 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9AA11E80ED; Sun, 15 Sep 2013 00:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R-57pGAGzdH; Sun, 15 Sep 2013 00:24:31 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 099CA11E80E8; Sun, 15 Sep 2013 00:24:31 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 10A2240413; Sun, 15 Sep 2013 03:24:29 -0400 (EDT) Message-ID: <523560AD.8070109@viagenie.ca> Date: Sun, 15 Sep 2013 09:24:29 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Martin Thomson References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , "rtcweb@ietf.org" , "Chenxin \(Xin\)" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 07:24:31 -0000 Le 2013-09-15 08:42, Martin Thomson a écrit : > On 14 September 2013 02:13, Simon Perreault wrote: >> Isn't this a big problem? I mean, if the client cannot trust the value of >> the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and >> everything else? > > Hardly. You just lose that option. It might suck if you needed it, > but given that you are using a relay, it's probably not that bad. > > The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with > TURN over TCP. Same upside. True. Then shouldn't server-reflexive candidates always be gathered using plain STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute would be ignored (or even not sent) for TURN-over-anything-but-UDP. 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 martin.thomson@gmail.com Sat Sep 14 23:43:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9B921E809D; Sat, 14 Sep 2013 23:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKpDo3mGib-r; Sat, 14 Sep 2013 23:42:59 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5A21E809C; Sat, 14 Sep 2013 23:42:59 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id f12so2463077wgh.26 for ; Sat, 14 Sep 2013 23:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7/9TB6OL/vXpa1XH+bR24FP2pnuHjjJICdgkq6PTpW4=; b=qHvZmxuu+V8adTSMYCm8pQ+eDNoYODTUUrdjUWw3xahYE1PbX7FHAeYJrvL6UwWGYq qDuyXALWOfw+Nf+Y0Q8KgkpCraklM6cuUCxeQUgTFpkSskaf6JY+4ldrzuD7KuEVQ8Vj 0wofE80Zu3LerRr3PdSMi2u4L5GqXSzSHGtMEhAdxk9NFueNGmyQMKGNYGWm3sfCdDUx gVloLQZRmeE0U4PydWSZ8EYiyJ7gsd3A+/BSzohQ0hufrnmCHE1Sjo7CNoVR1UZ5N00e c8/zuGi0E/0I77xz3gpBywJc+taGssBFC4SG2Yzz1wQtVDUSjM1ShwjXDuRJ6xLcX9Y8 ljCA== MIME-Version: 1.0 X-Received: by 10.180.212.51 with SMTP id nh19mr8710174wic.14.1379227378249; Sat, 14 Sep 2013 23:42:58 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Sat, 14 Sep 2013 23:42:58 -0700 (PDT) In-Reply-To: <523428D2.8050505@viagenie.ca> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> Date: Sat, 14 Sep 2013 23:42:58 -0700 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 15 Sep 2013 09:12:47 -0700 Cc: "behave@ietf.org" , "rtcweb@ietf.org" , "Chenxin \(Xin\)" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 06:43:00 -0000 On 14 September 2013 02:13, Simon Perreault wrote: > Isn't this a big problem? I mean, if the client cannot trust the value of > the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and > everything else? Hardly. You just lose that option. It might suck if you needed it, but given that you are using a relay, it's probably not that bad. The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with TURN over TCP. Same upside. From simon.perreault@viagenie.ca Tue Sep 17 02:02:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE311E80F3 for ; Tue, 17 Sep 2013 02:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cSEB+ya8Lh2 for ; Tue, 17 Sep 2013 02:02:12 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9093C11E83BD for ; Tue, 17 Sep 2013 02:02:12 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:e01a:be8d:b906:c8cd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A765B403DC; Tue, 17 Sep 2013 05:02:11 -0400 (EDT) Message-ID: <52381A93.7080705@viagenie.ca> Date: Tue, 17 Sep 2013 11:02:11 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tom Taylor References: <5231F1E8.5040904@gmail.com> In-Reply-To: <5231F1E8.5040904@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Logging action items: realm and subscriber site ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 09:02:13 -0000 Le 2013-09-12 18:55, Tom Taylor a écrit : > Reading over the MIB document, I see that I got the wrong idea about > realm. Basically to identify a specific subscriber site we need both the > realm and the subscriber site ID as described in > draft-ietf-behave-syslog-nat-logging-02, section 3. > > Issue: the MIB provides only for an IP address. This fails to > accommodate Gateway-Initiated DS-Lite [RFC6674]. Does the MIB need to be > extended? I think so. Unless anyone disagrees, the next revision will add an optional realm ID to the subscriber struct. > And it will be interesting to decide how SYSLOG should do it. > Rather than the generic string in the current version, perhaps we should > go back to explicit distinction between IPv4, IPv6, and a CID/SWID > combination. FWIW, the latter is how we do it in the MIB. Simon From tom.taylor.stds@gmail.com Tue Sep 17 04:52:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08311E8137 for ; Tue, 17 Sep 2013 04:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDnwd567h+LI for ; Tue, 17 Sep 2013 04:52:57 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 792BD11E8100 for ; Tue, 17 Sep 2013 04:52:57 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j15so1845321qaq.3 for ; Tue, 17 Sep 2013 04:52:55 -0700 (PDT) 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=Stw0mfYRKnDnywceW0mn6PucXzA+N5q6cZrx01A4k90=; b=XVtuOpO96HmcSyOYRiZCIQmq3V7Le6zD0PoUMYNoWAh5318m1r+HoqoesViVAEWhf6 FYRKDAet+0M8fw58ttKaGqU8Y6gR4RQyG+3pSJtDmO41Yk0VQPLLnS6q8G/erp2QSb3s +3zaFefpLtYOjYHS1W9/8Mu2jxAhl/yQJKhr3DJeBaPQpRfJPcdkPlbodpttbkWHv62v VcqcZklQCmtmUbwYfaK98JbLQdsEEKp2ZSc1SEwUzdOQfKoqO3Nd7rnbVJjgNCha5JtM 75V5jgPZigl0SU5XCKE28ju61pBve95eSUGAUnOmDTdbIE6HuBSqHvs1AVDfUUfO1owZ 7dAQ== X-Received: by 10.224.161.6 with SMTP id p6mr5745508qax.80.1379418775545; Tue, 17 Sep 2013 04:52:55 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id h2sm55192360qev.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 04:52:54 -0700 (PDT) Message-ID: <52384296.5030807@gmail.com> Date: Tue, 17 Sep 2013 07:52:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <5231F1E8.5040904@gmail.com> <52381A93.7080705@viagenie.ca> In-Reply-To: <52381A93.7080705@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Logging action items: realm and subscriber site ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 11:52:58 -0000 On 17/09/2013 5:02 AM, Simon Perreault wrote: > Le 2013-09-12 18:55, Tom Taylor a écrit : >> Reading over the MIB document, I see that I got the wrong idea about >> realm. Basically to identify a specific subscriber site we need both the >> realm and the subscriber site ID as described in >> draft-ietf-behave-syslog-nat-logging-02, section 3. >> >> Issue: the MIB provides only for an IP address. This fails to >> accommodate Gateway-Initiated DS-Lite [RFC6674]. Does the MIB need to be >> extended? > > I think so. Unless anyone disagrees, the next revision will add an > optional realm ID to the subscriber struct. [PTT] That seems like it would be useful in general. In the particular case of GW-initiated DS-Lite, it could substitute for the Context Identifier, so that the subscriber site ID would consist only of the 16-bit Softwire Identifier. Maybe the realm table could be extended to add an optional Context Identifier object. > >> And it will be interesting to decide how SYSLOG should do it. >> Rather than the generic string in the current version, perhaps we should >> go back to explicit distinction between IPv4, IPv6, and a CID/SWID >> combination. > > FWIW, the latter is how we do it in the MIB. > > Simon > From simon.perreault@viagenie.ca Tue Sep 17 04:54:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4211E8137 for ; Tue, 17 Sep 2013 04:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg7nk3PY8Jft for ; Tue, 17 Sep 2013 04:54:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8F011E80FE for ; Tue, 17 Sep 2013 04:54:13 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:e01a:be8d:b906:c8cd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 92F77403DC; Tue, 17 Sep 2013 07:54:11 -0400 (EDT) Message-ID: <523842E1.3000600@viagenie.ca> Date: Tue, 17 Sep 2013 13:54:09 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tom Taylor References: <5231F1E8.5040904@gmail.com> <52381A93.7080705@viagenie.ca> <52384296.5030807@gmail.com> In-Reply-To: <52384296.5030807@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Logging action items: realm and subscriber site ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 11:54:14 -0000 Le 2013-09-17 13:52, Tom Taylor a écrit : > [PTT] That seems like it would be useful in general. In the particular > case of GW-initiated DS-Lite, it could substitute for the Context > Identifier, so that the subscriber site ID would consist only of the > 16-bit Softwire Identifier. Maybe the realm table could be extended to > add an optional Context Identifier object. Not sure what "realm table" you are referring to. As far as the MIB is concerned, a realm is an opaque string with implementation-defined meaning. Simon From tom.taylor.stds@gmail.com Tue Sep 17 07:38:12 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE1511E8259 for ; Tue, 17 Sep 2013 07:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDX0f7rJoYEu for ; Tue, 17 Sep 2013 07:38:11 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1F711E8256 for ; Tue, 17 Sep 2013 07:38:11 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id g17so4215755vbg.0 for ; Tue, 17 Sep 2013 07:38:10 -0700 (PDT) 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=7AfwaoN/th0Cbxxf3veJcJEXy7wa0yUXXRSC/bY4trQ=; b=bLhKegOYrbPO3YfBrEl+4DZ44etjgVoa1kqJPlg1TWypbddOEoVC5o60bv1wsEdW59 XTImKtHFU465qMMA198KlvS0sA6EwdO4QWhkSYQaEoJIhgLAMeyMJNBZyJAulG44Shed nGqprGTAJ61IJllngN4g0dDlwYqZebsZbHlCuWWX3Q8KjxBa1x1jMIvqkk8IUTFh8kon qPvlwJPb3WZ+4fAUR52UQEWosp04PJ5+9w0lCTxsBFoyTs+a1lKLljvNiDF+i/qLFxqf eOs+3m571oCfVHpjtrwp0ARdYiB2j4dRoUN+WRjy4U/UIsqpZH4cKJ2LzEzFAHhvJFnW q5Zg== X-Received: by 10.58.220.162 with SMTP id px2mr109845vec.53.1379428689965; Tue, 17 Sep 2013 07:38:09 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id tf9sm24100473veb.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 07:38:09 -0700 (PDT) Message-ID: <52386950.8000504@gmail.com> Date: Tue, 17 Sep 2013 10:38:08 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <5231F1E8.5040904@gmail.com> <52381A93.7080705@viagenie.ca> <52384296.5030807@gmail.com> <523842E1.3000600@viagenie.ca> In-Reply-To: <523842E1.3000600@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Logging action items: realm and subscriber site ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 14:38:12 -0000 Sorry -- the realm table isn't there, but was proposed at the meeting, to provide the relationship between realms and VRFs or VLANs where applicable, though I initially misunderstood it. Adding RFC6674 (GW-initiated DS-Lite) Context Identifiers is a natural extension. Tom On 17/09/2013 7:54 AM, Simon Perreault wrote: > Le 2013-09-17 13:52, Tom Taylor a écrit : >> [PTT] That seems like it would be useful in general. In the particular >> case of GW-initiated DS-Lite, it could substitute for the Context >> Identifier, so that the subscriber site ID would consist only of the >> 16-bit Softwire Identifier. Maybe the realm table could be extended to >> add an optional Context Identifier object. > > Not sure what "realm table" you are referring to. As far as the MIB is > concerned, a realm is an opaque string with implementation-defined meaning. > > Simon > From creslin@digium.com Mon Sep 16 12:39:44 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7CD11E830D for ; Mon, 16 Sep 2013 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6h6wbR9gJHV for ; Mon, 16 Sep 2013 12:39:39 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id 792FD11E8326 for ; Mon, 16 Sep 2013 12:39:35 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so3482665lab.7 for ; Mon, 16 Sep 2013 12:39:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RCBLuwYdHdsFtkewwTZmLx3aQqeqppEstb59nWLRVKE=; b=fxOeSVMtN4rDgycLCNfjgrRDafYFTEClfYxGlD0/UO1HzMRaTtwIqGd1nQk1IWLsNO 9huYC0d9Uzq9Emw/Rso5MiWCVb+lEWY+B5UVcIAqqjqZTecSEYckwkAlRDAfTi7M/UHv s4ij/hOM6MsrS+sUrXrkcCEpgDaCz3BrqK0hbmb0obuXGy4+UycGv7seeCJSObSj4Kwe sv81hM43KehlN089vWMvZPxSYolisndbLsZarauiEg0ONDeMMvoAH4+qnfdrKvIZpkX2 qjUWDwymDFZmjt0xGY/zvHPkgdqDMuTV+0plGaVm0D9bnUM+7O39M1LqU1sgZfWOTcd8 3Mvw== X-Gm-Message-State: ALoCoQlEtZVTFANqiN/3YNK469TSwIquFlGMtahGS3oL2BEQ/vkr4gcEbeIL+xy3v/CPuJI3ylY0 MIME-Version: 1.0 X-Received: by 10.112.198.39 with SMTP id iz7mr7534343lbc.24.1379360374221; Mon, 16 Sep 2013 12:39:34 -0700 (PDT) Received: by 10.112.132.102 with HTTP; Mon, 16 Sep 2013 12:39:34 -0700 (PDT) In-Reply-To: <523560AD.8070109@viagenie.ca> References: <20130913005837.14362.66591.idtracker@ietfa.amsl.com> <9E34D50A21D1D1489134B4D770CE03976807F0B0@SZXEMA504-MBX.china.huawei.com> <5232D9A2.8050800@viagenie.ca> <52337505.9000109@gmail.com> <5233FC04.7040509@viagenie.ca> <9E34D50A21D1D1489134B4D770CE03976807F388@SZXEMA504-MBX.china.huawei.com> <523428D2.8050505@viagenie.ca> <523560AD.8070109@viagenie.ca> Date: Mon, 16 Sep 2013 14:39:34 -0500 Message-ID: From: Matt Fredrickson To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c233ea1f7fa404e6855d84 X-Mailman-Approved-At: Tue, 17 Sep 2013 11:36:58 -0700 Cc: "behave@ietf.org" , Martin Thomson , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 19:39:44 -0000 --001a11c233ea1f7fa404e6855d84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Sep 15, 2013 at 2:24 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2013-09-15 08:42, Martin Thomson a =E9crit : > > On 14 September 2013 02:13, Simon Perreault >> wrote: >> >>> Isn't this a big problem? I mean, if the client cannot trust the value = of >>> the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and >>> everything else? >>> >> >> Hardly. You just lose that option. It might suck if you needed it, >> but given that you are using a relay, it's probably not that bad. >> >> The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with >> TURN over TCP. Same upside. >> > > True. > > Then shouldn't server-reflexive candidates always be gathered using plain > STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute would be > ignored (or even not sent) for TURN-over-anything-but-UDP. That's what I was beginning to think as well... Is there any utility to be gained by advertising XOR-MAPPED-ADDRESS on transport types that (at least it would so seem to me) preclude its usage? Matthew Fredrickson --001a11c233ea1f7fa404e6855d84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 15, 2013 at 2:24 AM, Simon Perreault <= simon.perr= eault@viagenie.ca> wrote:
Le 2013-09-15 08:42, Martin Thomson a =E9cri= t :

On 14 September 2013 02:13, Simon Perreault <simon.perreault@viagenie.ca> w= rote:
Isn't this a big problem? I mean, if the client cannot trust the value = of
the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE and<= br> everything else?

Hardly. =A0You just lose that option. =A0It might suck if you needed it, but given that you are using a relay, it's probably not that bad.

The value of XOR-MAPPED-ADDRESS is degraded by a lesser degree with
TURN over TCP. =A0Same upside.

True.

Then shouldn't server-reflexive candidates always be gathered using pla= in STUN or TURN-over-UDP? That is, the XOR-MAPPED-ADDRESS attribute would b= e ignored (or even not sent) for TURN-over-anything-but-UDP.

That's what I was beginning to think as well... =A0= Is there any utility to be gained by advertising XOR-MAPPED-ADDRESS on tran= sport types that (at least it would so seem to me) preclude its usage?

Matthew Fredrickson
--001a11c233ea1f7fa404e6855d84-- From tom.taylor.stds@gmail.com Wed Sep 18 03:55:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E652F11E8210 for ; Wed, 18 Sep 2013 03:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK+49Qa+Cpt4 for ; Wed, 18 Sep 2013 03:55:24 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03411E81C7 for ; Wed, 18 Sep 2013 03:55:23 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n4so4493329qcx.27 for ; Wed, 18 Sep 2013 03:55:23 -0700 (PDT) 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=L8F1QEDB5SU7j84J5pVcZfnVAbG49uL2fBwZ3zc2OHI=; b=W7swu8oHfhVp897YzNruzM2pYAEezJiJg+gIYZVJMarny95waC4K1mKcATSreGD1jc nirEQfHyj6yg4fwWn0hlf8SMw+B1iP9WpG7bqNJFvDo2LGwTWoDmYYnKFUqIL7pkhX/t wANBq4Mw6CUky8pkoMUIsMHEJuluxdX+Rka5IUbsBvn72NjtIe+EPH8XT/XrM2zz1vao 8vMDVVfRbNPG81gz7AqvyuzEmhSw0AK6NxU10yeVqS7g/rkWA3bQRxrIZkb1HRxATYj3 7xt6wYTTtnt6VK9SlHBC7vEKIRTHEz/ZK3UCdti+TvY9apLwvhUOHxnr/QqkYvyCY/8e Hnxw== X-Received: by 10.224.88.10 with SMTP id y10mr13333103qal.14.1379501722953; Wed, 18 Sep 2013 03:55:22 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id u4sm4454347qat.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 03:55:21 -0700 (PDT) Message-ID: <52398699.6080903@gmail.com> Date: Wed, 18 Sep 2013 06:55:21 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Notifications and logs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 10:55:26 -0000 On the issue of notifications and logs, I had two responses on the OPSAWG list. Both said the operator should have a choice of which to deploy. In other words, the notifications and logs should both be defined. Because of the way I framed the question, this opinion is orthogonal to the matter of whether the Event MIB could be used instead of notifications in the NAT MIB. Tom Taylor From tom.taylor.stds@gmail.com Thu Sep 19 03:49:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7946121F96EF for ; Thu, 19 Sep 2013 03:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WewW3bjLlcZs for ; Thu, 19 Sep 2013 03:49:07 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9865B21F8EB5 for ; Thu, 19 Sep 2013 03:49:07 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so14612854iec.2 for ; Thu, 19 Sep 2013 03:48:51 -0700 (PDT) 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=q1d3HHm4wzwzLsWcNS6GGejuIGaV2fC+Z+ahwJny2UY=; b=Zwwvze89zgtK2t8goWba2pHN/zP4bTq9qD2Y7/yzzvmvuPXgU9l9Tduhwjzurof+i7 KCWGLJTJ+k/U0ssCkPRFmZAY43rQDDlPwFUWU8qj8Vfz5N7FQf/9/OGr9qoBQBTL6Jxs TAXQXYbdaMEc3w1C6WOhPoL3DfU6/dQ33k2u6Dblz8IGHXXLn2P2efPAe8mG/of6nYzq 2J2Y0gWHYzXE6aekcTyz+V82f5fpWzceTT8oeF6MRyoJUNmsmVXd62km9d8Ocz7aXhMH xKBf0UsRWdubZPDIp8i5azlDfpzoT67xYZEomaZz3zQQpihOT3t97lvKHTdaHzqaEzmb 9mEA== X-Received: by 10.50.45.73 with SMTP id k9mr735926igm.38.1379587731051; Thu, 19 Sep 2013 03:48:51 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id yt10sm3028984igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 03:48:50 -0700 (PDT) Message-ID: <523AD692.4010603@gmail.com> Date: Thu, 19 Sep 2013 06:48:50 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 10:49:13 -0000 Dave Thaler suggested in his review or at the meeting that we might assign sequence numbers to logs to allow detection of missing reports. I can see it as useful for all event report types, actually, But first, some terminology: - an event is detected - either an event report is generated or it is suppressed Suppression happens as a result of a management control limiting the volume of a particular event type. I propose to describe such controls in the new Management Considerations section of the SYSLOG document. So my proposal is that a sequence number is included in every event report generated. This sequence number reflects a counter that is carried per event type. The counter is incremented by 1 for every time the event is detected. The sequence number can be used to detect missing event reports for critical events such as session, BIB entry, and address mapping creation and deletion. It can also be used to determine the number of event reports suppressed between successive occurrences of a given boundary-type event such as a threshold crossing. Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would they be application-specific or something that should be defined in a separate draft as an extension to SYSLOG? I could also see a generic SYSLOG MIB that would, amongst other things, carry counters for total event detections and event reports suppressed by event type, but that is something I would take to the OPSAWG list. Tom Taylor From ietfdbh@comcast.net Thu Sep 19 07:09:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F0721F8C0C for ; Thu, 19 Sep 2013 07:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.348 X-Spam-Level: X-Spam-Status: No, score=-98.348 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_81=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToIDZjjhZxlv for ; Thu, 19 Sep 2013 07:09:04 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 88DC021F8B12 for ; Thu, 19 Sep 2013 07:09:04 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id SzML1m0031uE5Es592949Q; Thu, 19 Sep 2013 14:09:04 +0000 Received: from [192.168.13.104] ([38.101.90.254]) by omta16.westchester.pa.mail.comcast.net with comcast id T28W1m00A5VGBPJ3c28cHF; Thu, 19 Sep 2013 14:08:58 +0000 User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Thu, 19 Sep 2013 10:08:29 -0400 From: David Harrington To: Tom Taylor , "behave@ietf.org" Message-ID: Thread-Topic: [BEHAVE] Log sequencel numbers In-Reply-To: <523AD692.4010603@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379599744; bh=ETxmIggmlBS8y3o4rOsaKTgq6lHKdxfOtmTY1JCwsW0=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=ErEQOXc5jqnbS2jriIQFeYE6eoasa7tN+WwTvRcF3litV67VCuXn9BZhpSNVs+0qY CXtmEt8e640KjckOLvIuzbm/0fAICZgaRPDuFQWmSXuwuvcQVh9TsyzvwozoGqHe2a DTJ3oD8rnNKlkndLgSTOPxA1QYKOvCkf/moECUbmxYyMAQkpTJXDlmxI8Gv6lGysyG fzzXwHDUPljJ8dlS6+p23XYMLLNPqI6MFKjy2MBUWiCh/DTgswmaNg49hwu1rAieqU 9UzdIVS8KTJUreZOXaPbHF6ZAV/BK4PY1VVAnANqTqdF+5l3QWxjSh+qCd/B/K/jRh xZIgxXBg4D8oA== Cc: David Harrington Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:09:09 -0000 Hi, See rfc5848 "signed syslog messages", which deals with assigning sequence #s to syslog messages, for purposes of detecting missing messages. RFC5848 takes into consideration the fact that the relationship between a syslog sender and syslog receivers are not 1:1; syslog senders often send some messages to one receiver and some messages to other receivers, and receivers often accept syslog messages from multiple senders. So the sequence#s for received messages will not necessarily be sequential under normal circumstances. A specific sender uses signature blocks to sign groups of messages sent to each specific receiver, so the receiver can tell which messages it missed. The sender is identified by hostname, app-name, and proc-id. Since it can be important to maintain logs for law enforcement purposes, rfc5848 includes authentication, message integrity, and message replay as well as sequencing and detection of missing messages. Signed syslog works not only for the transport of messages, but also for subsequent archiving to verify that stored message logs have not been modified. I would think these would be really important for NAT logging. RFC5848 also deals with issues of signing-session reboot, some recommended approaches to reviewing logs both offline and online, and a substantial consideration of security. I have not looked at the techniques to determine whether they could be adapted easily for signing ipfix and/or snmp notifications. -- David Harrington Syslog WG co-chair Ietfdbh@comcast.net +1-603-828-1401 On 9/19/13 6:48 AM, "Tom Taylor" wrote: >Dave Thaler suggested in his review or at the meeting that we might >assign sequence numbers to logs to allow detection of missing reports. I >can see it as useful for all event report types, actually, But first, >some terminology: > >- an event is detected >- either an event report is generated or it is suppressed >Suppression happens as a result of a management control limiting the >volume of a particular event type. I propose to describe such controls >in the new Management Considerations section of the SYSLOG document. > >So my proposal is that a sequence number is included in every event >report generated. This sequence number reflects a counter that is >carried per event type. The counter is incremented by 1 for every time >the event is detected. > >The sequence number can be used to detect missing event reports for >critical events such as session, BIB entry, and address mapping creation >and deletion. It can also be used to determine the number of event >reports suppressed between successive occurrences of a given >boundary-type event such as a threshold crossing. > >Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would >they be application-specific or something that should be defined in a >separate draft as an extension to SYSLOG? > >I could also see a generic SYSLOG MIB that would, amongst other things, >carry counters for total event detections and event reports suppressed >by event type, but that is something I would take to the OPSAWG list. > >Tom Taylor >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Thu Sep 19 07:15:19 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C877C21F992A for ; Thu, 19 Sep 2013 07:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z82LPlOByYss for ; Thu, 19 Sep 2013 07:15:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 352EF21F95D0 for ; Thu, 19 Sep 2013 07:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2278; q=dns/txt; s=iport; t=1379600106; x=1380809706; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=a41DXaPLSCReKEdgl238jtRgOuhKCebZMoQYgRG/mew=; b=dc4hSLugN8wk8mYLOZRWK96syIxbMUgmpvr2mTtp6BUeaQBxsfHN8uGr cecUdSe7/vupg//DqubQniIrQSiz5FHX0GTOWt3WKaLJV/yLJzDHA3flY kTdPk7ERZ77DbXkGbic237L19ZCJClavsPPrNzLW70F9cCu2QIHgp8blJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAD4GO1KtJV2b/2dsb2JhbABbgwc4UsBjSoEgFnSCJwEEAQEBZAcdAQgiRQYLJQIEARIIh2kDDwyvbQ2JXgSMe4EhgRo4gx6BAAOJAI0TjiuFM4MkgWhC X-IronPort-AV: E=Sophos;i="4.90,936,1371081600"; d="scan'208";a="261923450" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 19 Sep 2013 14:15:05 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8JEF5JN010981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 14:15:05 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 09:15:05 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] Log sequencel numbers Thread-Index: AQHOtSXkc/+vMPQYjUKjviKG50VfzJnNK7uA Date: Thu, 19 Sep 2013 14:15:04 +0000 Message-ID: In-Reply-To: <523AD692.4010603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [64.102.83.140] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <911D90F18B505D4AA2A2406CD0026B1D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:15:19 -0000 I can understand the use of the sequence numbers in detecting missing events,=20 But I don=B9t understand what the receiver/collector should do in case of a missing event. Are we discovering another protocol to ask for the missing events and are we asking the NATs to maintain event Ids so that the missing events can be replayed? I believe this=20 goes back to reliable transports and why cant we just say use a reliable transport if=20 that is the most important thing and leave it to the implementation? Senthil On 9/19/13 6:48 AM, "Tom Taylor" wrote: >Dave Thaler suggested in his review or at the meeting that we might >assign sequence numbers to logs to allow detection of missing reports. I >can see it as useful for all event report types, actually, But first, >some terminology: > >- an event is detected >- either an event report is generated or it is suppressed >Suppression happens as a result of a management control limiting the >volume of a particular event type. I propose to describe such controls >in the new Management Considerations section of the SYSLOG document. > >So my proposal is that a sequence number is included in every event >report generated. This sequence number reflects a counter that is >carried per event type. The counter is incremented by 1 for every time >the event is detected. > >The sequence number can be used to detect missing event reports for >critical events such as session, BIB entry, and address mapping creation >and deletion. It can also be used to determine the number of event >reports suppressed between successive occurrences of a given >boundary-type event such as a threshold crossing. > >Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would >they be application-specific or something that should be defined in a >separate draft as an extension to SYSLOG? > >I could also see a generic SYSLOG MIB that would, amongst other things, >carry counters for total event detections and event reports suppressed >by event type, but that is something I would take to the OPSAWG list. > >Tom Taylor >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From achatz@forthnetgroup.gr Thu Sep 19 07:49:55 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA64B21F942D for ; Thu, 19 Sep 2013 07:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iucDfNw3gINy for ; Thu, 19 Sep 2013 07:49:50 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 425AD21F9371 for ; Thu, 19 Sep 2013 07:49:41 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8JEnbDp018751; Thu, 19 Sep 2013 17:49:37 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8JEnbiO004542; Thu, 19 Sep 2013 17:49:37 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8JEnZX0016020; Thu, 19 Sep 2013 17:49:36 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <523B0EFA.5000404@forthnetgroup.gr> Date: Thu, 19 Sep 2013 17:49:30 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , "behave@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 14:49:55 -0000 I could see some aid in troubleshooting. Unless there is a connection-oriented protocol used, alerts from both source and destination are a welcome idea. Going one step ahead, i dislike the idea of retrasmision for this matter. -- Tassos Senthil Sivakumar (ssenthil) wrote on 19/09/2013 17:15: > I can understand the use of the sequence numbers in detecting missing > events, > But I don¹t understand what the receiver/collector should do in case of a > missing event. > Are we discovering another protocol to ask for the missing events and are > we asking the > NATs to maintain event Ids so that the missing events can be replayed? I > believe this > goes back to reliable transports and why cant we just say use a reliable > transport if > that is the most important thing and leave it to the implementation? > > Senthil > > On 9/19/13 6:48 AM, "Tom Taylor" wrote: > >> Dave Thaler suggested in his review or at the meeting that we might >> assign sequence numbers to logs to allow detection of missing reports. I >> can see it as useful for all event report types, actually, But first, >> some terminology: >> >> - an event is detected >> - either an event report is generated or it is suppressed >> Suppression happens as a result of a management control limiting the >> volume of a particular event type. I propose to describe such controls >> in the new Management Considerations section of the SYSLOG document. >> >> So my proposal is that a sequence number is included in every event >> report generated. This sequence number reflects a counter that is >> carried per event type. The counter is incremented by 1 for every time >> the event is detected. >> >> The sequence number can be used to detect missing event reports for >> critical events such as session, BIB entry, and address mapping creation >> and deletion. It can also be used to determine the number of event >> reports suppressed between successive occurrences of a given >> boundary-type event such as a threshold crossing. >> >> Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would >> they be application-specific or something that should be defined in a >> separate draft as an extension to SYSLOG? >> >> I could also see a generic SYSLOG MIB that would, amongst other things, >> carry counters for total event detections and event reports suppressed >> by event type, but that is something I would take to the OPSAWG list. >> >> Tom Taylor >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From tom.taylor.stds@gmail.com Thu Sep 19 09:46:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B75321F95D0 for ; Thu, 19 Sep 2013 09:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXMPd+dGUi5O for ; Thu, 19 Sep 2013 09:46:51 -0700 (PDT) Received: from mail-ye0-x22f.google.com (mail-ye0-x22f.google.com [IPv6:2607:f8b0:4002:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3570221F960D for ; Thu, 19 Sep 2013 09:46:51 -0700 (PDT) Received: by mail-ye0-f175.google.com with SMTP id q8so3533717yen.34 for ; Thu, 19 Sep 2013 09:46:50 -0700 (PDT) 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=0ZaLnvFEn/5GYKoLReOn8uKa4RsKaKZs7hvz4or541c=; b=EOnk51VyhrpLDLqxqyLbPg+pevIUOT6W17lvNFrTI2exiyOMkhkSsxGkb3945uZN9Q 3dsHFhPkEZTxiZXLZhrSgWpLxLPpW/jgRhyd2Z67ApGi8V9vEsjBtHHs18Wsz31zn29Z 6Zo3Cm6hK2/qfSACoIpzlKumFYB9AGWPTngzQpEPe3c+IGuAcBhnT2DLMdS9s9W+zups zWlnDdjIFxhOQBIGitJqx+ScccqFf8RDPdpCYcr7ouacKzwLUyIB/CgZYBK5nBaG0da0 2Xxvhee14vW2V9getFxmyS1KesxSNDc8WjxMNwXnrOJKX9Pt+hyFUF7mGe2F7Z6Qvx6A /IrA== X-Received: by 10.236.38.74 with SMTP id z50mr1127038yha.134.1379609210738; Thu, 19 Sep 2013 09:46:50 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id s20sm11973144yhi.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 09:46:50 -0700 (PDT) Message-ID: <523B2A78.5070004@gmail.com> Date: Thu, 19 Sep 2013 12:46:48 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tassos Chatzithomaoglou References: <523B0EFA.5000404@forthnetgroup.gr> In-Reply-To: <523B0EFA.5000404@forthnetgroup.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:46:52 -0000 I certainly didn't have re-transmission in mind. I meant the information about missing logs to be flagged at the application level, so no mistakes are made correlating subscribers with sessions or whatever. I think this is a NOOP though because of David Harrington's point about a given collector not necessarily receiving all the logs of a given event type. Tom On 19/09/2013 10:49 AM, Tassos Chatzithomaoglou wrote: > I could see some aid in troubleshooting. > Unless there is a connection-oriented protocol used, alerts from both source and destination are a welcome idea. > > Going one step ahead, i dislike the idea of retrasmision for this matter. > > -- > Tassos > > Senthil Sivakumar (ssenthil) wrote on 19/09/2013 17:15: >> I can understand the use of the sequence numbers in detecting missing >> events, >> But I don¹t understand what the receiver/collector should do in case of a >> missing event. >> Are we discovering another protocol to ask for the missing events and are >> we asking the >> NATs to maintain event Ids so that the missing events can be replayed? I >> believe this >> goes back to reliable transports and why cant we just say use a reliable >> transport if >> that is the most important thing and leave it to the implementation? >> >> Senthil >> >> On 9/19/13 6:48 AM, "Tom Taylor" wrote: >> >>> Dave Thaler suggested in his review or at the meeting that we might >>> assign sequence numbers to logs to allow detection of missing reports. I >>> can see it as useful for all event report types, actually, But first, >>> some terminology: >>> >>> - an event is detected >>> - either an event report is generated or it is suppressed >>> Suppression happens as a result of a management control limiting the >>> volume of a particular event type. I propose to describe such controls >>> in the new Management Considerations section of the SYSLOG document. >>> >>> So my proposal is that a sequence number is included in every event >>> report generated. This sequence number reflects a counter that is >>> carried per event type. The counter is incremented by 1 for every time >>> the event is detected. >>> >>> The sequence number can be used to detect missing event reports for >>> critical events such as session, BIB entry, and address mapping creation >>> and deletion. It can also be used to determine the number of event >>> reports suppressed between successive occurrences of a given >>> boundary-type event such as a threshold crossing. >>> >>> Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would >>> they be application-specific or something that should be defined in a >>> separate draft as an extension to SYSLOG? >>> >>> I could also see a generic SYSLOG MIB that would, amongst other things, >>> carry counters for total event detections and event reports suppressed >>> by event type, but that is something I would take to the OPSAWG list. >>> >>> Tom Taylor >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From achatz@forthnetgroup.gr Thu Sep 19 10:20:23 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CF621F940D for ; Thu, 19 Sep 2013 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15GREw5W2DQb for ; Thu, 19 Sep 2013 10:20:17 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1643621F9425 for ; Thu, 19 Sep 2013 10:20:16 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8JHK94v030056; Thu, 19 Sep 2013 20:20:09 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8JHK9u9009363; Thu, 19 Sep 2013 20:20:09 +0300 Received: from [192.168.1.2] (194.219.240.254.dsl.dyn.forthnet.gr [194.219.240.254]) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r8JHK7Xw018179; Thu, 19 Sep 2013 20:20:08 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; spf=pass Authentication-Results: MX-IN-05.forthnet.gr header.from=achatz@forthnetgroup.gr; sender-id=pass Message-ID: <523B3240.3080604@forthnetgroup.gr> Date: Thu, 19 Sep 2013 20:20:00 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Tom Taylor References: <523B0EFA.5000404@forthnetgroup.gr> <523B2A78.5070004@gmail.com> In-Reply-To: <523B2A78.5070004@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 17:20:23 -0000 Can't sequencing be applied per collector and per event type? The logging system of the aftr vendor i'm using now can provide differentiation per collector and some kind of differentiation per event. -- Tassos Tom Taylor wrote on 19/9/2013 19:46: > I certainly didn't have re-transmission in mind. I meant the information about missing logs to be flagged at the application level, so no mistakes are made correlating subscribers with sessions or whatever. > > I think this is a NOOP though because of David Harrington's point about a given collector not necessarily receiving all the logs of a given event type. > > Tom > > On 19/09/2013 10:49 AM, Tassos Chatzithomaoglou wrote: >> I could see some aid in troubleshooting. >> Unless there is a connection-oriented protocol used, alerts from both source and destination are a welcome idea. >> >> Going one step ahead, i dislike the idea of retrasmision for this matter. >> >> -- >> Tassos >> >> Senthil Sivakumar (ssenthil) wrote on 19/09/2013 17:15: >>> I can understand the use of the sequence numbers in detecting missing >>> events, >>> But I don¹t understand what the receiver/collector should do in case of a >>> missing event. >>> Are we discovering another protocol to ask for the missing events and are >>> we asking the >>> NATs to maintain event Ids so that the missing events can be replayed? I >>> believe this >>> goes back to reliable transports and why cant we just say use a reliable >>> transport if >>> that is the most important thing and leave it to the implementation? >>> >>> Senthil >>> >>> On 9/19/13 6:48 AM, "Tom Taylor" wrote: >>> >>>> Dave Thaler suggested in his review or at the meeting that we might >>>> assign sequence numbers to logs to allow detection of missing reports. I >>>> can see it as useful for all event report types, actually, But first, >>>> some terminology: >>>> >>>> - an event is detected >>>> - either an event report is generated or it is suppressed >>>> Suppression happens as a result of a management control limiting the >>>> volume of a particular event type. I propose to describe such controls >>>> in the new Management Considerations section of the SYSLOG document. >>>> >>>> So my proposal is that a sequence number is included in every event >>>> report generated. This sequence number reflects a counter that is >>>> carried per event type. The counter is incremented by 1 for every time >>>> the event is detected. >>>> >>>> The sequence number can be used to detect missing event reports for >>>> critical events such as session, BIB entry, and address mapping creation >>>> and deletion. It can also be used to determine the number of event >>>> reports suppressed between successive occurrences of a given >>>> boundary-type event such as a threshold crossing. >>>> >>>> Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would >>>> they be application-specific or something that should be defined in a >>>> separate draft as an extension to SYSLOG? >>>> >>>> I could also see a generic SYSLOG MIB that would, amongst other things, >>>> carry counters for total event detections and event reports suppressed >>>> by event type, but that is something I would take to the OPSAWG list. >>>> >>>> Tom Taylor >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >> >> > From tom.taylor.stds@gmail.com Thu Sep 19 13:46:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4397D21F847C for ; Thu, 19 Sep 2013 13:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ2OaB5Juv7U for ; Thu, 19 Sep 2013 13:46:08 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6121F846E for ; Thu, 19 Sep 2013 13:46:08 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id t59so4357680yho.38 for ; Thu, 19 Sep 2013 13:46:08 -0700 (PDT) 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=LGRq/hIis9PFMbdFLRcTtx4ASYNP36TXzfcjPwv4yDc=; b=GazKAGXDUqq/UlvwAGgDceNg9bKf/4x/SvpSRxEcVj6H2CSyg3hB1efagnnXtPvSPN MBc69bIAXTdWG4nX8a92EipQ9U0IgbFrXSNrofAgwG/4dnv5D0FPBIldDhK37P2ckKyl PcBbE+SFZtuyFfx2OSZaKeP2Mk8qDMYHZ2OqwjXQoJWoJQjGv9Ue8ieuk1HtBEVWT6o2 rX4eH6kqO5nimK7dN/Uh/KtA0+Lr6qneGDfMnNSL6K4aSUfvPeJ8mWTgG5Y+ccLgyjTk OfX6OpcaMs+uzddInbKvoSR568nAP+T+mX0untPulVWvlmIPaR/4KKAPhuhdXOk89FJR JbEQ== X-Received: by 10.236.174.37 with SMTP id w25mr2767765yhl.36.1379623567829; Thu, 19 Sep 2013 13:46:07 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id t62sm13295465yhd.26.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 13:46:07 -0700 (PDT) Message-ID: <523B628B.7050401@gmail.com> Date: Thu, 19 Sep 2013 16:46:03 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Harrington , "behave@ietf.org" Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:46:09 -0000 For SYSLOG, then, it's as simple as suggesting the use of RFC5848. Though that's rather heavier than I envisioned. To get event-level granularity, we would have to specify an application-specific signature group scheme (SPRI="3"). I'd be satisfied if IPFIX just added event-specific sequence numbers as I originally proposed. I guess they would have to be maintained separately per collector to provide deployment flexibility, though it takes me some imagination to figure out use cases for splitting streams of specific event report types. Tom Taylor On 19/09/2013 10:08 AM, David Harrington wrote: > Hi, > > See rfc5848 "signed syslog messages", which deals with assigning sequence > #s to syslog messages, for purposes of detecting missing messages. > > RFC5848 takes into consideration the fact that the relationship between a > syslog sender and syslog receivers are not 1:1; syslog senders often send > some messages to one receiver and some messages to other receivers, and > receivers often accept syslog messages from multiple senders. So the > sequence#s for received messages will not necessarily be sequential under > normal circumstances. > > A specific sender uses signature blocks to sign groups of messages sent to > each specific receiver, so the receiver can tell which messages it missed. > The sender is identified by hostname, app-name, and proc-id. > > Since it can be important to maintain logs for law enforcement purposes, > rfc5848 includes authentication, message integrity, and message replay as > well as sequencing and detection of missing messages. Signed syslog works > not only for the transport of messages, but also for subsequent archiving > to verify that stored message logs have not been modified. I would think > these would be really important for NAT logging. > > RFC5848 also deals with issues of signing-session reboot, some recommended > approaches to reviewing logs both offline and online, and a substantial > consideration of security. > > I have not looked at the techniques to determine whether they could be > adapted easily for signing ipfix and/or snmp notifications. > > -- > David Harrington > Syslog WG co-chair > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 9/19/13 6:48 AM, "Tom Taylor" wrote: > >> Dave Thaler suggested in his review or at the meeting that we might >> assign sequence numbers to logs to allow detection of missing reports. I >> can see it as useful for all event report types, actually, But first, >> some terminology: >> >> - an event is detected >> - either an event report is generated or it is suppressed >> Suppression happens as a result of a management control limiting the >> volume of a particular event type. I propose to describe such controls >> in the new Management Considerations section of the SYSLOG document. >> >> So my proposal is that a sequence number is included in every event >> report generated. This sequence number reflects a counter that is >> carried per event type. The counter is incremented by 1 for every time >> the event is detected. >> >> The sequence number can be used to detect missing event reports for >> critical events such as session, BIB entry, and address mapping creation >> and deletion. It can also be used to determine the number of event >> reports suppressed between successive occurrences of a given >> boundary-type event such as a threshold crossing. >> >> Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would >> they be application-specific or something that should be defined in a >> separate draft as an extension to SYSLOG? >> >> I could also see a generic SYSLOG MIB that would, amongst other things, >> carry counters for total event detections and event reports suppressed >> by event type, but that is something I would take to the OPSAWG list. >> >> Tom Taylor >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > > From tom.taylor.stds@gmail.com Thu Sep 19 13:52:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DC921F856A for ; Thu, 19 Sep 2013 13:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya5Iq1BIylf2 for ; Thu, 19 Sep 2013 13:52:36 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94021F84F9 for ; Thu, 19 Sep 2013 13:52:36 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id a41so4345132yho.23 for ; Thu, 19 Sep 2013 13:52:36 -0700 (PDT) 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=uTGZCn4BG8Nrk2tujvdjNblo085CRgaNnUsZhqcvZLo=; b=gy9GGNSsqARl56NytIBEvyC+fMDd9TLNB9Tmja0XdETYsxbSVTKk7+raS62MXkpeSC EB7yVs/aX/z7L4HsP3gF1LVNm1azMYdk0q4U0Nh8R6q4f6INUqKXS/W+xp2gwGrQKONA 96dUk4LXWraaHRdV9RDouyVApTTvBXs2XcaKpE7ZA/QFxtO0rQvw7j40wCvGQND88THK EqvIAi0feHmRugMoWP6PYQGFGtcHtguqY0tT8JO/1xuZ0o4M3j8U0vJmYn0eaAKIPRpl 9aNN9YhT1elsPj/R42JaIpuGEM1Xo4KYhAVMIk8ZKb2StzqMksA5qqZU1u6j2xDBOblB HwGQ== X-Received: by 10.236.85.237 with SMTP id u73mr2751957yhe.67.1379623955968; Thu, 19 Sep 2013 13:52:35 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id 9sm13340787yhe.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 13:52:35 -0700 (PDT) Message-ID: <523B6412.70906@gmail.com> Date: Thu, 19 Sep 2013 16:52:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Logging threshold crossings and limit hits X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:52:37 -0000 If we log high-water-mark threshold crossings, do we also need to log when limits are hit (e.g., the existing "Addresses exhausted" event)? Tom T From simon.perreault@viagenie.ca Fri Sep 20 01:51:39 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4629C21F8CB4 for ; Fri, 20 Sep 2013 01:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF--vp7NgbTd for ; Fri, 20 Sep 2013 01:51:38 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0E8921F8C93 for ; Fri, 20 Sep 2013 01:51:38 -0700 (PDT) Received: from porto.nomis80.org (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DCA99415A1 for ; Fri, 20 Sep 2013 04:51:37 -0400 (EDT) Message-ID: <523C0C99.2060003@viagenie.ca> Date: Fri, 20 Sep 2013 10:51:37 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: behave@ietf.org References: <523B6412.70906@gmail.com> In-Reply-To: <523B6412.70906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Logging threshold crossings and limit hits X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 08:51:39 -0000 Le 2013-09-19 22:52, Tom Taylor a écrit : > If we log high-water-mark threshold crossings, do we also need to log > when limits are hit (e.g., the existing "Addresses exhausted" event)? I think people will want this. If the logging doesn't happen by itself, people will setup systems to log SNMP traps... 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 ssenthil@cisco.com Fri Sep 20 12:42:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C70921F9DA3 for ; Fri, 20 Sep 2013 12:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm5J-yn0evxN for ; Fri, 20 Sep 2013 12:42:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1D78521F9D3A for ; Fri, 20 Sep 2013 12:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4857; q=dns/txt; s=iport; t=1379706131; x=1380915731; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gcUKUKN0Nedpv4vlbCWCbQpi3Nh1O0r7yzX8u+m4NG8=; b=SHcu5/iEV+k22/Rucb+63ofRgIZeK/fjMfXnibLGpYRcZ8tf0k74JzEU 9yNMCFHFJaiuvRR29IV87iD++X/1spVffr5tIqi0HQR/Q3t7Mh+vSzjgw u4Fs49SR7Q3BUV4onAE48kqtAf0/NsL+MJn7RKCciUqop3x4qc9lyOpwO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFykPFKtJXG+/2dsb2JhbABYA4MHOFLBFUqBGhZ0giUBAQEEAQEBZAcEBxIBCBgKRQYLJQIEAQ0FCIdrAw8MsGAIBYlKBIx3gSMCgRYCIRAHEYMNgQADiQCNE44shTODJIFoCRci X-IronPort-AV: E=Sophos;i="4.90,946,1371081600"; d="scan'208";a="262514742" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 20 Sep 2013 19:42:10 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8KJgAmV030861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 19:42:10 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 14:42:09 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , David Harrington Thread-Topic: [BEHAVE] Log sequencel numbers Thread-Index: AQHOtSXkc/+vMPQYjUKjviKG50VfzJnNbPSAgABvFICAAT1qgA== Date: Fri, 20 Sep 2013 19:42:08 +0000 Message-ID: In-Reply-To: <523B628B.7050401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.82.249.43] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <86D9460B77AC954AB676BC08C696C45D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: David Harrington , "behave@ietf.org" Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 19:42:16 -0000 On 9/19/13 4:46 PM, "Tom Taylor" wrote: >For SYSLOG, then, it's as simple as suggesting the use of RFC5848. >Though that's rather heavier than I envisioned. To get event-level >granularity, we would have to specify an application-specific signature >group scheme (SPRI=3D"3"). > >I'd be satisfied if IPFIX just added event-specific sequence numbers as >I originally proposed. I guess they would have to be maintained >separately per collector to provide deployment flexibility, though it >takes me some imagination to figure out use cases for splitting streams >of specific event report types. Not sure I understand, are you proposing IPFIX header carrying a sequence number or NAT log events carrying a sequence number? As I mentioned in my Earlier email, the sequence number don=B9t really provide any advantage tha= n just detecting something is missing. I am against the idea of adding the sequence numbers. I would like to see strong consensus before adding the sequence number. Senthil > >Tom Taylor > >On 19/09/2013 10:08 AM, David Harrington wrote: >> Hi, >> >> See rfc5848 "signed syslog messages", which deals with assigning >>sequence >> #s to syslog messages, for purposes of detecting missing messages. >> >> RFC5848 takes into consideration the fact that the relationship between >>a >> syslog sender and syslog receivers are not 1:1; syslog senders often >>send >> some messages to one receiver and some messages to other receivers, and >> receivers often accept syslog messages from multiple senders. So the >> sequence#s for received messages will not necessarily be sequential >>under >> normal circumstances. >> >> A specific sender uses signature blocks to sign groups of messages sent >>to >> each specific receiver, so the receiver can tell which messages it >>missed. >> The sender is identified by hostname, app-name, and proc-id. >> >> Since it can be important to maintain logs for law enforcement purposes, >> rfc5848 includes authentication, message integrity, and message replay >>as >> well as sequencing and detection of missing messages. Signed syslog >>works >> not only for the transport of messages, but also for subsequent >>archiving >> to verify that stored message logs have not been modified. I would think >> these would be really important for NAT logging. >> >> RFC5848 also deals with issues of signing-session reboot, some >>recommended >> approaches to reviewing logs both offline and online, and a substantial >> consideration of security. >> >> I have not looked at the techniques to determine whether they could be >> adapted easily for signing ipfix and/or snmp notifications. >> >> -- >> David Harrington >> Syslog WG co-chair >> Ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> >> >> >> On 9/19/13 6:48 AM, "Tom Taylor" wrote: >> >>> Dave Thaler suggested in his review or at the meeting that we might >>> assign sequence numbers to logs to allow detection of missing reports. >>>I >>> can see it as useful for all event report types, actually, But first, >>> some terminology: >>> >>> - an event is detected >>> - either an event report is generated or it is suppressed >>> Suppression happens as a result of a management control limiting the >>> volume of a particular event type. I propose to describe such controls >>> in the new Management Considerations section of the SYSLOG document. >>> >>> So my proposal is that a sequence number is included in every event >>> report generated. This sequence number reflects a counter that is >>> carried per event type. The counter is incremented by 1 for every time >>> the event is detected. >>> >>> The sequence number can be used to detect missing event reports for >>> critical events such as session, BIB entry, and address mapping >>>creation >>> and deletion. It can also be used to determine the number of event >>> reports suppressed between successive occurrences of a given >>> boundary-type event such as a threshold crossing. >>> >>> Shall we add sequence numbers to IPFIX and SYSLOG? For SYSLOG, would >>> they be application-specific or something that should be defined in a >>> separate draft as an extension to SYSLOG? >>> >>> I could also see a generic SYSLOG MIB that would, amongst other things, >>> carry counters for total event detections and event reports suppressed >>> by event type, but that is something I would take to the OPSAWG list. >>> >>> Tom Taylor >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> >> >> >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Fri Sep 20 13:24:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA16C21F9A16 for ; Fri, 20 Sep 2013 13:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPOKfxFU2gi9 for ; Fri, 20 Sep 2013 13:24:16 -0700 (PDT) Received: from mail-ye0-x233.google.com (mail-ye0-x233.google.com [IPv6:2607:f8b0:4002:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5E96B21F99ED for ; Fri, 20 Sep 2013 13:24:16 -0700 (PDT) Received: by mail-ye0-f179.google.com with SMTP id r6so326052yen.10 for ; Fri, 20 Sep 2013 13:24:13 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=/5WthZ+2k3EluiVrCKKOTeyYYUtmvFP/xP1oZNjqpmo=; b=ZsY+QMUYRA2yKfUHvIrOnWO/MKZutmCDmV4M1mqa3cMvoWUqrA0G6wg45N47IZNni7 xZ07T9ETU3+J1fo1UuzcvsC56iDyRlt9cUNv5nA00IroSb1uP/nE8lvNPQymLWbzfN3G wM/mwloulDCbembLhUJhP0wgawUX7/6XRR2DRY0YwwRdQgJUmauS8ucUM4LIGCZV0Ebg PA8zsdJWoevVVii3iaq5zVrZ93JUDi8flr1qv+akQbIjNC/nsPNAQxF1eSmKLvr5YGXv nHVANeTrfs2cniWY9IDoJKCnqAUr8JsgIrOpOk2NvRDhXi4CZGP4rdncJ4S9ABv8EiUi 8T1A== X-Received: by 10.236.43.232 with SMTP id l68mr8407641yhb.4.1379708653611; Fri, 20 Sep 2013 13:24:13 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id d26sm20463301yhj.25.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 13:24:13 -0700 (PDT) Message-ID: <523CAEEA.9030704@gmail.com> Date: Fri, 20 Sep 2013 16:24:10 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Senthil Sivakumar , 'Simon Perreault' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 20:24:17 -0000 What is the intended relationship between these two counters. More specifically, is natPoolRangeAllocatedPorts incremented once per port-protocol combination allocated, or once when any protocol is allocated a given a port value, and not again for the same port value until it is subsequently freed? As I mentioned in an earlier private E-mail, I'd like to see natPoolUsage calculated based on the second alternative, but I'd be happy to see natPoolRangeAllocatedPorts incremented once per port-protocol combination. That would give the operator a fuller picture of address pool activity. Tom Taylor From ssenthil@cisco.com Fri Sep 20 13:35:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D0321F9E6B for ; Fri, 20 Sep 2013 13:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMMD-7q1ChR6 for ; Fri, 20 Sep 2013 13:35:10 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A75FE21F9E53 for ; Fri, 20 Sep 2013 13:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=977; q=dns/txt; s=iport; t=1379709310; x=1380918910; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i7XsMZERbcQxIXxRyxT5GkAyyzqvSRjElT4JpGqNs2k=; b=LRk8yF5oUYmzDHC9f4gw5T55e3bYRoQ/SFgPma3xhq5kq14rdYXDRq3L noZf/MwgMgPeu6jAPZOg9GSC/M9IT11Ouli0SPMWMm23Js9bxiV1cYX82 Y56DplPRDFnfX4ly4bOcQGuldii2noNJ2oD99JnAtMCrvOWoTe3Be1Ydr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABuwPFKtJV2Z/2dsb2JhbABbgweBCsFfgRsWdIInAQQ6OAcSAQgiFDERJQIEAQ0FCIdrAw+wdw2JaoJbihyBNYEIMQeDHoEAA5YTjiyFM4MkgXE5 X-IronPort-AV: E=Sophos;i="4.90,947,1371081600"; d="scan'208";a="262587372" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 20 Sep 2013 20:35:09 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8KKZ94U025901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 20:35:09 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 15:35:08 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "'Simon Perreault'" Thread-Topic: NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage Thread-Index: AQHOtj9oOboq/Xeeek6vURb6yn7T6JnPJg2A Date: Fri, 20 Sep 2013 20:35:08 +0000 Message-ID: In-Reply-To: <523CAEEA.9030704@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.82.249.43] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 20:35:16 -0000 On 9/20/13 4:24 PM, "Tom Taylor" wrote: >What is the intended relationship between these two counters. More >specifically, is natPoolRangeAllocatedPorts incremented once per >port-protocol combination allocated, or once when any protocol is >allocated a given a port value, and not again for the same port value >until it is subsequently freed? If you have 10 addresses in the pool, each address has 10k ports allocated (TCP or UDP), natPoolRangeAllocatedPorts counter will say 100k ports allocated. poolUsage is a percentage value. Not sure I remember why we decided to have two values.. Thanks Senthil > >As I mentioned in an earlier private E-mail, I'd like to see >natPoolUsage calculated based on the second alternative, but I'd be >happy to see natPoolRangeAllocatedPorts incremented once per >port-protocol combination. That would give the operator a fuller picture >of address pool activity. > >Tom Taylor From dthaler@microsoft.com Fri Sep 20 15:04:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0DA21F9AA8 for ; Fri, 20 Sep 2013 15:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rhrLPNvg0-E for ; Fri, 20 Sep 2013 15:04:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 26C5621F9A8C for ; Fri, 20 Sep 2013 15:04:09 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 20 Sep 2013 22:03:59 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.45]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.45]) with mapi id 15.00.0775.005; Fri, 20 Sep 2013 22:03:59 +0000 From: Dave Thaler To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , 'Simon Perreault' Thread-Topic: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage Thread-Index: AQHOtkDu4m/+vPjYDU6CoV5FpDp3t5nPLdPA Date: Fri, 20 Sep 2013 22:03:58 +0000 Message-ID: References: <523CAEEA.9030704@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 09752BC779 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(479174003)(377454003)(51704005)(13464003)(24454002)(4396001)(76796001)(56816003)(77096001)(76786001)(46102001)(54356001)(80022001)(77982001)(65816001)(47976001)(19580405001)(74876001)(47736001)(74366001)(74706001)(76576001)(50986001)(83322001)(19580395003)(49866001)(59766001)(80976001)(81342001)(31966008)(53806001)(79102001)(15975445006)(54316002)(74316001)(56776001)(74502001)(81816001)(81542001)(33646001)(83072001)(47446002)(81686001)(69226001)(74662001)(63696002)(51856001)(76482001)(145543001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 22:04:13 -0000 In MIB design one usual rule of thumb is you shouldn't have an object if it= s value can be trivially computed by the client from the values of other obje= cts. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Senthil Sivakumar (ssenthil) > Sent: Friday, September 20, 2013 1:35 PM > To: Tom Taylor; 'Simon Perreault' > Cc: behave@ietf.org > Subject: Re: [BEHAVE] NAT MIB: Relationship between > natPoolRangeAllocatedPorts and natPoolUsage >=20 >=20 >=20 > On 9/20/13 4:24 PM, "Tom Taylor" wrote: >=20 > >What is the intended relationship between these two counters. More > >specifically, is natPoolRangeAllocatedPorts incremented once per > >port-protocol combination allocated, or once when any protocol is > >allocated a given a port value, and not again for the same port value > >until it is subsequently freed? >=20 > If you have 10 addresses in the pool, each address has 10k ports allocate= d > (TCP or UDP), natPoolRangeAllocatedPorts counter will say 100k ports > allocated. >=20 > poolUsage is a percentage value. Not sure I remember why we decided to > have two values.. >=20 > Thanks > Senthil >=20 > > > >As I mentioned in an earlier private E-mail, I'd like to see > >natPoolUsage calculated based on the second alternative, but I'd be > >happy to see natPoolRangeAllocatedPorts incremented once per > >port-protocol combination. That would give the operator a fuller > >picture of address pool activity. > > > >Tom Taylor >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Fri Sep 20 18:45:20 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBD021F9FB7 for ; Fri, 20 Sep 2013 18:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sMpK0x6Mg9c for ; Fri, 20 Sep 2013 18:45:19 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEAD21F9A90 for ; Fri, 20 Sep 2013 18:45:17 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id k4so183358qaq.13 for ; Fri, 20 Sep 2013 18:45:17 -0700 (PDT) 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=YEz4yHACGnVLkG2BkSMw868WGnl8Nr5oZhORBuExhxQ=; b=FRF1UbdgtDj2gpadVFScbR6nmC1agwtaEj2GPz6eT8DpqkKqEb7TTKhFaKu2F1GxYH BEiV/Vhe7vPvnp/xpzc0Yez8Qsplb+ErDSGfQNPC+WEi6+gr3cfl5uhdP4ODXDaSFb0i lbBZYrSqiUpI4lr5M4QWa1jAb4Jbk/WgJd5SJYYcBn+pa2xWxW6MiTQy6d50FRB9/IMY fYt1//5ccDUz9D59BxiK0Mkxxkd/WmzHY2iLmPdM9oUChTBqN+KNNZcIprU9upMmMMLu oU+nS5ANiGQXoMr5iIaxPaMq70tBUuZW5Nlk4x7PIA5zPqlzSO8XD/m+lrZQOqPl+IUy fU7w== X-Received: by 10.229.244.8 with SMTP id lo8mr15521132qcb.20.1379727917608; Fri, 20 Sep 2013 18:45:17 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id b9sm23825163qad.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 18:45:16 -0700 (PDT) Message-ID: <523CFA2B.6060001@gmail.com> Date: Fri, 20 Sep 2013 21:45:15 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 01:45:20 -0000 On 20/09/2013 4:35 PM, Senthil Sivakumar (ssenthil) wrote: > > > On 9/20/13 4:24 PM, "Tom Taylor" wrote: > >> What is the intended relationship between these two counters. More >> specifically, is natPoolRangeAllocatedPorts incremented once per >> port-protocol combination allocated, or once when any protocol is >> allocated a given a port value, and not again for the same port value >> until it is subsequently freed? > > If you have 10 addresses in the pool, each address has 10k ports allocated > (TCP or UDP), [PTT] or both?? > natPoolRangeAllocatedPorts counter will say 100k ports allocated. > > poolUsage is a percentage value. Not sure I remember why we decided to > have two values.. poolUsage is over the whole pool. natPoolRangeAllocatedPorts is for a sub-range of addresses within the pool. The percentage is useful for thresholding, I suppose. > > Thanks > Senthil > >> >> As I mentioned in an earlier private E-mail, I'd like to see >> natPoolUsage calculated based on the second alternative, but I'd be >> happy to see natPoolRangeAllocatedPorts incremented once per >> port-protocol combination. That would give the operator a fuller picture >> of address pool activity. >> >> Tom Taylor > > From internet-drafts@ietf.org Fri Sep 20 19:05:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9AF21F9FB6; Fri, 20 Sep 2013 19:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5f+q1bjkkUJT; Fri, 20 Sep 2013 19:04:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB18B21F9DE9; Fri, 20 Sep 2013 19:04:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130921020459.3240.14667.idtracker@ietfa.amsl.com> Date: Fri, 20 Sep 2013 19:04:59 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 02:05:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Syslog Format for NAT Logging Author(s) : Zhonghua Chen Cathy Zhou Tina Tsou T. Taylor Filename : draft-ietf-behave-syslog-nat-logging-03.txt Pages : 38 Date : 2013-09-20 Abstract: With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for various operational purposes. The logs may be required for troubleshooting, to identify a host that was used to launch malicious attacks, and/or for accounting purposes. This document identifies the events that need to be logged and the parameters that are required in the logs depending on the context in which the NAT is being used. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 5101). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-syslog-nat-logging-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tom.taylor.stds@gmail.com Fri Sep 20 19:40:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445DC21F9FCE for ; Fri, 20 Sep 2013 19:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM4HEswHzzyr for ; Fri, 20 Sep 2013 19:40:44 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4817421F9FC3 for ; Fri, 20 Sep 2013 19:40:44 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 3so783821qeb.31 for ; Fri, 20 Sep 2013 19:40:43 -0700 (PDT) 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=yHSMqzYREVouhWz3C8+1dHKJGG/eVYB1s3gxwgHRZ4A=; b=iiAqOfCZ2KLRRQ6XpvI7HWnHcpuvFnTlmKmv+XvtiqSoU6dSfBDK+1GuM0TYXAJB7o mAkNHVjqynZKVE/E26+H5Pt6ANintHvcujTnFE41gH9NwsLAzA50acK95AQYj4JEs389 cUNSuAjSY91CNOip1pJRY0H6So2aNDlAkKdIzmJ+onh69vJ3ZArIb8ZkXYsIDw9PmT11 or8gmI2DDEwS6GWQEi5SiUiCoLjUHjzYJB9s1raDasHi/fDRkUul5L6Qed/2qT5AwWlm dv8wlLm22hi2SEPpWDJ8I881VtRQ4lD87BJlwmrBAiP6nfezSoXplAhu8o65tq1jp0G7 ZBVw== X-Received: by 10.229.116.197 with SMTP id n5mr364731qcq.22.1379731243736; Fri, 20 Sep 2013 19:40:43 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id m6sm18770810qaa.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 19:40:42 -0700 (PDT) Message-ID: <523D0724.2050401@gmail.com> Date: Fri, 20 Sep 2013 22:40:36 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" References: <20130921020500.3240.7926.idtracker@ietfa.amsl.com> In-Reply-To: <20130921020500.3240.7926.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130921020500.3240.7926.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Fwd: New Version Notification for draft-ietf-behave-syslog-nat-logging-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 02:40:45 -0000 I have submitted an update, but THIS IS A PARTIAL UPDATE, CONSISTENT ONLY THROUGH SECTION 3. Section 4 is probably OK too, but I haven't reviewed it. While I propagate the changes through the rest of the document, I would appreciate any comments on Sections 1-3 as they stand. Dave T., I'm afraid I didn't fold in the editorial changes you provided a link to in your pre-meeting review. Next update I'll look them over. Tom Taylor Major changes: 1. Adopted new definition of session (includes destination) from RFC6164. This distinguishes the session from BIB entries. 2. New Sec. 2.2 discusses realms and address pools. Beginning in this section, realigned terminology to talk about internal and external realms, addresses, and ports rather than various other terms. Realms are added as parameters of most of the event reports defined in Section 3. 3. New Sec. 2.3.1 introduces the generalized address in place of the subscriber site identifier. This is encoded as type-address-address/prefix length, but the types include IPv4, IPv6, and GW-initiated DS-Lite SWID. The GW-initiated DS-Lite context is characterized as a realm. In Section 3, got rid of the assumption that a mapping or session always involved a subscriber, where this was not necessary. Pulled the material that used to talk about subscriber site ID out of the introductory Section 3. 4. Got rid of the reporting device identifier optional parameter. Discussion on the OPSAWG list suggested we could get away with specifying that the HOSTNAME in the SYSLOG header always identifies the NAT device. 5. In Section 3.1, the session creation and deletion events always report destination address and port. The discussion of destination logging in Section 3.1.1 was modified to discourage destination logging but not forbid it. A proposal was added for a special study capability to enable destination logging only on a specified set of addresses. 6. BIB entry creation/deletion event added back in new Sec. 3.2, since it is now clearly distinguishable from sessions. 7. Port set allocation and deallocation in Sec. 3.4 now uses same notation as IPFIX, but I think Senthil and I have a basic disagreement on the semantics of that notation. The SYSLOG semantics are clearly spelled out in Sec. 3.4, with examples. 8. Took out the previous address exhausted and ports exhausted events (and the invalid port event, for other reasons) and replaced them with events based on the thresholds and limits in the NAT MIB. Hence new sections: 3.5. Address Pool High- and Low-Water-Mark Threshold Events . 16 3.6. Global Address Mapping High-Water-Mark Threshold Event . 17 3.7. Global Address Mapping Limit Exceeded . . . . . . . . . . 17 3.8. Global Transport Mapping High-Water-Mark Threshold Event 18 3.9. Global Transport Mapping Limit Exceeded . . . . . . . . . 18 3.10. Subscriber-Specific Mapping Threshold Event . . . . . . . 19 3.11. Global Limit On Number of Active Subscribers Exceeded . . 20 3.12. Subscriber-Specific Limit On Number of Transport Mappings Exceeded . . . . . . . . . . . . . . . . . . . . . . . . 21 3.14. Global Limit On Number Of Fragments Pending Reassembly Exceeded 9. The Quota Exceeded event in Sec. 3.13 was simplified as suggested in the meeting. -------- Original Message -------- Subject: New Version Notification for draft-ietf-behave-syslog-nat-logging-03.txt Date: Fri, 20 Sep 2013 19:05:00 -0700 From: internet-drafts@ietf.org To: Tina Tsou , T. Taylor , Tom Taylor , Cathy Zhou , Zhonghua Chen <18918588897@189.cn> A new version of I-D, draft-ietf-behave-syslog-nat-logging-03.txt has been successfully submitted by Zhonghua Chen and posted to the IETF repository. Filename: draft-ietf-behave-syslog-nat-logging Revision: 03 Title: Syslog Format for NAT Logging Creation date: 2013-09-21 Group: behave Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-ietf-behave-syslog-nat-logging-03.txt Status: http://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging Htmlized: http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-syslog-nat-logging-03 Abstract: With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for various operational purposes. The logs may be required for troubleshooting, to identify a host that was used to launch malicious attacks, and/or for accounting purposes. This document identifies the events that need to be logged and the parameters that are required in the logs depending on the context in which the NAT is being used. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 5101). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From tom.taylor.stds@gmail.com Sat Sep 21 08:45:28 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FED21F9473 for ; Sat, 21 Sep 2013 08:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6j23NwL6jjN for ; Sat, 21 Sep 2013 08:45:28 -0700 (PDT) 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 2E88021F9FB4 for ; Sat, 21 Sep 2013 08:45:28 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so3232176iet.5 for ; Sat, 21 Sep 2013 08:45:27 -0700 (PDT) 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=tPxeJ0wdvP6yvNFa6V0R0hZUKOx8J7Zh/+FlJFGE71E=; b=SaJvAbidF8+CI5m4G1+CqyTTy2uOu1yNl2FdzBk62Sh90U5Y091JPCrrX7C0JjuNIR 962a74I6uBV1RC0qx1YbdXmxyvExKTNG78gOvZ6lg8+yDTPYeIEqHkiHnc9it85ptA7C 2U5cq6Cq/LcMThLOuZQ8CAtDTUK2cCiUfFyW8iu0gynYEHT1WG84fXWP+uGHPxfLfTYf mmcElukfA+h39sxd6Rnpu53JzsJLXXthbop/5tzv+9YoaRrPvo5oW21NglrkMW3EQDaz wY95cIQ4Hk7jtnDaUKTcSdTza+bK3FKXmnx2VprVLz99pHF4WAmW9ETwYPO1iwAs3dJ6 lpgQ== X-Received: by 10.50.73.41 with SMTP id i9mr6311074igv.30.1379778327545; Sat, 21 Sep 2013 08:45:27 -0700 (PDT) Received: from [192.168.1.73] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id f5sm8304261igc.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 08:45:26 -0700 (PDT) Message-ID: <523DBF14.30401@gmail.com> Date: Sat, 21 Sep 2013 11:45:24 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" References: <20130921020500.3240.7926.idtracker@ietfa.amsl.com> <523D0724.2050401@gmail.com> In-Reply-To: <523D0724.2050401@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-ietf-behave-syslog-nat-logging-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:45:28 -0000 I see I missed deleting reporting device identifier from a number of events. Will be done in -04 update. On 20/09/2013 10:40 PM, Tom Taylor wrote: > I have submitted an update, but THIS IS A PARTIAL UPDATE, CONSISTENT > ONLY THROUGH SECTION 3. Section 4 is probably OK too, but I haven't > reviewed it. While I propagate the changes through the rest of the > document, I would appreciate any comments on Sections 1-3 as they stand. > > Dave T., I'm afraid I didn't fold in the editorial changes you provided > a link to in your pre-meeting review. Next update I'll look them over. > > Tom Taylor > > Major changes: > ... > > 4. Got rid of the reporting device identifier optional parameter. > Discussion on the OPSAWG list suggested we could get away with > specifying that the HOSTNAME in the SYSLOG header always identifies the > NAT device. > ... From tom.taylor.stds@gmail.com Sun Sep 22 08:48:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6452821F9E11 for ; Sun, 22 Sep 2013 08:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoBFyGmVBB8b for ; Sun, 22 Sep 2013 08:48:36 -0700 (PDT) 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 DF00421F9DF0 for ; Sun, 22 Sep 2013 08:48:35 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so4663109iej.38 for ; Sun, 22 Sep 2013 08:48:35 -0700 (PDT) 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=7GtK/XD6ocCZpBWe1cT92Uu4aWnYWRj45ycTpUZmRik=; b=crqA9N5E2cboERNF2Owlh3aj+h+VGzA4zj3/0Pl2GMaVF6tYnI0ddJ5gubuPZSlAMv p/khIP52o7iQ08VdjtrvQT/TV1HsHhpPKXNmTxqrvRQP1fBBEZLA0jvWRSS3QjDkuUzU O7sO94djqOQvxvdtEqvntPVvNFKEVWiHaQHfqVQSv3/H1q/WjOgT2J+CW86bk1vuYvu0 22sh0hOnAlbapFQwu8rj9/NUwZOrB/YQO0+HNBEdGUIrbWCVQGOKjQJd4HeWITp/x/YD Id3fvBl3CQDZiy7GGEfFV1zJLEOYuc/XxXWspQe9vrrEsFTAPCpPEnVedfEQ1eINTDXd MiPw== X-Received: by 10.50.20.99 with SMTP id m3mr9156226ige.54.1379864915433; Sun, 22 Sep 2013 08:48:35 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id hv5sm13870054igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 08:48:34 -0700 (PDT) Message-ID: <523F1150.50701@gmail.com> Date: Sun, 22 Sep 2013 11:48:32 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" References: <20130921020500.3240.7926.idtracker@ietfa.amsl.com> <523D0724.2050401@gmail.com> In-Reply-To: <523D0724.2050401@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-ietf-behave-syslog-nat-logging-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:48:36 -0000 Minor changes: on review, "triggering NAT procedure" didn't seem all that useful. Reverted to "reporting NAT type". Also replaced "transport mapping" with "BIB entry creation" in a number of places to make things a bit more consistent. Bigger change: re-reading GI DS-Lite, I see I got the roles of CID and SWID reversed. The CID is actually the individual site identifier, and SWID the tunnel identifier between the gateway and the AFTR. So I'll identify SWID with the realm and use the value of CID with a stated bit length (since RFC 6674 only says it is "usually" 32 bits wide) as the generalized address. On 20/09/2013 10:40 PM, Tom Taylor wrote: ... > > 3. New Sec. 2.3.1 introduces the generalized address in place of the > subscriber site identifier. This is encoded as > type-address-address/prefix length, but the types include IPv4, IPv6, > and GW-initiated DS-Lite SWID. The GW-initiated DS-Lite context is > characterized as a realm. In Section 3, got rid of the assumption that a > mapping or session always involved a subscriber, where this was not > necessary. Pulled the material that used to talk about subscriber site > ID out of the introductory Section 3. > ... From simon.perreault@viagenie.ca Mon Sep 23 02:31:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2C921F9DC7 for ; Mon, 23 Sep 2013 02:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdd2XIyqW9p4 for ; Mon, 23 Sep 2013 02:31:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C3EA721F9CF5 for ; Mon, 23 Sep 2013 02:31:47 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:e01a:be8d:b906:c8cd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E75EE403E0; Mon, 23 Sep 2013 05:31:46 -0400 (EDT) Message-ID: <52400A81.3090608@viagenie.ca> Date: Mon, 23 Sep 2013 11:31:45 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Tom Taylor , "Senthil Sivakumar (ssenthil)" References: <523CFA2B.6060001@gmail.com> In-Reply-To: <523CFA2B.6060001@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 09:31:49 -0000 Le 2013-09-21 03:45, Tom Taylor a écrit : > poolUsage is over the whole pool. natPoolRangeAllocatedPorts is for a > sub-range of addresses within the pool. Precisely. I'm not sure that natPoolUsage can be "easily" computed from individual natPoolRangeAllocatedPorts because there may be a lot of ranges, and walking them all could quickly become impractical. Simon From j.schoenwaelder@jacobs-university.de Mon Sep 23 03:03:31 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4C811E8170 for ; Mon, 23 Sep 2013 03:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.129 X-Spam-Level: X-Spam-Status: No, score=-103.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2atBDpHzCBj for ; Mon, 23 Sep 2013 03:03:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D0DA411E8178 for ; Mon, 23 Sep 2013 02:55:37 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8311820BF5; Mon, 23 Sep 2013 11:55:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FuHDe0hsroRk; Mon, 23 Sep 2013 11:55:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A4D120C06; Mon, 23 Sep 2013 11:55:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E65CD2884FD5; Mon, 23 Sep 2013 11:54:59 +0200 (CEST) Date: Mon, 23 Sep 2013 11:54:59 +0200 From: Juergen Schoenwaelder To: Simon Perreault Message-ID: <20130923095459.GA14842@elstar.local> Mail-Followup-To: Simon Perreault , Tom Taylor , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" References: <523CFA2B.6060001@gmail.com> <52400A81.3090608@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52400A81.3090608@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 10:03:34 -0000 On Mon, Sep 23, 2013 at 11:31:45AM +0200, Simon Perreault wrote: > Le 2013-09-21 03:45, Tom Taylor a écrit : > > poolUsage is over the whole pool. natPoolRangeAllocatedPorts is for a > > sub-range of addresses within the pool. > > Precisely. > > I'm not sure that natPoolUsage can be "easily" computed from individual > natPoolRangeAllocatedPorts because there may be a lot of ranges, and > walking them all could quickly become impractical. A slightly different question: How fast do these numbers change? Is reporting a snaphost really useful here? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From simon.perreault@viagenie.ca Mon Sep 23 03:06:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2336121F9985 for ; Mon, 23 Sep 2013 03:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtPrvfQdB0qW for ; Mon, 23 Sep 2013 03:06:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7F21F9EE0 for ; Mon, 23 Sep 2013 03:01:50 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:e01a:be8d:b906:c8cd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7E9FF403E0; Mon, 23 Sep 2013 06:01:40 -0400 (EDT) Message-ID: <52401183.1040406@viagenie.ca> Date: Mon, 23 Sep 2013 12:01:39 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Tom Taylor , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" References: <523CFA2B.6060001@gmail.com> <52400A81.3090608@viagenie.ca> <20130923095459.GA14842@elstar.local> In-Reply-To: <20130923095459.GA14842@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 10:07:00 -0000 Le 2013-09-23 11:54, Juergen Schoenwaelder a écrit : > A slightly different question: How fast do these numbers change? Is > reporting a snaphost really useful here? On a big NAT with large pools, I would expect the numbers to oscillate with a 24-hour period. When graphed, they would look similar to total bandwidth graphs. I think both objects can be very useful and are definitely needed. (An aside: on a busy node, byte counters change *very* often. The point of providing a snapshot is to make graphs and such. The exact value at a precise moment is not what's interesting. It's the trend.) Simon From Jean-Francois.TremblayING@videotron.com Mon Sep 23 05:42:05 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D1621F9BEF for ; Mon, 23 Sep 2013 05:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TTZ6a9Dc-Pj for ; Mon, 23 Sep 2013 05:42:00 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 184B221F9B5A for ; Mon, 23 Sep 2013 05:42:00 -0700 (PDT) In-Reply-To: References: <523B628B.7050401@gmail.com> To: "behave@ietf.org" MIME-Version: 1.0 X-KeepSent: 35F47BA8:A7F20287-85257BEF:0044462F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP1 March 08, 2012 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Mon, 23 Sep 2013 08:41:58 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP3|November 15, 2012) at 09/23/2013 08:41:59, Serialize complete at 09/23/2013 08:41:59 Content-Type: multipart/alternative; boundary="=_alternative 0045C33585257BEF_=" Received-SPF: none Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 12:42:05 -0000 Message en plusieurs parties au format MIME --=_alternative 0045C33585257BEF_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > De : "Senthil Sivakumar (ssenthil)" > > [...] the sequence number don=B9t really provide any advantage than > just detecting something is missing.=20 >=20 > Senthil Hi Senthil.=20 The operational need, IMHO is exactly that: "proving that=20 something is missing" or not. You don't actually need to know what was missing, just that something was lost and ideally for how much=20 time.=20 When an operator is asked to provide CGN logs to law enforcement,=20 it may be asked to prove in court that the logs are complete for=20 the covered period. Having message numbering is one light-weight way to do this without using stateful retransmissions (TCP) or heavyweight message-signing (RFC5848). Both of these methods=20 are probably too heavy for the kind of volume CGN logging involves.=20 Now Simon will throw RFC2804 at me (again), rightfully, but I=20 thought it would be a good idea to point out the *real*=20 operational need again here. /JF --=_alternative 0045C33585257BEF_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > De : "Senthil Sivakumar (ssenthil)" <s= senthil@cisco.com>
>
> [...] the sequence number don=B9t really provide any advantage than
> just detecting something is missing.
>
> Senthil

Hi Senthil.

<op-hat on>
The operational need, IMHO is exactly that: "pr= oving that
something is missing" or not. You don't actually need to know what
was missing, just that something was lost and ideally for how much
time.

When an operator is asked to provide CGN logs to law enforcement,
it may be asked to prove in court that the logs are complete for
the covered period. Having message numbering is one light-weight
way to do this without using stateful retransmissions (TCP) or
heavyweight message-signing (RFC5848). Both of these methods
are probably too heavy for the kind of volume CGN logging involves.

Now Simon will throw RFC2804 at me (again), rightful= ly, but I
thought it would be a good idea to point out the *re= al*
operational need again here.

/JF

--=_alternative 0045C33585257BEF_=-- From repenno@cisco.com Mon Sep 23 05:53:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E533121F9ECE for ; Mon, 23 Sep 2013 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.722 X-Spam-Level: X-Spam-Status: No, score=-9.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzrQvUeoabS9 for ; Mon, 23 Sep 2013 05:53:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0E921F9EB0 for ; Mon, 23 Sep 2013 05:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7427; q=dns/txt; s=iport; t=1379940788; x=1381150388; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=YKEaNDJ9xdv+TrH9xuabxeZZ+LKwDNE6duDulo9TQTU=; b=a94ybx5ZjVSTqTHvVWtSfHIK+QmYMYGhUHVVVw+Qeuy4rrgxuzofREiE xGwA2JLR1PZ9VsxTQMt0Oa7bqOwl+fxGp6y5iEfDbBp1pm+1Pjf2x89LE 4O6fYzr0HbzGVlQun96SRu4g96sN3wdj9MDQqEzj4pIO5IFrdz/5gbVaG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAMs4QFKtJXHB/2dsb2JhbABZgkNEgQqDKb4IF4EIFnSCJQEBAQMBfg0BCBEDAQILHQUEMBQJCAIEARIIh3cGjgObSwaSG480BhoYBoJdO4EAA6lzgySCKg X-IronPort-AV: E=Sophos;i="4.90,962,1371081600"; d="scan'208,217";a="263278857" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 23 Sep 2013 12:53:01 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8NCr0iP024216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 12:53:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 07:53:00 -0500 From: "Reinaldo Penno (repenno)" To: "Jean-Francois.TremblayING@videotron.com" , "behave@ietf.org" Thread-Topic: [BEHAVE] Log sequencel numbers Thread-Index: AQHOtSXkc/+vMPQYjUKjviKG50VfzJnNbPSAgABvFICAAT1qgIAEhKkA//+NugA= Date: Mon, 23 Sep 2013 12:53:00 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B6DD35C@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.120.226] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DD35Cxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 12:53:22 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DD35Cxmbrcdx04ciscoc_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 QWdyZWUuIFRoaXMgaGFzIGJlZW4gYSByZXF1aXJlbWVudHMgZnJvbSBtYW55IElTUHMuIFdoZW4g d2UgbG9va2VkIGludG8gaXQgdGhlcmUgYXJlIHNvbWUgaXNzdWVzIHN1Y2ggYXMgdGhlIHNlcXVl bmNlIG51bWJlciArIGV2ZW50IG5lZWQgdG8gYmUgdW5pcXVlIHN1Y2ggdGhhdCBpZiB5b3UgaGF2 ZSBzZXZlcmFsIENHTnMgbG9nZ2luZyB0byB0aGUgc2FtZSBzZXJ2ZXIsIHlvdSBjYW4gdGVsbCB0 aGUgdGhlIG9uZSB0aGF0IGhhZCBsb2dzIG1pc3NpbmcgKG9yIG5vdCkuIEFzc3VtZSBoZXJlIHRo YXQgbWFueSBtb250aHMgaGF2ZSBwYXNzZWQsIGNvbmZpZ3MgaGF2ZSBjaGFuZ2VkLCBldGMuDQoN Cg0KRnJvbTogIkplYW4tRnJhbmNvaXMuVHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbTxtYWlsdG86 SmVhbi1GcmFuY29pcy5UcmVtYmxheUlOR0B2aWRlb3Ryb24uY29tPiIgPEplYW4tRnJhbmNvaXMu VHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbTxtYWlsdG86SmVhbi1GcmFuY29pcy5UcmVtYmxheUlO R0B2aWRlb3Ryb24uY29tPj4NCkRhdGU6IE1vbmRheSwgU2VwdGVtYmVyIDIzLCAyMDEzIDU6NDEg QU0NClRvOiAiYmVoYXZlQGlldGYub3JnPG1haWx0bzpiZWhhdmVAaWV0Zi5vcmc+IiA8YmVoYXZl QGlldGYub3JnPG1haWx0bzpiZWhhdmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtCRUhBVkVd IExvZyBzZXF1ZW5jZWwgbnVtYmVycw0KDQo+IERlIDogIlNlbnRoaWwgU2l2YWt1bWFyIChzc2Vu dGhpbCkiIDxzc2VudGhpbEBjaXNjby5jb208bWFpbHRvOnNzZW50aGlsQGNpc2NvLmNvbT4+DQo+ DQo+IFsuLi5dIHRoZSBzZXF1ZW5jZSBudW1iZXIgZG9uqfZ0IHJlYWxseSBwcm92aWRlIGFueSBh ZHZhbnRhZ2UgdGhhbg0KPiBqdXN0IGRldGVjdGluZyBzb21ldGhpbmcgaXMgbWlzc2luZy4NCj4N Cj4gU2VudGhpbA0KDQpIaSBTZW50aGlsLg0KDQo8b3AtaGF0IG9uPg0KVGhlIG9wZXJhdGlvbmFs IG5lZWQsIElNSE8gaXMgZXhhY3RseSB0aGF0OiAicHJvdmluZyB0aGF0DQpzb21ldGhpbmcgaXMg bWlzc2luZyIgb3Igbm90LiBZb3UgZG9uJ3QgYWN0dWFsbHkgbmVlZCB0byBrbm93IHdoYXQNCndh cyBtaXNzaW5nLCBqdXN0IHRoYXQgc29tZXRoaW5nIHdhcyBsb3N0IGFuZCBpZGVhbGx5IGZvciBo b3cgbXVjaA0KdGltZS4NCg0KV2hlbiBhbiBvcGVyYXRvciBpcyBhc2tlZCB0byBwcm92aWRlIENH TiBsb2dzIHRvIGxhdyBlbmZvcmNlbWVudCwNCml0IG1heSBiZSBhc2tlZCB0byBwcm92ZSBpbiBj b3VydCB0aGF0IHRoZSBsb2dzIGFyZSBjb21wbGV0ZSBmb3INCnRoZSBjb3ZlcmVkIHBlcmlvZC4g SGF2aW5nIG1lc3NhZ2UgbnVtYmVyaW5nIGlzIG9uZSBsaWdodC13ZWlnaHQNCndheSB0byBkbyB0 aGlzIHdpdGhvdXQgdXNpbmcgc3RhdGVmdWwgcmV0cmFuc21pc3Npb25zIChUQ1ApIG9yDQpoZWF2 eXdlaWdodCBtZXNzYWdlLXNpZ25pbmcgKFJGQzU4NDgpLiBCb3RoIG9mIHRoZXNlIG1ldGhvZHMN CmFyZSBwcm9iYWJseSB0b28gaGVhdnkgZm9yIHRoZSBraW5kIG9mIHZvbHVtZSBDR04gbG9nZ2lu ZyBpbnZvbHZlcy4NCg0KTm93IFNpbW9uIHdpbGwgdGhyb3cgUkZDMjgwNCBhdCBtZSAoYWdhaW4p LCByaWdodGZ1bGx5LCBidXQgSQ0KdGhvdWdodCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBw b2ludCBvdXQgdGhlICpyZWFsKg0Kb3BlcmF0aW9uYWwgbmVlZCBhZ2FpbiBoZXJlLg0KDQovSkYN Cg0K --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DD35Cxmbrcdx04ciscoc_ Content-Type: text/html; charset="euc-kr" Content-ID: <7C1718B0DE3F5D4DA63EC02A2CC01604@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PkFncmVlLiBU aGlzIGhhcyBiZWVuIGEgcmVxdWlyZW1lbnRzIGZyb20gbWFueSBJU1BzLiBXaGVuIHdlIGxvb2tl ZCBpbnRvIGl0IHRoZXJlIGFyZSBzb21lIGlzc3VlcyBzdWNoIGFzIHRoZSBzZXF1ZW5jZSBudW1i ZXIgJiM0MzsgZXZlbnQgbmVlZCB0byBiZSB1bmlxdWUgc3VjaCB0aGF0IGlmIHlvdSBoYXZlIHNl dmVyYWwgQ0dOcyBsb2dnaW5nIHRvIHRoZSBzYW1lIHNlcnZlciwgeW91IGNhbiB0ZWxsIHRoZSB0 aGUgb25lIHRoYXQgaGFkIGxvZ3MNCiBtaXNzaW5nIChvciBub3QpLiBBc3N1bWUgaGVyZSB0aGF0 IG1hbnkgbW9udGhzIGhhdmUgcGFzc2VkLCBjb25maWdzIGhhdmUgY2hhbmdlZCwgZXRjLjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1z aXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1l ZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47 IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0 ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOkplYW4tRnJhbmNvaXMuVHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbSI+SmVh bi1GcmFuY29pcy5UcmVtYmxheUlOR0B2aWRlb3Ryb24uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkplYW4tRnJhbmNvaXMuVHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbSI+SmVhbi1G cmFuY29pcy5UcmVtYmxheUlOR0B2aWRlb3Ryb24uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgU2VwdGVtYmVyIDIzLCAy MDEzIDU6NDEgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj4mcXVvdDs8YSBocmVmPSJtYWlsdG86YmVoYXZlQGlldGYub3JnIj5iZWhhdmVAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmVoYXZlQGlldGYub3JnIj5iZWhhdmVAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 OiA8L3NwYW4+UmU6IFtCRUhBVkVdIExvZyBzZXF1ZW5jZWwgbnVtYmVyczxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IERl IDogJnF1b3Q7U2VudGhpbCBTaXZha3VtYXIgKHNzZW50aGlsKSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNzZW50aGlsQGNpc2NvLmNvbSI+c3NlbnRoaWxAY2lzY28uY29tPC9hPiZndDs8L2Zv bnQ+PC90dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+Jmd0Ozxicj4NCiZndDsgWy4uLl0gdGhl IHNlcXVlbmNlIG51bWJlciBkb26p9nQgcmVhbGx5IHByb3ZpZGUgYW55IGFkdmFudGFnZSB0aGFu PGJyPg0KJmd0OyBqdXN0IGRldGVjdGluZyBzb21ldGhpbmcgaXMgbWlzc2luZy4gPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFNlbnRoaWw8YnI+DQo8YnI+DQpIaSBTZW50aGlsLiA8L2ZvbnQ+PC90dD48 YnI+DQo8YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+Jmx0O29wLWhhdCBvbiZndDs8L2ZvbnQ+PC90 dD4gPGJyPg0KPHR0Pjxmb250IHNpemU9IjIiPlRoZSBvcGVyYXRpb25hbCBuZWVkLCBJTUhPIGlz IGV4YWN0bHkgdGhhdDogJnF1b3Q7cHJvdmluZyB0aGF0IDwvZm9udD4NCjwvdHQ+PGJyPg0KPHR0 Pjxmb250IHNpemU9IjIiPnNvbWV0aGluZyBpcyBtaXNzaW5nJnF1b3Q7IG9yIG5vdC4gWW91IGRv bid0IGFjdHVhbGx5IG5lZWQgdG8ga25vdyB3aGF0PC9mb250PjwvdHQ+PGJyPg0KPHR0Pjxmb250 IHNpemU9IjIiPndhcyBtaXNzaW5nLCBqdXN0IHRoYXQgc29tZXRoaW5nIHdhcyBsb3N0IGFuZCBp ZGVhbGx5IGZvciBob3cgbXVjaA0KPC9mb250PjwvdHQ+PGJyPg0KPHR0Pjxmb250IHNpemU9IjIi PnRpbWUuIDwvZm9udD48L3R0Pjxicj4NCjxicj4NCjx0dD48Zm9udCBzaXplPSIyIj5XaGVuIGFu IG9wZXJhdG9yIGlzIGFza2VkIHRvIHByb3ZpZGUgQ0dOIGxvZ3MgdG8gbGF3IGVuZm9yY2VtZW50 LA0KPC9mb250PjwvdHQ+PGJyPg0KPHR0Pjxmb250IHNpemU9IjIiPml0IG1heSBiZSBhc2tlZCB0 byBwcm92ZSBpbiBjb3VydCB0aGF0IHRoZSBsb2dzIGFyZSBjb21wbGV0ZSBmb3INCjwvZm9udD48 L3R0Pjxicj4NCjx0dD48Zm9udCBzaXplPSIyIj50aGUgY292ZXJlZCBwZXJpb2QuIEhhdmluZyBt ZXNzYWdlIG51bWJlcmluZyBpcyBvbmUgbGlnaHQtd2VpZ2h0PC9mb250PjwvdHQ+PGJyPg0KPHR0 Pjxmb250IHNpemU9IjIiPndheSB0byBkbyB0aGlzIHdpdGhvdXQgdXNpbmcgc3RhdGVmdWwgcmV0 cmFuc21pc3Npb25zIChUQ1ApIG9yPC9mb250PjwvdHQ+PGJyPg0KPHR0Pjxmb250IHNpemU9IjIi PmhlYXZ5d2VpZ2h0IG1lc3NhZ2Utc2lnbmluZyAoUkZDNTg0OCkuIEJvdGggb2YgdGhlc2UgbWV0 aG9kcyA8L2ZvbnQ+DQo8L3R0Pjxicj4NCjx0dD48Zm9udCBzaXplPSIyIj5hcmUgcHJvYmFibHkg dG9vIGhlYXZ5IGZvciB0aGUga2luZCBvZiB2b2x1bWUgQ0dOIGxvZ2dpbmcgaW52b2x2ZXMuDQo8 L2ZvbnQ+PC90dD48YnI+DQo8YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+Tm93IFNpbW9uIHdpbGwg dGhyb3cgUkZDMjgwNCBhdCBtZSAoYWdhaW4pLCByaWdodGZ1bGx5LCBidXQgSSA8L2ZvbnQ+DQo8 L3R0Pjxicj4NCjx0dD48Zm9udCBzaXplPSIyIj50aG91Z2h0IGl0IHdvdWxkIGJlIGEgZ29vZCBp ZGVhIHRvIHBvaW50IG91dCB0aGUgKnJlYWwqIDwvZm9udD4NCjwvdHQ+PGJyPg0KPHR0Pjxmb250 IHNpemU9IjIiPm9wZXJhdGlvbmFsIG5lZWQgYWdhaW4gaGVyZS48L2ZvbnQ+PC90dD4gPGJyPg0K PGJyPg0KPHR0Pjxmb250IHNpemU9IjIiPi9KRjwvZm9udD48L3R0PiA8YnI+DQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_45A697A8FFD7CF48BCF2BE7E106F06040B6DD35Cxmbrcdx04ciscoc_-- From simon.perreault@viagenie.ca Mon Sep 23 06:09:19 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91121F9F88 for ; Mon, 23 Sep 2013 06:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQOkUnN3+M4Q for ; Mon, 23 Sep 2013 06:09:18 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9D21F9EB0 for ; Mon, 23 Sep 2013 06:09:18 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:e01a:be8d:b906:c8cd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EDAAE403E0 for ; Mon, 23 Sep 2013 09:09:17 -0400 (EDT) Message-ID: <52403D7D.7010702@viagenie.ca> Date: Mon, 23 Sep 2013 15:09:17 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: behave@ietf.org References: <523B628B.7050401@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 13:09:19 -0000 Le 2013-09-23 14:41, Jean-Francois.TremblayING@videotron.com a écrit : > When an operator is asked to provide CGN logs to law enforcement, > it may be asked to prove in court that the logs are complete for > the covered period. Having message numbering is one light-weight > way to do this without using stateful retransmissions (TCP) or > heavyweight message-signing (RFC5848). Both of these methods > are probably too heavy for the kind of volume CGN logging involves. > > Now Simon will throw RFC2804 at me (again), rightfully, but I > thought it would be a good idea to point out the *real* > operational need again here. /me throws RFC2804 at JFT ;) IMHO, "we need to know that nothing is missing" is a valid technical reason. The "...for law enforcement" part is what's invalid. There may be reasons other than law enforcement why you might want to know that nothing is missing. Handling abuse requests comes to mind. Another idea: syslog over SCTP with partial reliability [RFC3758]. (almost not joking) Simon From ietfdbh@comcast.net Mon Sep 23 09:59:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF48021F9E89 for ; Mon, 23 Sep 2013 09:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.969 X-Spam-Level: X-Spam-Status: No, score=-98.969 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhXBLzKo97mA for ; Mon, 23 Sep 2013 09:59:41 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id DB55821F9E4D for ; Mon, 23 Sep 2013 09:59:40 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA11.westchester.pa.mail.comcast.net with comcast id UcjN1m0060Fqzac5BgzgKG; Mon, 23 Sep 2013 16:59:40 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id Ugzg1m0022yZEBF3UgzgGF; Mon, 23 Sep 2013 16:59:40 +0000 From: "ietfdbh" To: "'Simon Perreault'" , References: <523B628B.7050401@gmail.com> <52403D7D.7010702@viagenie.ca> In-Reply-To: <52403D7D.7010702@viagenie.ca> Date: Mon, 23 Sep 2013 12:59:40 -0400 Message-ID: <049001ceb87e$4b4d24a0$e1e76de0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKPg9X00+ir/9yEsHBzH9HT/i1ZNwFGf8aiARIBa3IBdTxIXpgzbEJg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379955580; bh=IoBtrIEwwLCyNZ6TxbNbOUJjE9ExCzahRHA9t4XtNMc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=fmb06YXvDEH8Ya4/QDe2Jz+Zq2FVHf9KfnZKknDmp4eJOKFy+SGwW7YBt5jAKuDTv IqPEr9XnNePpcsGBC9ckySyT5hfm2BpMtYtxUCxgM1LnN2GcrGt2JzL8zh5orFwSb6 oGje8bGYH8gVWPDwarj+h6ChEz2Oj+RxV3jXd1M6lfBFSzhTsFni+hoqHk5EHkwuc2 PjBt8zpf7fBi/A5GlcKJTRO1vHDSM/pxM9mclYnAbIKTVgBsH0RjBw50MF4NMrbak4 r+6wH1eTphDOlo6k289+FPC67fCFUL+PLcAecAJZQRg0+xug0lZ0AWdlJoUS+Oet56 bhKD7pxCK21uA== Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 16:59:45 -0000 Hi Simon, You have thrown in RFC2804, an Informational RFC about IETF policy on wiretapping. You apparently have argued that "for law enforcement" is invalid because = it violates the IETF policy on wiretapping. I think that "law enforcement" and "wiretapping" are not the same thing. = I'm not sure that saying "law enforcement" violates rfc2804. But that gets into semantics a lot ... So, let me rephrase JF's use case to satisfy your concerns ... "When an operator is asked to provide CGN logs, it may be asked to = prove that the logs are complete for the covered period." You might want to add some discussion of use cases, and their = operational and security requirements: "For some anticipated use cases, such as law enforcement, the proof = might be held to a "strong security" standard, such as proof that would be able = to stand up in a court of law that the logs are complete and have not been tampered with.=20 For other use cases, such as a service provider handling an abuse = request, less robustness might be sufficient, but if an accused user takes the provider to court, the service provider might need proof that meets a = strong security standard that the logs are complete and have not been altered. For some use cases, even less robustness might be sufficient, such as = the use case of a CEO wanting a statement of assurance from the IT = department that relevant logs are not missing or modified, before they sign off on = a Sarbanes-Oxley statement, but if an investor sues the company for = providing misleading information, strong security might be required to support the claim of completeness and integrity. In a common use case - an operator utilizing the logs to debug network problems- the security can probably be fairly lax or not enabled at = all." I recommend the completeness and integrity requirements of such use = cases should be spelled out in more detail. The only mention of integrity in the syslog-nat-logging doc is in the security considerations section, which says " When logs are being recorded for regulatory reasons, preservation of their integrity and authentication of their origin is essential." For something so essential, I would expect a bit more discussion of the types of use cases, why integrity and authentication are essential, and = more detail on the relevant **technical** requirements of an integrity and/or authentication solution. Is integrity and authentication really essential only for "regulatory" = use cases?=20 Is integrity and authentication really important, if not essential, for = some non-regulatory use cases? How about when handling an abuse case?=20 How about detecting an intruder attack? How about protecting a user's privacy, given archived logs of = information such as subscriber site, hostname, devID, etc.? What security requirements should be met for logs "in transit" and "at rest"? These questions apply not only to syslog, of course. The security requirements might apply to any logging mechanism. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Monday, September 23, 2013 9:09 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] Log sequencel numbers >=20 > Le 2013-09-23 14:41, Jean-Francois.TremblayING@videotron.com a =E9crit = : > > When an operator is asked to provide CGN logs to law enforcement, > > it may be asked to prove in court that the logs are complete for > > the covered period. Having message numbering is one light-weight > > way to do this without using stateful retransmissions (TCP) or > > heavyweight message-signing (RFC5848). Both of these methods > > are probably too heavy for the kind of volume CGN logging involves. > > > > Now Simon will throw RFC2804 at me (again), rightfully, but I > > thought it would be a good idea to point out the *real* > > operational need again here. >=20 > /me throws RFC2804 at JFT ;) >=20 > IMHO, "we need to know that nothing is missing" is a valid technical > reason. The "...for law enforcement" part is what's invalid. >=20 > There may be reasons other than law enforcement why you might want to > know that nothing is missing. Handling abuse requests comes to mind. >=20 > Another idea: syslog over SCTP with partial reliability [RFC3758]. > (almost not joking) >=20 > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Mon Sep 23 12:36:06 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B412C21F9DFC for ; Mon, 23 Sep 2013 12:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.722 X-Spam-Level: X-Spam-Status: No, score=-9.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtjBxVVwqIBy for ; Mon, 23 Sep 2013 12:36:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ADD8321F9E1D for ; Mon, 23 Sep 2013 12:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9833; q=dns/txt; s=iport; t=1379964960; x=1381174560; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=6G9hk0c19XvKLZP2Sf3vwIDp0K7anhZocaH/1UuDqI4=; b=iA3e43ZgCTF2L2aUala1jqN7exGULgmUm2WIQjcG2byD6ZiuKwmOChCr CQKFcxDj8jHnH5cWek9ASjZZjpE/5DTMOkKYGXieB5/toPY9aMUEl2rBj H6KZBJjU9TWKOOassbJXWG5x+HzQb4UWcKsvZcO3xzZcFsKCY7Mk8LRSs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAHyXQFKtJXG+/2dsb2JhbABPCoJDRIEKgym+ABeBDBZ0giUBAQEDAX4NAQgRAwECCx0FBDAUCQgCBAESCId3Bo4Fm0sGkjiOIoESBhoYBoJdO4EAA6lzgySCKg X-IronPort-AV: E=Sophos;i="4.90,964,1371081600"; d="scan'208,217";a="263447928" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 23 Sep 2013 19:35:58 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8NJZwl9018084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 19:35:58 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.246]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 14:35:57 -0500 From: "Senthil Sivakumar (ssenthil)" To: "Jean-Francois.TremblayING@videotron.com" , "behave@ietf.org" Thread-Topic: [BEHAVE] Log sequencel numbers Thread-Index: AQHOtSXkc/+vMPQYjUKjviKG50VfzJnNbPSAgABvFICAAT1qgIAEhKkAgAAwmoA= Date: Mon, 23 Sep 2013 19:35:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [64.102.83.140] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D02363C8DD3xmbrcdx15ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 19:36:06 -0000 --_000_CB1B483277FEC94E9B58357040EE5D02363C8DD3xmbrcdx15ciscoc_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 UkZDIDcwMTEsIG9ic29sZXRpbmcgcmZjIDUxMDEsIElQRklYIGhlYWRlciBoYXMgdGhpcyBmaWVs ZA0KDQpTZXF1ZW5jZSBOdW1iZXINCg0KICAgICAgSW5jcmVtZW50YWwgc2VxdWVuY2UgY291bnRl ciBtb2R1bG8gMl4zMiBvZiBhbGwgSVBGSVggRGF0YSBSZWNvcmRzDQogICAgICBzZW50IGluIHRo ZSBjdXJyZW50IHN0cmVhbSBmcm9tIHRoZSBjdXJyZW50IE9ic2VydmF0aW9uIERvbWFpbiBieQ0K ICAgICAgdGhlIEV4cG9ydGluZyBQcm9jZXNzLiAgRWFjaCBTQ1RQIFN0cmVhbSBjb3VudHMgc2Vx dWVuY2UgbnVtYmVycw0KICAgICAgc2VwYXJhdGVseSwgd2hpbGUgYWxsIG1lc3NhZ2VzIGluIGEg VENQIGNvbm5lY3Rpb24gb3IgVURQIHNlc3Npb24NCiAgICAgIGFyZSBjb25zaWRlcmVkIHRvIGJl IHBhcnQgb2YgdGhlIHNhbWUgc3RyZWFtLiAgVGhpcyB2YWx1ZSBjYW4gYmUNCiAgICAgIHVzZWQg YnkgdGhlIENvbGxlY3RpbmcgUHJvY2VzcyB0byBpZGVudGlmeSB3aGV0aGVyIGFueSBJUEZJWCBE YXRhDQogICAgICBSZWNvcmRzIGhhdmUgYmVlbiBtaXNzZWQuICBUZW1wbGF0ZSBhbmQgT3B0aW9u cyBUZW1wbGF0ZSBSZWNvcmRzDQogICAgICBkbyBub3QgaW5jcmVhc2UgdGhlIFNlcXVlbmNlIE51 bWJlci4NCg0KDQoNCldvdWxkbqGvdCB0aGF0IHN1ZmZpY2U/DQoNCg0KVGhhbmtzDQoNClNlbnRo aWwNCg0KRnJvbTogIkplYW4tRnJhbmNvaXMuVHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbTxtYWls dG86SmVhbi1GcmFuY29pcy5UcmVtYmxheUlOR0B2aWRlb3Ryb24uY29tPiIgPEplYW4tRnJhbmNv aXMuVHJlbWJsYXlJTkdAdmlkZW90cm9uLmNvbTxtYWlsdG86SmVhbi1GcmFuY29pcy5UcmVtYmxh eUlOR0B2aWRlb3Ryb24uY29tPj4NCkRhdGU6IE1vbmRheSwgU2VwdGVtYmVyIDIzLCAyMDEzIDg6 NDEgQU0NClRvOiAiYmVoYXZlQGlldGYub3JnPG1haWx0bzpiZWhhdmVAaWV0Zi5vcmc+IiA8YmVo YXZlQGlldGYub3JnPG1haWx0bzpiZWhhdmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtCRUhB VkVdIExvZyBzZXF1ZW5jZWwgbnVtYmVycw0KDQo+IERlIDogIlNlbnRoaWwgU2l2YWt1bWFyIChz c2VudGhpbCkiIDxzc2VudGhpbEBjaXNjby5jb208bWFpbHRvOnNzZW50aGlsQGNpc2NvLmNvbT4+ DQo+DQo+IFsuLi5dIHRoZSBzZXF1ZW5jZSBudW1iZXIgZG9uqfZ0IHJlYWxseSBwcm92aWRlIGFu eSBhZHZhbnRhZ2UgdGhhbg0KPiBqdXN0IGRldGVjdGluZyBzb21ldGhpbmcgaXMgbWlzc2luZy4N Cj4NCj4gU2VudGhpbA0KDQpIaSBTZW50aGlsLg0KDQo8b3AtaGF0IG9uPg0KVGhlIG9wZXJhdGlv bmFsIG5lZWQsIElNSE8gaXMgZXhhY3RseSB0aGF0OiAicHJvdmluZyB0aGF0DQpzb21ldGhpbmcg aXMgbWlzc2luZyIgb3Igbm90LiBZb3UgZG9uJ3QgYWN0dWFsbHkgbmVlZCB0byBrbm93IHdoYXQN CndhcyBtaXNzaW5nLCBqdXN0IHRoYXQgc29tZXRoaW5nIHdhcyBsb3N0IGFuZCBpZGVhbGx5IGZv ciBob3cgbXVjaA0KdGltZS4NCg0KV2hlbiBhbiBvcGVyYXRvciBpcyBhc2tlZCB0byBwcm92aWRl IENHTiBsb2dzIHRvIGxhdyBlbmZvcmNlbWVudCwNCml0IG1heSBiZSBhc2tlZCB0byBwcm92ZSBp biBjb3VydCB0aGF0IHRoZSBsb2dzIGFyZSBjb21wbGV0ZSBmb3INCnRoZSBjb3ZlcmVkIHBlcmlv ZC4gSGF2aW5nIG1lc3NhZ2UgbnVtYmVyaW5nIGlzIG9uZSBsaWdodC13ZWlnaHQNCndheSB0byBk byB0aGlzIHdpdGhvdXQgdXNpbmcgc3RhdGVmdWwgcmV0cmFuc21pc3Npb25zIChUQ1ApIG9yDQpo ZWF2eXdlaWdodCBtZXNzYWdlLXNpZ25pbmcgKFJGQzU4NDgpLiBCb3RoIG9mIHRoZXNlIG1ldGhv ZHMNCmFyZSBwcm9iYWJseSB0b28gaGVhdnkgZm9yIHRoZSBraW5kIG9mIHZvbHVtZSBDR04gbG9n Z2luZyBpbnZvbHZlcy4NCg0KTm93IFNpbW9uIHdpbGwgdGhyb3cgUkZDMjgwNCBhdCBtZSAoYWdh aW4pLCByaWdodGZ1bGx5LCBidXQgSQ0KdGhvdWdodCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0 byBwb2ludCBvdXQgdGhlICpyZWFsKg0Kb3BlcmF0aW9uYWwgbmVlZCBhZ2FpbiBoZXJlLg0KDQov SkYNCg0K --_000_CB1B483277FEC94E9B58357040EE5D02363C8DD3xmbrcdx15ciscoc_ Content-Type: text/html; charset="euc-kr" Content-ID: <9E9C69BACA1F1940A4D2D0B04E84830F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyAi PlJGQyA3MDExLCBvYnNvbGV0aW5nIHJmYyA1MTAxLCBJUEZJWCBoZWFkZXIgaGFzIHRoaXMgZmll bGQmbmJzcDs8L2Rpdj4NCjxkaXY+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1z aXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFr LWJlZm9yZTogYWx3YXlzOyAiPlNlcXVlbmNlIE51bWJlcg0KDQogICAgICBJbmNyZW1lbnRhbCBz ZXF1ZW5jZSBjb3VudGVyIG1vZHVsbyAyXjMyIG9mIGFsbCBJUEZJWCBEYXRhIFJlY29yZHMNCiAg ICAgIHNlbnQgaW4gdGhlIGN1cnJlbnQgc3RyZWFtIGZyb20gdGhlIGN1cnJlbnQgT2JzZXJ2YXRp b24gRG9tYWluIGJ5DQogICAgICB0aGUgRXhwb3J0aW5nIFByb2Nlc3MuICBFYWNoIFNDVFAgU3Ry ZWFtIGNvdW50cyBzZXF1ZW5jZSBudW1iZXJzDQogICAgICBzZXBhcmF0ZWx5LCB3aGlsZSBhbGwg bWVzc2FnZXMgaW4gYSBUQ1AgY29ubmVjdGlvbiBvciBVRFAgc2Vzc2lvbg0KICAgICAgYXJlIGNv bnNpZGVyZWQgdG8gYmUgcGFydCBvZiB0aGUgc2FtZSBzdHJlYW0uICBUaGlzIHZhbHVlIGNhbiBi ZQ0KICAgICAgdXNlZCBieSB0aGUgQ29sbGVjdGluZyBQcm9jZXNzIHRvIGlkZW50aWZ5IDxmb250 IGNvbG9yPSIjZmYwMDAwIj53aGV0aGVyIGFueSBJUEZJWCBEYXRhPC9mb250Pg0KICAgICAgPGZv bnQgY29sb3I9IiNmZjAwMDAiPlJlY29yZHMgaGF2ZSBiZWVuIG1pc3NlZDwvZm9udD4uICBUZW1w bGF0ZSBhbmQgT3B0aW9ucyBUZW1wbGF0ZSBSZWNvcmRzDQogICAgICBkbyBub3QgaW5jcmVhc2Ug dGhlIFNlcXVlbmNlIE51bWJlci48L3ByZT4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBhbHdheXM7ICI+PGJyPjwvcHJlPg0K PHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6 ZTogMWVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1i ZWZvcmU6IGFsd2F5czsgIj48YnI+PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPldvdWxkbqGvdCB0 aGF0IHN1ZmZpY2U/PC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRv bTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPjxicj48L3ByZT4NCjxwcmUgY2xh c3M9Im5ld3BhZ2UiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDFlbTsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBh bHdheXM7ICI+VGhhbmtzPC9wcmU+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPlNlbnRoaWw8L3ByZT4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgIj48YnI+DQo8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 ICI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4 dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 SmVhbi1GcmFuY29pcy5UcmVtYmxheUlOR0B2aWRlb3Ryb24uY29tIj5KZWFuLUZyYW5jb2lzLlRy ZW1ibGF5SU5HQHZpZGVvdHJvbi5jb208L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86SmVh bi1GcmFuY29pcy5UcmVtYmxheUlOR0B2aWRlb3Ryb24uY29tIj5KZWFuLUZyYW5jb2lzLlRyZW1i bGF5SU5HQHZpZGVvdHJvbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBTZXB0ZW1iZXIgMjMsIDIwMTMgODo0MSBBTTxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpiZWhhdmVAaWV0Zi5vcmciPmJlaGF2ZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpiZWhhdmVAaWV0Zi5vcmciPmJlaGF2ZUBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTog W0JFSEFWRV0gTG9nIHNlcXVlbmNlbCBudW1iZXJzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+PHR0Pjxmb250IHNpemU9IjIiPiZndDsgRGUgOiAmcXVvdDtTZW50 aGlsIFNpdmFrdW1hciAoc3NlbnRoaWwpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3NlbnRo aWxAY2lzY28uY29tIj5zc2VudGhpbEBjaXNjby5jb208L2E+Jmd0OzwvZm9udD48L3R0Pjxicj4N Cjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7PGJyPg0KJmd0OyBbLi4uXSB0aGUgc2VxdWVuY2UgbnVt YmVyIGRvbqn2dCByZWFsbHkgcHJvdmlkZSBhbnkgYWR2YW50YWdlIHRoYW48YnI+DQomZ3Q7IGp1 c3QgZGV0ZWN0aW5nIHNvbWV0aGluZyBpcyBtaXNzaW5nLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg U2VudGhpbDxicj4NCjxicj4NCkhpIFNlbnRoaWwuIDwvZm9udD48L3R0Pjxicj4NCjxicj4NCjx0 dD48Zm9udCBzaXplPSIyIj4mbHQ7b3AtaGF0IG9uJmd0OzwvZm9udD48L3R0PiA8YnI+DQo8dHQ+ PGZvbnQgc2l6ZT0iMiI+VGhlIG9wZXJhdGlvbmFsIG5lZWQsIElNSE8gaXMgZXhhY3RseSB0aGF0 OiAmcXVvdDtwcm92aW5nIHRoYXQgPC9mb250Pg0KPC90dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0i MiI+c29tZXRoaW5nIGlzIG1pc3NpbmcmcXVvdDsgb3Igbm90LiBZb3UgZG9uJ3QgYWN0dWFsbHkg bmVlZCB0byBrbm93IHdoYXQ8L2ZvbnQ+PC90dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+d2Fz IG1pc3NpbmcsIGp1c3QgdGhhdCBzb21ldGhpbmcgd2FzIGxvc3QgYW5kIGlkZWFsbHkgZm9yIGhv dyBtdWNoDQo8L2ZvbnQ+PC90dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+dGltZS4gPC9mb250 PjwvdHQ+PGJyPg0KPGJyPg0KPHR0Pjxmb250IHNpemU9IjIiPldoZW4gYW4gb3BlcmF0b3IgaXMg YXNrZWQgdG8gcHJvdmlkZSBDR04gbG9ncyB0byBsYXcgZW5mb3JjZW1lbnQsDQo8L2ZvbnQ+PC90 dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+aXQgbWF5IGJlIGFza2VkIHRvIHByb3ZlIGluIGNv dXJ0IHRoYXQgdGhlIGxvZ3MgYXJlIGNvbXBsZXRlIGZvcg0KPC9mb250PjwvdHQ+PGJyPg0KPHR0 Pjxmb250IHNpemU9IjIiPnRoZSBjb3ZlcmVkIHBlcmlvZC4gSGF2aW5nIG1lc3NhZ2UgbnVtYmVy aW5nIGlzIG9uZSBsaWdodC13ZWlnaHQ8L2ZvbnQ+PC90dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0i MiI+d2F5IHRvIGRvIHRoaXMgd2l0aG91dCB1c2luZyBzdGF0ZWZ1bCByZXRyYW5zbWlzc2lvbnMg KFRDUCkgb3I8L2ZvbnQ+PC90dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+aGVhdnl3ZWlnaHQg bWVzc2FnZS1zaWduaW5nIChSRkM1ODQ4KS4gQm90aCBvZiB0aGVzZSBtZXRob2RzIDwvZm9udD4N CjwvdHQ+PGJyPg0KPHR0Pjxmb250IHNpemU9IjIiPmFyZSBwcm9iYWJseSB0b28gaGVhdnkgZm9y IHRoZSBraW5kIG9mIHZvbHVtZSBDR04gbG9nZ2luZyBpbnZvbHZlcy4NCjwvZm9udD48L3R0Pjxi cj4NCjxicj4NCjx0dD48Zm9udCBzaXplPSIyIj5Ob3cgU2ltb24gd2lsbCB0aHJvdyBSRkMyODA0 IGF0IG1lIChhZ2FpbiksIHJpZ2h0ZnVsbHksIGJ1dCBJIDwvZm9udD4NCjwvdHQ+PGJyPg0KPHR0 Pjxmb250IHNpemU9IjIiPnRob3VnaHQgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gcG9pbnQg b3V0IHRoZSAqcmVhbCogPC9mb250Pg0KPC90dD48YnI+DQo8dHQ+PGZvbnQgc2l6ZT0iMiI+b3Bl cmF0aW9uYWwgbmVlZCBhZ2FpbiBoZXJlLjwvZm9udD48L3R0PiA8YnI+DQo8YnI+DQo8dHQ+PGZv bnQgc2l6ZT0iMiI+L0pGPC9mb250PjwvdHQ+IDxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CB1B483277FEC94E9B58357040EE5D02363C8DD3xmbrcdx15ciscoc_-- From Jean-Francois.TremblayING@videotron.com Mon Sep 23 18:54:38 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985F921F9E8B for ; Mon, 23 Sep 2013 18:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbndrnDyXooE for ; Mon, 23 Sep 2013 18:54:33 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 6A73721F9CC6 for ; Mon, 23 Sep 2013 18:54:33 -0700 (PDT) In-Reply-To: References: To: "behave@ietf.org" MIME-Version: 1.0 X-KeepSent: C5919C83:06C3FB73-85257BF0:00080347; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP1 March 08, 2012 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Mon, 23 Sep 2013 21:54:31 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP3|November 15, 2012) at 09/23/2013 21:54:32, Serialize complete at 09/23/2013 21:54:32 Content-Type: multipart/alternative; boundary="=_alternative 000A7C4185257BF0_=" Received-SPF: none Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 01:54:38 -0000 Message en plusieurs parties au format MIME --=_alternative 000A7C4185257BF0_= Content-Type: text/plain; charset="ISO-2022-KR" $)C > RFC 7011, obsoleting rfc 5101, IPFIX header has this field > Sequence Number > > Incremental sequence counter modulo 2^32 of all IPFIX Data Records > sent in the current stream from the current Observation Domain by > the Exporting Process. Each SCTP Stream counts sequence numbers > separately, while all messages in a TCP connection or UDP session > are considered to be part of the same stream. This value can be > used by the Collecting Process to identify whether any IPFIX Data > Records have been missed. Template and Options Template Records > do not increase the Sequence Number. > > Wouldn!/t that suffice? > > Thanks > Senthil This seems to answer Tom's original point about IPFIX. To Tom's defense, that document is a week old, it was published on the 15th, three days before the point was raised. I guess he can be excused for not reading it within that timeframe. This text seems to fit the requirement for IPFIX. As long as any gap in continuity can be detected it should be fine. The point is still open for syslog though. Having such a sequence number in syslog messages would be useful. /JF --=_alternative 000A7C4185257BF0_= Content-Type: text/html; charset="ISO-2022-KR" $)C 
> RFC 7011, obsoleting rfc 5101, IPFIX header has this field
> Sequence Number
>
>       Incremental sequence counter modulo 2^32 of all IPFIX Data Records
>       sent in the current stream from the current Observation Domain by
>       the Exporting Process.  Each SCTP Stream counts sequence numbers
>       separately, while all messages in a TCP connection or UDP session
>       are considered to be part of the same stream.  This value can be
>       used by the Collecting Process to identify whether any IPFIX Data
>       Records have been missed.  Template and Options Template Records
>       do not increase the Sequence Number.
>
> Wouldn!/t that suffice?
>
> Thanks
> Senthil

This seems to answer Tom's original point about IPFIX. To Tom's
defense, that document is a week old, it was published on the 15th,
three days before the point was raised. I guess he can be excused
for not reading it within that timeframe.

This text seems to fit the requirement for IPFIX. As long as any gap
in continuity can be detected it should be fine. The point is still
open for syslog though. Having such a sequence number in syslog
messages would be useful.

/JF
 
--=_alternative 000A7C4185257BF0_=-- From andy.donati@comcast.net Mon Sep 23 20:13:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA6621F9D92 for ; Mon, 23 Sep 2013 20:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.959 X-Spam-Level: X-Spam-Status: No, score=0.959 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K27I63LRmJtL for ; Mon, 23 Sep 2013 20:13:16 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 3941621F9D65 for ; Mon, 23 Sep 2013 20:13:16 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta15.westchester.pa.mail.comcast.net with comcast id Uqun1m0020SCNGk5FrDFq6; Tue, 24 Sep 2013 03:13:15 +0000 Received: from [192.168.1.3] ([24.218.118.50]) by omta09.westchester.pa.mail.comcast.net with comcast id UrD71m00D15KgXL3VrD8R9; Tue, 24 Sep 2013 03:13:15 +0000 References: <523CFA2B.6060001@gmail.com> <52400A81.3090608@viagenie.ca> <20130923095459.GA14842@elstar.local> <52401183.1040406@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <52401183.1040406@viagenie.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11A465) From: Andrew Donati Date: Mon, 23 Sep 2013 23:13:03 -0400 To: Simon Perreault DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379992395; bh=6I0kJHc2JT7ioGfoE5RHda0s11g7WSXpfYLMs81nYQg=; h=Received:Received:Mime-Version:Content-Type:Message-Id:From: Subject:Date:To; b=ZVmBDvOEnbYQSL6C4FSBQ25rYVtStn7z7tQfHyVXbkkx4J7eUCJVLmJ8cUMJa5tCC d6yAQiWhxlw7T18dtQJyIpi/XtNlroFhWLLwxvq05I0f0df9lxCS2qBL9zy4E1OTmL lyYdKT99U5mx3lQ1vCq6Gun0/U6zdE2LBanO3MvsOekr9uEAP5EJf90HJ0ECfgI1q4 tRP7peWD/ESKpcinqNDpFGt+0pr2geIcI6YZlcfl06ourhcWlgt8bYVUfXSq3ZZxYL Hm80KI/IWMjYsxYNQrYdlaYoxIVxhRpo+ymspuFBS8zm56vShvM/mwoJ1eibQ5NGaT iih+CvMn68Uzw== Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:13:21 -0000 Some operators have alluded to using performance history tables. -Andy=20 > On Sep 23, 2013, at 6:01 AM, Simon Perreault = wrote: >=20 > Le 2013-09-23 11:54, Juergen Schoenwaelder a =C3=A9crit : >> A slightly different question: How fast do these numbers change? Is >> reporting a snaphost really useful here? >=20 > On a big NAT with large pools, I would expect the numbers to oscillate > with a 24-hour period. When graphed, they would look similar to total > bandwidth graphs. I think both objects can be very useful and are > definitely needed. >=20 > (An aside: on a busy node, byte counters change *very* often. The point > of providing a snapshot is to make graphs and such. The exact value at a > precise moment is not what's interesting. It's the trend.) >=20 > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From j.schoenwaelder@jacobs-university.de Mon Sep 23 21:44:53 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A4611E80C5 for ; Mon, 23 Sep 2013 21:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.144 X-Spam-Level: X-Spam-Status: No, score=-103.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ACF3HaDm4Aj for ; Mon, 23 Sep 2013 21:44:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 25BBE11E80A2 for ; Mon, 23 Sep 2013 21:44:31 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D995F20C15; Tue, 24 Sep 2013 06:44:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ijag5Ei3g8mr; Tue, 24 Sep 2013 06:44:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4ADBF20C0F; Tue, 24 Sep 2013 06:44:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 884E12886CE0; Tue, 24 Sep 2013 06:44:25 +0200 (CEST) Date: Tue, 24 Sep 2013 06:44:25 +0200 From: Juergen Schoenwaelder To: Simon Perreault Message-ID: <20130924044425.GB17131@elstar.local> Mail-Followup-To: Simon Perreault , Tom Taylor , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" References: <523CFA2B.6060001@gmail.com> <52400A81.3090608@viagenie.ca> <20130923095459.GA14842@elstar.local> <52401183.1040406@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52401183.1040406@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 04:44:53 -0000 On Mon, Sep 23, 2013 at 12:01:39PM +0200, Simon Perreault wrote: > Le 2013-09-23 11:54, Juergen Schoenwaelder a écrit : > > A slightly different question: How fast do these numbers change? Is > > reporting a snaphost really useful here? > > On a big NAT with large pools, I would expect the numbers to oscillate > with a 24-hour period. When graphed, they would look similar to total > bandwidth graphs. I think both objects can be very useful and are > definitely needed. > > (An aside: on a busy node, byte counters change *very* often. The point > of providing a snapshot is to make graphs and such. The exact value at a > precise moment is not what's interesting. It's the trend.) Simon, byte counters are just that - counters. You can poll them at whatever granularity you want (within bounds). Such counters integrate how much data has passed over time - you do not 'miss' any bytes. What we have here seems very different. If the pool usage fluctuates heavily over short time scales (which I naively assume to be the case), then what is the right granularity to read these objects? The objects do not integrate and accumulate history since they report only a current snapshot. It would perhaps make more sense to have counters instead of snapshot values, e.g. the number of allocations and deallocations that have been done so that I do not have to poll at a very high rate to obtain a reasonably accurate idea of the situation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dthaler@microsoft.com Mon Sep 23 22:06:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C5821F9B21 for ; Mon, 23 Sep 2013 22:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.765 X-Spam-Level: X-Spam-Status: No, score=-103.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INjyNnmxVLi4 for ; Mon, 23 Sep 2013 22:06:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 06D0621F98AC for ; Mon, 23 Sep 2013 22:05:48 -0700 (PDT) Received: from BN1PR03MB267.namprd03.prod.outlook.com (10.255.200.17) by BN1PR03MB265.namprd03.prod.outlook.com (10.255.200.12) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 05:05:39 +0000 Received: from BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.122]) by BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.122]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 05:05:39 +0000 From: Dave Thaler To: Juergen Schoenwaelder , "Simon Perreault" Thread-Topic: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage Thread-Index: AQHOtkDu4m/+vPjYDU6CoV5FpDp3t5nPa+2AgAOnAYCAAAZ9gIAAAd2AgAE5s4CAAAXhYA== Date: Tue, 24 Sep 2013 05:05:38 +0000 Message-ID: <5c23484f9e6645a2bc7788e0684d30d0@BN1PR03MB267.namprd03.prod.outlook.com> References: <523CFA2B.6060001@gmail.com> <52400A81.3090608@viagenie.ca> <20130923095459.GA14842@elstar.local> <52401183.1040406@viagenie.ca> <20130924044425.GB17131@elstar.local> In-Reply-To: <20130924044425.GB17131@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(24454002)(13464003)(377454003)(189002)(199002)(377424004)(79102001)(65816001)(63696002)(59766001)(83322001)(77982001)(69226001)(81342001)(31966008)(66066001)(74662001)(80022001)(81542001)(74502001)(19580405001)(76576001)(76796001)(76786001)(74316001)(51856001)(54356001)(46102001)(33646001)(74706001)(53806001)(81686001)(81816001)(80976001)(74366001)(77096001)(56816003)(76482001)(47446002)(19580395003)(83072001)(49866001)(47736001)(4396001)(74876001)(54316002)(50986001)(56776001)(47976001)(145543001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB265; H:BN1PR03MB267.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:; RD:InfoNoRecords; MX:3; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 05:06:22 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Monday, September 23, 2013 9:44 PM > To: Simon Perreault > Cc: behave@ietf.org; Tom Taylor > Subject: Re: [BEHAVE] NAT MIB: Relationship between > natPoolRangeAllocatedPorts and natPoolUsage >=20 > On Mon, Sep 23, 2013 at 12:01:39PM +0200, Simon Perreault wrote: > > Le 2013-09-23 11:54, Juergen Schoenwaelder a =E9crit : > > > A slightly different question: How fast do these numbers change? Is > > > reporting a snaphost really useful here? > > > > On a big NAT with large pools, I would expect the numbers to oscillate > > with a 24-hour period. When graphed, they would look similar to total > > bandwidth graphs. I think both objects can be very useful and are > > definitely needed. > > > > (An aside: on a busy node, byte counters change *very* often. The > > point of providing a snapshot is to make graphs and such. The exact > > value at a precise moment is not what's interesting. It's the trend.) >=20 > Simon, >=20 > byte counters are just that - counters. You can poll them at whatever > granularity you want (within bounds). Such counters integrate how much > data has passed over time - you do not 'miss' any bytes. What we have he= re > seems very different. If the pool usage fluctuates heavily over short tim= e > scales (which I naively assume to be the case), then what is the right > granularity to read these objects? The objects do not integrate and > accumulate history since they report only a current snapshot. It would > perhaps make more sense to have counters instead of snapshot values, e.g. > the number of allocations and deallocations that have been done so that I= do > not have to poll at a very high rate to obtain a reasonably accurate idea= of the > situation. +1 =3DDave From simon.perreault@viagenie.ca Tue Sep 24 01:24:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940A021E8054 for ; Tue, 24 Sep 2013 01:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD4w52iuS13B for ; Tue, 24 Sep 2013 01:24:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D8B7121E8055 for ; Tue, 24 Sep 2013 01:23:16 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:e01a:be8d:b906:c8cd]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D131C403DC; Tue, 24 Sep 2013 04:23:15 -0400 (EDT) Message-ID: <52414BF2.8010103@viagenie.ca> Date: Tue, 24 Sep 2013 10:23:14 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: ietfdbh , behave@ietf.org References: <523B628B.7050401@gmail.com> <52403D7D.7010702@viagenie.ca> <049001ceb87e$4b4d24a0$e1e76de0$@comcast.net> In-Reply-To: <049001ceb87e$4b4d24a0$e1e76de0$@comcast.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 08:24:22 -0000 Le 2013-09-23 18:59, ietfdbh a écrit : > Hi Simon, > > You have thrown in RFC2804, an Informational RFC about IETF policy on > wiretapping. > You apparently have argued that "for law enforcement" is invalid because it > violates the IETF policy on wiretapping. (I'd prefer to keep this discussion impersonal. Even though you're replying to me personally, the RFC2804 argument is constantly used by many in this working group and others against any proposal facilitating "legal intercept", "law enforcement", "wiretapping", etc.) > I think that "law enforcement" and "wiretapping" are not the same thing. I'm > not sure that saying "law enforcement" violates rfc2804. > But that gets into semantics a lot ... We're clearly in RFC2804 territory when we talk about shipping CGN logs to authorities: An Internet equivalent of call tracing by means of accounting logs (sometimes called "pen registers") that is a feature of the telephone network is also wiretapping by this definition, since the normal expectation of the sender is that the company doing the accounting will keep this information in confidence. Other than that, I like your proposals very much and would agree with your proposed text. As you have shown, we can amply justify the technical requirements without referring to wiretapping. Thanks, Simon From tom.taylor.stds@gmail.com Tue Sep 24 01:37:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C321F9BC2 for ; Tue, 24 Sep 2013 01:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsy49RwcOfyA for ; Tue, 24 Sep 2013 01:37:37 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 474C221F9A71 for ; Tue, 24 Sep 2013 01:37:37 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id g12so1762094oah.1 for ; Tue, 24 Sep 2013 01:37:36 -0700 (PDT) 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=CsBfmpAcUOGLTo/4mzkO33fkAYpOc/8CVN4Eobl+lQc=; b=QuDGsKt+6z4LfGk3v3epKNn4eZ2DIRkr3DtFh3aKx1gBZ0TVHdavsx2Qbn3jiLay+w sNOWc/FN/x7qsxlailtWfAsxsK61Dl0f9qg+NGD5vQfaN/E+4HfPUMtKzOrArkuB//rm PN5o/8/Fah9cGmNslzhWlab4eTHLnNW8SE2zw6WeqCDa8KgQy4pVce3RcfxnE+sO/1A+ J17Hw873X1mCu/mfQ19wvrn/I8PB9JGGxpd9UEbttAjKEhx54CZnD0Bz9bJ9iM4m1jE+ NAOlaADC3Egi0Q8SREGgAjYiGHu1z5ww5Fy3gGPVhcPj/Nj/NclX0hxiKu+LyOI9s61c DZ7g== X-Received: by 10.182.143.5 with SMTP id sa5mr137848obb.80.1380011856551; Tue, 24 Sep 2013 01:37:36 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id hs4sm19565684obb.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 01:37:35 -0700 (PDT) Message-ID: <52414F4D.70701@gmail.com> Date: Tue, 24 Sep 2013 04:37:33 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <523B628B.7050401@gmail.com> <52403D7D.7010702@viagenie.ca> <049001ceb87e$4b4d24a0$e1e76de0$@comcast.net> <52414BF2.8010103@viagenie.ca> In-Reply-To: <52414BF2.8010103@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, ietfdbh Subject: Re: [BEHAVE] Log sequencel numbers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 08:37:38 -0000 On 24/09/2013 4:23 AM, Simon Perreault wrote: > Le 2013-09-23 18:59, ietfdbh a écrit : >> Hi Simon, >> >> You have thrown in RFC2804, an Informational RFC about IETF policy on >> wiretapping. >> You apparently have argued that "for law enforcement" is invalid because it >> violates the IETF policy on wiretapping. > > (I'd prefer to keep this discussion impersonal. Even though you're > replying to me personally, the RFC2804 argument is constantly used by > many in this working group and others against any proposal facilitating > "legal intercept", "law enforcement", "wiretapping", etc.) > >> I think that "law enforcement" and "wiretapping" are not the same thing. I'm >> not sure that saying "law enforcement" violates rfc2804. >> But that gets into semantics a lot ... > > We're clearly in RFC2804 territory when we talk about shipping CGN logs > to authorities: > > An Internet equivalent of call tracing by means of accounting logs > (sometimes called "pen registers") that is a feature of the telephone > network is also wiretapping by this definition, since the normal > expectation of the sender is that the company doing the accounting > will keep this information in confidence. > ... My personal work-around is "regulatory requirements". A bit of history: it was actually my WG (Megaco, media gateway control) that triggered the RAVEN discussion. While that went on, we went about our business, since room was full of telco operators and vendors. We had justification for forking media streams that went beyond legal intercept, so we just did it in the protocol. Tom From simon.perreault@viagenie.ca Tue Sep 24 01:48:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D21721F9A19 for ; Tue, 24 Sep 2013 01:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATjidxFjmAZM for ; Tue, 24 Sep 2013 01:48:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A751C21F9473 for ; Tue, 24 Sep 2013 01:48:44 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DC811403E5; Tue, 24 Sep 2013 04:48:43 -0400 (EDT) Message-ID: <524151EB.60500@viagenie.ca> Date: Tue, 24 Sep 2013 10:48:43 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Tom Taylor , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" References: <523CFA2B.6060001@gmail.com> <52400A81.3090608@viagenie.ca> <20130923095459.GA14842@elstar.local> <52401183.1040406@viagenie.ca> <20130924044425.GB17131@elstar.local> In-Reply-To: <20130924044425.GB17131@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 08:48:45 -0000 Le 2013-09-24 06:44, Juergen Schoenwaelder a écrit : > byte counters are just that - counters. You can poll them at whatever > granularity you want (within bounds). Such counters integrate how much > data has passed over time - you do not 'miss' any bytes. What we have > here seems very different. If the pool usage fluctuates heavily over > short time scales (which I naively assume to be the case), then what > is the right granularity to read these objects? The objects do not > integrate and accumulate history since they report only a current > snapshot. It would perhaps make more sense to have counters instead of > snapshot values, e.g. the number of allocations and deallocations that > have been done so that I do not have to poll at a very high rate to > obtain a reasonably accurate idea of the situation. Understood! Thanks for this very good suggestion! We already have number of allocations/deallocations for the mappings themselves, we can just do the equivalent for pools and get rid of the usage percentage. Simon From ietfdbh@comcast.net Tue Sep 24 04:51:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6594211E8123 for ; Tue, 24 Sep 2013 04:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.987 X-Spam-Level: X-Spam-Status: No, score=-99.987 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21O2cK-or26U for ; Tue, 24 Sep 2013 04:51:25 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 514B411E8116 for ; Tue, 24 Sep 2013 04:51:25 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id UzHE1m0030mv7h056zrQhu; Tue, 24 Sep 2013 11:51:24 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta11.westchester.pa.mail.comcast.net with comcast id UzrQ1m00D2yZEBF3XzrQkH; Tue, 24 Sep 2013 11:51:24 +0000 From: "ietfdbh" To: "'Dave Thaler'" , "'Juergen Schoenwaelder'" , "'Simon Perreault'" References: <523CFA2B.6060001@gmail.com> <52400A81.3090608@viagenie.ca> <20130923095459.GA14842@elstar.local> <52401183.1040406@viagenie.ca> <20130924044425.GB17131@elstar.local> <5c23484f9e6645a2bc7788e0684d30d0@BN1PR03MB267.namprd03.prod.outlook.com> In-Reply-To: <5c23484f9e6645a2bc7788e0684d30d0@BN1PR03MB267.namprd03.prod.outlook.com> Date: Tue, 24 Sep 2013 07:51:25 -0400 Message-ID: <04ce01ceb91c$65bd4a10$3137de30$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQITh3zZWmMlJUEx5JIzJxI+UO9/lgH8RZR0AiGlbHMBWX+DqwHWUyHWAkq2Q10CSwsvEJjsDdOw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380023484; bh=gauMXldkz3cwdNz1+KhWzWoM7I/exQAwaNSk+q9uzXI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=g90H/+NhbYJyLWYMpYZMS0WTWBd6sWtAADkqlEThqEVQ1ZcJ3zvQATlCxKw58Fobs YT0tLc7fGYGT2IHHv/jVo01WqgbB7s3yFG4HZygAt//gxVfTQN5cTJkkzC9OZFb9w7 0EakegZLZBQ22y2enaRVSpsabQO5pV5tdNa8pnDYnzSjDnEW3IlvEkBMLO8fsnrOc+ 2YFbJsQIUPK1gaqbgYMhIf17kGDzsDFFKrJcm0nKgGneo6Khb73eOzbo8YBKR5HUPv /NAr3IFMgRk7TnxCzAENjH36DGlrtqqdtWDMZmdPb38Jy/ncRU1mMtheI4PpVDUocX mFcWdiJI3Sgiw== Cc: behave@ietf.org, 'Tom Taylor' Subject: Re: [BEHAVE] NAT MIB: Relationship between natPoolRangeAllocatedPorts and natPoolUsage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 11:51:37 -0000 +1 David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Tuesday, September 24, 2013 1:06 AM > To: Juergen Schoenwaelder; Simon Perreault > Cc: behave@ietf.org; Tom Taylor > Subject: Re: [BEHAVE] NAT MIB: Relationship between > natPoolRangeAllocatedPorts and natPoolUsage >=20 > > -----Original Message----- > > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > > Behalf Of Juergen Schoenwaelder > > Sent: Monday, September 23, 2013 9:44 PM > > To: Simon Perreault > > Cc: behave@ietf.org; Tom Taylor > > Subject: Re: [BEHAVE] NAT MIB: Relationship between > > natPoolRangeAllocatedPorts and natPoolUsage > > > > On Mon, Sep 23, 2013 at 12:01:39PM +0200, Simon Perreault wrote: > > > Le 2013-09-23 11:54, Juergen Schoenwaelder a =E9crit : > > > > A slightly different question: How fast do these numbers change? = Is > > > > reporting a snaphost really useful here? > > > > > > On a big NAT with large pools, I would expect the numbers to = oscillate > > > with a 24-hour period. When graphed, they would look similar to = total > > > bandwidth graphs. I think both objects can be very useful and are > > > definitely needed. > > > > > > (An aside: on a busy node, byte counters change *very* often. The > > > point of providing a snapshot is to make graphs and such. The = exact > > > value at a precise moment is not what's interesting. It's the = trend.) > > > > Simon, > > > > byte counters are just that - counters. You can poll them at = whatever > > granularity you want (within bounds). Such counters integrate how = much > > data has passed over time - you do not 'miss' any bytes. What we = have > here > > seems very different. If the pool usage fluctuates heavily over = short time > > scales (which I naively assume to be the case), then what is the = right > > granularity to read these objects? The objects do not integrate and > > accumulate history since they report only a current snapshot. It = would > > perhaps make more sense to have counters instead of snapshot values, > e.g. > > the number of allocations and deallocations that have been done so = that I > do > > not have to poll at a very high rate to obtain a reasonably accurate idea of > the > > situation. >=20 > +1 >=20 > =3DDave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From wwwrun@rfc-editor.org Wed Sep 25 05:09:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA9C21F9E91 for ; Wed, 25 Sep 2013 05:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqV6DO387m8a for ; Wed, 25 Sep 2013 05:09:48 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CE75721F9EAE for ; Wed, 25 Sep 2013 05:09:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 389F58E016; Wed, 25 Sep 2013 05:02:47 -0700 (PDT) To: jdrosen@cisco.com, rohan@ekabal.com, philip_matthews@magma.ca, dwing@cisco.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, dwing@cisco.com, dthaler@microsoft.com From: RFC Errata System Message-Id: <20130925120250.389F58E016@rfc-editor.org> Date: Wed, 25 Sep 2013 05:02:47 -0700 (PDT) Cc: behave@ietf.org, spencerdawkins.ietf@gmail.com, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC5389 (3737) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 12:09:49 -0000 The following errata report has been submitted for RFC5389, "Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5389&eid=3737 -------------------------------------- Type: Technical Reported by: Spencer Dawkins Section: 17 Original Text ------------- The IAB has mandated that protocols developed for this purpose document a specific set of considerations. Corrected Text -------------- The IAB has suggested that protocols developed for this purpose document a specific set of considerations. Notes ----- The IAB UNSAF RFC (http://tools.ietf.org/html/rfc3424) is Informational, and the IAB hasn't "mandated" what IETF protocol documents contain for something like 20 years, if I understand correctly. 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. -------------------------------------- RFC5389 (draft-ietf-behave-rfc3489bis-18) -------------------------------------- Title : Session Traversal Utilities for NAT (STUN) Publication Date : October 2008 Author(s) : J. Rosenberg, R. Mahy, P. Matthews, D. Wing Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From dthaler@microsoft.com Wed Sep 25 07:56:25 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACA921F9642 for ; Wed, 25 Sep 2013 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.845 X-Spam-Level: X-Spam-Status: No, score=-103.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olz8-jw3OrMx for ; Wed, 25 Sep 2013 07:56:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6D21F958A for ; Wed, 25 Sep 2013 07:56:19 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 25 Sep 2013 14:56:10 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.45]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.45]) with mapi id 15.00.0775.005; Wed, 25 Sep 2013 14:56:10 +0000 From: Dave Thaler To: RFC Errata System , "jdrosen@cisco.com" , "rohan@ekabal.com" , "philip_matthews@magma.ca" , "dwing@cisco.com" , "spencerdawkins.ietf@gmail.com" , "mls.ietf@gmail.com" , "dwing@cisco.com" Thread-Topic: [Technical Errata Reported] RFC5389 (3737) Thread-Index: AQHOuegj9CVXeTS6cECJBlJ0YaB4XZnWir8Q Date: Wed, 25 Sep 2013 14:56:09 +0000 Message-ID: References: <20130925120250.389F58E016@rfc-editor.org> In-Reply-To: <20130925120250.389F58E016@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(13464003)(377454003)(78114003)(199002)(189002)(65816001)(59766001)(79102001)(31966008)(81542001)(74662001)(80022001)(15188155005)(69226001)(81342001)(16799955002)(66066001)(15188555002)(47446002)(74502001)(83072001)(46102001)(53806001)(51856001)(15975445006)(54356001)(74876001)(47976001)(49866001)(74316001)(74706001)(77096001)(81686001)(81816001)(76796001)(56816003)(74366001)(80976001)(47736001)(76786001)(33646001)(54316002)(50986001)(15202345003)(83322001)(77982001)(63696002)(19580405001)(19580395003)(76482001)(56776001)(76576001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "behave@ietf.org" , "spencerdawkins.ietf@gmail.com" Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5389 (3737) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:56:25 -0000 I think Spencer is correct. Per http://www.ietf.org/iesg/statement/errata-processing.html guideline #2, I think this erratum should be marked Hold for Document Updat= e. -Dave > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Wednesday, September 25, 2013 5:03 AM > To: jdrosen@cisco.com; rohan@ekabal.com; philip_matthews@magma.ca; > dwing@cisco.com; spencerdawkins.ietf@gmail.com; mls.ietf@gmail.com; > dwing@cisco.com; Dave Thaler > Cc: spencerdawkins.ietf@gmail.com; behave@ietf.org; rfc-editor@rfc- > editor.org > Subject: [Technical Errata Reported] RFC5389 (3737) >=20 > The following errata report has been submitted for RFC5389, "Session > Traversal Utilities for NAT (STUN)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5389&eid=3D3737 >=20 > -------------------------------------- > Type: Technical > Reported by: Spencer Dawkins >=20 > Section: 17 >=20 > Original Text > ------------- > The IAB has mandated that protocols developed for this purposedocument a > specific set of considerations. >=20 > Corrected Text > -------------- > The IAB has suggested that protocols developed for this purposedocument a > specific set of considerations. >=20 > Notes > ----- > The IAB UNSAF RFC (http://tools.ietf.org/html/rfc3424) is Informational, = and > the IAB hasn't "mandated" what IETF protocol documents contain for > something like 20 years, if I understand correctly. >=20 > 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 decisio= n is > reached, the verifying party (IESG) can log in to change the status and e= dit > the report, if necessary. >=20 > -------------------------------------- > RFC5389 (draft-ietf-behave-rfc3489bis-18) > -------------------------------------- > Title : Session Traversal Utilities for NAT (STUN) > Publication Date : October 2008 > Author(s) : J. Rosenberg, R. Mahy, P. Matthews, D. Wing > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG From andrewf@plixer.com Thu Sep 26 08:29:47 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E6F21F9A49; Thu, 26 Sep 2013 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGaMOGwxBA95; Thu, 26 Sep 2013 08:29:33 -0700 (PDT) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) by ietfa.amsl.com (Postfix) with ESMTP id 364D621F8319; Thu, 26 Sep 2013 08:29:25 -0700 (PDT) Received: from [10.8.1.2] (64.140.243.154) by mx1.plixer.com (10.1.5.1) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Sep 2013 11:29:19 -0400 Message-ID: <524452C7.3080100@plixer.com> Date: Thu, 26 Sep 2013 11:29:11 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: IPFIX Working Group , References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] [IPFIX] NAT logging using IPFIX - Requesting review X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 15:29:47 -0000 Hi Senthil, On 08/01/2013 09:37 AM, Senthil Sivakumar (ssenthil) wrote: > I would like the IPFIX WG to review this draft that uses IPFIX to log NAT > events. > > http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging I'm a little slow off the blocks on this one, but here is my review of draft-ietf-behave-ipfix-nat-logging-01.txt. In Table of Contents "de-allocate" should be "deallocate" "Acknowledgements" should be "Acknowledgments" Throughout the draft: "IE's" is used instead of "IEs" 3. Scope "as stated earlier, this document is not defining IPFIX or NetFlow v9". This is the only reference to NetFlow v9 (none earlier or later). I would either remove the "or NetFlow v9" or add some more about to the intended compatibility with NetFlow v9. Nothing jumped out at me as nto NetFlow v9 compatible, but there are differences. I'm not sure that this text... "This would mean that the NAT device will specify the template that it is going to use for each of the events. The templates can be of varying length and there could be multiple templates that a NAT device could use to log the events." belongs in the Scope. In fact there are various bits of IPFIX specific advice scattered through the draft. I would prefer to see this draft focus exclusively on the IEs needed and example templates. I would change "The implementation details of the collector application is beyond the scope of this document." to something like "The implementation details of the collector application and exporter function is beyond the scope of this document." 5. Event based logging I would delete this text " A NAT device MAY log these events to multiple collectors if redundancy is required. The network administrator will specify the collectors to which the log records are to be sent." and this text "Prior to logging any events, the NAT device MUST send the template of the record to the collector to advertise the format of the data record that it is using to send the events. The templates can be exchanged as frequently as required given the reliability of the connection. There SHOULD be a configurable timer for controlling the template refresh. NAT device SHOULD combine as many events as possible in a single packet to effectively utilize the network bandwidth." The above seem out of scope for specifying IEs and templates. 5.2. Information Elements timeStamp is used in several places and specified as IE 323. There isn't a single IPFIX timeStamp IE, but several depending on your granularity requirements. IE 323 is named "observationTimeMilliseconds". Also available are: 322 observationTimeSeconds 323 observationTimeMilliseconds 324 observationTimeMicroseconds 325 observationTimeNanoseconds I would remove the columns for "Size (bits)" and maybe "Description" and refer people to http://www.iana.org/assignments/ipfix. If you feel you need to keep size it would be more consistent with other IPFIX documents to specify dataType (eg unsigned64 vs 64 and ipv6Address vs 128). If you keep the Description "occured" in the timeStamp Description should be "occurred" The IE name for "vlanID" is actually "vlanId" sourceIPv6Address has the IE in the bits column and bits in the IE column postNATSourceIPv6Address "addresss" should be "address" 5.3. Definition of NAT Events Is this the definition for natEvent(230)? This doesn't match my understanding of what is currently defined. Currently 1 - Create event. 2 - Delete event. 3 - Pool exhausted. None of these specify NAT44. My understanding was that these events are equally applicable to NAT other than just NAT44 and the collector would infer the type of NAT from the type of addresses being sent. For example If the template includes a v6 source and a v4 destination the Create event is probably for a 64 NAT. So it isn't clear to me that you need | NAT64 Session create | 4 | | NAT64 Session delete | 5 | Also I think | NAT44 BIB create | 6 | | NAT44 BIB delete | 7 | | NAT64 BIB create | 8 | | NAT64 BIB delete | 9 | Can be collapsed to just 4 - BIB create. 5 - BIB BIB create. The last event, "Port block de-allocation", should be "Port block deallocation" 5.4. Quota exceeded - Sub Event types Maybe I missed something, but I don't see an IE defined to send this information. 5.5. Templates for NAT Events I would drop the size column from the tables in this section too. 5.5.2. NAT64 create and delete session event "This event will be generated when a NAT64 session is created. The following is a template of the event." Should be "This event will be generated when a NAT64 session is created or deleted. The template will be the same, the natEvent will indicate whether it is a create or a delete event. The following is a template of the event." I wonder if it is really necessary to duplicate everything between 5.5.1 and 5.5.2 when the only real difference is the address types. Same comment for 5.5.3 and 5.5.4. 5.5.3. NAT44 BIB create and delete event "This event will be generated when a NAT44 Bind entry is created." Needs an "or deleted". 5.5.4. NAT64 BIB create and delete event "This event will be generated when a NAT64 Bind entry is created." Needs an "or deleted". 5.5.5. Addresses Exhausted event "wont" should be "won't" in "NAT device wont be able to create" 5.5.6. Ports Exhausted event I'm not a NAT/IPv6 expert so I could easily be missing something here, but is this really only an IPv4 event? 7. Acknowledgements should be 7. Acknowledgments 8. IANA Considerations Currently "There are no IANA considerations for this document." Should include update of natEvent with additional values and creation of Quota exceeded - Sub Event. -Andrew > > This is a behave working group draft. Your feedback is greatly appreciated. > > Thanks > Senthil > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From simon.perreault@viagenie.ca Fri Sep 27 08:11:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7211E815A for ; Fri, 27 Sep 2013 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIHjlyO3j4+E for ; Fri, 27 Sep 2013 08:11:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEEF21F9EDB for ; Fri, 27 Sep 2013 08:11:40 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3539E403CD; Fri, 27 Sep 2013 11:11:39 -0400 (EDT) Message-ID: <5245A02A.3080505@viagenie.ca> Date: Fri, 27 Sep 2013 17:11:38 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tom Taylor References: <52322929.2080702@gmail.com> In-Reply-To: <52322929.2080702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 15:11:59 -0000 Le 2013-09-12 22:50, Tom Taylor a écrit : > 1. The descriptions for some of the notifications say that they are > triggered when the value is <= or >= the threshold, where for others > they only talk about when the threshold is exceeded. Should this be made > consistent? I think we need to send a trap whenever the threshold is crossed, no matter what direction we're going. > 2. Should the descriptions for natResourceError, > natProtocolResourceErrors and natSubscriberResourceErrors exclude quota > drops as well as out-of-port errors? Yes! > 3. There is a major discrepancy between the pool watermark notification > descriptions (which talk about addresses) and the objects in > natPoolEntry, which talk about ports. I imagine the latter descriptions > need updating. I updated the former (the notification description) to read: "This notification is generated when the specified pool's usage percentage becomes lower than or equal to the specified threshold. The threshold is specified by the natPoolWatermarkLow object" > 4. The contents of natMapIntAddrEntry include only one address type. > What if the external address type is different from the internal one? You're absolutely right. Fixed. > 5. For logging purposes, it would be good to have a quota identifier. > From the MIB point of view, would it make sense to have a quota table > presenting an SnmpAdminString identifier and a counter for the quota > violations? Maybe. Can you describe a little bit what those "quota identifiers" are? Maybe give an example? 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 simon.perreault@viagenie.ca Fri Sep 27 08:18:19 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A285911E810A for ; Fri, 27 Sep 2013 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FyVH0TFhf0U for ; Fri, 27 Sep 2013 08:18:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DEE1911E814D for ; Fri, 27 Sep 2013 08:18:18 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6CF4B403D5 for ; Fri, 27 Sep 2013 11:18:16 -0400 (EDT) Message-ID: <5245A1B7.9060401@viagenie.ca> Date: Fri, 27 Sep 2013 17:18:15 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: behave@ietf.org References: <52398699.6080903@gmail.com> In-Reply-To: <52398699.6080903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Notifications and logs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 15:18:19 -0000 Le 2013-09-18 12:55, Tom Taylor a écrit : > On the issue of notifications and logs, I had two responses on the > OPSAWG list. Both said the operator should have a choice of which to > deploy. In other words, the notifications and logs should both be defined. I think this is useful guidance. There was a third response on the BEHAVE mailing list going in the same direction. > Because of the way I framed the question, this opinion is orthogonal to > the matter of whether the Event MIB could be used instead of > notifications in the NAT MIB. Until anyone shows how this can be done with the Event MIB, I'm working under the assumption that we need notifications in the NAT MIB. 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 Fri Sep 27 09:01:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B1C21E80FD for ; Fri, 27 Sep 2013 09:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQaTwynmt2Rn for ; Fri, 27 Sep 2013 09:00:58 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EFF3011E8162 for ; Fri, 27 Sep 2013 09:00:30 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id t7so1827413qcv.7 for ; Fri, 27 Sep 2013 09:00:30 -0700 (PDT) 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=ZXmgUp5phqpARGc3ANPaXxcj4EoTatsm9H+nSx7aAWI=; b=Sor7UJJdpfo8BzJ0nC2Rk/TBfS3MYxS1qAyyVtWRotw9BARTP+xw6jSzVeKcfMZ2ya apLudLl0nojtIgD6019DPnlHZtI81AJed5hEFx0YPQshGzpl+/AA/YNPqALElHzT4ws2 CB9Ckv2sVAqMdqwVL3rnsmOoyVGrFgxt3ZCRa3b3Hptsgs3aD2xYoi08WyN1QHNEw9Xr iMG2bFE53enVm3B/UNNVed0Dgs9V66mO1PlRtJ+XcxayYWM9lJu75iEihFPFJWGOASgn lUrXIfH0+IwJ1lApBg5QNOWMPZnpJbI3LWbO7Z+h3JVKsSucXZFwRnYEygOxEI4ldn/D zZ2Q== X-Received: by 10.224.61.198 with SMTP id u6mr14949430qah.83.1380297630337; Fri, 27 Sep 2013 09:00:30 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id u8sm14074003qef.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 09:00:29 -0700 (PDT) Message-ID: <5245AB9B.9090800@gmail.com> Date: Fri, 27 Sep 2013 12:00:27 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <52322929.2080702@gmail.com> <5245A02A.3080505@viagenie.ca> In-Reply-To: <5245A02A.3080505@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:01:00 -0000 On 27/09/2013 11:11 AM, Simon Perreault wrote: > Le 2013-09-12 22:50, Tom Taylor a écrit : >> 1. The descriptions for some of the notifications say that they are >> triggered when the value is <= or >= the threshold, where for others >> they only talk about when the threshold is exceeded. Should this be made >> consistent? > > I think we need to send a trap whenever the threshold is crossed, no > matter what direction we're going. [PTT] Just to be clear: I take those "=" above to mean that a notification/log is generated when the high- or low- water-mark is EQUAL to the threshold. Is this the intent? "Exceed" is used exclusively for high-water-mark thresholds, and to me implies a strict greater-than relationship. That is, no notification/log is generated if the value is simply equal to the threshold. We need to be clear on the intent. FYI I've spelled out >= or <= relationships for all the thresholds in the relevant event descriptions of syslog-03. > ... > >> 5. For logging purposes, it would be good to have a quota identifier. >> From the MIB point of view, would it make sense to have a quota table >> presenting an SnmpAdminString identifier and a counter for the quota >> violations? > > Maybe. Can you describe a little bit what those "quota identifiers" are? > Maybe give an example? [PTT] Here's the text describing this in syslog-03, Section 3.13: Table [proposed] in the NAT MIB lists quota identifiers and corresponding total counts of packets dropped because of quota violations. This table may be extended to provide information on the configuration of the particular quota, depending on the implementation. Here's a sketch of the table as I envision it, based on cut-and-paste from the existing natPool table in the MIB. Maybe it would be useful to have an additional SnmpAdminString quota identifier for more human-friendly presentation. If we do have the drops counter, the global counter natQuotaDrops is redundant and should be dropped itself. Number of administrative denials is a new idea, providing a check on PCP requests, maybe. BTW I note that natPoolIndex id read-only rather than not-accessible. Is this correct? I copied it for natQuotaIndex. -- textual conventions NatQuotaId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique ID that is assigned to each quota." SYNTAX Unsigned32 (1..4294967295) -- quotas natQuotaObjects OBJECT IDENTIFIER ::= { natMIBObjects xx } natQuotaTable OBJECT-TYPE SYNTAX SEQUENCE OF NatQuotaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of quotas. May be extended by the implementation to include objects related to configuration." ::= { natQuotaObjects 1 } natQuotaEntry OBJECT-TYPE SYNTAX NatQuotaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry in the table of quotas." INDEX { natQuotaIndex } ::= { natQuotaTable 1 } NatQuotaEntry ::= SEQUENCE { natQuotaIndex NatQuotaId, natQuotaDrops Integer32, natQuotaDenies Integer32 } natQuotaIndex OBJECT-TYPE SYNTAX NatQuotaId MAX-ACCESS read-only STATUS current DESCRIPTION "Index of a quota." ::= { natQuotaEntry 1 } natQuotaDrops OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of packets dropped due to application of this quota." ::= { natQuotalEntry 2 } natQuotaDenies OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of administrative requests denied due to application of this quota." ::= { natQuotaEntry 3 } > > Thanks, > Simon From tom.taylor.stds@gmail.com Fri Sep 27 09:20:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B9B21F9FD6 for ; Fri, 27 Sep 2013 09:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYxJUXj-5ApK for ; Fri, 27 Sep 2013 09:19:59 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2472321F9633 for ; Fri, 27 Sep 2013 09:19:59 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id x12so1841992qcv.8 for ; Fri, 27 Sep 2013 09:19:58 -0700 (PDT) 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=/o6HbGFTdTxfOJgN+4pRz1gkLaEgDL2AcQT++tfPOm4=; b=VlO1qPO6Ap+f6cO/oBhmdmCwNO7j66vjg85WJRIM8ngqkR5jf4S+YuL/fNM5Dn1xS5 IYFh9AAK4PtXG1C2Hy8w11hEgHxmtId73dJmbtQLwDLcdhJoAgWanfTb0RzuTcXckjAp gaeEX8afH3RJXUHzhwqAe/qChewk1DIb0pWQLy3crnEsOB2kcRuRZWGTg32EZZMdYqgb 2y92cBBoqQv+yAaGmekrT9kswI3BJMXj2h9VAFlgDq0itnUR2s814I/+La5HayagcMlT qPVhTOdF7VMVeepvb/cb1PJOpAJH/S85L5KXJKL9E4eCutUX/6t2uZGY17I31L2smIZ7 nhPA== X-Received: by 10.224.119.196 with SMTP id a4mr2790314qar.120.1380298797644; Fri, 27 Sep 2013 09:19:57 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id h20sm14216833qen.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 09:19:57 -0700 (PDT) Message-ID: <5245B02A.7010207@gmail.com> Date: Fri, 27 Sep 2013 12:19:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Perreault References: <52322929.2080702@gmail.com> <5245A02A.3080505@viagenie.ca> <5245AB9B.9090800@gmail.com> In-Reply-To: <5245AB9B.9090800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comments on the NAT MIB X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:20:00 -0000 On 27/09/2013 12:00 PM, Tom Taylor wrote: > On 27/09/2013 11:11 AM, Simon Perreault wrote: >> Le 2013-09-12 22:50, Tom Taylor a écrit : > ... >> >>> 5. For logging purposes, it would be good to have a quota identifier. >>> From the MIB point of view, would it make sense to have a quota table >>> presenting an SnmpAdminString identifier and a counter for the quota >>> violations? >> >> Maybe. Can you describe a little bit what those "quota identifiers" are? >> Maybe give an example? > > [PTT] Here's the text describing this in syslog-03, Section 3.13: > > Table [proposed] in the > NAT MIB lists quota identifiers and corresponding total counts of > packets dropped because of quota violations. This table may be > extended to provide information on the configuration of the > particular quota, depending on the implementation. > > > Here's a sketch of the table as I envision it, based on cut-and-paste > from the existing natPool table in the MIB. Maybe it would be useful to > have an additional SnmpAdminString quota identifier for more > human-friendly presentation. If we do have the drops counter, the global > counter natQuotaDrops is redundant and should be dropped itself. Number > of administrative denials is a new idea, providing a check on PCP > requests, maybe. > > BTW I note that natPoolIndex id read-only rather than not-accessible. Is > this correct? I copied it for natQuotaIndex. > > -- textual conventions > > NatQuotaId ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "A unique ID that is assigned to each quota." > SYNTAX Unsigned32 (1..4294967295) > > > -- quotas > > natQuotaObjects OBJECT IDENTIFIER ::= { natMIBObjects xx } > > natQuotaTable OBJECT-TYPE > SYNTAX SEQUENCE OF NatQuotaEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Table of quotas. May be extended by the implementation > to include objects related to configuration." > ::= { natQuotaObjects 1 } [PTT2] Thinking this through a bit further, I realize that the configuration table would be a separate table in which the index value would be created. This table just quotes the created value. > > natQuotaEntry OBJECT-TYPE > SYNTAX NatQuotaEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Entry in the table of quotas." > INDEX { natQuotaIndex } > ::= { natQuotaTable 1 } > > NatQuotaEntry ::= > SEQUENCE { > natQuotaIndex NatQuotaId, > natQuotaDrops Integer32, > natQuotaDenies Integer32 > } > > natQuotaIndex OBJECT-TYPE > SYNTAX NatQuotaId > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Index of a quota." > ::= { natQuotaEntry 1 } > > natQuotaDrops OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Number of packets dropped due to application of this quota." > ::= { natQuotalEntry 2 } > > natQuotaDenies OBJECT-TYPE > SYNTAX Counter64 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Number of administrative requests denied due to > application of this quota." > ::= { natQuotaEntry 3 } > > >> >> Thanks, >> Simon From internet-drafts@ietf.org Fri Sep 27 09:22:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2FD21E8108; Fri, 27 Sep 2013 09:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N10V52zvE0eh; Fri, 27 Sep 2013 09:22:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA5521F9FD6; Fri, 27 Sep 2013 09:22:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130927162229.11230.23926.idtracker@ietfa.amsl.com> Date: Fri, 27 Sep 2013 09:22:29 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:22:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Definitions of Managed Objects for Network Address Trans= lators (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-08.txt Pages : 82 Date : 2013-09-27 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat-mib-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Fri Sep 27 09:26:43 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E9121E80FB for ; Fri, 27 Sep 2013 09:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+BsCiO-hwXC for ; Fri, 27 Sep 2013 09:26:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C2CD321F9CAE for ; Fri, 27 Sep 2013 09:26:01 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 72B37403CD for ; Fri, 27 Sep 2013 12:25:55 -0400 (EDT) Message-ID: <5245B192.4020009@viagenie.ca> Date: Fri, 27 Sep 2013 18:25:54 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: behave@ietf.org References: <20130927162229.11230.23926.idtracker@ietfa.amsl.com> In-Reply-To: <20130927162229.11230.23926.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:26:43 -0000 All, This is a snapshot of a work in progress. There are still many things left to do. Simon Le 2013-09-27 18:22, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > Title : Definitions of Managed Objects for Network Address Translators (NAT) > Author(s) : Simon Perreault > Tina Tsou > Senthil Sivakumar > Filename : draft-ietf-behave-nat-mib-08.txt > Pages : 82 > Date : 2013-09-27 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for devices implementing Network Address Translator (NAT) function. > This MIB module may be used for monitoring of a device capable of NAT > function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- 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 Sun Sep 29 01:22:47 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644DF21F9609 for ; Sun, 29 Sep 2013 01:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQmVn-7ltMyI for ; Sun, 29 Sep 2013 01:22:45 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5216021F9FA2 for ; Sun, 29 Sep 2013 01:22:45 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id e14so7385723iej.6 for ; Sun, 29 Sep 2013 01:22:44 -0700 (PDT) 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=NNSq76xbV1nNVMbTk4MBJhGW5O3RvrKZMaC4kL0SdKk=; b=x5AL0tWmcSkKNDdvovanKf2vLMd2gkUsixGWIBORvk5DNd+h0OOXmLsTMpfsrMe2c+ VP8MJj3hXaa3zVsO8c4/8FRUcTH9cVif2t35DlNygiprg7NYNgj/TDMCnV5VPd2/oN0B N8Wlv5LzUAEnBp7jTagtKapb027aGbYpO+7YTd9J1e4rzVecvDIfkZhsHdqBUbSUe9nw ZwI6S+wDuTPPdoPuCqgKWCpef2SY5b3Z707KBwaQCNjX/UeIByo/SI27Rr0DwL2dzt5q p4TtXJ0OSUx/paHaiQ12kP6ItislGTcOfTDI5fnSQjhpVbbtlDNddEm6ovIiRiOeWhLI Hdag== X-Received: by 10.42.63.194 with SMTP id d2mr12145095ici.10.1380442964315; Sun, 29 Sep 2013 01:22:44 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-79-23.tor.primus.ca. [173.206.79.23]) by mx.google.com with ESMTPSA id k6sm9377268igx.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Sep 2013 01:22:43 -0700 (PDT) Message-ID: <5247E351.1070108@gmail.com> Date: Sun, 29 Sep 2013 04:22:41 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Logging: address exhaustion and port exhaustion events X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 08:22:47 -0000 In the -04 pass for the SYSLOG logging document, I added the following text in the section describing the address pool threshold events: The high-water-mark threshold event provides a warning that the address-port combinations offered by the pool are nearing exhaustion. Upon exhaustion, packets may be dropped because no address has enough free port values left to be allocated to an address mapping ("address exhaustion"). This applies to the case of "paired" pooling behaviour [RFC4787], where typically an address will not be allocated unless it has a sufficient number of free ports. Alternatively, packets will be dropped simply because no address in the pool has a free port number for the required protocol ("port exhaustion"). Packets dropped due to address exhaustion are included in the amounts provided by the following NAT MIB counters: o globally, natResourceErrors in the natCounters table; o per protocol, natProtocolResourceErrors in natProtocolTable; o per subscriber, natSubscriberResourceErrors in natSubscribersTable.> Packets dropped due to port exhaustion are counted in the following NAT MIB counters: o globally, natOutOfPortErrors in the natCounters table; o per protocol, natProtocolOutOfPortErrors in natProtocolTable; o per subscriber, natSubscriberOutOfPortErrors in natSubscribersTable. First question: do people agree with the proposed definitions of address exhaustion and port exhaustion? If so, we have operational definitions a NAT can work with in generating both counts and logs. Second question: our current OAM-related events are all based on administratively-set limits and thresholds. Should the address exhaustion and port exhaustion events also be logged? Tom Taylor From simon.perreault@viagenie.ca Sun Sep 29 02:53:02 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7121F9E63 for ; Sun, 29 Sep 2013 02:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXf2SuzwMnmR for ; Sun, 29 Sep 2013 02:52:59 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8165321F9EA2 for ; Sun, 29 Sep 2013 02:52:59 -0700 (PDT) Received: from porto.nomis80.org (87-231-137-212.rev.numericable.fr [87.231.137.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C7F73403CB for ; Sun, 29 Sep 2013 05:52:54 -0400 (EDT) Message-ID: <5247F874.4090307@viagenie.ca> Date: Sun, 29 Sep 2013 11:52:52 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: behave@ietf.org References: <5247E351.1070108@gmail.com> In-Reply-To: <5247E351.1070108@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Logging: address exhaustion and port exhaustion events X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 09:53:03 -0000 Le 2013-09-29 10:22, Tom Taylor a écrit : > First question: do people agree with the proposed definitions of address > exhaustion and port exhaustion? If so, we have operational definitions a > NAT can work with in generating both counts and logs. Looks good to me! > Second question: our current OAM-related events are all based on > administratively-set limits and thresholds. Should the address > exhaustion and port exhaustion events also be logged? I'm not sure. What I would expect people to do is graph the counters of port allocations/deallocations so as to produce a graph of pool usage. Based on historical usage you can make plans for future dimensioning of the pools. Exhaustion events are not much more useful. If you're interested in the immediate effects of exhaustion events, then you have the drop counters. 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 tireddy@cisco.com Mon Sep 30 05:04:25 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C4B21F9A49 for ; Mon, 30 Sep 2013 05:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcrcSaWV0JYh for ; Mon, 30 Sep 2013 05:04:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B8A6E21F898A for ; Mon, 30 Sep 2013 05:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2234; q=dns/txt; s=iport; t=1380542660; x=1381752260; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=NYAEx0QgYApdxfMomuQx4gLE+bEf6FlUpBU9Jv5za00=; b=QB4ETyjqJ6hRCnRPbc7gux/nkAMTj26kDH8lNly5exHrKt6p5mjpLK9u MFCa2wO/onrRXe8j0eETMxh6lCYnyolBSSBjfLvY8rVZX1TmroRSPYxk2 kN+/ngDRVYXLMWgcMfm1SmQyPHir9EVux7pwIibNV4zIYtF20B8TeK0u5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncFANJnSVKtJV2a/2dsb2JhbABagwc4TAaDKb1UF4ESFm0HgiUBAQEEIxFDDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEEwgBh30HBZtjjwSSF4EpjXc+gmQ1gQMDmS6QSoMkgio X-IronPort-AV: E=Sophos;i="4.90,1007,1371081600"; d="scan'208";a="266154195" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 30 Sep 2013 12:04:20 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8UC4K37007549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Sep 2013 12:04:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 30 Sep 2013 07:04:20 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Behave@ietf.org" Thread-Topic: New Version Notification for draft-reddy-behave-turn-auth-04.txt Thread-Index: AQHOvcmEw2geb0kerkuI3x1Pm2XOZZneF85w Date: Mon, 30 Sep 2013 12:04:19 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A190A16CD@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.206] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 12:04:26 -0000 UmV2aXNlZCBkcmFmdC1yZWRkeS1iZWhhdmUtdHVybi1hdXRoLTA0IGhhcyBiZWVuIHB1Ymxpc2hl ZC4gVGhlIHVwZGF0ZSBpbmNvcnBvcmF0ZXMgY29tbWVudHMgZnJvbSBIYXJhbGQuIA0KRnVydGhl ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNClRoYW5rcyBhbmQgUmVn YXJkcywNCi1BdXRob3JzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDMwLCAyMDEzIDQ6MTEgUE0NClRvOiBSYW0gTW9oYW4g UiAocm1vaGFucik7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IE11dGh1IEFydWwgTW96 aGkgUGVydW1hbCAobXBlcnVtYWwpOyBBbHBlciBZZWdpbjsgUmFtIE1vaGFuIFIgKHJtb2hhbnIp OyBBbHBlciBFLiBZZWdpbjsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmVkZHktYmVoYXZlLXR1 cm4tYXV0aC0wNC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktYmVo YXZlLXR1cm4tYXV0aC0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg VGlydW1hbGVzd2FyIFJlZGR5IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoN CkZpbGVuYW1lOgkgZHJhZnQtcmVkZHktYmVoYXZlLXR1cm4tYXV0aA0KUmV2aXNpb246CSAwNA0K VGl0bGU6CQkgUHJvYmxlbXMgd2l0aCBTVFVOIEF1dGhlbnRpY2F0aW9uIGZvciBUVVJODQpDcmVh dGlvbiBkYXRlOgkgMjAxMy0wOS0zMA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpO dW1iZXIgb2YgcGFnZXM6IDcNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktYmVoYXZlLXR1cm4tYXV0aC0wNC50eHQNClN0YXR1 czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZWRkeS1i ZWhhdmUtdHVybi1hdXRoDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJlZGR5LWJlaGF2ZS10dXJuLWF1dGgtMDQNCkRpZmY6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcmVkZHktYmVoYXZlLXR1cm4tYXV0 aC0wNA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHNvbWUgb2YgdGhl IGlzc3VlcyB3aXRoIFNUVU4gYXV0aGVudGljYXRpb24NCiAgIGZvciBUVVJOIG1lc3NhZ2VzLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K