From rgerhards@hq.adiscon.com Mon Apr 1 09:20:24 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 4947E21E804A for ; Mon, 1 Apr 2013 09:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 qaftzqPaqNbd for ; Mon, 1 Apr 2013 09:20:23 -0700 (PDT) Received: from vmmail.adiscon.com (vmmail.adiscon.com [176.9.56.141]) by ietfa.amsl.com (Postfix) with ESMTP id 74D5A21E8042 for ; Mon, 1 Apr 2013 09:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vmmail.adiscon.com (Postfix) with ESMTP id 52EE474A3B4 for ; Mon, 1 Apr 2013 18:19:18 +0200 (CEST) Received: from vmmail.adiscon.com ([127.0.0.1]) by localhost (vmmail.adiscon.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlAQiDApQm4r for ; Mon, 1 Apr 2013 18:19:18 +0200 (CEST) Received: from vmexch2.intern.adiscon.com (vmvpn.adiscon.com [188.40.57.185]) by vmmail.adiscon.com (Postfix) with ESMTPSA id F237774A3A7 for ; Mon, 1 Apr 2013 18:19:17 +0200 (CEST) Received: from VMEXCH2.intern.adiscon.com ([fe80::8cb1:e14c:5f97:b29b]) by vmexch2.intern.adiscon.com ([fe80::8cb1:e14c:5f97:b29b%10]) with mapi id 14.02.0342.003; Mon, 1 Apr 2013 18:20:20 +0200 From: Rainer Gerhards To: "behave@ietf.org" Thread-Topic: syslog scalability Thread-Index: AQHOLvTNRU5FnjJ1Y0mVM/dyoWifNA== Date: Mon, 1 Apr 2013 16:20:20 +0000 Message-ID: <1364833219.2022.11.camel@linux.fritz.box> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.92.119.74] Content-Type: text/plain; charset="utf-8" Content-ID: <9C7283108616B34F89530300320F7290@ADISCON.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [BEHAVE] syslog scalability 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, 01 Apr 2013 16:20:24 -0000 SGkgYWxsLA0KDQpJIGFtIHRoZSBhdXRob3Igb2YgcnN5c2xvZyAodGhlIGRlZmF1bHQgc3lzbG9n ZCBvbiBtb3N0DQpMaW51eGVzKSBhbmQgaGF2ZSBiZWVuIGludm9sdmVkIGluIHRoZSByZWNlbnQg c3lzbG9nIFJGQyBzZXJpZXMuIERhdmlkDQpIYXJyaW5ndG9uIGhhcyBhc2tlZCBteSB0byBjb21t ZW50IG9uIHN5c2xvZyBzY2FsYWJpbGl0eS4NCg0KV2l0aCByc3lzbG9nLCBJIHJvdXRpbmVseSBk byBhcm91bmQgMjAwLDAwMCBtZXNzYWdlcyBwZXIgc2Vjb25kIChtcHMpIG9uDQpsb3ctZW5kIChu b3RlYm9vaykgaGFyZHdhcmUuIEkga25vdyB0aGF0IHVzZXJzIGRvIG11Y2ggbGFyZ2VyIHRyYWZm aWMNCnZvbHVtZXMgaW4gcHJvZHVjdGlvbiBzeXN0ZW1zLiBPbmUgdXNlciByZXBvcnQgY2FuIGJl IGZvdW5kIGluIFsxXSwNCndoZXJlIDEgbWlsbGlvbiBtcHMgd2VyZSBwcm9jZXNzZWQgKHdpdGgg YW4gb2xkZXIgYW5kIHNsb3dlciB2ZXJzaW9uKS4NClRoZSBtZXNzYWdlIHNpemVzIGFmZmVjdCBt ZXNzYWdlIHJhdGUuIE15IHRlc3Rpbmcgd2FzIHdpdGggNjAgdG8gODAgYnl0ZQ0KbWVzc2FnZXMg KHRoZSB1c3VhbCBzaXplIGZvciBsaW51eCBzeXNsb2cgZW50cmllcykuIEFzIGFub3RoZXIgZXhh bXBsZSwNCkkga25vdyBhIGN1c3RvbWVyIHdobyBkb2VzIGhlYXZ5IGxvZ2dpbmcgb2YgY2FsbCBk YXRhIHJlY29yZHMsIHNpemUNCmJldHdlZW4gMC41IGFuZCAxLjVrLCB3aXRoIGFyb3VuZCAxNTAs MDAwIG1wcy4gVGhleSBoYXZlIGRlbGliZXJhdGVseQ0KY2hvc2VuIHRvIHN0aWNrIHRvIHRoaXMg bnVtYmVyIHNvIHRoYXQgdGhleSBoYXZlIGhlYWRyb29tIGluIGNhc2Ugb2YNCnRyYWZmaWMgc3Bp a2VzLiBOb3RlIHRoYXQgaW4gdGhhdCBjYXNlLCB0aGUgb3V0cHV0IGlzIGF1dG9tYXRpY2FsbHkN CnppcHBlZCwgd2hhdCBvYnZpb3VzbHkgdGFrZXMgc29tZSB0b2xsIG9uIHByb2Nlc3NpbmcgdGlt ZS4gVGhleSBhbHNvIHVzZQ0KYW4gb2xkZXIgYW5kIHNsb3dlciB2ZXJzaW9uLg0KDQpUaGVzZSBz Y2VuYXJpb3MsIGFzIGZhciBhcyBJIGtub3csIHdlcmUgdGFrZW4gdmlhIFVEUCBhbmQgcGxhaW4g VENQDQpzeXNsb2cuIElmIFRMUyBpcyB1c2VkLCB0aGUgbnVtYmVycyBvYnZpb3VzbHkgYXJlIHJl ZHVjZWQgZHVlIHRvIHRoZQ0KZXh0cmEgZW5jcnlwdGlvbiByZXF1aXJlbWVudC4gT2YgY291cnNl LCB0aGlzIGlzIG5vdCBzeXNsb2cgc3BlY2lmaWMgYnV0DQphcHBsaWVzIHRvIGFsbCBwcm90b2Nv bHMgdXRpbGl6aW5nIFRMUyAoYW5kIHdpdGggaGFyZHdhcmUgY3J5cHRvIGJveGVzDQp0aGUgcGVy Zm9ybWFuY2UgaGl0IGlzIG9mIGNvdXJzZSBtdWNoIGxvd2VyKS4NCg0KUmVnYXJkaW5nIFRMUywg SSBuZWVkIHRvIG1lbnRpb24gdGhhdCBpdCBpcyBzdXBwb3J0ZWQgYnkgYXQgbGVhc3QNCnJzeXNs b2cgYW5kIHN5c2xvZy1uZywgd2hpY2ggdG9nZXRoZXIgaGF2ZSA5MCsgcGVyY2VudCAibWFya2V0 IHNoYXJlIiBvbg0KTGludXggYW5kIFVuaXguIEFkaXNjb24gYWxzbyBzdXBwb3J0cyBUTFMgb24g V2luZG93cyBpbiBvdXIgV2luU3lzbG9nLA0KRXZlbnRSZXBvcnRlciBhbmQgTW9uaXRvcldhcmUg QWdlbnQgcHJvZHVjdHMuIEkgYW0gbm90IHN1cmUgd2hvIGVsc2UgaGFzDQppbXBsZW1lbnRlZCBp dCwgYnV0IEkgYW0gc3VyZSB0aGVyZSBhcmUgbWFueSBtb3JlIGltcGxlbWVudGF0aW9ucy4NCg0K QWN0dWFsIGRlcGxveW1lbnRzIGN1cnJlbnRseSBmYXZvciBsZWdhY3kgVENQIHN5c2xvZyAoQXMg ZGVzY3JpYmVkIGluDQpSRkM2NTg3KS4gVGhlcmUgYXJlIHZhcmlvdXMgcmVhc29ucyBmb3IgdGhp czsgb25lIHJlYXNvbiBjdXN0b21lcnMgb2Z0ZW4NCm1lbnRpb24gaXMgdGhhdCB0aGV5IHJ1biB0 aGVpciBzeXNsb2cgdHJhZmZpYyBpbiBhbiBhbHJlYWR5LXNlY3VyZWQNCmJhY2tlbmQgZW52aXJv bm1lbnQuIFBsYWluIFRDUCBzeXNsb2cgaXMgdmVyeSB3aWRlbHkgZGVwbG95ZWQgYW5kDQpzdXBw b3J0ZWQgYnkgYWxtb3N0IGFsbCBzeXNsb2cgdG9vbHMgdGhhdCBoYXZlIGF0IGxlYXN0IHNvbWUg bWFya2V0DQpzaGFyZS4NCg0KSSBob3BlIHRoaXMgY29tbWVudCBpcyB1c2VmdWwuIEZlZWwgZnJl ZSB0byBhc2sgaWYgaW5mb3JtYXRpb24gaXMNCm1pc3NpbmcuIEkgZGlkICpub3QqIHJlYWQgbWFu eSBtYWlscyBvbiB0aGlzIG1haWxpbmcgbGlzdCBoZXJlLiBTbyBJIG1heQ0KaGF2ZSBtaXNzZWQg c29tZSBpbXBvcnRhbnQgcG9pbnRzLiBJIGFtIGN1cnJlbnRseSBzdWJzY3JpYmVkIHRvIHRoZSBs aXN0DQphbmQgd2lsbCBmb2xsb3cgdXAuDQoNCkJlc3QgcmVnYXJkcywNClJhaW5lciBHZXJoYXJk cw0KDQpbMV1odHRwOi8va2IubW9uaXRvcndhcmUuY29tLzAwMC0wMDAtY2hhcmFjdGVyLW1lc3Nh Z2VzLXNlYy13aXRoLXJzeXNsb2ctdDEwNzQwLmh0bWwNCg0K From dbharrington@comcast.net Fri Mar 29 13:50: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 04B8721F8ED4 for ; Fri, 29 Mar 2013 13:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.023 X-Spam-Level: X-Spam-Status: No, score=-98.023 tagged_above=-999 required=5 tests=[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 lOmHEQ0b1Tuy for ; Fri, 29 Mar 2013 13:50:40 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 16A8921F8ECB for ; Fri, 29 Mar 2013 13:50:37 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id HRRo1l00317dt5G55YqchW; Fri, 29 Mar 2013 20:50:36 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta13.westchester.pa.mail.comcast.net with comcast id HYqb1l0173Ecudz3ZYqcYD; Fri, 29 Mar 2013 20:50:36 +0000 From: "David Harrington" To: , , Date: Fri, 29 Mar 2013 16:50:35 -0400 Message-ID: <015f01ce2cbf$10085400$3018fc00$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4svP/Sma8JdsAYS/6c9PDQENK6rg== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364590236; bh=ZTuGgXp0D7bfq2yGiU9t2NMkRLlzd0+Yka/eGiGQ6fo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=eVJB8xJFSIOhJpQQCyNDM4EO+MYIkuFQGAf+erwoqol2mw5dYUCOUBmnzADdNtZfL kuPidqVHauBKBLbR/5NN+iQf+ufBS1UHfDVcAbX1QI1jvet6T9HPg412B8/ZUvKNE5 MhWs71pKWlUfTWYzH4BS8eZdH/bN9kZyDcOTWzEogJ8iLwJG8LzT7T1TA4pICs7qHQ Ayy6J430TQFwB/uMsozfQuNb0paBw4tA3cGms3a7AYIdepFNysebKEJyWjXHt7wYte wnihXNMGNyRJ6j4T/Z54a77NUZujh+HEejXIpret/TNHVn1Oip2ArL8Bql5hScdwhI Il/63bz0S3wcQ== X-Mailman-Approved-At: Mon, 01 Apr 2013 09:21:23 -0700 Cc: behave@ietf.org Subject: [BEHAVE] nat-mib-05 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, 29 Mar 2013 20:50:41 -0000 Hi, I ran the nat-mib-05 through libsmi tools, and it reported errors. I'm having some issues with my use if libsmi on a new machine, so there might be some false positives in my results, But I manually checked a couple and they do appear to be errors. (REVISION versus LAST-Update; NatNotifications appears to be undefined; natPoolIndex should be not-accessible) Have you run the MIB through the libsmi tools? (http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/) Have you checked the MIB against the guidelines in RFC4181? David Harrington dbharrington@comcast.net +1-603-828-1401 From ietfdbh@comcast.net Mon Apr 1 20:43: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 D865C21E8176 for ; Mon, 1 Apr 2013 20:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[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 YrQ896NRKizq for ; Mon, 1 Apr 2013 20:43:52 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 18E9521E8127 for ; Mon, 1 Apr 2013 20:43:52 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id Jrgc1l0031c6gX85Crjrsa; Tue, 02 Apr 2013 03:43:51 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta23.westchester.pa.mail.comcast.net with comcast id Jrjq1l00r3Ecudz3jrjrhW; Tue, 02 Apr 2013 03:43:51 +0000 From: "ietfdbh" To: "'David Harrington'" , , , Date: Mon, 1 Apr 2013 23:43:50 -0400 Message-ID: <020401ce2f54$4a87b890$df9729b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4vVDU3ztjXiVlmQNSgaHxIaLcnIw== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1364874231; bh=gPlutlBSdezuiA/gEGvPQEDyixJFL1F56DkioKjCpJE=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Tp/+io/dHTAMn/zW8MFDbztorWmV0A8RUlrXjE0eu+tg0VXbxFqenxUbSluPtU2ia MwT8RyLNmOnuOLvvI9gFPm/yjQ8wV2GKsMFnMw3pRuHzxUHLgVZqmV9BFm545DqSX0 mUD/s9LJtTcQF7JPa+vJkDNggzFAnQKlOYOlmeOC9aldcEzYo2ExVWyThy8Rq/6sRX i6O73G76M7inQHk1O27lX3lDVSaBoU+SfrcSHxRUASXNVnz9cg34UUmUhWcSo6eJxU Du8w0cE8HletmpXReR7R8N5e2paUY6GDJ+aiCk2Qq0lYTZ2ghn7rRnaUpFkocEwdDv VKB1sAkiT9BEQ== Cc: behave@ietf.org Subject: [BEHAVE] nat-mib-05 security considerations 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, 02 Apr 2013 03:43:53 -0000 Hi, I notice that you have used a crafted security considerations section rather than using the boilerplate available at https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security# I haven't seen anything that makes me believe the policy has changed. You really should use the boilerplate, and fill it in in the manner described. It took significant negotiation between the various slates of OPS and SEC Ads to craft the boilerplate. Some of the text in your sec cons is not consistent with best current practices. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of David Harrington Sent: Friday, March 29, 2013 4:51 PM To: simon.perreault@viagenie.ca; tina.tsou.zouting@huawei.com; ssenthil@cisco.com Cc: behave@ietf.org Subject: [BEHAVE] nat-mib-05 Hi, I ran the nat-mib-05 through libsmi tools, and it reported errors. I'm having some issues with my use if libsmi on a new machine, so there might be some false positives in my results, But I manually checked a couple and they do appear to be errors. (REVISION versus LAST-Update; NatNotifications appears to be undefined; natPoolIndex should be not-accessible) Have you run the MIB through the libsmi tools? (http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/) Have you checked the MIB against the guidelines in RFC4181? David Harrington dbharrington@comcast.net +1-603-828-1401 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From kaname@nttv6.jp Tue Apr 2 01:37: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 CE99121F98AE for ; Tue, 2 Apr 2013 01:37: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, HTML_MESSAGE=0.001, 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 ovOtnp8lnnSJ for ; Tue, 2 Apr 2013 01:37:19 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by ietfa.amsl.com (Postfix) with ESMTP id E304B21F98AC for ; Tue, 2 Apr 2013 01:37:18 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 74D04BDC21 for ; Tue, 2 Apr 2013 17:37:15 +0900 (JST) Received: from [IPv6:2402:c800:ff06:0:656e:cb95:25b2:86b4] (unknown [IPv6:2402:c800:ff06:0:656e:cb95:25b2:86b4]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 64258E2274; Tue, 2 Apr 2013 17:37:15 +0900 (JST) Message-ID: <515A98BA.9030409@nttv6.jp> Date: Tue, 02 Apr 2013 17:37:14 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: behave@ietf.org References: <20130328141225.16450.37444.idtracker@ietfa.amsl.com> <515A8B2E.9060706@nttv6.jp> In-Reply-To: <515A8B2E.9060706@nttv6.jp> Content-Type: multipart/alternative; boundary="------------080100010404020903030602" Cc: Shin Miyakawa Subject: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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, 02 Apr 2013 08:37:19 -0000 This is a multi-part message in MIME format. --------------080100010404020903030602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, I'm kaname from NTT communications in Japan. We are testing CGN under the support of Japanese Government. Now, we've uploaded a new draft based on the result of our verification. The useful information about the average consumption of the ports are available on the document. Please look through it, and all kind of feedback are welcome. By conducting realistic experiment, this draft is answering to "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC very soon. The document is *NOT* intended to be Standards Track. It's for Informational. The wrong description is just mere mistake, so we'll soon correct it in the next revision. The full report of our work will be available soon on the Web in English. I'll also announce it when it's available to this mailing-list. Best regards, kaname > -------- Original Message -------- > Subject: New Version Notification for > draft-nishizuka-cgn-deployment-considerations-00.txt > Date: Thu, 28 Mar 2013 07:12:25 -0700 > From: internet-drafts@ietf.org > To: kaname@nttv6.jp > > > > A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00.txt > has been successfully submitted by Kaname Nishizuka and posted to the > IETF repository. > > Filename: draft-nishizuka-cgn-deployment-considerations > Revision: 00 > Title: Carrier-Grade-NAT (CGN) Deployment Considerations. > Creation date: 2013-03-29 > Group: Individual Submission > Number of pages: 16 > URL:http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-considerations-00.txt > Status:http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerations > Htmlized:http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00 > > > Abstract: > This document provides deployment considerations for Carrier-Grade- > NAT (CGN) based on the verification result include the investigation > of the number of sessions of applications. The verification was > conducted in StarBED which is one of the largest scale network > experiment environment in Japan. A million of subscribers was > emulated and it revealed the realistic behavior of CGN. > > > > > The IETF Secretariat > > > -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 --------------080100010404020903030602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
Dear all,

I'm kaname from NTT communications in Japan.
We are testing CGN under the support of Japanese Government.
Now, we've uploaded a new draft based on the result of our verification.
The useful information about the average consumption of the ports are available on the document.
Please look through it, and all kind of feedback are welcome.

By conducting realistic experiment, this draft is answering to "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC very soon.

The document is *NOT* intended to be Standards Track. It's for Informational.
The wrong description is just mere mistake, so we'll soon correct it in the next revision.

The full report of our work will be available soon on the Web in English.
I'll also announce it when it's available to this mailing-list.

Best regards,

kaname



-------- Original Message --------
Subject: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt
Date: Thu, 28 Mar 2013 07:12:25 -0700
From: internet-drafts@ietf.org
To: kaname@nttv6.jp 


A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00.txt
has been successfully submitted by Kaname Nishizuka and posted to the
IETF repository.

Filename:	 draft-nishizuka-cgn-deployment-considerations
Revision:	 00
Title:		 Carrier-Grade-NAT (CGN) Deployment Considerations.
Creation date:	 2013-03-29
Group:		 Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-considerations-00.txt
Status:          http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerations
Htmlized:        http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00


Abstract:
   This document provides deployment considerations for Carrier-Grade-
   NAT (CGN) based on the verification result include the investigation
   of the number of sessions of applications.  The verification was
   conducted in StarBED which is one of the largest scale network
   experiment environment in Japan.  A million of subscribers was
   emulated and it revealed the realistic behavior of CGN.

                                                                                  


The IETF Secretariat






-- 
---- 
Kaname Nishizuka
Innovative Architecture Center
NTT Communications Corporation
+81-50-3812-4704
--------------080100010404020903030602-- From dwing@cisco.com Tue Apr 2 09:07:46 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 3E36C21F8D2E for ; Tue, 2 Apr 2013 09:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 0jrs1svU-4ih for ; Tue, 2 Apr 2013 09:07:45 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 646CE21F8D11 for ; Tue, 2 Apr 2013 09:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10884; q=dns/txt; s=iport; t=1364918865; x=1366128465; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=uWEnBYGUX2/xq6oBolmygAyPFX1qvm6j9sbciFd0Suo=; b=JPIo5b1R/2ZbTcei22XmActjkJYaHD7Aw1zS9h4vHmu1Y6bwoCTFNR/7 S8Y+xSBsMWNwSCq7dCyNP5SyivE4nlwO4mRIM1xJ+JTYHQkfP3CHBVeBC 3AX7iHGGac7l+iC9YQ69II4N0tAHklAJoiYIscMiBfUoBEQfFPEVc65tS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFACYBW1GrRDoJ/2dsb2JhbABDgwc2twcBiDeBBRZ0gh8BAQEDAQEBAWQHCQIFBwQLEQECAQIvJyIGCAYTCYgFBQ2xSpATjwgGCwcGgllhA4h6jXGBH49sgVWBVhw X-IronPort-AV: E=Sophos;i="4.87,394,1363132800"; d="scan'208,217";a="75069655" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 02 Apr 2013 16:07:44 +0000 Received: from sjc-vpn7-1852.cisco.com (sjc-vpn7-1852.cisco.com [10.21.151.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r32G7hPj015209; Tue, 2 Apr 2013 16:07:43 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_68EAD554-4854-42C0-8376-7F99067CE509" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <515A98BA.9030409@nttv6.jp> Date: Tue, 2 Apr 2013 09:07:43 -0700 Message-Id: References: <20130328141225.16450.37444.idtracker@ietfa.amsl.com> <515A8B2E.9060706@nttv6.jp> <515A98BA.9030409@nttv6.jp> To: kaname nishizuka X-Mailer: Apple Mail (2.1503) Cc: Shin Miyakawa , behave@ietf.org Subject: Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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, 02 Apr 2013 16:07:46 -0000 --Apple-Mail=_68EAD554-4854-42C0-8376-7F99067CE509 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 2, 2013, at 1:37 AM, kaname nishizuka wrote: > Dear all, >=20 > I'm kaname from NTT communications in Japan. > We are testing CGN under the support of Japanese Government. > Now, we've uploaded a new draft based on the result of our = verification. > The useful information about the average consumption of the ports are = available on the document. > Please look through it, and all kind of feedback are welcome. Thanks for publishing this document. I like the description of DNS location at = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0#section-6.3, as this is an important mechanism to reduce the = transactional load on the CGN. Have you analyzed the number of = subscribers that over-ride the ISP-provided DNS servers to use other DNS = servers (e.g., Google, OpenDNS), as that DNS query traffic will traverse = the CGN. = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0#section-5.3.2 would benefit from some discussion of the privacy impact = of an ISP storing destination information, and should also describe = memory impact (in the CGN) if the subscriber uses the same source port = to visit many different destinations (if CGN does not store the list of = destinations, CGN will generate a log for every packet sent to a new = destination). Applications such as bittorrent can consume a lot of = memory in a CGN that is configured for destination logging. -d > By conducting realistic experiment, this draft is answering to = "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC = very soon. >=20 > The document is *NOT* intended to be Standards Track. It's for = Informational. > The wrong description is just mere mistake, so we'll soon correct it = in the next revision. >=20 > The full report of our work will be available soon on the Web in = English. > I'll also announce it when it's available to this mailing-list. >=20 > Best regards, >=20 > kaname >=20 >=20 >=20 >=20 >> -------- Original Message -------- >> Subject: New Version Notification for = draft-nishizuka-cgn-deployment-considerations-00.txt >> Date: Thu, 28 Mar 2013 07:12:25 -0700 >> From: internet-drafts@ietf.org >> To: kaname@nttv6.jp >>=20 >> A new version of I-D, = draft-nishizuka-cgn-deployment-considerations-00.txt >> has been successfully submitted by Kaname Nishizuka and posted to the >> IETF repository. >>=20 >> Filename: draft-nishizuka-cgn-deployment-considerations >> Revision: 00 >> Title: Carrier-Grade-NAT (CGN) Deployment = Considerations. >> Creation date: 2013-03-29 >> Group: Individual Submission >> Number of pages: 16 >> URL: = http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-conside= rations-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerati= ons >> Htmlized: = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0 >>=20 >>=20 >> Abstract: >> This document provides deployment considerations for = Carrier-Grade- >> NAT (CGN) based on the verification result include the = investigation >> of the number of sessions of applications. The verification was >> conducted in StarBED which is one of the largest scale network >> experiment environment in Japan. A million of subscribers was >> emulated and it revealed the realistic behavior of CGN. >>=20 >> = =20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >=20 >=20 > --=20 > ----=20 > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --Apple-Mail=_68EAD554-4854-42C0-8376-7F99067CE509 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii kaname@nttv6.jp> wrote:
=20 
Dear all,

I'm kaname from NTT communications in Japan.
We are testing CGN under the support of Japanese Government.
Now, we've uploaded a new draft based on the result of our verification.
The useful information about the average consumption of the ports are =
available on the document.
Please look through it, and all kind of feedback are welcome.
Thanks for publishing this = document.

I like the description of DNS = location at http://tools.ietf.org/html/draft-nishizuka-cgn-depl= oyment-considerations-00#section-6.3, as this is an important = mechanism to reduce the transactional load on the CGN.  Have you = analyzed the number of subscribers that over-ride the ISP-provided DNS = servers to use other DNS servers (e.g., Google, OpenDNS), as that DNS = query traffic will traverse the CGN.

http://tools.ietf.org/html/draft-nishizuka-cgn-de= ployment-considerations-00#section-5.3.2 would benefit from some = discussion of the privacy impact of an ISP storing destination = information, and should also describe memory impact (in the CGN) if the = subscriber uses the same source port to visit many different = destinations (if CGN does not store the list of destinations, CGN will = generate a log for every packet sent to a new destination). =  Applications such as bittorrent can consume a lot of memory in a = CGN that is configured for destination = logging.

-d


By conducting realistic experiment, this draft is answering to =
"draft-ietf-behave-lsn-requirements-10" which will be the newest RFC =
very soon.

The document is *NOT* intended to be Standards Track. It's for =
Informational.
The wrong description is just mere mistake, so we'll soon correct it in =
the next revision.

The full report of our work will be available soon on the Web in =
English.
I'll also announce it when it's available to this mailing-list.

Best regards,

kaname



-------- Original Message -------- =
Subject: New Version Notification for = draft-nishizuka-cgn-deployment-considerations-00.txt
Date: Thu, 28 Mar 2013 07:12:25 -0700
From: internet-drafts@ietf.org
To: kaname@nttv6.jp 


A new version of I-D, =
draft-nishizuka-cgn-deployment-considerations-00.txt
has been successfully submitted by Kaname Nishizuka and posted to the
IETF repository.

Filename:	 draft-nishizuka-cgn-deployment-considerations
Revision:	 00
Title:		 Carrier-Grade-NAT (CGN) Deployment Considerations.
Creation date:	 2013-03-29
Group:		 Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-nishizuk=
a-cgn-deployment-considerations-00.txt
Status:          http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deploymen=
t-considerations
Htmlized:        http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-consi=
derations-00


Abstract:
   This document provides deployment considerations for Carrier-Grade-
   NAT (CGN) based on the verification result include the investigation
   of the number of sessions of applications.  The verification was
   conducted in StarBED which is one of the largest scale network
   experiment environment in Japan.  A million of subscribers was
   emulated and it revealed the realistic behavior of CGN.

                                                                         =
        =20


The IETF Secretariat






--=20
----=20
Kaname Nishizuka
Innovative Architecture Center
NTT Communications Corporation
+81-50-3812-4704
_______________________________________________
Behave mailing = list
Behave@ietf.org
https://www.ietf.or= g/mailman/listinfo/behave

= --Apple-Mail=_68EAD554-4854-42C0-8376-7F99067CE509-- From rajiva@cisco.com Tue Apr 2 09:26:24 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 D67F621F8D90 for ; Tue, 2 Apr 2013 09:26:24 -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 AUdugRV9lyp4 for ; Tue, 2 Apr 2013 09:26:24 -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 BC91221F8D8D for ; Tue, 2 Apr 2013 09:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5371; q=dns/txt; s=iport; t=1364919983; x=1366129583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uWgHH0jQpiKKD8bbneKEgqZNJ/d+Q0vfDSbzszIBJSI=; b=XMFFNgHXyzTYJ9HuuJ7fO3rg6UbwyDdg3+/s35xjLdxiIcA71X+OKEBg ZBL48cMqh2WWWlfjPZZjhod3ixM/q19cuhAlEBGV5cVZw6z+iudpqJTdP SUU4Z3LWYjmnxIMmuvzbN85ITlN8otstKf89K3uCLEY+csiM7E47+WdlB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAIYFW1GtJV2d/2dsb2JhbABDgwc2vz+BBRZ0gh8BAQEDAQEBATctBwkCBQcEAgEIEQECAQEBAQoUCQcnCxQDBggCBAENBQgBiAUGDLFfkBiOaCYLBwaCWWEDmAqPbIFVgTaCKA X-IronPort-AV: E=Sophos;i="4.87,394,1363132800"; d="scan'208";a="194160148" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 02 Apr 2013 16:26:20 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r32GQJai025206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 16:26:19 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.244]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 11:26:19 -0500 From: "Rajiv Asati (rajiva)" To: "Dan Wing (dwing)" , kaname nishizuka Thread-Topic: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt Thread-Index: AQHOL7w/MAwMiGZq3EC7nspjQ3pgwJjDHAQg Date: Tue, 2 Apr 2013 16:26:18 +0000 Message-ID: References: <20130328141225.16450.37444.idtracker@ietfa.amsl.com> <515A8B2E.9060706@nttv6.jp> <515A98BA.9030409@nttv6.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.38.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shin Miyakawa , "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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, 02 Apr 2013 16:26:25 -0000 This document would benefit from including the throughput/capacity discussi= on a bit along the following lines: - challenges in spreading the traffic load (100G, say) among the available = NAT capacity (distributed intra-chassis or inter-chassis). For ex, NAT entr= y is created by the upstream traffic, which is negligible to the downstream= traffic that can exhaust the NAT capacity. For ex, poor usage of NAT capacity by fragmenting the IP pool (both inside= and outside) More inline, > I like the description of DNS location at http://tools.ietf.org/html/draf= t- > nishizuka-cgn-deployment-considerations-00#section-6.3, as this is an > important mechanism to reduce the transactional load on the CGN. Have It is certainly desirable trait to let the DNS server not exhaust the CGN c= apacity. However, such a trait is not attainable when the number of users i= s too high to avoid overlapping (of private address space). This ends up mo= ving DNS behind the CGN. :( Cheers, Rajiv > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dan Wing (dwing) > Sent: Tuesday, April 02, 2013 12:08 PM > To: kaname nishizuka > Cc: Shin Miyakawa; behave@ietf.org > Subject: Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn- > deployment-considerations-00.txt >=20 >=20 > On Apr 2, 2013, at 1:37 AM, kaname nishizuka wrote: >=20 >=20 > Dear all, >=20 > I'm kaname from NTT communications in Japan. > We are testing CGN under the support of Japanese Government. > Now, we've uploaded a new draft based on the result of our > verification. > The useful information about the average consumption of the ports > are available on the document. > Please look through it, and all kind of feedback are welcome. >=20 > Thanks for publishing this document. >=20 > I like the description of DNS location at http://tools.ietf.org/html/draf= t- > nishizuka-cgn-deployment-considerations-00#section-6.3, as this is an > important mechanism to reduce the transactional load on the CGN. Have > you analyzed the number of subscribers that over-ride the ISP-provided > DNS servers to use other DNS servers (e.g., Google, OpenDNS), as that DNS > query traffic will traverse the CGN. >=20 > http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations- > 00#section-5.3.2 would benefit from some discussion of the privacy impact > of an ISP storing destination information, and should also describe memor= y > impact (in the CGN) if the subscriber uses the same source port to visit = many > different destinations (if CGN does not store the list of destinations, C= GN > will generate a log for every packet sent to a new destination). Applica= tions > such as bittorrent can consume a lot of memory in a CGN that is configure= d > for destination logging. >=20 > -d >=20 >=20 >=20 > By conducting realistic experiment, this draft is answering to "draft- > ietf-behave-lsn-requirements-10" which will be the newest RFC very soon. >=20 > The document is *NOT* intended to be Standards Track. It's for > Informational. > The wrong description is just mere mistake, so we'll soon correct it > in the next revision. >=20 > The full report of our work will be available soon on the Web in > English. > I'll also announce it when it's available to this mailing-list. >=20 > Best regards, >=20 > kaname >=20 >=20 >=20 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-nishizuka-cgn- > deployment-considerations-00.txt > Date: Thu, 28 Mar 2013 07:12:25 -0700 > From: internet-drafts@ietf.org > To: kaname@nttv6.jp >=20 >=20 > A new version of I-D, draft-nishizuka-cgn-deployment- > considerations-00.txt > has been successfully submitted by Kaname Nishizuka and > posted to the > IETF repository. >=20 > Filename: draft-nishizuka-cgn-deployment- > considerations > Revision: 00 > Title: Carrier-Grade-NAT (CGN) Deployment > Considerations. > Creation date: 2013-03-29 > Group: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft- > nishizuka-cgn-deployment-considerations-00.txt > Status: http://datatracker.ietf.org/doc/draft-nishizuka- > cgn-deployment-considerations > Htmlized: http://tools.ietf.org/html/draft-nishizuka-cgn- > deployment-considerations-00 >=20 >=20 > Abstract: > This document provides deployment considerations for > Carrier-Grade- > NAT (CGN) based on the verification result include the > investigation > of the number of sessions of applications. The verification > was > conducted in StarBED which is one of the largest scale > network > experiment environment in Japan. A million of subscribers > was > emulated and it revealed the realistic behavior of CGN. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 >=20 > -- > ---- > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave >=20 >=20 From ssenthil@cisco.com Tue Apr 2 15:03: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 2801721F8A40 for ; Tue, 2 Apr 2013 15:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DuCkVNanv047 for ; Tue, 2 Apr 2013 15:03:42 -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 2D30121F85D7 for ; Tue, 2 Apr 2013 15:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26961; q=dns/txt; s=iport; t=1364940222; x=1366149822; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=5AmrzbqoXxMvjZY5YtCXirQ6G7OJ6LjWczSYYcpdoMI=; b=Jn9CtNoxtLbWBzJwu5c8ZFZcVJ8HKA/bXmSnKSU5MSXMdK2AI5JPi3rp NokNwbuT+LAVGjdgmf44ZU5MzLOzJNpn1yLA7lLsIrHi+tuKdr2drUlrk XRSArIkJhBkUf03TzoNxcvfbukGojsnMGfpdS4AiU/fPQmBH82IAC/gcI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FACdVW1GtJV2a/2dsb2JhbABDgkNENrdLAYg3gQcWdIIfAQEBBGcHCQIMBgEIEQECAQILCwsDBDkUAwYIAgQBDQUIAYgLDLFgkA2OaCAGCwcGAwGCVWEDmAqPbIFVgTaCKA X-IronPort-AV: E=Sophos;i="4.87,396,1363132800"; d="scan'208,217";a="194240762" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 02 Apr 2013 22:03:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r32M3fix006195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 22:03:41 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.42]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 17:03:40 -0500 From: "Senthil Sivakumar (ssenthil)" To: kaname nishizuka , "behave@ietf.org" Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt Thread-Index: AQHOL+3uZcY5y2kg70eS7ETyuhJHpA== Date: Tue, 2 Apr 2013 22:03:40 +0000 Message-ID: In-Reply-To: <515A98BA.9030409@nttv6.jp> 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.132] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D0232430EAExmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: Shin Miyakawa Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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, 02 Apr 2013 22:03:44 -0000 --_000_CB1B483277FEC94E9B58357040EE5D0232430EAExmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kaname, It is a pretty interesting study. I have a few comments on the sections on = your IP address requirements calculations.In the dynamic assignment, the po= rts of pool address are allocated " # of pool address (P) =3D # of Subscriber (S) * a * N / (65536 - R) Here, (R) is reserved TCP/UDP port list referred in [I-D.donley-behave-deterministic-cgn]. CGN should eliminate the wellknown ports (0-1023 for TCP and UDP) to avoid the bad interpretation from destination servers. It is natural to translate source port of outgoing packet to ephemeral ports. The ports after 32768 is considered to be used without any problems because ephemeral ports are 32768-61000 for Linux and 49152-65535 in the IANA recommendations. As the result, 3,051 pool addresses are sufficient for 1,000,000 subscribers. The feasibility of configuration was confirmed in the verification." [Senthil] Most of the NATs use the entire port space from 1024-65536, did y= ou find differently? If you had used the entire port space, you would only require 1526 addresse= s instead of 3051. I think not using the 1024-32768 is not practical and inefficient. On the other hand, in static assignment, the ports are allocated a priori for every users. The pool addresses and ports are reserved to every users, so most of them could be a dead stock because there are light users and heavy users in aspect of port consumption. The max number of port consumption in all subscribers is the key value for static assignment. The true peak number of the session by a heavy user could be over 10,000 sessions. However it is assumed that such a severe consumption of ports to be an abuse, so the number of statically assigned port (M) is controllable parameter by each providers. In the static assignment, the required number of the pool address is as follows: # of pool address (P) =3D # of Subscriber (S) * M / (65536 - R) Taking account into the investigation of number of sessions of applications, the desirable value of (M) is over 1,000. As the result, no less than 30,517 pool addresses are needed for 1,000,000 subscribers. The compression ratio is one tenth of the case of dynamic assignment." [Senthil] Going by the same standards of using the entire available port ra= nge, you should require 15259 addresses. But the point is the cost of static allocation to dynamic allocation is 10:= 1, which is huge and given the fact there is only so little address space that is available, it should be used efficiently. Just by loo= king at that calculation, it seems amply clear that dynamic is preferred ov= er static, as you have noted. That leads us to the next topic on logging. " In addition, the indicator of the allocation and deallocation are needed because it assures that the identified subscriber certainly had been using the translated IP address and port. Plus, including the index of the CGN host, the average size of NAT log is about 120 byte in ASCII format. Every active subscriber generate 400 sessions in average for a certain amount of time. It is assumed that the event happens every 5 minute in the most severe condition. The size of the log (L) for time frame (T) can be estimated as follows: The size of log (L) =3D # of Subscriber (S) * a * N * 120byte * 2 * ( Time frame(T) / 5 min. ) It should be noted that the log is generated at the timing of NAT table creation and freeing. As the result, for 1,000,000 users, the size of log is piled up to 6.4 terabytes per day. The verification result confirm the existing estimation referred in [I-D.donley-behave-deterministic-cgn]." [Senthil] I think it should be mentioned that with binary format for the ab= ove logging information, you need 26 bytes. Transport Protocol - 1 byte Source IP address:port =96 6 bytes Source IP address:port after translation =96 6 bytes Timestamp =96 8 bytes Add/Delete =96 1 byte Subscriber ID/VRF ID =96 4 bytes I would help a lot to add the binary logging calculation in addition to the= ascii format to help people choose the right method for them. Going by the same formula you need 1.36 TB/day with binary logging. Assumin= g that the compression ratio is the same For both ascii and binary data, you have 1/4-1/5th of advantage with binary= logging. You spread the cost of 1.36TB across a 1,000,000 subscribers assuming cost = of 1TB is US$80, we come to 0.00008 cents/subscriber/day or 0.024 cents/subscriber/month. Ev= en with ASCII logging requirements this doesn=92t sound like a mammoth cost= . Sure, there are other operating expenses involved but comparing that with t= he efficiency of a dynamic port allocation mechanism and requiring 10 times= less public addresses seems to be a compelling winning argument than changing ev= ery CGN implementation to save for logging costs. Thanks Senthil From: kaname nishizuka > Date: Tuesday, April 2, 2013 4:37 AM To: "behave@ietf.org" > Cc: Shin Miyakawa > Subject: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-dep= loyment-considerations-00.txt Dear all, I'm kaname from NTT communications in Japan. We are testing CGN under the support of Japanese Government. Now, we've uploaded a new draft based on the result of our verification. The useful information about the average consumption of the ports are avail= able on the document. Please look through it, and all kind of feedback are welcome. By conducting realistic experiment, this draft is answering to "draft-ietf-= behave-lsn-requirements-10" which will be the newest RFC very soon. The document is *NOT* intended to be Standards Track. It's for Informationa= l. The wrong description is just mere mistake, so we'll soon correct it in the= next revision. The full report of our work will be available soon on the Web in English. I'll also announce it when it's available to this mailing-list. Best regards, kaname -------- Original Message -------- Subject: New Version Notification for draft-nishizuka-cgn-deployment= -considerations-00.txt Date: Thu, 28 Mar 2013 07:12:25 -0700 From: internet-drafts@ietf.org To: kaname@nttv6.jp A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00.txt has been successfully submitted by Kaname Nishizuka and posted to the IETF repository. Filename: draft-nishizuka-cgn-deployment-considerations Revision: 00 Title: Carrier-Grade-NAT (CGN) Deployment Considerations. Creation date: 2013-03-29 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-de= ployment-considerations-00.txt Status: http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deploy= ment-considerations Htmlized: http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-= considerations-00 Abstract: This document provides deployment considerations for Carrier-Grade- NAT (CGN) based on the verification result include the investigation of the number of sessions of applications. The verification was conducted in StarBED which is one of the largest scale network experiment environment in Japan. A million of subscribers was emulated and it revealed the realistic behavior of CGN. The IETF Secretariat -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 --_000_CB1B483277FEC94E9B58357040EE5D0232430EAExmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <68089BB594B0424EA7D87965371D11BC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Kaname,
It is a pretty interesting study. I have a few comments on the sections on = your IP address requirements calculations.= In the dynamic assignment, the ports of pool address are allocated 
  =20


"   # of pool address (P) =
=3D # of Subscriber (S) * a * N / (65536 - R)

   Here, (R) is reserved TCP/UDP port list referred in
   [I-D.donley-behave-=
deterministic-cgn].  CGN should eliminate the
   wellknown ports (0-1023 for TCP and UDP) to avoid the bad
   interpretation from destination servers.  It is natural to translate
   source port of outgoing packet to ephemeral ports.  The ports after
   32768 is considered to be used without any problems because ephemeral
   ports are 32768-61000 for Linux and 49152-65535 in the IANA
   recommendations.  As the result, 3,051 pool addresses are sufficient
   for 1,000,000 subscribers.  The feasibility of configuration was
   confirmed in the verification."

[Senthil] Most of the NATs use the entire port sp=
ace from 1024-65536, did you find differently?
If you had used the entire port space, you would =
only require 1526 addresses instead of 3051.
I think not using the 1024-32768 is not practical=
 and inefficient. 


   On the other hand, in static assignment, the ports are allocated a
   priori for every users.  The pool addresses and ports are reserved to
   every users, so most of them could be a dead stock because there are
   light users and heavy users in aspect of port consumption.  The max
   number of port consumption in all subscribers is the key value for
   static assignment.  The true peak number of the session by a heavy
   user could be over 10,000 sessions.  However it is assumed that such
   a severe consumption of ports to be an abuse, so the number of
   statically assigned port (M) is controllable parameter by each
   providers.  In the static assignment, the required number of the pool
   address is as follows:

   # of pool address (P) =3D # of Subscriber (S) * M / (65536 - R)

   Taking account into the investigation of number of sessions of
   applications, the desirable value of (M) is over 1,000.  As the
   result, no less than 30,517 pool addresses are needed for 1,000,000
   subscribers.  The compression ratio is one tenth of the case of
   dynamic assignment."

[Senthil] Going by the same standards of using the entire available port ra= nge, you should require 15259 addresses.
But the point is the cost of static allocation to dynamic allocation is 10:= 1, which is huge and given the fact there is only so little 
address space that is available, it should be used efficiently. Just by loo= king at that calculation, it seems amply clear that dynamic is preferred ov= er static,
as you have noted.
That leads us to the next topic on logging.

 =20
  " In addition, the indicator of the al=
location and deallocation are
   needed because it assures that the identified subscriber certainly
   had been using the translated IP address and port.  Plus, including
   the index of the CGN host, the average size of NAT log is about 120
   byte in ASCII format.  Every active subscriber generate 400 sessions
   in average for a certain amount of time.  It is assumed that the
   event happens every 5 minute in the most severe condition.  The size
   of the log (L) for time frame (T) can be estimated as follows:

   The size of log (L) =3D # of Subscriber (S) * a * N * 120byte * 2 * (
   Time frame(T) / 5 min. )


   It should be noted that the log is generated at the timing of NA=
T
   table creation and freeing.  As the result, for 1,000,000 users, the
   size of log is piled up to 6.4 terabytes per day.  The verification
   result confirm the existing estimation referred in
   [I-D.donley-behave-=
deterministic-cgn]."

=
[Senthil] I think it should be =
mentioned that with binary format for the above logging information, you ne=
ed 26 bytes.
=
Transport Protocol -  1 byte
 Source IP address:port =96 6 bytes
 Source IP address:port after translation =96 6 bytes
 Timestamp =96 8 bytes=

 Add/Delete =96 1 byte<=
/font>
 Subscriber ID/VRF ID =96 4 bytes

I would help a l=
ot to add the binary logging calculation in addition to the ascii format to=
 help people choose the right method for them.
Going by =
the same formula you need 1.36 TB/day with binary logging. Assuming that th=
e compression ratio is the same 
For=
 both ascii and binary data, you have 1/4-1/5th of advantage with binary lo=
gging.
You spread the cost of 1.36TB across a 1,00=
0,000 subscribers assuming cost of 1TB is US$80, 
=
we come to 0.00008 cents/subscriber/day or 0.024 cents/subscriber/month. Ev=
en with ASCII logging requirements this doesn=92t sound like a mammoth cost=
.
Sure, there are other operating expense=
s involved but comparing that with the efficiency of a dynamic port allocat=
ion mechanism and requiring 10 times less 
public addresses seems to be a =
compelling winning argument than changing every CGN implementation to save =
for logging costs.

Thanks
Senthil




From: kaname nishizuka <kaname@nttv6.jp>
Date: Tuesday, April 2, 2013 4:37 A= M
To: "behave@ietf.org" <= behave@ietf.org>
Cc: Shin Miyakawa <miyakawa@nttv6.jp>
Subject: [BEHAVE] Fwd: New Version = Notification for draft-nishizuka-cgn-deployment-considerations-00.txt

Dear all,

I'm kaname from NTT communications in Japan.
We are testing CGN under the support of Japanese Government.
Now, we've uploaded a new draft based on the result of our verification.
The useful information about the average consumption of the ports are avail=
able on the document.
Please look through it, and all kind of feedback are welcome.

By conducting realistic experiment, this draft is answering to "draft-=
ietf-behave-lsn-requirements-10" which will be the newest RFC very soo=
n.

The document is *NOT* intended to be Standards Track. It's for Informationa=
l.
The wrong description is just mere mistake, so we'll soon correct it in the=
 next revision.

The full report of our work will be available soon on the Web in English.
I'll also announce it when it's available to this mailing-list.

Best regards,

kaname



-------- Original Message --------
Subject: New Version Notification for draft-nishizuka-cgn-deployment-considerati= ons-00.txt
Date: Thu, 28 Mar 2013 07:12:25 -0700
From: internet-drafts@ietf.org
To: kaname@nttv6.jp 


A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00=
.txt
has been successfully submitted by Kaname Nishizuka and posted to the
IETF repository.

Filename:	 draft-nishizuka-cgn-deployment-considerations
Revision:	 00
Title:		 Carrier-Grade-NAT (CGN) Deployment Considerations.
Creation date:	 2013-03-29
Group:		 Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-nishizuk=
a-cgn-deployment-considerations-00.txt
Status:          http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deploymen=
t-considerations
Htmlized:        http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-consi=
derations-00


Abstract:
   This document provides deployment considerations for Carrier-Grade-
   NAT (CGN) based on the verification result include the investigation
   of the number of sessions of applications.  The verification was
   conducted in StarBED which is one of the largest scale network
   experiment environment in Japan.  A million of subscribers was
   emulated and it revealed the realistic behavior of CGN.

                                                                           =
      =20


The IETF Secretariat






--=20
----=20
Kaname Nishizuka
Innovative Architecture Center
NTT Communications Corporation
+81-50-3812-4704
 --_000_CB1B483277FEC94E9B58357040EE5D0232430EAExmbrcdx15ciscoc_-- From simon.perreault@viagenie.ca Wed Apr 3 01:44: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 7CB1E21F8548 for ; Wed, 3 Apr 2013 01:44:31 -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 yLov42jCV2Yp for ; Wed, 3 Apr 2013 01:44:30 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5D21F853D for ; Wed, 3 Apr 2013 01:44:24 -0700 (PDT) Received: from [127.0.0.1] (161.renater.fr [193.49.159.161]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0767B403AF for ; Wed, 3 Apr 2013 04:44:23 -0400 (EDT) Message-ID: <515BEC30.3060609@viagenie.ca> Date: Wed, 03 Apr 2013 10:45:36 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: behave@ietf.org References: <20130328141225.16450.37444.idtracker@ietfa.amsl.com> <515A8B2E.9060706@nttv6.jp> <515A98BA.9030409@nttv6.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Wed, 03 Apr 2013 08:44:31 -0000 Le 2013-04-02 18:07, Dan Wing a écrit : > http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#section-5.3.2 > would benefit from some discussion of the privacy impact of an ISP > storing destination information, and should also describe memory impact > (in the CGN) if the subscriber uses the same source port to visit many > different destinations (if CGN does not store the list of destinations, > CGN will generate a log for every packet sent to a new destination). > Applications such as bittorrent can consume a lot of memory in a CGN > that is configured for destination logging. Another issue with this section is that it ignores bulk port allocation. It says: "It is confirmed by the verification that by logging destination address, only 4% of amount of log is increased in ASCII format." The percentage would be much higher with bulk port allocation. Simon From simon.perreault@viagenie.ca Wed Apr 3 01:51:51 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 A5FDB21F87D5 for ; Wed, 3 Apr 2013 01:51:51 -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 qg9FHLSvl8Ta for ; Wed, 3 Apr 2013 01:51:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 04F3C21F86BA for ; Wed, 3 Apr 2013 01:51:51 -0700 (PDT) Received: from [127.0.0.1] (161.renater.fr [193.49.159.161]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 36264403AF for ; Wed, 3 Apr 2013 04:51:20 -0400 (EDT) Message-ID: <515BEDD1.9060603@viagenie.ca> Date: Wed, 03 Apr 2013 10:52:33 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Wed, 03 Apr 2013 08:51:51 -0000 Le 2013-04-03 00:03, Senthil Sivakumar (ssenthil) a écrit : > [Senthil] Going by the same standards of using the entire available > port range, you should require 15259 addresses. But the point is the > cost of static allocation to dynamic allocation is 10:1, which is > huge and given the fact there is only so little address space that is > available, it should be used efficiently. Just by looking at that > calculation, it seems amply clear that dynamic is preferred over > static, as you have noted. My reaction was different. I was thinking "only 10:1, this is pretty good for static." > You spread the cost of 1.36TB across a 1,000,000 subscribers assuming > cost of 1TB is US$80, we come to 0.00008 cents/subscriber/day or > 0.024 cents/subscriber/month. Even with ASCII logging requirements > this doesn’t sound like a mammoth cost. Sure, there are other > operating expenses involved The raw cost of storage is probably insignificant compared to those "other operating expenses"... Simon From ssenthil@cisco.com Wed Apr 3 06:19: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 D59AC21F8CEC for ; Wed, 3 Apr 2013 06:19:39 -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=[AWL=0.000, 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 P3yLoc11uSaE for ; Wed, 3 Apr 2013 06:19:39 -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 96C1821F8CD2 for ; Wed, 3 Apr 2013 06:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1779; q=dns/txt; s=iport; t=1364995177; x=1366204777; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Q1RSBUNmOX8mr7GCwvj79bPiyhsrAaqgcaKOREV7YvA=; b=JDM75ldyW/R3GOnnBVaJB9GTh0aRLNYHbPVfV9IpinkIn8UjrB06zF7p g1QsU4e9LTRyFu6UMjQ5ukVzRlRFdWlIFbj8El2eNU9EkX7TnrmBTfjKK At3/czEnVsUMSykfkL7GOiGoJhJYilJV6RyAEZfWxkWmn4bxHip9ng+Nf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAB8sXFGtJXG+/2dsb2JhbABDgwc2wD+BDBZ0giEBBAEBAWcECRQBCCIZMgslAgQTCIgMDJ9OoRkEjW17OIJfYQOIQp80gVWBNoFrPQ X-IronPort-AV: E=Sophos;i="4.87,401,1363132800"; d="scan'208";a="194540807" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 03 Apr 2013 13:19:18 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r33DJIsm008127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Apr 2013 13:19:18 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.42]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 08:19:18 -0500 From: "Senthil Sivakumar (ssenthil)" To: "behave@ietf.org" Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt Thread-Index: AQHOMG3Xhnjd2jRD/UGEr6B7si3Slw== Date: Wed, 3 Apr 2013 13:19:16 +0000 Message-ID: In-Reply-To: <515BEDD1.9060603@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.132] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <219D82CA300A8546916A2F892675818E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Wed, 03 Apr 2013 13:19:40 -0000 On 4/3/13 4:52 AM, "Simon Perreault" wrote: >Le 2013-04-03 00:03, Senthil Sivakumar (ssenthil) a =E9crit : >> [Senthil] Going by the same standards of using the entire available >> port range, you should require 15259 addresses. But the point is the >> cost of static allocation to dynamic allocation is 10:1, which is >> huge and given the fact there is only so little address space that is >> available, it should be used efficiently. Just by looking at that >> calculation, it seems amply clear that dynamic is preferred over >> static, as you have noted. > >My reaction was different. I was thinking "only 10:1, this is pretty >good for static." Why so? With the same 15259 addresses that I have, I could add 10 times more subscribers, I can add up to 10Million subscribers as per this example, that is 10 times more=20 revenue. That was also the revenue lost, why is it good for business? > >> You spread the cost of 1.36TB across a 1,000,000 subscribers assuming >> cost of 1TB is US$80, we come to 0.00008 cents/subscriber/day or >> 0.024 cents/subscriber/month. Even with ASCII logging requirements >> this doesn=B9t sound like a mammoth cost. Sure, there are other >> operating expenses involved > >The raw cost of storage is probably insignificant compared to those >"other operating expenses"... Can you put a dollar value to the significant other operating expenses? Does it offset the 10x revenue generated by doing dynamic port allocation and logging ? I think the key would be what the business proposition is at the end of the day. Senthil > >Simon >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Wed Apr 3 06:58:15 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 BBCEA21F86C1 for ; Wed, 3 Apr 2013 06:58:15 -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 8vbW-VEWjZWA for ; Wed, 3 Apr 2013 06:58:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 493E121F862B for ; Wed, 3 Apr 2013 06:58:14 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:ac04:7d6e:9b3e:38d3]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6B9BF4150E for ; Wed, 3 Apr 2013 09:58:13 -0400 (EDT) Message-ID: <515C35BD.7060503@viagenie.ca> Date: Wed, 03 Apr 2013 15:59:25 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Wed, 03 Apr 2013 13:58:15 -0000 Le 2013-04-03 15:19, Senthil Sivakumar (ssenthil) a écrit : >> My reaction was different. I was thinking "only 10:1, this is pretty >> good for static." > > Why so? With the same 15259 addresses that I have, I could add 10 times > more subscribers, > I can add up to 10Million subscribers as per this example, that is 10 > times more > revenue. That was also the revenue lost, why is it good for business? You're assuming that the limiting factor is addresses. You're assuming that even with dynamic allocation, the ISP is going to "fill" all its available public space. That's not what the text says. All the text says is that dynamic allows ~10 times more users behind each address than static. Nowhere does it say that static isn't "good enough". >>> You spread the cost of 1.36TB across a 1,000,000 subscribers assuming >>> cost of 1TB is US$80, we come to 0.00008 cents/subscriber/day or >>> 0.024 cents/subscriber/month. Even with ASCII logging requirements >>> this doesnąt sound like a mammoth cost. Sure, there are other >>> operating expenses involved >> >> The raw cost of storage is probably insignificant compared to those >> "other operating expenses"... > > Can you put a dollar value to the significant other operating expenses? > Does it offset the 10x revenue generated by doing dynamic > port allocation and logging ? I think the key would be what the business > proposition is at the end of the day. It would vary per organization. An organization that is already well equipped in logging infrastructure and procedures would have a much lower cost deploying additional logging for CGN. But an organization that doesn't have this infrastructure would quickly say "no way!" and would look hard for alternatives. But all this is over-generalization, of course. Simon From ssenthil@cisco.com Wed Apr 3 11:57: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 2711B21F8BF8 for ; Wed, 3 Apr 2013 11:57:11 -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 rbnYsDFDl4fz for ; Wed, 3 Apr 2013 11:57:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5117021F8B6D for ; Wed, 3 Apr 2013 11:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2946; q=dns/txt; s=iport; t=1365015430; x=1366225030; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JN6jNTp9mXPNP7ZzF/N3GPGx83hYL0C/pQ2PQ1A+KqA=; b=eJvTHuyOqJCGxZmXNpOz2r+R3deOtP+8kZyuUuUL3UmUDMHHrj5l5RqN ZwLT/vHu7sMDhk4E971B1LucXcJz08EdejrB1jM2Ux1TMo+/gJjvPUhD7 +qnKT0NecAR4j5ys2f4zN79euIJcytAdrVI2R6qJO4RNtrZGzMz/CHmkU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FABx7XFGtJV2b/2dsb2JhbABDgwc2wEiBDRZ0giEBBAEBAWcECRQBCCIZMgslAgQTCIgMDJ9DoQkEjW17OIJfYQOndoFVgTaBaz0 X-IronPort-AV: E=Sophos;i="4.87,402,1363132800"; d="scan'208";a="194769560" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 03 Apr 2013 18:57:06 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r33Iv6WX017733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Apr 2013 18:57:06 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.42]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 3 Apr 2013 13:57:06 -0500 From: "Senthil Sivakumar (ssenthil)" To: "behave@ietf.org" Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt Thread-Index: AQHOMJ0IkiEqeCVHx02R0YbUwz8tLA== Date: Wed, 3 Apr 2013 18:57:05 +0000 Message-ID: In-Reply-To: <515C35BD.7060503@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.132] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Wed, 03 Apr 2013 18:57:11 -0000 On 4/3/13 9:59 AM, "Simon Perreault" wrote: >Le 2013-04-03 15:19, Senthil Sivakumar (ssenthil) a =E9crit : >>> My reaction was different. I was thinking "only 10:1, this is pretty >>> good for static." >> >> Why so? With the same 15259 addresses that I have, I could add 10 times >> more subscribers, >> I can add up to 10Million subscribers as per this example, that is 10 >> times more >> revenue. That was also the revenue lost, why is it good for business? > >You're assuming that the limiting factor is addresses. You're assuming >that even with dynamic allocation, the ISP is going to "fill" all its >available public space. That's not what the text says. All the text says >is that dynamic allows ~10 times more users behind each address than >static. Nowhere does it say that static isn't "good enough". If it is not the address, what is the limiting factor? The reason ISP is deploying CGN is the shortage of addresses and cant provide a single address to each of his subscribers. Maybe you meant to say the address is not the only limiting factor. I never said the text was saying static isnt good enough :-), I deduced from the study that the usage of ports is far more compellingly efficient with dynamic port allocation and the cost of logging infra can be justified. Most of the studies in the past projected how bad the logging problem is but didn=92t have any data on the other side of the equation on how inefficient the static port allocation is. I wouldn=92t want this draft to say one is better than the other, but let the operators choose, if 10:1 static to dynamic port allocation is justified for their deployment. Senthil > >>>> You spread the cost of 1.36TB across a 1,000,000 subscribers assuming >>>> cost of 1TB is US$80, we come to 0.00008 cents/subscriber/day or >>>> 0.024 cents/subscriber/month. Even with ASCII logging requirements >>>> this doesn=B9t sound like a mammoth cost. Sure, there are other >>>> operating expenses involved >>> >>> The raw cost of storage is probably insignificant compared to those >>> "other operating expenses"... >> >> Can you put a dollar value to the significant other operating expenses? >> Does it offset the 10x revenue generated by doing dynamic >> port allocation and logging ? I think the key would be what the business >> proposition is at the end of the day. > >It would vary per organization. An organization that is already well >equipped in logging infrastructure and procedures would have a much >lower cost deploying additional logging for CGN. But an organization >that doesn't have this infrastructure would quickly say "no way!" and >would look hard for alternatives. But all this is over-generalization, >of course. > >Simon >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From lee.howard@twcable.com Wed Apr 3 13:40: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 9347B21F8E5C for ; Wed, 3 Apr 2013 13:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 XEVfCIOTVX3A for ; Wed, 3 Apr 2013 13:40:12 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6654321F8E5A for ; Wed, 3 Apr 2013 13:40:09 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,403,1363147200"; d="scan'208";a="53028525" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Apr 2013 16:39:41 -0400 Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 3 Apr 2013 16:40:05 -0400 From: "Howard, Lee" To: "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" Date: Wed, 3 Apr 2013 16:40:05 -0400 Thread-Topic: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt Thread-Index: Ac4wq2uqrjXCQTIUSeu2L+RgtNPEYA== 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.2.130206 acceptlanguage: en-US Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Wed, 03 Apr 2013 20:40:12 -0000 On 4/3/13 2:57 PM, "Senthil Sivakumar (ssenthil)" wrote: > > >On 4/3/13 9:59 AM, "Simon Perreault" wrote: > >>Le 2013-04-03 15:19, Senthil Sivakumar (ssenthil) a =E9crit : >>>> My reaction was different. I was thinking "only 10:1, this is pretty >>>> good for static." >>> >>> Why so? With the same 15259 addresses that I have, I could add 10 times >>> more subscribers, >>> I can add up to 10Million subscribers as per this example, that is 10 >>> times more >>> revenue. That was also the revenue lost, why is it good for business? >> >>You're assuming that the limiting factor is addresses. You're assuming >>that even with dynamic allocation, the ISP is going to "fill" all its >>available public space. That's not what the text says. All the text says >>is that dynamic allows ~10 times more users behind each address than >>static. Nowhere does it say that static isn't "good enough". I have not been following this thread closely, but it keeps popping up. It doesn't say it's not good enough, but it spends two paragraphs describing why it is inferior. And says, "In the aspect of the efficiency, the dynamic assignment is preferable than the static assignment. However the size of the log is the main consideration." I agree that there's an important consideration in whether more efficiency is "compression ratio" is needed. If static port allocation allows an ISP to take the addresses they would normally consume in one month and make them last for five years (60:1 compression), then just a month or a couple of months' worth of addresses lasts through the transition. By the way, improving your CGN does not increase revenue. > >If it is not the address, what is the limiting factor? The reason ISP is >deploying CGN is the shortage of addresses and cant provide a single >address to each >of his subscribers. Maybe you meant to say the address is not the only >limiting factor. >I never said the text was saying static isnt good enough :-), I deduced >from the study that >the usage of ports is far more compellingly efficient with dynamic port >allocation and the cost >of logging infra can be justified. Maybe it should say, "IF the cost of logging can be justified." Even 30% of 6.2TB per day is a lot of data, and depending on your data retention requirements, might require a significant system to retrieve records efficiently. > >Most of the studies in the past projected how bad the logging problem is >but didn=92t have >any data on the other side of the equation on how inefficient the static >port allocation is. >I wouldn=92t want this draft to say one is better than the other, but let >the operators choose, if 10:1 >static to dynamic port allocation is justified for their deployment. It could be clearer in the draft. Lee > >Senthil > >> >>>>> You spread the cost of 1.36TB across a 1,000,000 subscribers assuming >>>>> cost of 1TB is US$80, we come to 0.00008 cents/subscriber/day or >>>>> 0.024 cents/subscriber/month. Even with ASCII logging requirements >>>>> this doesn=B9t sound like a mammoth cost. Sure, there are other >>>>> operating expenses involved >>>> >>>> The raw cost of storage is probably insignificant compared to those >>>> "other operating expenses"... >>> >>> Can you put a dollar value to the significant other operating expenses? >>> Does it offset the 10x revenue generated by doing dynamic >>> port allocation and logging ? I think the key would be what the >>>business >>> proposition is at the end of the day. >> >>It would vary per organization. An organization that is already well >>equipped in logging infrastructure and procedures would have a much >>lower cost deploying additional logging for CGN. But an organization >>that doesn't have this infrastructure would quickly say "no way!" and >>would look hard for alternatives. But all this is over-generalization, >>of course. >> >>Simon >>_______________________________________________ >>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 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From kaname@nttv6.jp Wed Apr 3 18:57: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 D03A721F8EAD for ; Wed, 3 Apr 2013 18:57:45 -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, 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 QNEU7K+BZv2U for ; Wed, 3 Apr 2013 18:57:45 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by ietfa.amsl.com (Postfix) with ESMTP id CA32621F8EA5 for ; Wed, 3 Apr 2013 18:57:44 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 64866BDC53; Thu, 4 Apr 2013 10:57:40 +0900 (JST) Received: from [IPv6:2402:c800:ff06:0:40b2:ff61:6375:30a9] (unknown [IPv6:2402:c800:ff06:0:40b2:ff61:6375:30a9]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 56D15E22D1; Thu, 4 Apr 2013 10:57:40 +0900 (JST) Message-ID: <515CDE13.5080003@nttv6.jp> Date: Thu, 04 Apr 2013 10:57:39 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Dan Wing References: <20130328141225.16450.37444.idtracker@ietfa.amsl.com> <515A8B2E.9060706@nttv6.jp> <515A98BA.9030409@nttv6.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Shin Miyakawa , behave@ietf.org Subject: Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Thu, 04 Apr 2013 01:57:45 -0000 Thanks for your comment. > I like the description of DNS location at http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#section-6.3, as this is an important mechanism to reduce the transactional load on the CGN. Have you analyzed the number of subscribers that over-ride the ISP-provided DNS servers to use other DNS servers (e.g., Google, OpenDNS), as that DNS query traffic will traverse the CGN. Unfortunately, we have not yet investigated the proportion of the subscribers who are using provided DNS versus who are using public DNS. Before investigating it, the test we managed to do was that all DNS traffic traverse the CGN as the most severe case. The proportion could be different in providers, but the impact of the DNS query traffic is relatively small if DNS timeout is adjusted. > http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#section-5.3.2 would benefit from some discussion of the privacy impact of an ISP storing destination information, and should also describe memory impact (in the CGN) if the subscriber uses the same source port to visit many different destinations (if CGN does not store the list of destinations, CGN will generate a log for every packet sent to a new destination). Applications such as bittorrent can consume a lot of memory in a CGN that is configured for destination logging. > We also should care for port-overlapping behavior. kaname (2013/04/03 1:07), Dan Wing wrote: > On Apr 2, 2013, at 1:37 AM, kaname nishizuka wrote: > >> Dear all, >> >> I'm kaname from NTT communications in Japan. >> We are testing CGN under the support of Japanese Government. >> Now, we've uploaded a new draft based on the result of our verification. >> The useful information about the average consumption of the ports are available on the document. >> Please look through it, and all kind of feedback are welcome. > Thanks for publishing this document. > I like the description of DNS location at http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#section-6.3, as this is an important mechanism to reduce the transactional load on the CGN. Have you analyzed the number of subscribers that over-ride the ISP-provided DNS servers to use other DNS servers (e.g., Google, OpenDNS), as that DNS query traffic will traverse the CGN. > http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00#section-5.3.2 would benefit from some discussion of the privacy impact of an ISP storing destination information, and should also describe memory impact (in the CGN) if the subscriber uses the same source port to visit many different destinations (if CGN does not store the list of destinations, CGN will generate a log for every packet sent to a new destination). Applications such as bittorrent can consume a lot of memory in a CGN that is configured for destination logging. > > -d > > >> By conducting realistic experiment, this draft is answering to "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC very soon. >> >> The document is *NOT* intended to be Standards Track. It's for Informational. >> The wrong description is just mere mistake, so we'll soon correct it in the next revision. >> >> The full report of our work will be available soon on the Web in English. >> I'll also announce it when it's available to this mailing-list. >> >> Best regards, >> >> kaname >> >> >> >> >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt >>> Date: Thu, 28 Mar 2013 07:12:25 -0700 >>> From: internet-drafts@ietf.org >>> To: kaname@nttv6.jp >>> >>> A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00.txt >>> has been successfully submitted by Kaname Nishizuka and posted to the >>> IETF repository. >>> >>> Filename: draft-nishizuka-cgn-deployment-considerations >>> Revision: 00 >>> Title: Carrier-Grade-NAT (CGN) Deployment Considerations. >>> Creation date: 2013-03-29 >>> Group: Individual Submission >>> Number of pages: 16 >>> URL: http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-considerations-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerations >>> Htmlized: http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00 >>> >>> >>> Abstract: >>> This document provides deployment considerations for Carrier-Grade- >>> NAT (CGN) based on the verification result include the investigation >>> of the number of sessions of applications. The verification was >>> conducted in StarBED which is one of the largest scale network >>> experiment environment in Japan. A million of subscribers was >>> emulated and it revealed the realistic behavior of CGN. >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> >> >> -- >> ---- >> Kaname Nishizuka >> Innovative Architecture Center >> NTT Communications Corporation >> +81-50-3812-4704 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 From dwing@cisco.com Wed Apr 3 19:21: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 A38C31F0CF7 for ; Wed, 3 Apr 2013 19:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lYqjAWHLU0tg for ; Wed, 3 Apr 2013 19:21:22 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BF16F1F0CE0 for ; Wed, 3 Apr 2013 19:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6131; q=dns/txt; s=iport; t=1365042082; x=1366251682; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BZjadre9IOkt/iqSxqq1BBOOmMD9yzYmQH0Og10lB4A=; b=N68lCpyiKvOy2AMPZvvzm0MKqM1QBX4zkcyY3vEunAi0TzjzZHtza5GN qi7Sd3GqatTcO4rjkbq1a1vSrj2HRaQDod3I2IVcqYU36Xl2bp/UEXMSV VL+yZYFE0XeVaWgpfuhGztoCH/NHK4NMUDXRrSJfs0U1pbOHv/+MvMHQE M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADrjXFGrRDoG/2dsb2JhbABDgwY2wQOBDBZ0gh8BAQEDAQEBAWQHCQIFBwQLEQECAQIBLiciBggGEwmIBQUNwEWNYoEEKAsHBoJZYQOIeo1xgR+PbIFVgVYcgS8 X-IronPort-AV: E=Sophos;i="4.87,404,1363132800"; d="scan'208";a="75206713" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Apr 2013 02:21:22 +0000 Received: from sjc-vpn7-1110.cisco.com (sjc-vpn7-1110.cisco.com [10.21.148.86]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r342LKYL029477; Thu, 4 Apr 2013 02:21:20 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <515CDE13.5080003@nttv6.jp> Date: Wed, 3 Apr 2013 19:21:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130328141225.16450.37444.idtracker@ietfa.amsl.com> <515A8B2E.9060706@nttv6.jp> <515A98BA.9030409@nttv6.jp> <515CDE13.5080003@nttv6.jp> To: kaname nishizuka X-Mailer: Apple Mail (2.1503) Cc: Shin Miyakawa , behave@ietf.org Subject: Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Thu, 04 Apr 2013 02:21:23 -0000 On Apr 3, 2013, at 6:57 PM, kaname nishizuka wrote: > Thanks for your comment. >=20 >> I like the description of DNS location at = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0#section-6.3, as this is an important mechanism to reduce the = transactional load on the CGN. Have you analyzed the number of = subscribers that over-ride the ISP-provided DNS servers to use other DNS = servers (e.g., Google, OpenDNS), as that DNS query traffic will traverse = the CGN. > Unfortunately, we have not yet investigated the proportion of the = subscribers who are using provided DNS versus who are using public DNS. > Before investigating it, the test we managed to do was that all DNS = traffic traverse the CGN as the most severe case. > The proportion could be different in providers, but the impact of the = DNS query traffic is relatively small if DNS timeout is adjusted. Yeah, and most of the DNS traffic is UDP (until we have larger records) = so even if the UDP timers were pretty long I bet the user port limit = wouldn't be exhausted. >> = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0#section-5.3.2 would benefit from some discussion of the privacy impact = of an ISP storing destination information, and should also describe = memory impact (in the CGN) if the subscriber uses the same source port = to visit many different destinations (if CGN does not store the list of = destinations, CGN will generate a log for every packet sent to a new = destination). Applications such as bittorrent can consume a lot of = memory in a CGN that is configured for destination logging. >>=20 > We also should care for port-overlapping behavior. Yes, I believe it's the same thing using a different term. -d > kaname >=20 > (2013/04/03 1:07), Dan Wing wrote: >> On Apr 2, 2013, at 1:37 AM, kaname nishizuka wrote: >>=20 >>> Dear all, >>>=20 >>> I'm kaname from NTT communications in Japan. >>> We are testing CGN under the support of Japanese Government. >>> Now, we've uploaded a new draft based on the result of our = verification. >>> The useful information about the average consumption of the ports = are available on the document. >>> Please look through it, and all kind of feedback are welcome. >> Thanks for publishing this document. >> I like the description of DNS location at = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0#section-6.3, as this is an important mechanism to reduce the = transactional load on the CGN. Have you analyzed the number of = subscribers that over-ride the ISP-provided DNS servers to use other DNS = servers (e.g., Google, OpenDNS), as that DNS query traffic will traverse = the CGN. >> = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0#section-5.3.2 would benefit from some discussion of the privacy impact = of an ISP storing destination information, and should also describe = memory impact (in the CGN) if the subscriber uses the same source port = to visit many different destinations (if CGN does not store the list of = destinations, CGN will generate a log for every packet sent to a new = destination). Applications such as bittorrent can consume a lot of = memory in a CGN that is configured for destination logging. >>=20 >> -d >>=20 >>=20 >>> By conducting realistic experiment, this draft is answering to = "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC = very soon. >>>=20 >>> The document is *NOT* intended to be Standards Track. It's for = Informational. >>> The wrong description is just mere mistake, so we'll soon correct it = in the next revision. >>>=20 >>> The full report of our work will be available soon on the Web in = English. >>> I'll also announce it when it's available to this mailing-list. >>>=20 >>> Best regards, >>>=20 >>> kaname >>>=20 >>>=20 >>>=20 >>>=20 >>>> -------- Original Message -------- >>>> Subject: New Version Notification for = draft-nishizuka-cgn-deployment-considerations-00.txt >>>> Date: Thu, 28 Mar 2013 07:12:25 -0700 >>>> From: internet-drafts@ietf.org >>>> To: kaname@nttv6.jp >>>>=20 >>>> A new version of I-D, = draft-nishizuka-cgn-deployment-considerations-00.txt >>>> has been successfully submitted by Kaname Nishizuka and posted to = the >>>> IETF repository. >>>>=20 >>>> Filename: draft-nishizuka-cgn-deployment-considerations >>>> Revision: 00 >>>> Title: Carrier-Grade-NAT (CGN) Deployment = Considerations. >>>> Creation date: 2013-03-29 >>>> Group: Individual Submission >>>> Number of pages: 16 >>>> URL: = http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-conside= rations-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerati= ons >>>> Htmlized: = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0 >>>>=20 >>>>=20 >>>> Abstract: >>>> This document provides deployment considerations for = Carrier-Grade- >>>> NAT (CGN) based on the verification result include the = investigation >>>> of the number of sessions of applications. The verification was >>>> conducted in StarBED which is one of the largest scale network >>>> experiment environment in Japan. A million of subscribers was >>>> emulated and it revealed the realistic behavior of CGN. >>>>=20 >>>> = =20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> --=20 >>> ---- >>> Kaname Nishizuka >>> Innovative Architecture Center >>> NTT Communications Corporation >>> +81-50-3812-4704 >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >=20 >=20 > --=20 > ---- > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 >=20 From kaname@nttv6.jp Wed Apr 3 19:39: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 62C5711E80A2 for ; Wed, 3 Apr 2013 19:39: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=[AWL=0.000, 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 y2lz0sIerW-l for ; Wed, 3 Apr 2013 19:39:12 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by ietfa.amsl.com (Postfix) with ESMTP id BEFC011E80A4 for ; Wed, 3 Apr 2013 19:39:11 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 14A30BDC21; Thu, 4 Apr 2013 11:39:05 +0900 (JST) Received: from [IPv6:2402:c800:ff06:0:40b2:ff61:6375:30a9] (unknown [IPv6:2402:c800:ff06:0:40b2:ff61:6375:30a9]) by z.nttv6.jp (NTTv6MTA) with ESMTP id EF042E22D1; Thu, 4 Apr 2013 11:39:04 +0900 (JST) Message-ID: <515CE7C7.2040605@nttv6.jp> Date: Thu, 04 Apr 2013 11:39:03 +0900 From: kaname nishizuka User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Shin Miyakawa , "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Thu, 04 Apr 2013 02:39:13 -0000 Thank you for your comments, > [Senthil] Most of the NATs use the entire port space from 1024-65536, did you find differently? > > If you had used the entire port space, you would only require 1526 addresses instead of 3051. > > I think not using the 1024-32768 is not practical and inefficient. What you pointed out is reasonable enough, but our concern is that there are de-facto well-known port in 1024-32768 like 1433/tcp. Especially in the static assignment, the subscriber who has a "dirty" range would be attacked more frequently than others. We know that most of the NATs use the entire port space from 1024-65536, but we described it in the most safe side. As you mentioned, the ratio of dynamic:static is the same. > [Senthil] I think it should be mentioned that with binary format for the above logging information, you need 26 bytes. > > Transport Protocol - 1 byte > > Source IP address:port – 6 bytes > Source IP address:port after translation – 6 bytes > Timestamp – 8 bytes > > Add/Delete – 1 byte > > Subscriber ID/VRF ID – 4 bytes > I agree with that. It's useful and it supports the logic. Thanks, kaname (2013/04/03 7:03), Senthil Sivakumar (ssenthil) wrote: > Hi Kaname, > It is a pretty interesting study. I have a few comments on the sections on your IP address requirements calculations.In the dynamic assignment, the ports of pool address are allocated > > > > > > " # of pool address (P) = # of Subscriber (S) * a * N / (65536 - R) > > Here, (R) is reserved TCP/UDP port list referred in > [I-D.donley-behave-deterministic-cgn]. CGN should eliminate the > wellknown ports (0-1023 for TCP and UDP) to avoid the bad > interpretation from destination servers. It is natural to translate > source port of outgoing packet to ephemeral ports. The ports after > 32768 is considered to be used without any problems because ephemeral > ports are 32768-61000 for Linux and 49152-65535 in the IANA > recommendations. As the result, 3,051 pool addresses are sufficient > for 1,000,000 subscribers. The feasibility of configuration was > confirmed in the verification." > > [Senthil] Most of the NATs use the entire port space from 1024-65536, did you find differently? > > If you had used the entire port space, you would only require 1526 addresses instead of 3051. > > I think not using the 1024-32768 is not practical and inefficient. > > > > On the other hand, in static assignment, the ports are allocated a > priori for every users. The pool addresses and ports are reserved to > every users, so most of them could be a dead stock because there are > light users and heavy users in aspect of port consumption. The max > number of port consumption in all subscribers is the key value for > static assignment. The true peak number of the session by a heavy > user could be over 10,000 sessions. However it is assumed that such > a severe consumption of ports to be an abuse, so the number of > statically assigned port (M) is controllable parameter by each > providers. In the static assignment, the required number of the pool > address is as follows: > > # of pool address (P) = # of Subscriber (S) * M / (65536 - R) > > Taking account into the investigation of number of sessions of > applications, the desirable value of (M) is over 1,000. As the > result, no less than 30,517 pool addresses are needed for 1,000,000 > subscribers. The compression ratio is one tenth of the case of > dynamic assignment." > > > [Senthil] Going by the same standards of using the entire available port range, you should require 15259 addresses. > But the point is the cost of static allocation to dynamic allocation is 10:1, which is huge and given the fact there is only so little > address space that is available, it should be used efficiently. Just by looking at that calculation, it seems amply clear that dynamic is preferred over static, > as you have noted. > That leads us to the next topic on logging. > > > > " In addition, the indicator of the allocation and deallocation are > needed because it assures that the identified subscriber certainly > had been using the translated IP address and port. Plus, including > the index of the CGN host, the average size of NAT log is about 120 > byte in ASCII format. Every active subscriber generate 400 sessions > in average for a certain amount of time. It is assumed that the > event happens every 5 minute in the most severe condition. The size > of the log (L) for time frame (T) can be estimated as follows: > > The size of log (L) = # of Subscriber (S) * a * N * 120byte * 2 * ( > Time frame(T) / 5 min. ) > > > > It should be noted that the log is generated at the timing of NAT > table creation and freeing. As the result, for 1,000,000 users, the > size of log is piled up to 6.4 terabytes per day. The verification > result confirm the existing estimation referred in > [I-D.donley-behave-deterministic-cgn]." > > [Senthil] I think it should be mentioned that with binary format for the above logging information, you need 26 bytes. > > Transport Protocol - 1 byte > > Source IP address:port – 6 bytes > Source IP address:port after translation – 6 bytes > Timestamp – 8 bytes > > Add/Delete – 1 byte > > Subscriber ID/VRF ID – 4 bytes > > > I would help a lot to add the binary logging calculation in addition to the ascii format to help people choose the right method for them. > > Going by the same formula you need 1.36 TB/day with binary logging. Assuming that the compression ratio is the same > > For both ascii and binary data, you have 1/4-1/5th of advantage with binary logging. > > You spread the cost of 1.36TB across a 1,000,000 subscribers assuming cost of 1TB is US$80, > > we come to 0.00008 cents/subscriber/day or 0.024 cents/subscriber/month. Even with ASCII logging requirements this doesn’t sound like a mammoth cost. > > Sure, there are other operating expenses involved but comparing that with the efficiency of a dynamic port allocation mechanism and requiring 10 times less > > public addresses seems to be a compelling winning argument than changing every CGN implementation to save for logging costs. > > > Thanks > > Senthil > > > > > > > > > From: kaname nishizuka > > Date: Tuesday, April 2, 2013 4:37 AM > To: "behave@ietf.org" > > Cc: Shin Miyakawa > > Subject: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt > > > Dear all, > > I'm kaname from NTT communications in Japan. > We are testing CGN under the support of Japanese Government. > Now, we've uploaded a new draft based on the result of our verification. > The useful information about the average consumption of the ports are available on the document. > Please look through it, and all kind of feedback are welcome. > > By conducting realistic experiment, this draft is answering to "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC very soon. > > The document is *NOT* intended to be Standards Track. It's for Informational. > The wrong description is just mere mistake, so we'll soon correct it in the next revision. > > The full report of our work will be available soon on the Web in English. > I'll also announce it when it's available to this mailing-list. > > Best regards, > > kaname > > > > > > -------- Original Message -------- > Subject: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.txt > Date: Thu, 28 Mar 2013 07:12:25 -0700 > From: internet-drafts@ietf.org > To: kaname@nttv6.jp > > > > A new version of I-D, draft-nishizuka-cgn-deployment-considerations-00.txt > has been successfully submitted by Kaname Nishizuka and posted to the > IETF repository. > > Filename: draft-nishizuka-cgn-deployment-considerations > Revision: 00 > Title: Carrier-Grade-NAT (CGN) Deployment Considerations. > Creation date: 2013-03-29 > Group: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-considerations-00.txt > Status: http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerations > Htmlized: http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-00 > > > Abstract: > This document provides deployment considerations for Carrier-Grade- > NAT (CGN) based on the verification result include the investigation > of the number of sessions of applications. The verification was > conducted in StarBED which is one of the largest scale network > experiment environment in Japan. A million of subscribers was > emulated and it revealed the realistic behavior of CGN. > > > > > The IETF Secretariat > > > > > > > > -- > ---- > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 > -- ---- Kaname Nishizuka Innovative Architecture Center NTT Communications Corporation +81-50-3812-4704 From internet-drafts@ietf.org Thu Apr 4 00:39: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 96E5621F961E; Thu, 4 Apr 2013 00:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 hGAbNtlfmc16; Thu, 4 Apr 2013 00:39:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3121F95E5; Thu, 4 Apr 2013 00:39:25 -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.43 Message-ID: <20130404073925.22567.93845.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 00:39:25 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-17.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: Thu, 04 Apr 2013 07:39:25 -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 : Discovery of the IPv6 Prefix Used for IPv6 Address Synth= esis Author(s) : Teemu Savolainen Jouni Korhonen Dan Wing Filename : draft-ietf-behave-nat64-discovery-heuristic-17.txt Pages : 20 Date : 2013-04-04 Abstract: This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-heuris= tic-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Thu Apr 4 02:49: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 2622921F93F4 for ; Thu, 4 Apr 2013 02:49:43 -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 yGcK6dAEWvr8 for ; Thu, 4 Apr 2013 02:49:42 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 599C721F95FB for ; Thu, 4 Apr 2013 02:49:38 -0700 (PDT) Received: from porto.nomis80.org (85-169-43-76.rev.numericable.fr [85.169.43.76]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BEE2B470FB for ; Thu, 4 Apr 2013 05:49:06 -0400 (EDT) Message-ID: <515D4C91.4020504@viagenie.ca> Date: Thu, 04 Apr 2013 11:49:05 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1254; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Fwd: New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Thu, 04 Apr 2013 09:49:43 -0000 Le 2013-04-03 20:57, Senthil Sivakumar (ssenthil) a écrit : > If it is not the address, what is the limiting factor? The reason ISP > is deploying CGN is the shortage of addresses and cant provide a > single address to each of his subscribers. Maybe you meant to say the > address is not the only limiting factor. I never said the text was > saying static isnt good enough :-), I deduced from the study that the > usage of ports is far more compellingly efficient with dynamic port > allocation and the cost of logging infra can be justified. I'll try to illustrate my point with an example with numbers. An ISP is running out of addresses. It considers two options: static CGN vs dynamic CGN. Static allows, let's say, 32 users per public IPv4 address. Given the 1:10 figure from the draft, it follows that dynamic allows 320 users per public IPv4 address. If 32 is "enough", why suffer the trouble of logging (among others) just to get to 320? If 32 and 320 are both "enough", then considerations other than efficient use of public IPv4 addresses must take priority. "Enough" could mean something like "enough to support projected growth for X years". > Most of the studies in the past projected how bad the logging problem > is but didn’t have any data on the other side of the equation on how > inefficient the static port allocation is. I wouldn’t want this draft > to say one is better than the other, but let the operators choose, if > 10:1 static to dynamic port allocation is justified for their > deployment. The 10:1 figure is useful. However, the conclusion "therefore dynamic is better" is premature. There are tons of other criteria to consider. Even worse, it is very possible that the 10:1 figure does not even matter: if static is "good enough", you may not care that dynamic is 10 times better. 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 dwing@cisco.com Thu Apr 4 09:04:46 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 A9AE921F95DB for ; Thu, 4 Apr 2013 09:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 gYXuvBmBRohO for ; Thu, 4 Apr 2013 09:04:45 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6909821F958A for ; Thu, 4 Apr 2013 09:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10771; q=dns/txt; s=iport; t=1365091485; x=1366301085; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ky3SKnrKnKEKcZmb9tFj91In+0uHPK74EUGNEkSdutk=; b=jCX4D1pP+jP7XC71WAlJuwhWt7ryuP0kf/oCCZ6KnDbNEwDhEOlIkdDz WPFDd4jJ4rlupVm8O0SQw2HqIf29xrBoIQYuYASjeTvK1sC3KupUvnOYe sxaFbDF7G3ivQu0JI9KVgbRUb2W0C1vgsap2mpIuraKCNwAWVXW6P1JKg M=; X-IronPort-AV: E=Sophos;i="4.87,410,1363132800"; d="scan'208";a="77760420" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 04 Apr 2013 16:04:45 +0000 Received: from [10.21.74.54] ([10.21.74.54]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r34G4hAT017455; Thu, 4 Apr 2013 16:04:44 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <515CE7C7.2040605@nttv6.jp> Date: Thu, 4 Apr 2013 09:04:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <515CE7C7.2040605@nttv6.jp> To: kaname nishizuka X-Mailer: Apple Mail (2.1503) Cc: Shin Miyakawa , "behave@ietf.org" Subject: Re: [BEHAVE] New Version Notification for draft-nishizuka-cgn-deployment-considerations-00.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: Thu, 04 Apr 2013 16:04:46 -0000 On Apr 3, 2013, at 7:39 PM, kaname nishizuka wrote: > Thank you for your comments, >=20 >> [Senthil] Most of the NATs use the entire port space from 1024-65536, = did you find differently? >>=20 >> If you had used the entire port space, you would only require 1526 = addresses instead of 3051. >>=20 >> I think not using the 1024-32768 is not practical and inefficient. > What you pointed out is reasonable enough, but our concern is that = there are de-facto well-known port in 1024-32768 like 1433/tcp. > Especially in the static assignment, the subscriber who has a "dirty" = range would be attacked more frequently than others. No more so than every subscriber is being attacked on those ports today, = when subscribers are getting the entire port range. -d > We know that most of the NATs use the entire port space from = 1024-65536, but we described it in the most safe side. > As you mentioned, the ratio of dynamic:static is the same. >=20 >=20 >> [Senthil] I think it should be mentioned that with binary format for = the above logging information, you need 26 bytes. >>=20 >> Transport Protocol - 1 byte >>=20 >> Source IP address:port =96 6 bytes >> Source IP address:port after translation =96 6 bytes >> Timestamp =96 8 bytes >>=20 >> Add/Delete =96 1 byte >>=20 >> Subscriber ID/VRF ID =96 4 bytes >>=20 > I agree with that. It's useful and it supports the logic. >=20 > Thanks, > kaname >=20 > (2013/04/03 7:03), Senthil Sivakumar (ssenthil) wrote: >> Hi Kaname, >> It is a pretty interesting study. I have a few comments on the = sections on your IP address requirements calculations.In the dynamic = assignment, the ports of pool address are allocated >>=20 >>=20 >>=20 >>=20 >>=20 >> " # of pool address (P) =3D # of Subscriber (S) * a * N / (65536 - = R) >>=20 >> Here, (R) is reserved TCP/UDP port list referred in >> = [I-D.donley-behave-deterministic-cgn]. CGN should eliminate the >> wellknown ports (0-1023 for TCP and UDP) to avoid the bad >> interpretation from destination servers. It is natural to = translate >> source port of outgoing packet to ephemeral ports. The ports after >> 32768 is considered to be used without any problems because = ephemeral >> ports are 32768-61000 for Linux and 49152-65535 in the IANA >> recommendations. As the result, 3,051 pool addresses are = sufficient >> for 1,000,000 subscribers. The feasibility of configuration was >> confirmed in the verification." >>=20 >> [Senthil] Most of the NATs use the entire port space from 1024-65536, = did you find differently? >>=20 >> If you had used the entire port space, you would only require 1526 = addresses instead of 3051. >>=20 >> I think not using the 1024-32768 is not practical and inefficient. >>=20 >>=20 >>=20 >> On the other hand, in static assignment, the ports are allocated a >> priori for every users. The pool addresses and ports are reserved = to >> every users, so most of them could be a dead stock because there = are >> light users and heavy users in aspect of port consumption. The max >> number of port consumption in all subscribers is the key value for >> static assignment. The true peak number of the session by a heavy >> user could be over 10,000 sessions. However it is assumed that = such >> a severe consumption of ports to be an abuse, so the number of >> statically assigned port (M) is controllable parameter by each >> providers. In the static assignment, the required number of the = pool >> address is as follows: >>=20 >> # of pool address (P) =3D # of Subscriber (S) * M / (65536 - R) >>=20 >> Taking account into the investigation of number of sessions of >> applications, the desirable value of (M) is over 1,000. As the >> result, no less than 30,517 pool addresses are needed for 1,000,000 >> subscribers. The compression ratio is one tenth of the case of >> dynamic assignment." >>=20 >>=20 >> [Senthil] Going by the same standards of using the entire available = port range, you should require 15259 addresses. >> But the point is the cost of static allocation to dynamic allocation = is 10:1, which is huge and given the fact there is only so little >> address space that is available, it should be used efficiently. Just = by looking at that calculation, it seems amply clear that dynamic is = preferred over static, >> as you have noted. >> That leads us to the next topic on logging. >>=20 >>=20 >>=20 >> " In addition, the indicator of the allocation and deallocation are >> needed because it assures that the identified subscriber certainly >> had been using the translated IP address and port. Plus, including >> the index of the CGN host, the average size of NAT log is about 120 >> byte in ASCII format. Every active subscriber generate 400 = sessions >> in average for a certain amount of time. It is assumed that the >> event happens every 5 minute in the most severe condition. The = size >> of the log (L) for time frame (T) can be estimated as follows: >>=20 >> The size of log (L) =3D # of Subscriber (S) * a * N * 120byte * 2 * = ( >> Time frame(T) / 5 min. ) >>=20 >>=20 >>=20 >> It should be noted that the log is generated at the timing of NAT >> table creation and freeing. As the result, for 1,000,000 users, = the >> size of log is piled up to 6.4 terabytes per day. The verification >> result confirm the existing estimation referred in >> = [I-D.donley-behave-deterministic-cgn]." >>=20 >> [Senthil] I think it should be mentioned that with binary format for = the above logging information, you need 26 bytes. >>=20 >> Transport Protocol - 1 byte >>=20 >> Source IP address:port =96 6 bytes >> Source IP address:port after translation =96 6 bytes >> Timestamp =96 8 bytes >>=20 >> Add/Delete =96 1 byte >>=20 >> Subscriber ID/VRF ID =96 4 bytes >>=20 >>=20 >> I would help a lot to add the binary logging calculation in addition = to the ascii format to help people choose the right method for them. >>=20 >> Going by the same formula you need 1.36 TB/day with binary logging. = Assuming that the compression ratio is the same >>=20 >> For both ascii and binary data, you have 1/4-1/5th of advantage with = binary logging. >>=20 >> You spread the cost of 1.36TB across a 1,000,000 subscribers assuming = cost of 1TB is US$80, >>=20 >> we come to 0.00008 cents/subscriber/day or 0.024 = cents/subscriber/month. Even with ASCII logging requirements this = doesn=92t sound like a mammoth cost. >>=20 >> Sure, there are other operating expenses involved but comparing that = with the efficiency of a dynamic port allocation mechanism and requiring = 10 times less >>=20 >> public addresses seems to be a compelling winning argument than = changing every CGN implementation to save for logging costs. >>=20 >>=20 >> Thanks >>=20 >> Senthil >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From: kaname nishizuka > >> Date: Tuesday, April 2, 2013 4:37 AM >> To: "behave@ietf.org" = > >> Cc: Shin Miyakawa > >> Subject: [BEHAVE] Fwd: New Version Notification for = draft-nishizuka-cgn-deployment-considerations-00.txt >>=20 >>=20 >> Dear all, >>=20 >> I'm kaname from NTT communications in Japan. >> We are testing CGN under the support of Japanese Government. >> Now, we've uploaded a new draft based on the result of our = verification. >> The useful information about the average consumption of the ports are = available on the document. >> Please look through it, and all kind of feedback are welcome. >>=20 >> By conducting realistic experiment, this draft is answering to = "draft-ietf-behave-lsn-requirements-10" which will be the newest RFC = very soon. >>=20 >> The document is *NOT* intended to be Standards Track. It's for = Informational. >> The wrong description is just mere mistake, so we'll soon correct it = in the next revision. >>=20 >> The full report of our work will be available soon on the Web in = English. >> I'll also announce it when it's available to this mailing-list. >>=20 >> Best regards, >>=20 >> kaname >>=20 >>=20 >>=20 >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for = draft-nishizuka-cgn-deployment-considerations-00.txt >> Date: Thu, 28 Mar 2013 07:12:25 -0700 >> From: internet-drafts@ietf.org >> To: kaname@nttv6.jp >>=20 >>=20 >>=20 >> A new version of I-D, = draft-nishizuka-cgn-deployment-considerations-00.txt >> has been successfully submitted by Kaname Nishizuka and posted to the >> IETF repository. >>=20 >> Filename: draft-nishizuka-cgn-deployment-considerations >> Revision: 00 >> Title: Carrier-Grade-NAT (CGN) Deployment Considerations. >> Creation date: 2013-03-29 >> Group: Individual Submission >> Number of pages: 16 >> URL: = http://www.ietf.org/internet-drafts/draft-nishizuka-cgn-deployment-conside= rations-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-nishizuka-cgn-deployment-considerati= ons >> Htmlized: = http://tools.ietf.org/html/draft-nishizuka-cgn-deployment-considerations-0= 0 >>=20 >>=20 >> Abstract: >> This document provides deployment considerations for Carrier-Grade- >> NAT (CGN) based on the verification result include the = investigation >> of the number of sessions of applications. The verification was >> conducted in StarBED which is one of the largest scale network >> experiment environment in Japan. A million of subscribers was >> emulated and it revealed the realistic behavior of CGN. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> ---- >> Kaname Nishizuka >> Innovative Architecture Center >> NTT Communications Corporation >> +81-50-3812-4704 >>=20 >=20 >=20 > --=20 > ---- > Kaname Nishizuka > Innovative Architecture Center > NTT Communications Corporation > +81-50-3812-4704 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Thu Apr 11 08:43:18 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 89BF821F9036 for ; Thu, 11 Apr 2013 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 bUf++15kPFOO for ; Thu, 11 Apr 2013 08:43:18 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id E400B21F8FDB for ; Thu, 11 Apr 2013 08:43:17 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id l25so1548713iad.10 for ; Thu, 11 Apr 2013 08:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=lYfvt2UaNYV7G3hHYX4ZO9Wb1JMXvazCBphbh/nFuEw=; b=RttQwvtK9fmJLXHerKp21rcdVtqT7oRzx34SxuATmW+pkUX+55XiJg5F68VNglWecr 0kenmLGPSLgY7tx7LFYz74gSDKakfzkSijhEGqn02CRJHCqJD1C/5Gnba9jbRZTwe52Z 1EV5+gqSqSnfy+u+KfFM4XS/N5PQX8ibIBeD/MyXKW24pkiPi2Tt2t1oV4w+OV3ckzQE C05HDowMcdH/Y8z6TyF8mMUEbAoaFQ6BoHaMrdmSLBXXW1yN0cOeJzCGX2FnsSgXCVrx mlR61uXNVv8fTEFvL0ZT6FdlNuC+rf0scY5HneW9I3jCq5sChEYKDo8WAJjGP2WsvtgX yz3g== X-Received: by 10.50.164.162 with SMTP id yr2mr4912789igb.0.1365694997601; Thu, 11 Apr 2013 08:43:17 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id y5sm3178875igg.7.2013.04.11.08.43.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 08:43:16 -0700 (PDT) Message-ID: <5166DA14.4090603@gmail.com> Date: Thu, 11 Apr 2013 11:43:16 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] IETF86 minutes 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, 11 Apr 2013 15:43:18 -0000 I looked over the IETF86 minutes in preparation for updating the Syslog draft and noted that a bit was missing from the discussion at the end of the logging topic. We agreed, I believe, that it might be practical to do per-session logging using Syslog in specific situations where the number of events per second was limited. As a result, per-session logging would also be added to the Syslog draft along with an applicability statement. Tom Taylor From tom.taylor.stds@gmail.com Sat Apr 13 15:52:50 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 A9D1F21F84F9 for ; Sat, 13 Apr 2013 15:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 lucikm0rrqKi for ; Sat, 13 Apr 2013 15:52:50 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id F2AE921F84E7 for ; Sat, 13 Apr 2013 15:52:49 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id x14so317869ief.21 for ; Sat, 13 Apr 2013 15:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NIh5/ZzfMgmy9hkUtXoue7tpuBad9j8Hp+rLlfudiV0=; b=Nie+jQpaBhceXv3M9BJ35ttC93TsphwMy9vV/dPqD/9hrJCcbnZ9H5HCeNrB1VzlOG bf4zGh1Zx28s0YKp0lnwEWMhA4ZgCRFxvvyUo9nHJwG+cIdtTLpqY58q7MxFTBZHuz1v GYQp7xbGUhANK5qDqMEEaGTTtwFev5zndj17mIrqptDpJsTg+8eewjbo8r/zCkPH6trO jmAgfafwMlhs4YXfgDUKMJ0ay36MbNzx6eHwiZwd4J+6fXouM6edkntHdkhEgBHYqOxD PwFVYWI3Iacrx76f/kzLJUP1CFFOaHFHevXR44jmYvo30O47HuR6X2AWd0SVxKe60EhJ 0RSw== X-Received: by 10.50.17.166 with SMTP id p6mr2272001igd.12.1365893569452; Sat, 13 Apr 2013 15:52:49 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id ip2sm4568098igc.5.2013.04.13.15.52.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 15:52:48 -0700 (PDT) Message-ID: <5169E1BF.6000202@gmail.com> Date: Sat, 13 Apr 2013 18:52:47 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dan Wing References: <65DAA8E7-B1A8-4581-80F2-D1734999BA1A@cisco.com> In-Reply-To: <65DAA8E7-B1A8-4581-80F2-D1734999BA1A@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] logging drafts 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, 13 Apr 2013 22:52:50 -0000 I propose the following: (1) Record exactly the same events and parameters in SYSLOG as in IPFIX. I have arguments for why this is reasonable. (2) Add a Deployment Considerations section that provides a context for the use of the fields that have been defined. As an example, it would cover what logging would include for different transition methods. As another example, it might explore different architectures in which log collection would happen. As a sub-case of the latter, some events in some situations happen at provisioning time and are reasonably collected or reported by AAA. Comments? Tom Taylor On 13/03/2013 2:11 PM, Dan Wing wrote: > The two NAT logging drafts were presented at the BEHAVE meeting at IETF86 (draft-sivakumar-behave-nat-logging-06 and draft-ietf-behave-syslog-nat-logging-00). They are both WG documents and based on the feedback at the meeting, we would like to see: > > * an update of the table presented at the meeting (slide 6 of http://tools.ietf.org/agenda/86/slides/slides-86-behave-2.pdf). > * text added to the SYSLOG and IPFIX documents explaining their applicability. > * discussion on the list to reach consensus that SYSLOG and IPFIX should, or should not, send different events because of their different applicability. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Mon Apr 15 13:15:54 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 A1BB521F9437 for ; Mon, 15 Apr 2013 13:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3luBBQb9S4iL for ; Mon, 15 Apr 2013 13:15:53 -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 CD73921F93E1 for ; Mon, 15 Apr 2013 13:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1816; q=dns/txt; s=iport; t=1366056954; x=1367266554; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Efhv7s5UsfK12mstNvF3v7HhR+CHbhLhNt1b0UPMLqo=; b=IACFbk0BdGkpAfZR9I9W5e8zUnLy9dfTSgy10PfR7HEJyOYue/WUBT5G nj/PQ2wYEjFpxII9MyeG29x/+8TtHvyezVupjozzKJ0TIJkRy0i7EKaLR dM9bu/eEelHH5AXjqjIZISbpEpzpCEzmylSPoJaDb8YaeBl0L3wuj06FB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYFAMJebFGtJV2d/2dsb2JhbABQgwY2wQWBBxZ0gh8BAQECAQEBAQE3NAsFCwsYLiEGMAYTiAIDCQYMsXQNiV2MRIIgMweCYGEDiQWMHYFjgSGEZIVwhRyDKxw X-IronPort-AV: E=Sophos;i="4.87,479,1363132800"; d="scan'208";a="199038084" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 15 Apr 2013 20:15:22 +0000 Received: from [10.156.17.93] ([10.156.17.93]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3FKFJ8i022503; Mon, 15 Apr 2013 20:15:19 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <5169E1BF.6000202@gmail.com> Date: Mon, 15 Apr 2013 13:15:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <30323D44-D982-4090-B42F-4BB36E8D7545@cisco.com> References: <65DAA8E7-B1A8-4581-80F2-D1734999BA1A@cisco.com> <5169E1BF.6000202@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1503) Cc: "behave@ietf.org" , behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] logging drafts 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, 15 Apr 2013 20:15:54 -0000 On Apr 13, 2013, at 3:52 PM, Tom Taylor = wrote: > I propose the following: >=20 > (1) Record exactly the same events and parameters in SYSLOG as in = IPFIX. I have arguments for why this is reasonable. >=20 > (2) Add a Deployment Considerations section that provides a context = for the use of the fields that have been defined. As an example, it = would cover what logging would include for different transition methods. = As another example, it might explore different architectures in which = log collection would happen. As a sub-case of the latter, some events in = some situations happen at provisioning time and are reasonably collected = or reported by AAA. >=20 > Comments? Yes, that sounds like a good approach. -d > Tom Taylor >=20 > On 13/03/2013 2:11 PM, Dan Wing wrote: >> The two NAT logging drafts were presented at the BEHAVE meeting at = IETF86 (draft-sivakumar-behave-nat-logging-06 and = draft-ietf-behave-syslog-nat-logging-00). They are both WG documents = and based on the feedback at the meeting, we would like to see: >>=20 >> * an update of the table presented at the meeting (slide 6 of = http://tools.ietf.org/agenda/86/slides/slides-86-behave-2.pdf). >> * text added to the SYSLOG and IPFIX documents explaining their = applicability. >> * discussion on the list to reach consensus that SYSLOG and IPFIX = should, or should not, send different events because of their different = applicability. >>=20 >> -d >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >>=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Thu Apr 18 05:22:17 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 5F5D521F8E96 for ; Thu, 18 Apr 2013 05:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 Ir0ME+wyKmpw for ; Thu, 18 Apr 2013 05:22:16 -0700 (PDT) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EEC8D21F8ACD for ; Thu, 18 Apr 2013 05:22:15 -0700 (PDT) Received: by mail-ia0-f171.google.com with SMTP id f27so2397117iae.16 for ; Thu, 18 Apr 2013 05:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f/tEH4OXbvtanfv6rMn4Fxh1Oz/MhRy9QTGJiLjgSIw=; b=cBcXQg6D1qKT/69vYslP+jhrcnfm1FRlVjgZd2K+ojnWZ13CC4KC7W8F/ffq0bW6qE 28bNnW8dA3sfaGwUW0ZjfG/ZiZvP/GxIiGFjduKk2UDVga+LebiZKgCrmrPXgvoqoTJx 3rHlObI+iNLdyAEWu/ILADAA6eFWTEslJNiA3tq5We850+k4pBO9nEyGgAvppCVOR5ir 2NnJiAUCTqb8MtqoVMKSo/8ePzn/pjYvSy+3NExf0TWRqdxvZF1aWJiZXKLfO/BzjItb A7QofU2XnD+S74t+2xf/KCRTImSOHNYy7ZRMz3RxhHgOu+59JE6qtN7xvCC8AcOsre6E SmfQ== X-Received: by 10.42.145.137 with SMTP id f9mr5734189icv.52.1366287735539; Thu, 18 Apr 2013 05:22:15 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id xf4sm25051479igb.8.2013.04.18.05.22.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 05:22:14 -0700 (PDT) Message-ID: <516FE577.8030704@gmail.com> Date: Thu, 18 Apr 2013 08:22:15 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> In-Reply-To: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 12:22:17 -0000 I note that explicit NAT44 and NAT64 events are defined in this draft, rather than general events where the address types are taken from the parameters. I can see that this provides a certain level of possibility for validation of the parameter types at the receiving end. Are there other advantages? The general event approach seems more natural to me. Tom taylor From tom.taylor.stds@gmail.com Thu Apr 18 05:47: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 D74EC21F8E98 for ; Thu, 18 Apr 2013 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 K1BGtK+klcfo for ; Thu, 18 Apr 2013 05:47:39 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5E21F8E6D for ; Thu, 18 Apr 2013 05:47:39 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id m10so435410iam.19 for ; Thu, 18 Apr 2013 05:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6W3UraMemxILMkEb5gkhwkusxCpk2EMEjjYIVn7uUU4=; b=CoVPGX+99LpM8W5aTmRdXe0+kvHWDfQr+cdprQyAjfnGELHstK6qzM3vfpdzBgjz4L kMDsKTCYC9Auy0Y42S1rba3bZvy6T+JvhDe005fwL7r0dZ/Xlr/uBpJZ7YDRIgR05rCx VuI6+LTt8KkvsSyhDIw1NLJuYPinjhiSaNRyUnNke6pL9LhK+Y1W6LlP38w8f3ZbOZRk vDjOvMAuLeX3lIiJ14mt8UmS6JwN8k+DDPcon3bTsaK72sOLSJncnB2fOb5fWp43EaPr hntX/vYgnaJaMRp230nFZfVE9mrGKEHn2wqRq2lZrQW86fUTaAQXLEnN2u4NGD2+dO6V onMw== X-Received: by 10.50.6.35 with SMTP id x3mr12933287igx.85.1366289258675; Thu, 18 Apr 2013 05:47:38 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id ua6sm25210803igb.0.2013.04.18.05.47.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 05:47:37 -0700 (PDT) Message-ID: <516FEB6A.5050408@gmail.com> Date: Thu, 18 Apr 2013 08:47:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> In-Reply-To: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 12:47:40 -0000 By the RFC 2663 definition, amplified by the discussion in Section 3 of RFC 6146, a NAT session as opposed to a binding involves a specific destination address and port. Why are these marked not mandatory in the session create and delete events (Tables 4 and 5)? Tom Taylor From tom.taylor.stds@gmail.com Thu Apr 18 06:36: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 51F4A21F8EBD for ; Thu, 18 Apr 2013 06:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_52=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 OpJ6VLImI3+g for ; Thu, 18 Apr 2013 06:36:19 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0570E21F8EB1 for ; Thu, 18 Apr 2013 06:36:18 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id j5so2472041iaf.32 for ; Thu, 18 Apr 2013 06:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KUMO+gPEqcyvsQgSv82nFyBke+bA3BauxSvbKZdcyo0=; b=JpaO/uGNvvoic/smuDfPfleBwIKpavY6X2JMf6Dwd4Sotu1ueYmD1wsHVIQv4tiV3Y pvQDhiE7adGQFFCF1ug337O+HlNKChRiNQ1n5r92PYzxZ/2940ZDiQmyUzzpx6gAoI9F IpQZW6Zyrlk1KZ6sHGU8mqJPiVeYO1+Di26Ww0vJ4VmlMUT/RHeK2HAzEMoL9M/pfIAQ k55zkPPoJ1KOIFKBnA3sGD0e890NoXfUTuw8bdD2KfS1lws75GUGndRbnBKVcC9YHDJY RxoooH9vYU44t/NzE09MxToZor6NmRvTBN+lq7UES4hvQWp5K3EFoT8h2MGFJtcPFX4u lqqQ== X-Received: by 10.50.192.201 with SMTP id hi9mr13064346igc.48.1366292178238; Thu, 18 Apr 2013 06:36:18 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id wn10sm25366132igb.2.2013.04.18.06.36.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 06:36:17 -0700 (PDT) Message-ID: <516FF6D1.1080403@gmail.com> Date: Thu, 18 Apr 2013 09:36:17 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> In-Reply-To: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 13:36:20 -0000 The parameter "NAT originating address realm"is provided for the various session and BIB creation and deletion events. Is that "originating" meant to be "internal", or to reflect instead whether the packet that triggered the event came from the internal or external realm? Tom Taylor From simon.perreault@viagenie.ca Thu Apr 18 06:52:14 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 D79E421F85A2 for ; Thu, 18 Apr 2013 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 sixB4SU9olKB for ; Thu, 18 Apr 2013 06:52:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8F721F8574 for ; Thu, 18 Apr 2013 06:52:08 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:a0bf:2ff:321b:e17b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D31EE40437 for ; Thu, 18 Apr 2013 09:52:07 -0400 (EDT) Message-ID: <516FFA86.5050607@viagenie.ca> Date: Thu, 18 Apr 2013 15:52:06 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> <516FF6D1.1080403@gmail.com> In-Reply-To: <516FF6D1.1080403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 13:52:15 -0000 Le 2013-04-18 15:36, Tom Taylor a écrit : > The parameter "NAT originating address realm"is provided for the various > session and BIB creation and deletion events. Is that "originating" > meant to be "internal", or to reflect instead whether the packet that > triggered the event came from the internal or external realm? BIB entries can only be dynamically created from the internal side. Therefore that parameter should be renamed to "NAT internal realm". Simon From tom.taylor.stds@gmail.com Thu Apr 18 07:17:17 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 70C8221F8F40 for ; Thu, 18 Apr 2013 07:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.148 X-Spam-Level: X-Spam-Status: No, score=0.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 Ij9lAtJWFvIe for ; Thu, 18 Apr 2013 07:17:17 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id EBBF021F8EF7 for ; Thu, 18 Apr 2013 07:17:16 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id l25so2492773iad.24 for ; Thu, 18 Apr 2013 07:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8pfWW5rok1hwjDIRPnvx02FXrAz4lH4PGLrVWO3xX+I=; b=ffKYHNtL1u5QSUPmyd1TFx1UMSJHuZgGovdBw0SJtXmTsbw2hjwBNDMfRU03iAyIY4 nX+uV+RMbzYlc9wvRwbw0aevcelzPzz8L5jqnHbo5uekKp3u1oujT5Yh1WXXV3Djw+mV W6em+qMIhHoarRbXtCta+gG/8V30Z7Rt2cwEvDl/zaUpZXWw/JYKQM23kzAEJ3MCKZWH FxZYjN5krCMjeCrlsTybKZSoOqI8uLE913TUsX/EVnD0TQAlXro1dgU6lFXYYEDWM1H2 yiqiXLSYPswWBa/+/ksxvKEa+48Xav6/TwUwTP2t9g4TkxgKRVa/4YB8XFlEBtaBTG8C RX4g== X-Received: by 10.50.120.34 with SMTP id kz2mr1186184igb.38.1366294636579; Thu, 18 Apr 2013 07:17:16 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id p9sm4366239iga.7.2013.04.18.07.17.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 07:17:15 -0700 (PDT) Message-ID: <5170006C.2030000@gmail.com> Date: Thu, 18 Apr 2013 10:17:16 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> In-Reply-To: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 14:17:17 -0000 In the quota exceeded event, are the limits expected to apply to the sum over all protocols, or should protocol identifier also be a parameter of the template? Is it right to say that one source address, IPv4 or IPv6, MUST be present in the event report? Tom taylor From ssenthil@cisco.com Thu Apr 18 07:28:15 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 1D13221F85D6 for ; Thu, 18 Apr 2013 07:28:15 -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 9R81xOLZSvmY for ; Thu, 18 Apr 2013 07:28:14 -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 5A99821F845A for ; Thu, 18 Apr 2013 07:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=723; q=dns/txt; s=iport; t=1366295294; x=1367504894; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ji+HrgFB4JMO/jABnJ67WgHZqNMG0cms5TvDDPrjaIM=; b=EtI+vCCbGD1rxBsRfAm5jJ5Z4NusX8MCWTO4bkqJrGU0H8s2FTKLyRGX pxBtf0Q2Sp3C3IJw6CRcIzJqgcUrtb+jTgO5SA0HQUTr36A39PqOtshKw tGymY3vKV16hOub5KEp67unUhXQEhahMsxM8zF37ZKBOE4u8YqfNeSDdu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFACgCcFGtJV2c/2dsb2JhbABQgwY2gmq9c4ECFnSCIQEEAQEBNzQdAQgiFDEGCyUCBAESCId6Aw8MtQINiVkEjEWCIjiCZmEDlSSNW4UcgwuBbCQY X-IronPort-AV: E=Sophos;i="4.87,502,1363132800"; d="scan'208";a="200265266" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 18 Apr 2013 14:28:14 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3IESDs7024266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 14:28:13 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 09:28:13 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt Thread-Index: AQHOJNvmAeK5n+hD1UKb9ZNo7XkbnZjcaNKA///gJIA= Date: Thu, 18 Apr 2013 14:28:13 +0000 Message-ID: In-Reply-To: <516FE577.8030704@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.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C5F8724C3EB2149962D70FAA40AE680@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 14:28:15 -0000 With IPFIX the templates have to be exchanged and the IE will have a type and length. Not sure what do you mean by general event. On 4/18/13 8:22 AM, "Tom Taylor" wrote: >I note that explicit NAT44 and NAT64 events are defined in this draft, >rather than general events where the address types are taken from the >parameters. I can see that this provides a certain level of possibility >for validation of the parameter types at the receiving end. Are there >other advantages? The general event approach seems more natural to me. > >Tom taylor >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Thu Apr 18 07:29: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 4238421F8EED for ; Thu, 18 Apr 2013 07:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 3mqtDm5WpIzf for ; Thu, 18 Apr 2013 07:29:04 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B970721F8E6B for ; Thu, 18 Apr 2013 07:29:04 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id e16so2486940iaa.20 for ; Thu, 18 Apr 2013 07:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Gn9n1GkY7QnJOnmQug0IBDR+DUwTgZc7HOvvYl6B/vg=; b=as3xd1LdijEzjr75zzMcvwgPHdQumsBmnwHfF7x3rmGRt/W/qLBuS/+PzsaRbi6kJP OoJ61b6Xp3pZ9vy4MV2Hdce8Kj/mrmL+zqn2bcewk6tjHaLge4vNgqTfCi9K4sqI7L1G c+/MwLxFvpxdE0230n+R+BKz5zpiADYa0GF3rP07aqhXsdnsnlwPD0RjIxHyL8Y3/b+S 2lHn1xvtgLWvXQYobrg3vqFl0AJlq5l5xDLMMnSBcmSdHLtEph4l81gcSmeXwRg4mCkA RjlkbxK9s7/EmnvopnNiYnw6ic1pzz7WH347qzseZFft65FYgTi5MuIYw+55M+WCdbix RkRw== X-Received: by 10.50.57.166 with SMTP id j6mr7082992igq.21.1366295344389; Thu, 18 Apr 2013 07:29:04 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id ip2sm25535949igc.5.2013.04.18.07.29.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 07:29:03 -0700 (PDT) Message-ID: <5170032F.1040108@gmail.com> Date: Thu, 18 Apr 2013 10:29:03 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> In-Reply-To: <20130319195605.19816.13531.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 14:29:05 -0000 The address binding event description has a couple of editorial glitches: the sentence describing when the event happens is incomplete, and instead of MANDATORY or not, the translated IPv4 source address is "8". I assume that should be MANDATORY. Address binding could also happen because the NAT has decided to allocate a new address, e.g., to effect port preservation. Finally, as with the Quota Exhausted event, would it be right to say that one of IPv4 or IPv6 source address MUST be present? Tom Taylor From ssenthil@cisco.com Thu Apr 18 07:31:07 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 9B77F21F8F5C for ; Thu, 18 Apr 2013 07:31:07 -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 O+42-1sSaN5R for ; Thu, 18 Apr 2013 07:31:05 -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 4720621F8F2E for ; Thu, 18 Apr 2013 07:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=751; q=dns/txt; s=iport; t=1366295464; x=1367505064; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=O0f9PG4K/NLnDm5uO3Ch63YJr3v0TOxsuryZLI1g8C8=; b=ex7JHvL/5DjaPCrw3CE5Qe76D0ivQHLzzmSMPdlTpSK6ckfYgveMdeRq 5UIgYmE1lupzsfrIJRxgEOFD+kIJvzM433P9E42AYD8BiqyOuaIlsdJmh N3Cc/OohaEYZtvl+0oOyQSxR/3bCc+MAUApW8h5TU440c1eYSsObF7Hpa c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAHACcFGtJXG9/2dsb2JhbABQgwY2gmq9c4ECFnSCIQEEAQEBNzQdAQgiFDEGCyUCBAESCId6Aw8MtQMNiVkEjEWCIjiCZmEDlSSNW4UcgwuCKA X-IronPort-AV: E=Sophos;i="4.87,502,1363132800"; d="scan'208";a="200278111" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 18 Apr 2013 14:31:00 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3IEV08h023354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 14:31:00 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 09:30:59 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt Thread-Index: AQHOJNvmAeK5n+hD1UKb9ZNo7XkbnZjcb+oA///Z0AA= Date: Thu, 18 Apr 2013 14:30:59 +0000 Message-ID: In-Reply-To: <516FEB6A.5050408@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.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <16BC73F74ED80645AB287AD20D420A5A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 14:31:08 -0000 Session as it gets created in NAT will have a destination address and port. That is not to say they MUST be logged. In fact, lsn-requirements says desitnation information SHOULD NOT be logged for privacy reasons. That is why they are not mandatory. On 4/18/13 8:47 AM, "Tom Taylor" wrote: >By the RFC 2663 definition, amplified by the discussion in Section 3 of >RFC 6146, a NAT session as opposed to a binding involves a specific >destination address and port. Why are these marked not mandatory in the >session create and delete events (Tables 4 and 5)? > >Tom Taylor >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Thu Apr 18 07:34: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 D1E9221F8BDD for ; Thu, 18 Apr 2013 07:34:09 -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_52=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 pWV4R1lByBqI for ; Thu, 18 Apr 2013 07:34:06 -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 593E321F8B3A for ; Thu, 18 Apr 2013 07:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=786; q=dns/txt; s=iport; t=1366295646; x=1367505246; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=rRRdISwbAubs2hQ5Jj0H2sgc7W/FIZEUcbJqibwcP8s=; b=K2BHRysGZKOjIDM9N5ZmSxB0ukYsMB1eUE6yZcg6JZAHOrpz3qIXsN/Y /lxRIUIYDU8+nv/ZoGoZfrUUdMKTG2dLdF0z9IwxyNhMfUcMcCA/Abszg jHg7MKvd6D2gk32Jo79GCXV+fzKNagMY7mH99ejtywpiOsqfux994QPgd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAIQDcFGtJV2c/2dsb2JhbABQgwY2gmq9c4ECFnSCIQEEAQEBax0BCCJFBgslAgQBEgiHegMPDLUADYlZBIxFgQ+BEziCZmEDiE+MVY1bhRyDC4FqPg X-IronPort-AV: E=Sophos;i="4.87,502,1363132800"; d="scan'208";a="200295997" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 18 Apr 2013 14:34:02 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3IEY2KJ032367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 14:34:02 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 09:34:02 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt Thread-Index: AQHOJNvmAeK5n+hD1UKb9ZNo7XkbnZjcfYGA///NFQA= Date: Thu, 18 Apr 2013 14:34:02 +0000 Message-ID: In-Reply-To: <516FF6D1.1080403@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.103] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 14:34:10 -0000 Once a BIB entry is created, the session can be created from the BIB either from internal or external realms. But that is based on the configured filtering policies. Maybe the BIB creation shouldn=B9t have the Originating address realm. I will ask for the WG input on that. On 4/18/13 9:36 AM, "Tom Taylor" wrote: >The parameter "NAT originating address realm"is provided for the various >session and BIB creation and deletion events. Is that "originating" >meant to be "internal", or to reflect instead whether the packet that >triggered the event came from the internal or external realm? > >Tom Taylor >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ssenthil@cisco.com Thu Apr 18 07:37: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 D364121F8FA7 for ; Thu, 18 Apr 2013 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ZIpVZsnghIO7 for ; Thu, 18 Apr 2013 07:37:36 -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 1F64A21F8F03 for ; Thu, 18 Apr 2013 07:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=840; q=dns/txt; s=iport; t=1366295856; x=1367505456; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=FaAcDryJMp92Fiv4VLjC8GzL3Dt43sWZN1+K+4Q0eJA=; b=Dgg/d8TZ2lf7Sth1b5gmMKCFt6m2spA9tnwufiMh/zn7kf+yzmu/05M0 PbTKaE7oMuDndgezhW+ygt1wiQdvbzIqH8posSiL36iiOG5fVHXQ2nW2o 3emCirU/QvL71TebfZmuJ8fgpazT3rjZaVZFSmtbpXkPypO2p0UJBNlHK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAOIEcFGtJV2d/2dsb2JhbABQgwY2gmq9coEDFnSCIQEEAQEBNzQdAQgiFDEGCyUCBAESCId6Aw8MtQANiVkEjEWBEhF/OIJmYQOVJI1bhRyDC4FrPQ X-IronPort-AV: E=Sophos;i="4.87,502,1363132800"; d="scan'208";a="200281332" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 18 Apr 2013 14:37:35 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3IEbZS0013456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 14:37:35 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 09:37:35 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt Thread-Index: AQHOJNvmAeK5n+hD1UKb9ZNo7XkbnZjciPUA///CnQA= Date: Thu, 18 Apr 2013 14:37:34 +0000 Message-ID: In-Reply-To: <5170006C.2030000@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.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <592B9067DA979B48BEDCCC21E112913F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 14:37:36 -0000 On 4/18/13 10:17 AM, "Tom Taylor" wrote: >In the quota exceeded event, are the limits expected to apply to the sum >over all protocols, or should protocol identifier also be a parameter of >the template? That is a good question. I think there are limits per protocol and there are overall limits per nat instance. There can also be limits per host or per domain (vrf).=20 > >Is it right to say that one source address, IPv4 or IPv6, MUST be >present in the event report? Maybe not. If you have per host limits, then a host identifier makes sense. But if collectively the limits were exceeded, then a host identifier wont be there. > >Tom taylor >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From tom.taylor.stds@gmail.com Thu Apr 18 08:48:56 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 345F321F88FB for ; Thu, 18 Apr 2013 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 J05roaaM-5aE for ; Thu, 18 Apr 2013 08:48:55 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B1D0021F881C for ; Thu, 18 Apr 2013 08:48:55 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so3581302ieb.29 for ; Thu, 18 Apr 2013 08:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nOqVeSm+YsyyhuXikyxTZjogKk3b8c/2PchqBAWWbkM=; b=ME9L1ymEexdLrT0yL8klZPcrcv2Xj/topawOF0uqola9/f58SYFy4BZxKhr2uMKIO9 QT0AqjoIRGkNj7n1xbNbz62PogkWzLCOw3Am50Yckbrn6AyQCmFY/tU6/l5t77iLF0++ dhsjz6nmlf3hnfkfL/5eCx3RLRfKz1/mekGKwmDkPqqQErvQlbyUeneTsP1//V7GBo2v lTbj6ojKsIgquud8B8NU0WB291Ike6rK26qA/5QzdjZqiWYKIBzhvxLym+4Y3pXQ7wCk /H8azOv2X/AHLrAWDRdcL+p360VLIFzCFqA7G10m6Y5IMCT1CK6ndxU95RjKuAaXhCIB ubOw== X-Received: by 10.50.10.161 with SMTP id j1mr7053804igb.45.1366300135290; Thu, 18 Apr 2013 08:48:55 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id qs4sm13051172igb.10.2013.04.18.08.48.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 08:48:54 -0700 (PDT) Message-ID: <517015E6.3020408@gmail.com> Date: Thu, 18 Apr 2013 11:48:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 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] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 15:48:56 -0000 I mean a NAT session or BIB (create or delete) event where whether it is NAT44 or NAT64 is inferred from the type of the source address parameter. On 18/04/2013 10:28 AM, Senthil Sivakumar (ssenthil) wrote: > With IPFIX the templates have to be exchanged and the IE will have a type > and length. > Not sure what do you mean by general event. > > On 4/18/13 8:22 AM, "Tom Taylor" wrote: > >> I note that explicit NAT44 and NAT64 events are defined in this draft, >> rather than general events where the address types are taken from the >> parameters. I can see that this provides a certain level of possibility >> for validation of the parameter types at the receiving end. Are there >> other advantages? The general event approach seems more natural to me. >> >> Tom taylor >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From tom.taylor.stds@gmail.com Thu Apr 18 08:51: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 A154F21F8F75 for ; Thu, 18 Apr 2013 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_52=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 j36S4Z7W1b5n for ; Thu, 18 Apr 2013 08:51:10 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFDA21F89A6 for ; Thu, 18 Apr 2013 08:51:10 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id x14so3489759ief.35 for ; Thu, 18 Apr 2013 08:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R8cxliCO4iqLZB4FvT/32RSVzxYFZe66c2VMcT9AhkI=; b=AWesp2WSpGkrkC7esAM5dlDQWxn2dE9VZLfTVUZmlMvTwepu22V1rM2QFv1CGtyHQ5 dAXVVPzI7WulDB3nQsofAMZUH0a5QmQ1PQTYsXrx202ZHoPFjyM81naR3SP7WLFktSgF gp+SNJ75FRpp+bb1UjKeSz/ZB1zPetCZuOJYuV9J8RoAk6C4LHz6cMaP5nD8qxnIW/pA s5liZai/v4KIy5f6IBshC0zklsAOXvt/T3FpScxDWB2B2Vb8txTuYzQRZRj+YcHxqGZB XvjjxPoUTKl9GmSIjDf12swJTDHCxq56eLSMuVF8MZ5ObXT21WryCUbbHo+liLC4fLOx Jhdg== X-Received: by 10.42.80.196 with SMTP id w4mr5784543ick.43.1366300269820; Thu, 18 Apr 2013 08:51:09 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id ua6sm25901301igb.0.2013.04.18.08.51.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 08:51:09 -0700 (PDT) Message-ID: <5170166D.7060108@gmail.com> Date: Thu, 18 Apr 2013 11:51:09 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 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: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 15:51:10 -0000 I was asking what the intention was for the parameter. Is it intended to reflect the triggering event, or is it intended to indicate which internal realm is involved? On 18/04/2013 10:34 AM, Senthil Sivakumar (ssenthil) wrote: > Once a BIB entry is created, the session can be created from the BIB > either from internal or external > realms. But that is based on the configured filtering policies. Maybe the > BIB creation shouldnąt have the > Originating address realm. I will ask for the WG input on that. > > On 4/18/13 9:36 AM, "Tom Taylor" wrote: > >> The parameter "NAT originating address realm"is provided for the various >> session and BIB creation and deletion events. Is that "originating" >> meant to be "internal", or to reflect instead whether the packet that >> triggered the event came from the internal or external realm? >> >> Tom Taylor >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > . > From tom.taylor.stds@gmail.com Thu Apr 18 08:54:18 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 52E6821F8F7F for ; Thu, 18 Apr 2013 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 C3oBDSIrB+Qy for ; Thu, 18 Apr 2013 08:54:17 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3746121F878F for ; Thu, 18 Apr 2013 08:54:17 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id m10so625967iam.5 for ; Thu, 18 Apr 2013 08:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2FXtLPWJuOAvx9/sYvaYTFAMTYPcGRX2bT4l1iHoLpI=; b=NK29X8bn9T0rJ0HHJpiOlJZ9obeFx+G7Ayz41WHOwI9Uf/FC2gJgkgP6NG7uFVu4GJ gwpvpVzkMcBNYZ2zfyQxSDXAaE2HXLCqLJBBwb0IJbXwq+5/vzqBbnLXPu/+GXr1Tu7M JcSnvYScJLIVTe6PlRoqX88TJ7VTe8izUXcF7IuuNEElhJnlt31lSx28fGW4ivyVFb7B 8wqARSxXxg8TrV/B1qA8/55BkrhOQpoPyi0eNLjAMnNB1JrYw5yMk3VPdfUgdUFEE12h KPFDkIsla/79YVHHdBQsSc2WBHi6ZVnXcIpMZiUZD91wDEY0LJmPgfzvBjwjlakxHtRW KpZQ== X-Received: by 10.50.13.101 with SMTP id g5mr13821048igc.64.1366300454447; Thu, 18 Apr 2013 08:54:14 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id qs4sm13073496igb.10.2013.04.18.08.54.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 08:54:13 -0700 (PDT) Message-ID: <51701725.9030803@gmail.com> Date: Thu, 18 Apr 2013 11:54:13 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 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] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 15:54:18 -0000 OK, we should probably add an optional protocol identifier parameter, and should we add an optional VLANid/VRFid parameter with the requirement that one of that parameter or an IPv4 or IPv6 source address MUST be present? On 18/04/2013 10:37 AM, Senthil Sivakumar (ssenthil) wrote: > > > On 4/18/13 10:17 AM, "Tom Taylor" wrote: > >> In the quota exceeded event, are the limits expected to apply to the sum >> over all protocols, or should protocol identifier also be a parameter of >> the template? > > That is a good question. I think there are limits per protocol and there > are overall > limits per nat instance. There can also be limits per host or per domain > (vrf). > >> >> Is it right to say that one source address, IPv4 or IPv6, MUST be >> present in the event report? > > Maybe not. If you have per host limits, then a host identifier makes sense. > But if collectively the limits were exceeded, then a host identifier wont > be there. > >> >> Tom taylor >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From ssenthil@cisco.com Thu Apr 18 09:55: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 EFCEC21F8EBF for ; Thu, 18 Apr 2013 09:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.348 X-Spam-Level: X-Spam-Status: No, score=-9.348 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 wpwg6ppHeRNQ for ; Thu, 18 Apr 2013 09:55:47 -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 22E4B21F8E48 for ; Thu, 18 Apr 2013 09:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1708; q=dns/txt; s=iport; t=1366304147; x=1367513747; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ut8SXm2pcDzWKlHsek4I3F+0MB6bSA+GhVUBAE/lW80=; b=R0vZyacmAE2ETvSiVy8ouB5WoTVEoQonRhZ/X98dtIEWH+ovvN0iLjK7 wwXH2J7cpWIQDnGKJ9YFP+9gybXlGZos0ewiTydpL+dtXhhTOW8sS4UaB pbWchmZFR0fGOuFhA1GOiDVx9PJkZPD2k0rc/h3ITt6lcrTQ7TpPrWtuk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAFUkcFGtJV2c/2dsb2JhbABQgwY2gzG9Kw13FnSCHwEBAQQBAQExOgsSAQgYBAYiBB8GCyUCBA4FCId6Aw8MkHmafgaJAw2JWQSBHYsogQ+BEQIWGweCLjhhA5UkjVuFHIMLgWo+ X-IronPort-AV: E=Sophos;i="4.87,502,1363132800"; d="scan'208";a="200313679" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 18 Apr 2013 16:55:46 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3IGtkA8010548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 16:55:46 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 11:55:46 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt Thread-Index: AQHOJNvmAeK5n+hD1UKb9ZNo7XkbnZjcfYGA///NFQCAAFiagP//zv0A Date: Thu, 18 Apr 2013 16:55:45 +0000 Message-ID: In-Reply-To: <5170166D.7060108@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.103] Content-Type: text/plain; charset="euc-kr" Content-ID: <2864D7DE4A3CD54BA266FD075CE4DF6A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 16:55:48 -0000 SW50ZW5kZWQgdG8gaW5kaWNhdGUgaWYgdGhlIGNyZWF0aW9uIHdhcyBmcm9tIGludGVybmFsIG9y IGV4dGVybmFsIHJlYWxtLg0KDQpPbiA0LzE4LzEzIDExOjUxIEFNLCAiVG9tIFRheWxvciIgPHRv bS50YXlsb3Iuc3Rkc0BnbWFpbC5jb20+IHdyb3RlOg0KDQo+SSB3YXMgYXNraW5nIHdoYXQgdGhl IGludGVudGlvbiB3YXMgZm9yIHRoZSBwYXJhbWV0ZXIuIElzIGl0IGludGVuZGVkIHRvDQo+cmVm bGVjdCB0aGUgdHJpZ2dlcmluZyBldmVudCwgb3IgaXMgaXQgaW50ZW5kZWQgdG8gaW5kaWNhdGUg d2hpY2gNCj5pbnRlcm5hbCByZWFsbSBpcyBpbnZvbHZlZD8NCj4NCj5PbiAxOC8wNC8yMDEzIDEw OjM0IEFNLCBTZW50aGlsIFNpdmFrdW1hciAoc3NlbnRoaWwpIHdyb3RlOg0KPj4gT25jZSBhIEJJ QiBlbnRyeSBpcyBjcmVhdGVkLCB0aGUgc2Vzc2lvbiBjYW4gYmUgY3JlYXRlZCBmcm9tIHRoZSBC SUINCj4+IGVpdGhlciBmcm9tIGludGVybmFsIG9yIGV4dGVybmFsDQo+PiByZWFsbXMuIEJ1dCB0 aGF0IGlzIGJhc2VkIG9uIHRoZSBjb25maWd1cmVkIGZpbHRlcmluZyBwb2xpY2llcy4gTWF5YmUN Cj4+dGhlDQo+PiBCSUIgY3JlYXRpb24gc2hvdWxkbqn2dCBoYXZlIHRoZQ0KPj4gT3JpZ2luYXRp bmcgYWRkcmVzcyByZWFsbS4gSSB3aWxsIGFzayBmb3IgdGhlIFdHIGlucHV0IG9uIHRoYXQuDQo+ Pg0KPj4gT24gNC8xOC8xMyA5OjM2IEFNLCAiVG9tIFRheWxvciIgPHRvbS50YXlsb3Iuc3Rkc0Bn bWFpbC5jb20+IHdyb3RlOg0KPj4NCj4+PiBUaGUgcGFyYW1ldGVyICJOQVQgb3JpZ2luYXRpbmcg YWRkcmVzcyByZWFsbSJpcyBwcm92aWRlZCBmb3IgdGhlDQo+Pj52YXJpb3VzDQo+Pj4gc2Vzc2lv biBhbmQgQklCIGNyZWF0aW9uIGFuZCBkZWxldGlvbiBldmVudHMuIElzIHRoYXQgIm9yaWdpbmF0 aW5nIg0KPj4+IG1lYW50IHRvIGJlICJpbnRlcm5hbCIsIG9yIHRvIHJlZmxlY3QgaW5zdGVhZCB3 aGV0aGVyIHRoZSBwYWNrZXQgdGhhdA0KPj4+IHRyaWdnZXJlZCB0aGUgZXZlbnQgY2FtZSBmcm9t IHRoZSBpbnRlcm5hbCBvciBleHRlcm5hbCByZWFsbT8NCj4+Pg0KPj4+IFRvbSBUYXlsb3INCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEJl aGF2ZSBtYWlsaW5nIGxpc3QNCj4+PiBCZWhhdmVAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0KPj4NCj4+IC4NCj4+DQoNCg== From ssenthil@cisco.com Thu Apr 18 09:56:30 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 78A1D21F8FFA for ; Thu, 18 Apr 2013 09:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.304 X-Spam-Level: X-Spam-Status: No, score=-10.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 rmhEhgtPAVZh for ; Thu, 18 Apr 2013 09:56:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E641121F8FF8 for ; Thu, 18 Apr 2013 09:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1366304190; x=1367513790; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/QzGH2kce6cVIJ05hLbMLqWTFcYKSSZ537DPPwE6Nxo=; b=UPVFVaX8yo/XITgBVp8bs8RMdTJWJBtmBqKCxDwmK8m5wF1fA+Cblv// +Freeek2j+lqdDhYmpbaUN6pJdB++q0E48EsxfNP3W7UA5sJyVLlVHASZ yty5e4bTZmSupDxnBvlw7OhuGQJ4irD2Y5nFxVn2YwYcIZAr0eA2B/7kN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGwlcFGtJXG+/2dsb2JhbABQgwY2wFyBBRZ0gh8BAQEEAQEBNzQLEgEIGAoUMQYLJQIEDgUIh3oDDwy0fw2JWQSMRYESEX8xB4JmYQOVJI1bhRyDC4FrPQ X-IronPort-AV: E=Sophos;i="4.87,503,1363132800"; d="scan'208";a="200151535" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 18 Apr 2013 16:56:28 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3IGuSi3023169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Apr 2013 16:56:28 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 18 Apr 2013 11:56:27 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt Thread-Index: AQHOJNvmAeK5n+hD1UKb9ZNo7XkbnZjciPUA///CnQCAAFh5gP//zlWA Date: Thu, 18 Apr 2013 16:56:27 +0000 Message-ID: In-Reply-To: <51701725.9030803@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.103] 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] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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: Thu, 18 Apr 2013 16:56:30 -0000 Makes sense. On 4/18/13 11:54 AM, "Tom Taylor" wrote: >OK, we should probably add an optional protocol identifier parameter, >and should we add an optional VLANid/VRFid parameter with the >requirement that one of that parameter or an IPv4 or IPv6 source address >MUST be present? > >On 18/04/2013 10:37 AM, Senthil Sivakumar (ssenthil) wrote: >> >> >> On 4/18/13 10:17 AM, "Tom Taylor" wrote: >> >>> In the quota exceeded event, are the limits expected to apply to the >>>sum >>> over all protocols, or should protocol identifier also be a parameter >>>of >>> the template? >> >> That is a good question. I think there are limits per protocol and there >> are overall >> limits per nat instance. There can also be limits per host or per domain >> (vrf). >> >>> >>> Is it right to say that one source address, IPv4 or IPv6, MUST be >>> present in the event report? >> >> Maybe not. If you have per host limits, then a host identifier makes >>sense. >> But if collectively the limits were exceeded, then a host identifier >>wont >> be there. >> >>> >>> Tom taylor >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> >> From tom.taylor.stds@gmail.com Fri Apr 19 03:51: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 52FC921F943A for ; Fri, 19 Apr 2013 03:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_52=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 jUerq4Gv3IMX for ; Fri, 19 Apr 2013 03:51:46 -0700 (PDT) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1562921F8A08 for ; Fri, 19 Apr 2013 03:51:40 -0700 (PDT) Received: by mail-ia0-f173.google.com with SMTP id j5so3320264iaf.18 for ; Fri, 19 Apr 2013 03:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vOUG4biTeUxLlN+PfarYH7OvTxhSR+tlC2Czx1uJFto=; b=xRMqzrIRC4KPPNdAAiqusy5Z7CpPI/xCPuSpwwZEThnf5yCvVZbn+BkcLAJC5qSjCT MqLbyzH1QRG7b4/N0+s0eOOuQtt8npv4T6TJitBzc/8TzLf6frz7hqjS6JFjNXcGcHD4 b8IEVyblsDRBNS3FPbIm0ZMcoXMIRpHuHnB/tC4f1xt6dGWmO3hkp9rcz9vAS0UME89i zV8Ni6Qp40SBcfg1MDIQVYZGU5PVkrTGsMvcJ4nEpqW3suNLXZB4QGAe7UP2K843mNaR 9TkdfcuzvavuCgrUdFLX33nANqIl8Ivs9z5aEViNImUaKqwOYi6iwNj483GJFbkKTewp 0njQ== X-Received: by 10.50.77.110 with SMTP id r14mr8987843igw.85.1366368699039; Fri, 19 Apr 2013 03:51:39 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id s8sm2554081igs.0.2013.04.19.03.51.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 03:51:38 -0700 (PDT) Message-ID: <517121BA.70903@gmail.com> Date: Fri, 19 Apr 2013 06:51:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" References: In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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, 19 Apr 2013 10:51:47 -0000 OK, let's nail this down. Was this was meant to be a two-valued field (internal | external) or was it meant to be a realm number (0 - 255)? On 18/04/2013 12:55 PM, Senthil Sivakumar (ssenthil) wrote: > Intended to indicate if the creation was from internal or external realm. > > On 4/18/13 11:51 AM, "Tom Taylor" wrote: > >> I was asking what the intention was for the parameter. Is it intended to >> reflect the triggering event, or is it intended to indicate which >> internal realm is involved? >> >> On 18/04/2013 10:34 AM, Senthil Sivakumar (ssenthil) wrote: >>> Once a BIB entry is created, the session can be created from the BIB >>> either from internal or external >>> realms. But that is based on the configured filtering policies. Maybe >>> the >>> BIB creation shouldn©öt have the >>> Originating address realm. I will ask for the WG input on that. >>> >>> On 4/18/13 9:36 AM, "Tom Taylor" wrote: >>> >>>> The parameter "NAT originating address realm"is provided for the >>>> various >>>> session and BIB creation and deletion events. Is that "originating" >>>> meant to be "internal", or to reflect instead whether the packet that >>>> triggered the event came from the internal or external realm? >>>> >>>> Tom Taylor >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>> >>> . >>> > From ssenthil@cisco.com Fri Apr 19 04:15:51 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 C9BDE21F9434 for ; Fri, 19 Apr 2013 04:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.246 X-Spam-Level: X-Spam-Status: No, score=-8.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 t1xc9Hl1Mpji for ; Fri, 19 Apr 2013 04:15:51 -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 F116321F8D61 for ; Fri, 19 Apr 2013 04:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2288; q=dns/txt; s=iport; t=1366370151; x=1367579751; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=muIJ90mEr5z8I8h0DZJ3PIUljq7DJ/7Wo8P7jYTJMCs=; b=JsOiZZ8g09C95NrxrJLdGWpEiHqS/Xw/82PbrhEltuyQjlD41FooY3D5 diwWvLc+YXLQtQ4S9S3F2ztZhXsFJtr5ky02vOHJwQZWkG/idyEYeztHn N9qoN2Tgz5olnsv1gcHw8PJRQ/WyDr+Mum4mCYxykBuLfifZJSuZFNe0v M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHEmcVGtJV2d/2dsb2JhbABQgwY2gzG9MQ15FnSCHwEBAQQBAQExOgsSAQgYBAYiBB8GCyUCBA4FCId6Aw8Mj0aafgaIew2JWQSBHYsogQ+BEQIWGweCLjhhA5UkjVuFHIMLgWo+ X-IronPort-AV: E=Sophos;i="4.87,508,1363132800"; d="scan'208";a="200664512" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 19 Apr 2013 11:15:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3JBFohj003286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 11:15:50 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 06:15:50 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor Thread-Topic: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.txt Thread-Index: AQHOJNvmAeK5n+hD1UKb9ZNo7XkbnZjcfYGA///NFQCAAFiagP//zv0AgAFvqAD//8OygA== Date: Fri, 19 Apr 2013 11:15:49 +0000 Message-ID: In-Reply-To: <517121BA.70903@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.132] Content-Type: text/plain; charset="euc-kr" Content-ID: <396F37CACDE97149A024842F87EF2FC1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-ipfix-nat-logging-00.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, 19 Apr 2013 11:15:52 -0000 VHdvIHZhbHVlZCBmaWVsZCAtIGNhbiBiZSBpbnRlcm5hbCBvciBleHRlcm5hbCByZWFsbS4NCg0K T24gNC8xOS8xMyA2OjUxIEFNLCAiVG9tIFRheWxvciIgPHRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5j b20+IHdyb3RlOg0KDQo+T0ssIGxldCdzIG5haWwgdGhpcyBkb3duLiBXYXMgdGhpcyB3YXMgbWVh bnQgdG8gYmUgYSB0d28tdmFsdWVkIGZpZWxkDQo+KGludGVybmFsIHwgZXh0ZXJuYWwpIG9yIHdh cyBpdCBtZWFudCB0byBiZSBhIHJlYWxtIG51bWJlciAoMCAtIDI1NSk/DQo+DQo+T24gMTgvMDQv MjAxMyAxMjo1NSBQTSwgU2VudGhpbCBTaXZha3VtYXIgKHNzZW50aGlsKSB3cm90ZToNCj4+IElu dGVuZGVkIHRvIGluZGljYXRlIGlmIHRoZSBjcmVhdGlvbiB3YXMgZnJvbSBpbnRlcm5hbCBvciBl eHRlcm5hbA0KPj5yZWFsbS4NCj4+IA0KPj4gT24gNC8xOC8xMyAxMTo1MSBBTSwgIlRvbSBUYXls b3IiIDx0b20udGF5bG9yLnN0ZHNAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4+IEkgd2FzIGFz a2luZyB3aGF0IHRoZSBpbnRlbnRpb24gd2FzIGZvciB0aGUgcGFyYW1ldGVyLiBJcyBpdCBpbnRl bmRlZA0KPj4+dG8NCj4+PiByZWZsZWN0IHRoZSB0cmlnZ2VyaW5nIGV2ZW50LCBvciBpcyBpdCBp bnRlbmRlZCB0byBpbmRpY2F0ZSB3aGljaA0KPj4+IGludGVybmFsIHJlYWxtIGlzIGludm9sdmVk Pw0KPj4+DQo+Pj4gT24gMTgvMDQvMjAxMyAxMDozNCBBTSwgU2VudGhpbCBTaXZha3VtYXIgKHNz ZW50aGlsKSB3cm90ZToNCj4+Pj4gT25jZSBhIEJJQiBlbnRyeSBpcyBjcmVhdGVkLCB0aGUgc2Vz c2lvbiBjYW4gYmUgY3JlYXRlZCBmcm9tIHRoZSBCSUINCj4+Pj4gZWl0aGVyIGZyb20gaW50ZXJu YWwgb3IgZXh0ZXJuYWwNCj4+Pj4gcmVhbG1zLiBCdXQgdGhhdCBpcyBiYXNlZCBvbiB0aGUgY29u ZmlndXJlZCBmaWx0ZXJpbmcgcG9saWNpZXMuIE1heWJlDQo+Pj4+IHRoZQ0KPj4+PiBCSUIgY3Jl YXRpb24gc2hvdWxkbqn2dCBoYXZlIHRoZQ0KPj4+PiBPcmlnaW5hdGluZyBhZGRyZXNzIHJlYWxt LiBJIHdpbGwgYXNrIGZvciB0aGUgV0cgaW5wdXQgb24gdGhhdC4NCj4+Pj4NCj4+Pj4gT24gNC8x OC8xMyA5OjM2IEFNLCAiVG9tIFRheWxvciIgPHRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb20+IHdy b3RlOg0KPj4+Pg0KPj4+Pj4gVGhlIHBhcmFtZXRlciAiTkFUIG9yaWdpbmF0aW5nIGFkZHJlc3Mg cmVhbG0iaXMgcHJvdmlkZWQgZm9yIHRoZQ0KPj4+Pj4gdmFyaW91cw0KPj4+Pj4gc2Vzc2lvbiBh bmQgQklCIGNyZWF0aW9uIGFuZCBkZWxldGlvbiBldmVudHMuIElzIHRoYXQgIm9yaWdpbmF0aW5n Ig0KPj4+Pj4gbWVhbnQgdG8gYmUgImludGVybmFsIiwgb3IgdG8gcmVmbGVjdCBpbnN0ZWFkIHdo ZXRoZXIgdGhlIHBhY2tldCB0aGF0DQo+Pj4+PiB0cmlnZ2VyZWQgdGhlIGV2ZW50IGNhbWUgZnJv bSB0aGUgaW50ZXJuYWwgb3IgZXh0ZXJuYWwgcmVhbG0/DQo+Pj4+Pg0KPj4+Pj4gVG9tIFRheWxv cg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+IEJlaGF2ZSBtYWlsaW5nIGxpc3QNCj4+Pj4+IEJlaGF2ZUBpZXRmLm9yZw0KPj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCj4+Pj4NCj4+Pj4g Lg0KPj4+Pg0KPj4gDQoNCg== From tom.taylor.stds@gmail.com Fri Apr 19 13:03:35 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 A168221F8D8E for ; Fri, 19 Apr 2013 13:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 RcU41PIZXI7i for ; Fri, 19 Apr 2013 13:03:35 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 32F3921F8D61 for ; Fri, 19 Apr 2013 13:03:35 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c12so1183414ieb.3 for ; Fri, 19 Apr 2013 13:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JGUcaCbkmCPLuATc8Gd90gjK9Bg4gYUWSOQw3bOxM0s=; b=peZSPAHIGjQEk3rie0tbxQ31UquHVzYifxBQngDSHk2rURCv7WkseuCnnytzcSjXpO sUCbzMDrwzTu3Hyn0yP7i8ASk+LA1/wyen3kEwWoV1DCogjU7T2VVbMAveoASBgiz9YC LWtU7TB4okuWej+8RxWKiG9qobRvTLZFdMIbN9B0S9403Io/W+0rk08ZI5j70zU3YGD3 NcfS3EVwt+p0Rvi8TU59xaQkRlc0ZWJIcRdBdtzH/vaDROKKxmmFGehw7mZVUSeSNCkO LdKZT8lbsrottpo47YRYMCfQNorJaFVp5qdfZxni9KYuBfZY8hbWRwwJTk+LEgPjI3c0 vUUw== X-Received: by 10.43.78.77 with SMTP id zl13mr8613916icb.55.1366401814848; Fri, 19 Apr 2013 13:03:34 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id x16sm4642744igp.8.2013.04.19.13.03.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Apr 2013 13:03:34 -0700 (PDT) Message-ID: <5171A316.1070202@gmail.com> Date: Fri, 19 Apr 2013 16:03:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] NAT logging for DS-Lite 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, 19 Apr 2013 20:03:35 -0000 I think we have to add a parameter to the session records for logging at the DS-Lite AFTR. Since the source IPv4 address may not be unique, the IPv6 tunnel address should also be logged. Is there enough deployment of GW-initiated DS-Lite that we should be considering other types of tunnel identifier too? Tom Taylor From dwing@cisco.com Mon Apr 22 12:10:35 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 84E8E11E80E4 for ; Mon, 22 Apr 2013 12:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cTZHENr39gin for ; Mon, 22 Apr 2013 12:10:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DDAD611E80E7 for ; Mon, 22 Apr 2013 12:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1165; q=dns/txt; s=iport; t=1366657834; x=1367867434; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VIstKGSq9ld5RzuuwcaCl4UKUqoiPZQMCBS1w5Fpj6c=; b=j6q2dUmFJihR8KH+wW768OTbL/fitCpeOq2U6Snnr9mNPe7YHEc87rSe xPkGa4Jdzft2O6D7nTOU0EHdQr+gEy5beIr6IgDIaL5Y7pLq73FuSlmpO GcVCIeW00NAuLhzUpyN4siunYhZ66VGAIJYFqBmM4wpRqBzxjhRAjaFjg w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAL2KdVGrRDoH/2dsb2JhbABFCoMGNgHBBoEGFnSCHwEBAQMBAQEBNzQLBQsLRiEGMAYTiAIDCQUNswsNiEIEjGiBG4EJMweCZmEDiQ2MJIFkhguFcYUegywc X-IronPort-AV: E=Sophos;i="4.87,528,1363132800"; d="scan'208";a="76240747" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 22 Apr 2013 19:10:33 +0000 Received: from [10.155.120.152] ([10.155.120.152]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3MJAW00007881; Mon, 22 Apr 2013 19:10:33 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <5171A316.1070202@gmail.com> Date: Mon, 22 Apr 2013 12:10:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <96920AC9-B62D-46B1-BAE7-05FE42FF8723@cisco.com> References: <5171A316.1070202@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1503) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT logging for DS-Lite 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, 22 Apr 2013 19:10:35 -0000 On Apr 19, 2013, at 1:03 PM, Tom Taylor = wrote: > I think we have to add a parameter to the session records for logging = at the DS-Lite AFTR. Since the source IPv4 address may not be unique, = the IPv6 tunnel address should also be logged. For DS-Lite, I don't see a need to log the inside IPv4 address at all. = The requirement is not to log which host within a subscriber's home = caused a mapping, rather the requirement is to identify the subscriber. = The IPv6 address, or rather the first 64 bits of the IPv6 address, are = plenty sufficient for that. If all the subscribers using the DS-Lite = have the same IPv6 prefix, the IPv6 prefix doesn't need to be logged = (which would be pretty common with most DS-Lite deployments which are = for an ISP's own subscribers, and not an Internet-facing service). -d >=20 > Is there enough deployment of GW-initiated DS-Lite that we should be = considering other types of tunnel identifier too? >=20 > Tom Taylor > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From tireddy@cisco.com Tue Apr 23 20:22: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 1785721F9128 for ; Tue, 23 Apr 2013 20:22:36 -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 fifKwGAXAiIw for ; Tue, 23 Apr 2013 20:22:35 -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 816B921F9120 for ; Tue, 23 Apr 2013 20:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1366773755; x=1367983355; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uhaKYk+krHHZVzJacMmY6uV8+OVppunID0Z+ZfpSB98=; b=TzUqPO6S3H5WiIoWfd2t08Ju7ILnCpTnzSAwJD171MOtjDrs46FtI1eb F44qKZJy56qr/1hH9+tUNO7I9unELjCjoh/OKUcmtqRqzIyUZusDfoWHQ HhsigyY6XgC7CBSvTdtBKpLqyUwogufbFgqxtrg0rVqk8V3g+ONC9du+0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAIRPd1GtJV2Y/2dsb2JhbABQgwY2gzK7Hg1+Fm0Hgh8BAQEEIxFDDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEEwgBiAsMnR2OU4RYjQ6BI41UPoIwMmEDmD2PeoMBDYIo X-IronPort-AV: E=Sophos;i="4.87,538,1363132800"; d="scan'208";a="202295517" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 24 Apr 2013 03:22:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3O3MLGc002882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Apr 2013 03:22:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.150]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 22:22:21 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-reddy-behave-turn-auth-00.txt Thread-Index: AQHOQB7ZnyvT0xMVb0S9pJAXf/EWoJjks3Rg Date: Wed, 24 Apr 2013 03:22:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A149778C5@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.42.144] 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-00.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: Wed, 24 Apr 2013 03:22:36 -0000 VGhpcyBkcmFmdCBkaXNjdXNzZXMgc29tZSBvZiB0aGUgcHJvYmxlbXMgd2l0aCBjdXJyZW50IFRV Uk4gYXV0aGVudGljYXRpb24gc28gdGhhdCBpdCBjYW4gc2VydmUgYXMgdGhlIGJhc2lzIGZvciBz dHJvbmdlciBUVVJOIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuICANCg0KY29tbWVudHMgYW5k IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpCZXN0IFJlZ2FyZHMsDQotLUF1dGhvcnMuDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgQXBy aWwgMjMsIDIwMTMgNjowNCBQTQ0KVG86IFJhbSBNb2hhbiBSIChybW9oYW5yKTsgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk7 IEFscGVyIFllZ2luOyBSYW0gTW9oYW4gUiAocm1vaGFucik7IEFscGVyIEUuIFllZ2luOyBNdXRo dSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1yZWRkeS1iZWhhdmUtdHVybi1hdXRoLTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yZWRkeS1iZWhhdmUtdHVybi1hdXRoLTAwLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1yZWRk eS1iZWhhdmUtdHVybi1hdXRoDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBQcm9ibGVtcyB3aXRo IFRVUk4gQXV0aGVudGljYXRpb24NCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA0LTIzDQpHcm91cDoJ CSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNg0KVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS1iZWhh dmUtdHVybi1hdXRoLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LWJlaGF2ZS10dXJuLWF1dGgNCkh0bWxpemVkOiAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVkZHktYmVoYXZlLXR1cm4tYXV0 aC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgc29tZSBvZiB0 aGUgaXNzdWVzIHdpdGggVFVSTiBhdXRoZW50aWNhdGlvbi4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From simon.perreault@viagenie.ca Wed Apr 24 01:23:46 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 9DC9E21F8F0F for ; Wed, 24 Apr 2013 01:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.465, 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 wBpy0y8mxmKn for ; Wed, 24 Apr 2013 01:23:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id ED8AA21F8F1E for ; Wed, 24 Apr 2013 01:23:45 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:75b7:d54f:7e76:34ca]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 62AB640432 for ; Wed, 24 Apr 2013 04:23:44 -0400 (EDT) Message-ID: <5177968F.6050805@viagenie.ca> Date: Wed, 24 Apr 2013 10:23:43 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: behave@ietf.org References: <913383AAA69FF945B8F946018B75898A149778C5@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A149778C5@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.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: Wed, 24 Apr 2013 08:23:47 -0000 Le 2013-04-24 05:22, Tirumaleswar Reddy (tireddy) a écrit : > This draft discusses some of the problems with current TURN authentication so that it can serve as the basis for stronger TURN authentication mechanisms. > > comments and suggestions are welcome. And here are some... - "TURN authentication" doesn't exist. It's "STUN authentication" that you're talking about. TURN just uses STUN auth. - In section "4. Problems with TURN Authentication", what's the difference between problems 1 and 2? - Problem 4 could also include the REALM attribute, which could be snooped and harvested similarly. - About the above: wasn't this all well known and accepted at the time STUN auth was being designed? - I have encountered another problem: it's impossible to host multiple realms on a single IP address. When the server needs to send the REALM attribute in response to an unauthenticated request, it has no useful information for determining which realm it should send, except the destination address of the request. This sucks, IPv4 addresses being not exactly free... I'm very interested in hearing about any solution you may have in mind... Simon From tom.taylor.stds@gmail.com Thu Apr 25 04: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 EDED821F93CD for ; Thu, 25 Apr 2013 04:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 WyXgE4az0FvT for ; Thu, 25 Apr 2013 04:35:16 -0700 (PDT) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6A27321F93B9 for ; Thu, 25 Apr 2013 04:35:16 -0700 (PDT) Received: by mail-ia0-f178.google.com with SMTP id j38so2573982iad.37 for ; Thu, 25 Apr 2013 04:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=GdLHwy0Ru5+RBd2uWmGfqwEMu7wRgyNZG3nRQwN4vyQ=; b=ZefPlgaXNRY/QcYAogy+PUjA4L5UXhNkQYbgwU7rhP2KfEPZegWXuBATMK5wFp0/bI 4bRsUhaHr42Ag9g/qUoY7dQHXNOHVFXtL24pnNgn+k10g9TIgNR2d8AR/AoWmv6+t19I ulNeQMOs9SRacGE0aCNiZH4dXq0SFbnN0sZS/FgaRYJUT4Y/kifDuhiKrg8+UzHtqIwC SMRb2wuYvasIMZrFu+538C3B1nW5rHzMT9ErvKgFNgnnFs9KOmtBbMDse0YP4cjj3c6V 6h0CjPPO6SaC8dw3TPBS98BDmowLjFFkA15KN644ZPOaL5VFGC7T2xQqaC2mGbSqrdvM RJoA== X-Received: by 10.50.78.34 with SMTP id y2mr1887882igw.50.1366889716059; Thu, 25 Apr 2013 04:35:16 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPSA id ip2sm33832791igc.5.2013.04.25.04.35.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 04:35:15 -0700 (PDT) Message-ID: <517914F3.2070003@gmail.com> Date: Thu, 25 Apr 2013 07:35:15 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] NAT Logging -- Port violation event for MAP-E or LW4over6 BR 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, 25 Apr 2013 11:35:17 -0000 The MAP-E and LW4over6 border routers are responsible for checking that the ports assigned by the CE are within the set allocated to that CE. I think we need a NAT logging event to report detection of an out-of-range port. Tom Taylor From tireddy@cisco.com Thu Apr 25 11:44:29 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 5F2FF21F8A18 for ; Thu, 25 Apr 2013 11:44:29 -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 X38EeQQ3Zjuw for ; Thu, 25 Apr 2013 11:44:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2821F89DB for ; Thu, 25 Apr 2013 11:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3093; q=dns/txt; s=iport; t=1366915468; x=1368125068; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=39sRkKZ5wdWpjrW26b9ZyhmOtSFwTIpvjNZMkBENAu8=; b=hYMT/PBXek0rcZe0z7+7dxBe5fuimsCePUV2UCPfTveacOe2Ksg9XCyG rInW6ZK9eCwzJ79vT99EBvPNixnSYQmSJ5xG02gKhQTAGscm6hMmce4kR vjdbwF0Iap/X2evCFatWAiHW6D7SW0RbkMuJN33KBNhWRK0X5JziJHH6I A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADh4eVGtJXHB/2dsb2JhbABRgwa+ZIEEFnSCHwEBAQMBdw4EAgEIEQQBAQsODwcyFAgBCAIEARIIE4dzBr5VjwQ4BhKCVWEDiFmfZYFYgTaCKA X-IronPort-AV: E=Sophos;i="4.87,552,1363132800"; d="scan'208";a="202925467" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 25 Apr 2013 18:44:25 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3PIiP59002564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 18:44:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.150]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 25 Apr 2013 13:44:25 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.txt Thread-Index: AQHOQeToW/CAZcoTg0SCQxMcWJzg9Q== Date: Thu, 25 Apr 2013 18:44:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14978FF1@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A149778C5@xmb-rcd-x10.cisco.com> <5177968F.6050805@viagenie.ca> In-Reply-To: <5177968F.6050805@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.68.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.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: Thu, 25 Apr 2013 18:44:29 -0000 Hi Sam, Thanks for the comments; please see inline > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Wednesday, April 24, 2013 1:54 PM > To: behave@ietf.org > Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave= - > turn-auth-00.txt >=20 > Le 2013-04-24 05:22, Tirumaleswar Reddy (tireddy) a =E9crit : > > This draft discusses some of the problems with current TURN authenticat= ion > so that it can serve as the basis for stronger TURN authentication mechan= isms. > > > > comments and suggestions are welcome. >=20 > And here are some... >=20 > - "TURN authentication" doesn't exist. It's "STUN authentication" that > you're talking about. TURN just uses STUN auth. Yes, TURN uses the authentication mechanism specified in STUN. TURN authent= ication is required because resources will be allocated on the TURN server,= whereas with STUN there are no resources allocated on the STUN server. The= STUN server is stateless and is only responding to the request from the cl= ient. Though both techniques need authentication for integrity protection o= f request and response. But there are STUN servers deployed without authent= ication and if the endpoints use DTLS-SRTP then there may not be a problem = even if man-in-middle device modifies the STUN response.=20 But TURN servers let's say deployed in DMZ need authentication. >=20 > - In section "4. Problems with TURN Authentication", what's the > difference between problems 1 and 2 ? [TR] Problem 1 seem to be possible even if strong password is used. since p= assword does not change frequently, the attacker could keep trying a number= of candidate passwords. [/TR] >=20 > - Problem 4 could also include the REALM attribute, which could be > snooped and harvested similarly. >=20 > - About the above: wasn't this all well known and accepted at the time > STUN auth was being designed ? May be the authors of STUN/TURN could answer this question, if these attack= s were previously discussed or not in WG. If TURN over TLS is used it would= solve the problem; but it would impact sending media over TCP and could in= troduce delays which are directly noticeable. >=20 > - I have encountered another problem: it's impossible to host multiple > realms on a single IP address. When the server needs to send the REALM > attribute in response to an unauthenticated request, it has no useful > information for determining which realm it should send, except the > destination address of the request. This sucks, IPv4 addresses being not > exactly free... Good point. For web Authentication, destination IP address helps to pick di= fferent REALM, but with TURN the only=20 information available is the Source IP. >=20 > I'm very interested in hearing about any solution you may have in mind... we are still discussing the solutions, some of them already being discussed= in PCP WG that needs to be evaluated for TURN are EAP-over-TURN, PANA etc.= =20 --Tiru. >=20 > Simon From simon.perreault@viagenie.ca Fri Apr 26 01:12: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 3255821F97F9 for ; Fri, 26 Apr 2013 01:12:16 -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 c1C+3g7vv5eL for ; Fri, 26 Apr 2013 01:12:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DEDAD21F97F6 for ; Fri, 26 Apr 2013 01:12:03 -0700 (PDT) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F3886469B1; Fri, 26 Apr 2013 04:12:02 -0400 (EDT) Message-ID: <517A36D2.6040504@viagenie.ca> Date: Fri, 26 Apr 2013 10:12:02 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A149778C5@xmb-rcd-x10.cisco.com> <5177968F.6050805@viagenie.ca> <913383AAA69FF945B8F946018B75898A14978FF1@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14978FF1@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.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, 26 Apr 2013 08:12:17 -0000 Le 2013-04-25 20:44, Tirumaleswar Reddy (tireddy) a écrit : >> - "TURN authentication" doesn't exist. It's "STUN authentication" >> that you're talking about. TURN just uses STUN auth. > > Yes, TURN uses the authentication mechanism specified in STUN. TURN > authentication is required because resources will be allocated on the > TURN server, whereas with STUN there are no resources allocated on > the STUN server. The STUN server is stateless and is only responding > to the request from the client. Though both techniques need > authentication for integrity protection of request and response. But > there are STUN servers deployed without authentication and if the > endpoints use DTLS-SRTP then there may not be a problem even if > man-in-middle device modifies the STUN response. > > But TURN servers let's say deployed in DMZ need authentication. I understand all that, but that's not the point. The point is that "TURN authentication" does not *exist*. All the problems you have identified apply to *STUN* authentication, which is defined in the *STUN* RFC. The fact that the Allocate request is more likely than the Binding request to be identified by a server administrator as needing auth protection is completely irrelevant, except perhaps in the introduction, or an operational considerations section. >> - In section "4. Problems with TURN Authentication", what's the >> difference between problems 1 and 2 ? > > [TR] Problem 1 seem to be possible even if strong password is used. > since password does not change frequently, the attacker could keep > trying a number of candidate passwords. [/TR] Doesn't that characteristic also apply to problem 2? >> - About the above: wasn't this all well known and accepted at the >> time STUN auth was being designed ? > > May be the authors of STUN/TURN could answer this question, if these > attacks were previously discussed or not in WG. If TURN over TLS is > used it would solve the problem; but it would impact sending media > over TCP and could introduce delays which are directly noticeable. DTLS? >> - I have encountered another problem: it's impossible to host >> multiple realms on a single IP address. When the server needs to >> send the REALM attribute in response to an unauthenticated request, >> it has no useful information for determining which realm it should >> send, except the destination address of the request. This sucks, >> IPv4 addresses being not exactly free... > > Good point. For web Authentication, destination IP address helps to > pick different REALM, but with TURN the only information available is > the Source IP. Exactly! I guess (D)TLS would solve that issue with the server_name extension [RFC6066]. >> I'm very interested in hearing about any solution you may have in >> mind... > > we are still discussing the solutions, some of them already being > discussed in PCP WG that needs to be evaluated for TURN are > EAP-over-TURN, PANA etc. I don't think we can rely on the PCP stuff also applying to STUN. The environments are very different, both on servers and clients. Anyway, I would appreciate being involved in that discussion. 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 tireddy@cisco.com Fri Apr 26 06:05: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 AE20321F9883 for ; Fri, 26 Apr 2013 06:05:36 -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 XiMAXLPU0qse for ; Fri, 26 Apr 2013 06:05:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6746721F983F for ; Fri, 26 Apr 2013 06:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4862; q=dns/txt; s=iport; t=1366981535; x=1368191135; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qgXWDDIRSemLrUj576+m84TNZpVkYJNIIMT+tNfweyM=; b=Ob1b3XaoyDX7c26wl56Jo83uBhfcYwz8sLkZwWWHm7BMjMkn85GopX5d EVCdouwCkWu5/5uFw9TdcJaJlBEzDto5SxIfvTbEXgTprlcmLO9lzZU68 PNHreCTu0CpfNpmXJP4vzdX5WPG4N8U0Jwpb1hzN1nJK7yVaD5GES7Mwq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAG16elGtJV2Z/2dsb2JhbABRgwc2vjSBAxZ0gh8BAQEDASdQAgwEAgEIEQQBAQsODwcyFAgBCAIEDgUIE4dzBr8NjwQxBwYSglVhA4hZj2iPfYFYgTaCKA X-IronPort-AV: E=Sophos;i="4.87,558,1363132800"; d="scan'208";a="203235463" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Apr 2013 13:05:27 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3QD5RCv007263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 13:05:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.150]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 08:05:27 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.txt Thread-Index: AQHOQlW91m3CzIDE2Eqi368ZoPAl75joXRjw Date: Fri, 26 Apr 2013 13:05:26 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1497986F@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A149778C5@xmb-rcd-x10.cisco.com> <5177968F.6050805@viagenie.ca> <913383AAA69FF945B8F946018B75898A14978FF1@xmb-rcd-x10.cisco.com> <517A36D2.6040504@viagenie.ca> In-Reply-To: <517A36D2.6040504@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.23] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.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, 26 Apr 2013 13:05:36 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Friday, April 26, 2013 1:42 PM > To: Tirumaleswar Reddy (tireddy) > Cc: behave@ietf.org > Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave= - > turn-auth-00.txt >=20 > Le 2013-04-25 20:44, Tirumaleswar Reddy (tireddy) a =E9crit : > >> - "TURN authentication" doesn't exist. It's "STUN authentication" > >> that you're talking about. TURN just uses STUN auth. > > > > Yes, TURN uses the authentication mechanism specified in STUN. TURN > > authentication is required because resources will be allocated on the > > TURN server, whereas with STUN there are no resources allocated on > > the STUN server. The STUN server is stateless and is only responding > > to the request from the client. Though both techniques need > > authentication for integrity protection of request and response. But > > there are STUN servers deployed without authentication and if the > > endpoints use DTLS-SRTP then there may not be a problem even if > > man-in-middle device modifies the STUN response. > > > > But TURN servers let's say deployed in DMZ need authentication. >=20 > I understand all that, but that's not the point. >=20 > The point is that "TURN authentication" does not *exist*. All the > problems you have identified apply to *STUN* authentication, which is > defined in the *STUN* RFC. Agreed, will update in the next version to say it's a problem with STUN Aut= hentication. >=20 > The fact that the Allocate request is more likely than the Binding > request to be identified by a server administrator as needing auth > protection is completely irrelevant, except perhaps in the introduction, > or an operational considerations section. Yes, will highlight that point. >=20 > >> - In section "4. Problems with TURN Authentication", what's the > >> difference between problems 1 and 2 ? > > > > [TR] Problem 1 seem to be possible even if strong password is used. > > since password does not change frequently, the attacker could keep > > trying a number of candidate passwords. [/TR] >=20 > Doesn't that characteristic also apply to problem 2 ? Yes it does, Do you want us to merge problem 1 and 2 ? >=20 > >> - About the above: wasn't this all well known and accepted at the > >> time STUN auth was being designed ? > > > > May be the authors of STUN/TURN could answer this question, if these > > attacks were previously discussed or not in WG. If TURN over TLS is > > used it would solve the problem; but it would impact sending media > > over TCP and could introduce delays which are directly noticeable. >=20 > DTLS? Yes, that is one possibility to use EAP over DTLS and multiplex the channel= Data also on the same 5-tuple (for fate sharing). we are yet to evaluate if it works, any problems with multiplexing etc. >=20 > - Problem 4 could also include the REALM attribute, which could be > snooped and harvested similarly. Do you have an attack or privacy problem in mind with REALM that we can add= ?=20 >=20 > >> - I have encountered another problem: it's impossible to host > >> multiple realms on a single IP address. When the server needs to > >> send the REALM attribute in response to an unauthenticated request, > >> it has no useful information for determining which realm it should > >> send, except the destination address of the request. This sucks, > >> IPv4 addresses being not exactly free... > > > > Good point. For web Authentication, destination IP address helps to > > pick different REALM, but with TURN the only information available is > > the Source IP. >=20 > Exactly! >=20 > I guess (D)TLS would solve that issue with the server_name extension > [RFC6066]. Yes, it will solve the problem. will add the problem you mentioned in the n= ext version, so that it will help coming up with a solution. >=20 > >> I'm very interested in hearing about any solution you may have in > >> mind... > > > > we are still discussing the solutions, some of them already being > > discussed in PCP WG that needs to be evaluated for TURN are > > EAP-over-TURN, PANA etc. >=20 > I don't think we can rely on the PCP stuff also applying to STUN. The > environments are very different, both on servers and clients. Agreed, though there could be some scenarios where PCP capable Firewall and= TURN server could be co-located.=20 >=20 > Anyway, I would appreciate being involved in that discussion. sure, will be happy to involve you in the discussion. Regards, --Tiru. >=20 > 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 Apr 26 06:16:14 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 1E84C21F9914 for ; Fri, 26 Apr 2013 06:16:14 -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 YOprpUoFSnEs for ; Fri, 26 Apr 2013 06:16: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 2D8BA21F990B for ; Fri, 26 Apr 2013 06:16:13 -0700 (PDT) Received: from porto.nomis80.org (unknown [193.49.160.97]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 56059403E0; Fri, 26 Apr 2013 09:16:12 -0400 (EDT) Message-ID: <517A7E1B.7000108@viagenie.ca> Date: Fri, 26 Apr 2013 15:16:11 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A149778C5@xmb-rcd-x10.cisco.com> <5177968F.6050805@viagenie.ca> <913383AAA69FF945B8F946018B75898A14978FF1@xmb-rcd-x10.cisco.com> <517A36D2.6040504@viagenie.ca> <913383AAA69FF945B8F946018B75898A1497986F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1497986F@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.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, 26 Apr 2013 13:16:14 -0000 Le 2013-04-26 15:05, Tirumaleswar Reddy (tireddy) a écrit : >>>> - In section "4. Problems with TURN Authentication", what's the >>>> difference between problems 1 and 2 ? >>> >>> [TR] Problem 1 seem to be possible even if strong password is used. >>> since password does not change frequently, the attacker could keep >>> trying a number of candidate passwords. [/TR] >> >> Doesn't that characteristic also apply to problem 2 ? > > Yes it does, Do you want us to merge problem 1 and 2 ? Well, I'm just trying to understand. If 1 and 2 are the same problem, then yes they should be merged. At this point I don't see any difference between the two. >> - Problem 4 could also include the REALM attribute, which could be >> snooped and harvested similarly. > > Do you have an attack or privacy problem in mind with REALM that we can add ? Not really. I guess that leaking the domain of a call is acceptable. >> I don't think we can rely on the PCP stuff also applying to STUN. The >> environments are very different, both on servers and clients. > > Agreed, though there could be some scenarios where PCP capable Firewall and TURN server could be co-located. Right. I am more focused on the WebRTC use case, where the TURN server is operated by the WebRTC application provider, and thus completely separate from any firewall the user might be behind. 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 Apr 26 08:46: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 830C421F99F1 for ; Fri, 26 Apr 2013 08:46:22 -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 Z0WM2p376+sk for ; Fri, 26 Apr 2013 08:46:21 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 90EF521F99E7 for ; Fri, 26 Apr 2013 08:46:21 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id i38so3748240iae.6 for ; Fri, 26 Apr 2013 08:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zZNm6mnWp/K23y5I1U5kg01My0HdFd1bTCkd9fEX1T0=; b=ezyLs54VNqo7rT9bmddC7mLoHNIysjuU7sXnnR/AguJFXYCHI0sSiPeGOA5Pawn9zV 20eZLlk3MUQ8a4qsYXFoZVJGOwqkVyMVq8kiVAcPuN07dwftxgaogyiJclCF92FQiLvP PnAMEs37j3HdD0HCOIJzUkpZl1euT2xPdaPZnLHMTUK+Ghz//WlETy+b906o90vnQwXt ElIij+pCRjBAKEfOaQ8QaPZ9z1t5fuU6GELlIAN+NbZs7re7xEUufDdxR2iX01zE0vLy tfBdIE4TneGljJtFbEpuhr/fD8erR4GYoqwjgpX51QO5jTiOFls1m/DP79OVPS3eIiA5 yD3Q== X-Received: by 10.50.50.8 with SMTP id y8mr2271634ign.55.1366991181114; Fri, 26 Apr 2013 08:46:21 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPSA id o10sm3806411igh.2.2013.04.26.08.46.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Apr 2013 08:46:20 -0700 (PDT) Message-ID: <517AA14C.4030605@gmail.com> Date: Fri, 26 Apr 2013 11:46:20 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "behave@ietf.org" References: <517914F3.2070003@gmail.com> In-Reply-To: <517914F3.2070003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] NAT Logging -- Port violation event for MAP-E or LW4over6 BR 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, 26 Apr 2013 15:46:22 -0000 Well, this comment has triggered an interesting discussion in Softwires, but now that I'm putting the final touches to a reissue of the SYSLOG NAT logging draft, I see it doesn't fit in very neatly there. The border router in these cases is not a NAT, so any discussion of logging probably belongs in a MAP-specific document. The CE is also responsible for checking, and the CE is a NAT, so it fits with the CE, but I'm not sure if it's worth standardizing. I'll leave it out unless I get comments otherwise. On 25/04/2013 7:35 AM, Tom Taylor wrote: > The MAP-E and LW4over6 border routers are responsible for checking that > the ports assigned by the CE are within the set allocated to that CE. I > think we need a NAT logging event to report detection of an out-of-range > port. > > Tom Taylor From dwing@cisco.com Fri Apr 26 09:29: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 C61EC21F99EC for ; Fri, 26 Apr 2013 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.339 X-Spam-Level: X-Spam-Status: No, score=-110.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QiC0kZZRtPzI for ; Fri, 26 Apr 2013 09:29:10 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8AB21F99E0 for ; Fri, 26 Apr 2013 09:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1417; q=dns/txt; s=iport; t=1366993750; x=1368203350; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BnQLupkdDuRnJ3CKSdyFrU5Zu7nZ1b/f3E17gitQwjA=; b=GVNxz3WmP+JliC2DQHMZ+J98KV/nH5MZ6KtWuOORRH+JJLkt7Fy1DRv7 AZFigWvZAMAWO4exDp841uz5GmFarcw2YDmv4JuaZg/oKdUmHATFYzEb7 YYJUom5rH59pkQ1t1nV3D/UgtWg+XEXPxvX7Bwv0Q+s1wQUim2RCZkgH3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAJCqelGrRDoG/2dsb2JhbABRgwc2Ab44gQUWdIIfAQEBAwEBAQE3NAsFCwsYLiEGMAYTiAIDCQUNtjkNiEkEjDyCIzMHgm1hA4kSijyBa4FkhhKFeIUfgy4cgS4H X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208";a="79630010" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 26 Apr 2013 16:29:10 +0000 Received: from [10.32.240.196] ([10.32.240.196]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3QGT9ft015726; Fri, 26 Apr 2013 16:29:09 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <517AA14C.4030605@gmail.com> Date: Fri, 26 Apr 2013 09:29:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8FA24700-118B-4BAE-8DD0-FB72C45DEE22@cisco.com> References: <517914F3.2070003@gmail.com> <517AA14C.4030605@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1503) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT Logging -- Port violation event for MAP-E or LW4over6 BR 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, 26 Apr 2013 16:29:10 -0000 On Apr 26, 2013, at 8:46 AM, Tom Taylor = wrote: > Well, this comment has triggered an interesting discussion in = Softwires, but now that I'm putting the final touches to a reissue of = the SYSLOG NAT logging draft, I see it doesn't fit in very neatly there. = The border router in these cases is not a NAT, so any discussion of = logging probably belongs in a MAP-specific document. The CE is also = responsible for checking, and the CE is a NAT, so it fits with the CE, = but I'm not sure if it's worth standardizing. >=20 > I'll leave it out unless I get comments otherwise. I believe the intent of generating such logging messages is = diagnostics/troubleshooting, in order to detect mis-configured = equipment. The mis-configured equipment is the CPE router. I don't = recall, but doesn't the MAP router send back ICMP errors if the = subscriber's CPE sends packets with the wrong port number? -d > On 25/04/2013 7:35 AM, Tom Taylor wrote: >> The MAP-E and LW4over6 border routers are responsible for checking = that >> the ports assigned by the CE are within the set allocated to that CE. = I >> think we need a NAT logging event to report detection of an = out-of-range >> port. >>=20 >> Tom Taylor > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From alper.yegin@yegin.org Fri Apr 26 09:30: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 EB37621F9A0D for ; Fri, 26 Apr 2013 09:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 LlOM3c3We2He for ; Fri, 26 Apr 2013 09:30:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0709121F99FA for ; Fri, 26 Apr 2013 09:30:15 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LhfEf-1Ursoo1RQ1-00nI6o; Fri, 26 Apr 2013 12:30:11 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_28DA17CC-7579-4C9C-AF21-25FA5E8A08F8" From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A1497986F@xmb-rcd-x10.cisco.com> Date: Fri, 26 Apr 2013 19:30:05 +0300 Message-Id: References: <913383AAA69FF945B8F946018B75898A149778C5@xmb-rcd-x10.cisco.com> <5177968F.6050805@viagenie.ca> <913383AAA69FF945B8F946018B75898A14978FF1@xmb-rcd-x10.cisco.com> <517A36D2.6040504@viagenie.ca> <913383AAA69FF945B8F946018B75898A1497986F@xmb-rcd-x10.cisco.com> To: Simon Perreault X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:DkExmKX0t8LJWrm7MoRHIb1pbBCS/onXH/emnRZOy7X TLmvT0B50aCp3gSezT8lEE1kwqoT/ueMIXBPZhYCrZQR6rZ47n As+Od/JPpzU7Yp6VqiekKEGs889+pLP0eEH0uVLoGdcW7Cu4Dl 2RniKPVqXYCgm8AHwC9KpvAnRY3SFcblWzNW8gfMHlMW8zpvKu lcNdjPX5dR34qNWjWeu410wNlA4XorqjuA66LYQ/jSyMhIYcWB 4rnN9yyWvO5g5CPPEi3FA0QelV/y+cQkeqeOUIlfD1dvlFdfHj nUCE7k27m1kcekyvZiqH36dx1fZuX4uBOMmRX/fMMSomy64J4f 8N1XYSZjtZY58UcnzaJkHGVBHSrdyEufYikEHkglY6yBTfYqZ9 0x7spoGnbdmTw== Cc: behave@ietf.org, "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-00.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, 26 Apr 2013 16:30:17 -0000 --Apple-Mail=_28DA17CC-7579-4C9C-AF21-25FA5E8A08F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 26, 2013, at 4:05 PM, Tirumaleswar Reddy (tireddy) wrote: >>> we are still discussing the solutions, some of them already being >>> discussed in PCP WG that needs to be evaluated for TURN are >>> EAP-over-TURN, PANA etc. >>=20 >> I don't think we can rely on the PCP stuff also applying to STUN. The >> environments are very different, both on servers and clients. I think the point is, there are two approaches here: One is to define = protocol-specific EAP transport (such as EAP-over-PCP, and = EAP-over-TURN, etc.), or to rely on using PANA. --Apple-Mail=_28DA17CC-7579-4C9C-AF21-25FA5E8A08F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
we are still = discussing the solutions, some of them already = being
discussed in PCP WG that needs to be evaluated for TURN = are
EAP-over-TURN, PANA = etc.

I don't think = we can rely on the PCP stuff also applying to STUN. = The
environments are very = different, both on servers and = clients.


I think the point is, there are two approaches here: One is to define = protocol-specific EAP transport (such as EAP-over-PCP, and = EAP-over-TURN, etc.), or to rely on using = PANA.





= --Apple-Mail=_28DA17CC-7579-4C9C-AF21-25FA5E8A08F8-- From ssenthil@cisco.com Fri Apr 26 10:27: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 EFB1E21F9971 for ; Fri, 26 Apr 2013 10:27:55 -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 7NR2Uezo6Bng for ; Fri, 26 Apr 2013 10:27:55 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2E21F21F996C for ; Fri, 26 Apr 2013 10:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1926; q=dns/txt; s=iport; t=1366997275; x=1368206875; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=as7J/X4RPYwFEUIIG7E0diPvZhSbCERsJG3V46+Z8KI=; b=S9opW6dNaUPlb0mkgjBuwzA3TqjwGq93jqMptK2bGVBofjgQ4HGO7ASw f4h7qi3HvFs2VMIkK0EQur9OVRJ8zCY51m5jZIc5BDWYLuRNs3HvSxij7 S134QYO9vntKQOBJIy7Pwp0AKEk9ULBQasTYJ5iEwUBov2XKzRQYmUBtL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAOa3elGtJV2d/2dsb2JhbABRgwc2vjqBBRZ0gh8BAQEEAQEBNzQLEgEIGAoUMQYLJQIEAQ0FCId6Aw8MtjMNiEkEjDyCJTEHgm1hA5NOgWuNboUfgw6Bagc3 X-IronPort-AV: E=Sophos;i="4.87,559,1363132800"; d="scan'208";a="203524803" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 26 Apr 2013 17:27:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3QHRshw031702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Apr 2013 17:27:54 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.104]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 26 Apr 2013 12:27:54 -0500 From: "Senthil Sivakumar (ssenthil)" To: "Dan Wing (dwing)" , Tom Taylor Thread-Topic: [BEHAVE] NAT Logging -- Port violation event for MAP-E or LW4over6 BR Thread-Index: AQHOQqNi+pv2b5Du+USrk93ke0odAA== Date: Fri, 26 Apr 2013 17:27:54 +0000 Message-ID: In-Reply-To: <8FA24700-118B-4BAE-8DD0-FB72C45DEE22@cisco.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.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <2627EE4D383ACE4BB8BA5796F04C8408@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT Logging -- Port violation event for MAP-E or LW4over6 BR 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, 26 Apr 2013 17:27:56 -0000 On 4/26/13 12:29 PM, "Dan Wing (dwing)" wrote: > >On Apr 26, 2013, at 8:46 AM, Tom Taylor wrote: > >> Well, this comment has triggered an interesting discussion in >>Softwires, but now that I'm putting the final touches to a reissue of >>the SYSLOG NAT logging draft, I see it doesn't fit in very neatly there. >>The border router in these cases is not a NAT, so any discussion of >>logging probably belongs in a MAP-specific document. The CE is also >>responsible for checking, and the CE is a NAT, so it fits with the CE, >>but I'm not sure if it's worth standardizing. >>=20 >> I'll leave it out unless I get comments otherwise. > >I believe the intent of generating such logging messages is >diagnostics/troubleshooting, in order to detect mis-configured equipment. > The mis-configured equipment is the CPE router. I don't recall, but >doesn't the MAP router send back ICMP errors if the subscriber's CPE >sends packets with the wrong port number? Yes, it does. "If the packets source port number is found to be outside the range allowed for this CE and the BMR, the BR MUST drop the packet and respond with an ICMPv6 "Destination Unreachable, Source address failed ingress/egress policy" (Type 1, Code 5)." > >-d > > >> On 25/04/2013 7:35 AM, Tom Taylor wrote: >>> The MAP-E and LW4over6 border routers are responsible for checking that >>> the ports assigned by the CE are within the set allocated to that CE. I >>> think we need a NAT logging event to report detection of an >>>out-of-range >>> port. >>>=20 >>> 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 johnsonhammond2@hushmail.com Sat Apr 27 10:14:40 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 0AECE21F9822 for ; Sat, 27 Apr 2013 10:14:40 -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 vEnyZPqWUgUu for ; Sat, 27 Apr 2013 10:14:39 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id C11CD21F9821 for ; Sat, 27 Apr 2013 10:14:39 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 85C6DE7CA2 for ; Sat, 27 Apr 2013 17:14:39 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:14:39 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 3F92314DBDE; Sat, 27 Apr 2013 17:14:39 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:14:39 -0400 To: behave@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427171439.3F92314DBDE@smtp.hushmail.com> Subject: [BEHAVE] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 18:06:18 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From wwwrun@rfc-editor.org Mon Apr 29 15:39:29 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 B9AFA21F9BA6; Mon, 29 Apr 2013 15:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.188, 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 ilCEAiW8m-XC; Mon, 29 Apr 2013 15:39:29 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4218521F9BA4; Mon, 29 Apr 2013 15:39:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9B69CB1E003; Mon, 29 Apr 2013 15:39:03 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130429223903.9B69CB1E003@rfc-editor.org> Date: Mon, 29 Apr 2013 15:39:03 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] BCP 127, RFC 6888 on Common Requirements for Carrier-Grade NATs (CGNs) 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, 29 Apr 2013 22:39:29 -0000 A new Request for Comments is now available in online RFC libraries. BCP 127 RFC 6888 Title: Common Requirements for Carrier-Grade NATs (CGNs) Author: S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida Status: Best Current Practice Stream: IETF Date: April 2013 Mailbox: simon.perreault@viagenie.ca, ikuhei@nttv6.jp, miyakawa@nttv6.jp, a-nakagawa@jpix.ad.jp, hiashida@cisco.com Pages: 15 Characters: 32484 Updates: RFC 4787 See Also: BCP 127 I-D Tag: draft-ietf-behave-lsn-requirements-10.txt URL: http://www.rfc-editor.org/rfc/rfc6888.txt This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Apr 29 15:40: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 046BA21F9BA4; Mon, 29 Apr 2013 15:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 t0dQ5ebZw-Am; Mon, 29 Apr 2013 15:39:59 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 80E1221F9BB6; Mon, 29 Apr 2013 15:39:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 213DEB1E004; Mon, 29 Apr 2013 15:39:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130429223932.213DEB1E004@rfc-editor.org> Date: Mon, 29 Apr 2013 15:39:32 -0700 (PDT) Cc: behave@ietf.org, rfc-editor@rfc-editor.org Subject: [BEHAVE] RFC 6889 on Analysis of Stateful 64 Translation 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, 29 Apr 2013 22:40:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6889 Title: Analysis of Stateful 64 Translation Author: R. Penno, T. Saxena, M. Boucadair, S. Sivakumar Status: Informational Stream: IETF Date: April 2013 Mailbox: rpenno@juniper.net, tasaxena@cisco.com, mohamed.boucadair@orange.com, ssenthil@cisco.com Pages: 15 Characters: 33171 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-behave-64-analysis-07.txt URL: http://www.rfc-editor.org/rfc/rfc6889.txt Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC