From meng.wei2@zte.com.cn Fri Nov 2 20:17:41 2012 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 61D0111E8103; Fri, 2 Nov 2012 20:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.95 X-Spam-Level: X-Spam-Status: No, score=-92.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKlXEpWH2b8N; Fri, 2 Nov 2012 20:17:40 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE4111E80DF; Fri, 2 Nov 2012 20:17:40 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 275161261D6D; Sat, 3 Nov 2012 11:18:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qA33HUpv020938; Sat, 3 Nov 2012 11:17:30 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <03fd01cdb5f5$5de3d640$19ab82c0$@cisco.com> To: "Dan Wing" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Wei Meng Date: Sat, 3 Nov 2012 11:17:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-11-03 11:17:11, Serialize complete at 2012-11-03 11:17:11 Content-Type: multipart/alternative; boundary="=_alternative 0012150C48257AAB_=" X-MAIL: mse02.zte.com.cn qA33HUpv020938 Cc: behave-bounces@ietf.org, wang.cui1@zte.com.cn, huj@ctbri.com.cn, behave@ietf.org Subject: [BEHAVE] =?gb2312?b?tPC4tDogUmU6ICBBIGRyYWZ0IGFib3V0IHNoYXJpbmcg?= =?gb2312?b?cG9vbCBhbW9uZyByZWdpb25z?= 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, 03 Nov 2012 03:17:41 -0000 This is a multipart message in MIME format. --=_alternative 0012150C48257AAB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRGFuLA0KICAgIFRoYW5rcyBmb3IgQ2hhaXIncyBzdWdnZXN0aW9uLiBGb3IgdGhpcyBkcmFm dCwgSSB1c2VkIHRvIGZvY3VzIG9uIHRoZSANCm1ldGhvZCBob3cgdG8gc2hhcmUgdGhlIHBvb2xz Lg0KDQogICAgRm9yIFBhcmFncmFwaCAxDQogICAgSSB0aGluayB3ZSBjYW4gc2V0IGEgZmxhZyB0 byBtYXJrIHdoaWNoIENFTEwocykgd2lsbCBiZSByZWxlYXNlZCwgYW5kIA0KdGhlIENFTEwocykg d2lsbCBub3QgYmUgYXNzaWduZWQgYWdhaW4uIEJvdGggdGhlIHJlbGVhc2luZyBhbmQgcmVxdWVz dGluZyANCmFjdGlvbihhICYgYikgc2hvdWxkIGJlIHB1dCBpbiBvbmUgcHJvY2Vzc2lvbi4NCiAg ICBIb3dldmVyLCBtYXliZSB3ZSBhbHNvIGhhdmUgb3RoZXIgbW90aGVkcyB0byByZXNvbHZlIHRo aXMgcHJvYmxlbS4NCg0KICAgIEZvciBQYXJhZ3JhcGggMg0KICAgIEkgd2lsbCBhZGQgcmVsYXRl ZCBjb250ZW50IHRvIHRoZSBkcmFmdC4NCg0KICAgIEZvciBQYXJhZ3JhcGggMw0KICAgIFRoaXMg ZHJhZnQgZG9lcyBub3QgcmVmZXIgdG8gbXVsdGktdmVuZGVyIGludGVyb3BlcmFiaWxpdHkuIEkg dGhpbmsgDQp0aGUgQ0VMTChzKSBzaG91bGQgaGF2ZSBhbiBhdHRyaWJ1dGUgb2YgdmVuZGVyLiBJ dCBjYW4gcmVzb2x2ZSB0aGUgDQpwcm9ibGVtLg0KDQpCZXN0IFJlZ2FyZHMsDQpXZWkNCiANCg0K YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLzEwLzMwIDAwOjQ5OjMwOg0KDQo+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBiZWhhdmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBPbiANCkJlaGFsZg0KPiA+IE9m IG1lbmcud2VpMkB6dGUuY29tLmNuDQo+ID4gU2VudDogVHVlc2RheSwgT2N0b2JlciAwOSwgMjAx MiA2OjI2IFBNDQo+ID4gVG86IGJlaGF2ZUBpZXRmLm9yZw0KPiA+IENjOiB3YW5nLmN1aTFAenRl LmNvbS5jbjsgaHVqQGN0YnJpLmNvbS5jbg0KPiA+IFN1YmplY3Q6IFtCRUhBVkVdIEEgZHJhZnQg YWJvdXQgc2hhcmluZyBwb29sIGFtb25nIHJlZ2lvbnMNCj4gPiANCj4gPiANCj4gPiBEZWFyIGFs bCwNCj4gPiANCj4gPiBXZSBhcmUgdmVyeSBpbnRlcmVzdGVkIGluIEJlaGF2ZSBXRywgd2UgYWdy ZWUgdGhhdCBzZXZlcmFsIHByb2JsZW1zDQo+ID4gc2hvdWxkIGJlIHJlc29sdmVkIGluIElFVEYu DQo+ID4gDQo+ID4gQSBkcmFmdCBhYm91dCBpbXByb3ZpbmcgcG9vbCBzaGFyZS1yYXRpbyBoYWQg YWxyZWFkeSBiZWVuIHN1Ym1pdHRlZCB0bw0KPiA+IHRoZSBCZWhhdmUgbGlzdCBpbiBTZXB0ZW1i ZXIuDQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWVuZy1iZWhhdmUtaXAt cmVzb3VyY2VzLXNoYXJlLTAwDQo+ID4gPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW1lbmctYmVoYXZlLWlwLXJlc291cmNlcy1zaGFyZS0wMD4NCj4gPiANCj4gPiBJIGFwcHJlY2lh dGUgeW91ciBjb21tZW50cyBhbmQgb3RoZXIgc29sdXRpb25zLCBJIHdpbGwgdXBkYXRlIHRoZSAN CmRyYWZ0DQo+ID4gbGF0ZXIuIEhvcGUgd2Ugd2lsbCBtb3ZlIGZvcndhcmQgOi0pDQo+IA0KPiBV c2VyJ3MgcHVibGljIElQIGFkZHJlc3NlcyBuZWVkIHRvIHN0YXkgdGhlIHNhbWUgKG9yIGVsc2Ug ZXhpc3RpbmcNCj4gc2Vzc2lvbnMgYnJlYWspLCBzbyBJIGFzc3VtZSB0aGUgaW50ZW50IGlzIGVp dGhlciAoYSkgbW92ZSBvbmx5DQo+ICduZXdseSBhY3RpdmUgdXNlcnMnICh3aG8gaGF2ZSBzZW50 IHRoZWlyIGZpcnN0IHBhY2tldCksIG9yIChiKQ0KPiBhc3NpZ24gdXNlcnMgdG8gYSBzcGVjaWZp YyBOQVQgd2hlbiB0aGV5IGpvaW4gdGhlIG5ldHdvcmsgKHZpYQ0KPiBESENQLCBQUFBvRSwgZXRj LikuICBUaGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyZXIgb24gaG93IHRoYXQgDQo+IG9jY3Vycy4N Cj4gDQo+IEFmdGVyIHRoYXQgb2NjdXJzLCBJIGRvbid0IHNlZSBob3cgYSB1c2VyJ3MgdHJhZmZp YyBpcyBzdGVlcmVkDQo+IHRvd2FyZHMgdGhlIGFwcHJvcHJpYXRlIE5BVC4gIFRoYXQgc2VlbXMg dG8gZGVwZW5kIG9uIHdoYXQNCj4gc29ydCBvZiBuZXR3b3JrIGV4aXN0cyBiZXR3ZWVuIHRoZSBz dWJzY3JpYmVyIGFuZCB0aGVpciBOQVQNCj4gKERTLUxpdGUgdHVubmVsLCBJUHY0IHJvdXRlZCBu ZXR3b3JrLCBOQVQgY28tbG9jYXRlZCB3aXRoIHRoZQ0KPiBmaXJzdC1ob3Agcm91dGVyIChlLmcu LCBDTVRTKSksIGFuZCBzbyBvbikuICBUaGF0IGlzIGNyaXRpY2FsDQo+IGZvciB0aGlzIGlkZWEg dG8gd29yaywgYW5kIHRoZSBkcmFmdCBuZWVkcyB0byBjb25zdHJhaW4gaXRzZWxmDQo+IHRvIHRo ZSBuZXR3b3JrIHRvcG9sb2dpZXMgdGhlIGF1dGhvcnMgYXJlIGNvbnNpZGVyaW5nLg0KPiANCj4g SXMgdGhlcmUgYSBuZWVkIGZvciBtdWx0aS12ZW5kZXIgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRo aXMNCj4gbWVjaGFuaXNtPyAgVGhhdCBpcywgd291bGQgYW4gb3BlcmF0b3IgZGVwbG95IGEgTkFU IGZyb20gdmVuZG9yDQo+IEEgYW5kIGFub3RoZXIgTkFUIGZyb20gdmVuZG9yIEIsIGFuZCBleHBl Y3QgdG8gbG9hZCBiYWxhbmNlDQo+IG91dGdvaW5nIHRyYWZmaWMsIGFtb25nc3Qgc3Vic2NyaWJl cnMsIGJldHdlZW4gdGhvc2UgdHdvDQo+IE5BVHM/ICBUaGUgTkFUcyB3aWxsIGhhdmUgZGlmZmVy ZW50IHBlcmZvcm1hbmNlIGNoYXJhY3RlcmlzdGljcw0KPiBhbmQgZGlmZmVyZW50IHR5cGVzIG9m IHRyYWZmaWMgd2lsbCBsb2FkIHRoZW0gZGlmZmVyZW50bHkgKGUuZy4sDQo+IG9uZSBtYXkgaGF2 ZSBoaWdoZXIgcHBzIGJ1dCBsb3cgbnVtYmVyIG9mIG1hcHBpbmdzOyBvbmUgbWlnaHQNCj4gc3Vw cG9ydCBJUHNlYyBQYXNzdGhydSB3aGlsZSB0aGUgb3RoZXIgZG9lc24ndCkuDQo+IA0KPiAtZA0K PiANCj4gDQo+ID4gQmVzdCB3aXNoZXMNCj4gPiANCj4gPiBXZWkNCj4gPiANCj4gPiANCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyANCm1haWwNCj4gPiAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVk IGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCANCmNvbmZpZGVudGlhbA0KPiA+IGFuZCBpcyBp bnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlv dSBhcmUNCj4gPiBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24gDQpvcg0KPiA+IG90aGVyIGRpc3NlbWluYXRpb24gb3Ig dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkNCj4gPiBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0DQo+ID4gYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCj4gPiANCj4gPiANCj4gDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBC ZWhhdmUgbWFpbGluZyBsaXN0DQo+IEJlaGF2ZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0KDQo= --=_alternative 0012150C48257AAB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIERhbiw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgVGhhbmtzIGZvciBD aGFpcidzIHN1Z2dlc3Rpb24uDQpGb3IgdGhpcyBkcmFmdCwgSSB1c2VkIHRvIGZvY3VzIG9uIHRo ZSBtZXRob2QgaG93IHRvIHNoYXJlIHRoZSBwb29scy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgRm9yIDwvZm9udD48Zm9udCBz aXplPTE+UGFyYWdyYXBoPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCjE8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg SSB0aGluayB3ZSBjYW4gc2V0IGEgZmxhZw0KdG8gbWFyayB3aGljaCBDRUxMKHMpIHdpbGwgYmUg cmVsZWFzZWQsIGFuZCB0aGUgQ0VMTChzKSB3aWxsIG5vdCBiZSBhc3NpZ25lZA0KYWdhaW4uIEJv dGggdGhlIHJlbGVhc2luZyBhbmQgcmVxdWVzdGluZyBhY3Rpb24oYSAmYW1wOyBiKSBzaG91bGQg YmUgcHV0DQppbiBvbmUgcHJvY2Vzc2lvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgSG93ZXZlciwgbWF5YmUgd2UgYWxzbw0KaGF2ZSBv dGhlciBtb3RoZWRzIHRvIHJlc29sdmUgdGhpcyBwcm9ibGVtLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBGb3IgPC9mb250Pjxm b250IHNpemU9MT5QYXJhZ3JhcGg8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pg0KMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyBJIHdpbGwgYWRkIHJlbGF0ZWQgY29udGVudA0KdG8gdGhlIGRyYWZ0LjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBGb3Ig PC9mb250Pjxmb250IHNpemU9MT5QYXJhZ3JhcGg8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPg0KMzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyBUaGlzIGRyYWZ0IGRvZXMgbm90IHJlZmVyDQp0byA8L2ZvbnQ+PGZvbnQg c2l6ZT0yPm11bHRpLXZlbmRlcjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD5pbnRlcm9wZXJhYmlsaXR5PC90dD48L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi4NCkkgdGhpbmsgdGhlIENFTEwocykgc2hvdWxk IGhhdmUgYW4gYXR0cmlidXRlIG9mIHZlbmRlci4gSXQgY2FuIHJlc29sdmUNCnRoZSBwcm9ibGVt LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCBS ZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2VpPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PmJlaGF2ZS1ib3VuY2VzQGlldGYub3Jn INC009ogMjAxMi8xMC8zMCAwMDo0OTozMDo8YnI+DQo8YnI+DQomZ3Q7ICZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10NCk9uIEJlaGFsZjxicj4NCiZn dDsgJmd0OyBPZiBtZW5nLndlaTJAenRlLmNvbS5jbjxicj4NCiZndDsgJmd0OyBTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDA5LCAyMDEyIDY6MjYgUE08YnI+DQomZ3Q7ICZndDsgVG86IGJlaGF2ZUBp ZXRmLm9yZzxicj4NCiZndDsgJmd0OyBDYzogd2FuZy5jdWkxQHp0ZS5jb20uY247IGh1akBjdGJy aS5jb20uY248YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogW0JFSEFWRV0gQSBkcmFmdCBhYm91dCBz aGFyaW5nIHBvb2wgYW1vbmcgcmVnaW9uczxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IERlYXIgYWxsLDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg V2UgYXJlIHZlcnkgaW50ZXJlc3RlZCBpbiBCZWhhdmUgV0csIHdlIGFncmVlIHRoYXQgc2V2ZXJh bCBwcm9ibGVtczxicj4NCiZndDsgJmd0OyBzaG91bGQgYmUgcmVzb2x2ZWQgaW4gSUVURi48YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEEgZHJhZnQgYWJvdXQgaW1wcm92aW5nIHBvb2wg c2hhcmUtcmF0aW8gaGFkIGFscmVhZHkgYmVlbiBzdWJtaXR0ZWQNCnRvPGJyPg0KJmd0OyAmZ3Q7 IHRoZSBCZWhhdmUgbGlzdCBpbiBTZXB0ZW1iZXIuPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1lbmctYmVoYXZlLWlwLXJlc291cmNlcy1zaGFyZS0wMDxi cj4NCiZndDsgJmd0OyAmbHQ7aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWVuZy1i ZWhhdmUtaXAtcmVzb3VyY2VzLXNoYXJlLTAwJmd0Ozxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgSSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYW5kIG90aGVyIHNvbHV0aW9ucywgSSB3 aWxsIHVwZGF0ZQ0KdGhlIGRyYWZ0PGJyPg0KJmd0OyAmZ3Q7IGxhdGVyLiBIb3BlIHdlIHdpbGwg bW92ZSBmb3J3YXJkIDotKTxicj4NCiZndDsgPGJyPg0KJmd0OyBVc2VyJ3MgcHVibGljIElQIGFk ZHJlc3NlcyBuZWVkIHRvIHN0YXkgdGhlIHNhbWUgKG9yIGVsc2UgZXhpc3Rpbmc8YnI+DQomZ3Q7 IHNlc3Npb25zIGJyZWFrKSwgc28gSSBhc3N1bWUgdGhlIGludGVudCBpcyBlaXRoZXIgKGEpIG1v dmUgb25seTxicj4NCiZndDsgJ25ld2x5IGFjdGl2ZSB1c2VycycgKHdobyBoYXZlIHNlbnQgdGhl aXIgZmlyc3QgcGFja2V0KSwgb3IgKGIpPGJyPg0KJmd0OyBhc3NpZ24gdXNlcnMgdG8gYSBzcGVj aWZpYyBOQVQgd2hlbiB0aGV5IGpvaW4gdGhlIG5ldHdvcmsgKHZpYTxicj4NCiZndDsgREhDUCwg UFBQb0UsIGV0Yy4pLiAmbmJzcDtUaGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyZXIgb24gaG93IHRo YXQNCjxicj4NCiZndDsgb2NjdXJzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBZnRlciB0aGF0IG9j Y3VycywgSSBkb24ndCBzZWUgaG93IGEgdXNlcidzIHRyYWZmaWMgaXMgc3RlZXJlZDxicj4NCiZn dDsgdG93YXJkcyB0aGUgYXBwcm9wcmlhdGUgTkFULiAmbmJzcDtUaGF0IHNlZW1zIHRvIGRlcGVu ZCBvbiB3aGF0PGJyPg0KJmd0OyBzb3J0IG9mIG5ldHdvcmsgZXhpc3RzIGJldHdlZW4gdGhlIHN1 YnNjcmliZXIgYW5kIHRoZWlyIE5BVDxicj4NCiZndDsgKERTLUxpdGUgdHVubmVsLCBJUHY0IHJv dXRlZCBuZXR3b3JrLCBOQVQgY28tbG9jYXRlZCB3aXRoIHRoZTxicj4NCiZndDsgZmlyc3QtaG9w IHJvdXRlciAoZS5nLiwgQ01UUykpLCBhbmQgc28gb24pLiAmbmJzcDtUaGF0IGlzIGNyaXRpY2Fs PGJyPg0KJmd0OyBmb3IgdGhpcyBpZGVhIHRvIHdvcmssIGFuZCB0aGUgZHJhZnQgbmVlZHMgdG8g Y29uc3RyYWluIGl0c2VsZjxicj4NCiZndDsgdG8gdGhlIG5ldHdvcmsgdG9wb2xvZ2llcyB0aGUg YXV0aG9ycyBhcmUgY29uc2lkZXJpbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElzIHRoZXJlIGEg bmVlZCBmb3IgbXVsdGktdmVuZGVyIGludGVyb3BlcmFiaWxpdHkgd2l0aCB0aGlzPGJyPg0KJmd0 OyBtZWNoYW5pc20/ICZuYnNwO1RoYXQgaXMsIHdvdWxkIGFuIG9wZXJhdG9yIGRlcGxveSBhIE5B VCBmcm9tIHZlbmRvcjxicj4NCiZndDsgQSBhbmQgYW5vdGhlciBOQVQgZnJvbSB2ZW5kb3IgQiwg YW5kIGV4cGVjdCB0byBsb2FkIGJhbGFuY2U8YnI+DQomZ3Q7IG91dGdvaW5nIHRyYWZmaWMsIGFt b25nc3Qgc3Vic2NyaWJlcnMsIGJldHdlZW4gdGhvc2UgdHdvPGJyPg0KJmd0OyBOQVRzPyAmbmJz cDtUaGUgTkFUcyB3aWxsIGhhdmUgZGlmZmVyZW50IHBlcmZvcm1hbmNlIGNoYXJhY3RlcmlzdGlj czxicj4NCiZndDsgYW5kIGRpZmZlcmVudCB0eXBlcyBvZiB0cmFmZmljIHdpbGwgbG9hZCB0aGVt IGRpZmZlcmVudGx5IChlLmcuLDxicj4NCiZndDsgb25lIG1heSBoYXZlIGhpZ2hlciBwcHMgYnV0 IGxvdyBudW1iZXIgb2YgbWFwcGluZ3M7IG9uZSBtaWdodDxicj4NCiZndDsgc3VwcG9ydCBJUHNl YyBQYXNzdGhydSB3aGlsZSB0aGUgb3RoZXIgZG9lc24ndCkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IC1kPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBCZXN0IHdpc2hlczxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2VpPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KdGhpcyBtYWlsPGJyPg0K Jmd0OyAmZ3Q7IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHBy aXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbDxicj4NCiZndDsgJmd0OyBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICZuYnNwO0lmDQp5b3Ug YXJlPGJyPg0KJmd0OyAmZ3Q7IG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9z dXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbg0Kb3I8YnI+DQomZ3Q7ICZndDsgb3RoZXIg ZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJp Y3RseTxicj4NCiZndDsgJmd0OyBwcm9oaWJpdGVkLiAmbmJzcDtJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZQ0KZGVsZXRlIGl0PGJyPg0KJmd0OyAmZ3Q7IGFu ZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgQmVoYXZlIG1haWxpbmcgbGlzdDxicj4N CiZndDsgQmVoYXZlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JlaGF2ZTxicj4NCjwvdHQ+PC9mb250Pg0K --=_alternative 0012150C48257AAB_=-- From internet-drafts@ietf.org Mon Nov 5 04:02:36 2012 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 44F0921F861F; Mon, 5 Nov 2012 04:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twoyOnIDskT6; Mon, 5 Nov 2012 04:02:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A35721F8616; Mon, 5 Nov 2012 04:02:35 -0800 (PST) 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.35 Message-ID: <20121105120235.30668.1041.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 04:02:35 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-12.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:02:36 -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-12.txt Pages : 18 Date : 2012-11-05 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 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-heuris= tic-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tireddy@cisco.com Mon Nov 12 20:51:40 2012 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 AC74721E802E for ; Mon, 12 Nov 2012 20:51:40 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjWTBrWxwW83 for ; Mon, 12 Nov 2012 20:51:39 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF7C821F8895 for ; Mon, 12 Nov 2012 20:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7639; q=dns/txt; s=iport; t=1352782299; x=1353991899; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UPeNdJV0rYGlBd5h8lRyTawa2zsczYLuiNGowZVufHg=; b=glgKk6rQBzlJf3zLYEgZcDcVsrmi7C3d7RaEjg7u9DOEZusLvijgPPEZ YlHQr9f7Pjn69tG6CVDgcXxfq4og/ETGckDcRvEMF2FH5+H5W9xG0jTie wTq6+5Zu1FXo4CnvZqunqSI4XC5UH3l1b7UbX3QpoxrvuNrFAzwMM8wbe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJHQoVCtJXG8/2dsb2JhbABEgkm4JAGIeYEIgh4BAQEEEgEaTBACAQgRBAEBCx0HIREUCQgCBAENBQgah1YDDwuaBo9lhkcNiVSLLGmFaWEDlCeCcYoWgyaBa4JiDYIZ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141527613" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 13 Nov 2012 04:51:39 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAD4pdt5027593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Nov 2012 04:51:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 22:51:38 -0600 From: "Tirumaleswar Reddy (tireddy)" To: chen wilson , "behave@ietf.org" Thread-Topic: [BEHAVE] Some questions regarding RFC5766(TURN) authentication Thread-Index: AQHNt5oJ7eBWYbNOjk6k8nO61pJD2pfia5Bg Date: Tue, 13 Nov 2012 04:51:38 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1484849E@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.70.224] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--35.941600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A1484849Exmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "alper.yegin@partner.samsung.com" Subject: Re: [BEHAVE] Some questions regarding RFC5766(TURN) authentication 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, 13 Nov 2012 04:51:40 -0000 --_000_913383AAA69FF945B8F946018B75898A1484849Exmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wilson, In enterprise deployments for webrtc calls TURN server is required to audit= all media sessions from inside the company premises to any external peer (= http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09)= . Hence this will be a important scenario to consider for Enterprise deploy= ments. PANA (RFC 5191) can be used to solve the problem for both STUN/TURN = servers deployed in Enterprise premises. Using PANA for other protocols lik= e PCP is already being discussed in PCP WG. --Tiru. From: chen wilson [mailto:oeichenwei@gmail.com] Sent: Wednesday, October 31, 2012 3:07 AM To: behave@ietf.org Subject: [BEHAVE] Some questions regarding RFC5766(TURN) authentication RFC5389(STUN) section 10 provides 2 ways to do authentication and integrity check while RFC 5766 only supports long-term credential. My question is how to integrate the long-term credential with SSO, for example, SAML mechanism? 2 typical user cases in my mind are: 1. Deploy TURN in enterprise just like HTTP proxy, in such a case, it would be better to authenticate with enterprise Active Directory; 2. Deploy TURN as a cloud service, the service providers would always have their own unified authentication server. Are these 2 user cases typical for TURN? Thanks, Wilson Chen --_000_913383AAA69FF945B8F946018B75898A1484849Exmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi Wilson,
In enterprise deployments for webrtc calls =
TURN server is required to audit all media sessions from inside the company=
 premises to any external peer (http://tools.ietf.org/html/draf=
t-ietf-rtcweb-use-cases-and-requirements-09). Hence this will be a impo=
rtant scenario to consider for Enterprise deployments. PANA (RFC 5191) can =
be used to solve the problem for both STUN/TURN servers deployed in Enterpr=
ise premises. Using PANA for other protocols like PCP is already being disc=
ussed in PCP WG. 
 

--Tiru.

From: chen wil= son [mailto:oeichenwei@gmail.com]
Sent: Wednesday, October 31, 2012 3:07 AM
To: behave@ietf.org
Subject: [BEHAVE] Some questions regarding RFC5766(TURN) authenticat= ion

 

RFC5389(STUN) section 10 provides 2 ways to do authe= ntication and 

integrity check while RFC 5766 only supports lo= ng-term credential.

My question is how to integrate the long-term creden= tial with SSO, 

for example, SAML mechanism?

 

2 typical user cases in my mind are:

1. Deploy TURN in enterprise just like HTTP proxy, i= n such a case, 

it would be better to authenticate with enterprise A= ctive Directory;

2. Deploy TURN as a cloud service, the service provi= ders would 

always have their own unified authentication server.=

Are these 2 user cases typical for TURN?<= /p>

 

Thanks,

Wilson Chen

 

--_000_913383AAA69FF945B8F946018B75898A1484849Exmbrcdx10ciscoc_-- From oeichenwei@gmail.com Fri Nov 16 00:56:43 2012 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 406CB21F8504 for ; Fri, 16 Nov 2012 00:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz-+MDr71UnD for ; Fri, 16 Nov 2012 00:56:42 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7787E21F84F1 for ; Fri, 16 Nov 2012 00:56:42 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so2727440obb.31 for ; Fri, 16 Nov 2012 00:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PpHcTLfWbeOXrmsAu3LD4nqcNYmNkKXr7cvVtnlCoz4=; b=PJQoTH2F6C5bP1UJpFko1QV9xxnWsGpgUYefV12YX60KDQcnRw0WBKChsY5ATAnBrQ ZTecQnNAQvqXBTUlyk3s+6Wr2qDljpRCce3lzxuASMCKFePgRzjrAXbNF7qFyLcSN4IL Ry70ddSY0uiAh1z4L9qpTQD6JSxIOz0JN7x5PmBsIrB6izfelaPQBpVvqtvUJ86j/xWb d+E4G1fNRSiolDmt4jh4Ic54VWsQSuhFG/uPO0OFLaHpk4WHXJmsn6ypieClDazJcfVF rHE+kSwS/2JUm3a/orvGmjOOcwIvlOW1VZdOJBvnXB4PXWbhRqVDHN7qN8cqM1C0D0hn Am3g== MIME-Version: 1.0 Received: by 10.182.152.4 with SMTP id uu4mr3197175obb.85.1353056201951; Fri, 16 Nov 2012 00:56:41 -0800 (PST) Received: by 10.182.73.161 with HTTP; Fri, 16 Nov 2012 00:56:41 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A1484849E@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1484849E@xmb-rcd-x10.cisco.com> Date: Fri, 16 Nov 2012 16:56:41 +0800 Message-ID: From: chen wilson To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=f46d0444ece54747f704ce98f2fa Cc: "alper.yegin@partner.samsung.com" , "behave@ietf.org" Subject: Re: [BEHAVE] Some questions regarding RFC5766(TURN) authentication 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, 16 Nov 2012 08:56:43 -0000 --f46d0444ece54747f704ce98f2fa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Tiru, I take a look at the PANA, it didn't clear my confusion. My real headache is TURN needs to generate long-term credential attribute, it requires a username and password, how to choose the username? In enterprise, I have a domain account with realm -- that is my windows credential. I would like user to use that credential, but the TURN server is most likely to be deployed in DMZ, AD-DS is always in internal network, so how can TURN get the username and password to verify my TURN authentication attribute? Thanks, Wilson Chen On Tue, Nov 13, 2012 at 12:51 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Wilson,**** > > ** ** > > In enterprise deployments for webrtc calls TURN server is required to aud= it all media sessions from inside the company premises to any external peer= (http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-0= 9). Hence this will be a important scenario to consider for Enterprise depl= oyments. PANA (RFC 5191) can be used to solve the problem for both STUN/TUR= N servers deployed in Enterprise premises. Using PANA for other protocols l= ike PCP is already being discussed in PCP WG. **** > > ** ** > > --Tiru.**** > > *From:* chen wilson [mailto:oeichenwei@gmail.com] > *Sent:* Wednesday, October 31, 2012 3:07 AM > *To:* behave@ietf.org > *Subject:* [BEHAVE] Some questions regarding RFC5766(TURN) authentication= * > *** > > ** ** > > RFC5389(STUN) section 10 provides 2 ways to do authentication and **** > > integrity check while RFC 5766 only supports long-term credential.**** > > My question is how to integrate the long-term credential with SSO, **** > > for example, SAML mechanism?**** > > ** ** > > 2 typical user cases in my mind are:**** > > 1. Deploy TURN in enterprise just like HTTP proxy, in such a case, **** > > it would be better to authenticate with enterprise Active Directory;**** > > 2. Deploy TURN as a cloud service, the service providers would **** > > always have their own unified authentication server.**** > > Are these 2 user cases typical for TURN?**** > > ** ** > > Thanks,**** > > Wilson Chen**** > > ** ** > --f46d0444ece54747f704ce98f2fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Tiru,=A0

I take a look at the PANA, it didn't= clear my confusion.
My real headache is TURN needs to generate l= ong-term credential attribute, it requires a username and password, how to = choose the username?
In enterprise, I have a domain account with realm -- that is my window= s credential. I would like user to use that credential, but the TURN server= is most likely to be deployed in DMZ, AD-DS is always in internal network,= so how can TURN get the username and password to verify my TURN authentica= tion attribute?


Thanks,
Wilson Chen=A0


On Tue, Nov 13,= 2012 at 12:51 PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>= wrote:
Hi Wilson,
=A0
In enterprise deployments for webrtc calls =
TURN server is required to audit all media sessions from inside the company=
 premises to any external peer (http://tools.=
ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09). Hence t=
his will be a important scenario to consider for Enterprise deployments. PA=
NA (RFC 5191) can be used to solve the problem for both STUN/TURN servers d=
eployed in Enterprise premises. Using PANA for other protocols like PCP is =
already being discussed in PCP WG. 
=A0

--Tiru.

From: chen wil= son [mailto:oeich= enwei@gmail.com]
Sent: Wednesday, October 31, 2012 3:07 AM
To: behave@ietf= .org
Subject: [BEHAVE] Some questions regarding RFC5766(TURN) authenticat= ion

=A0

RFC5389(STUN) section 10 provides 2 ways to do authe= ntication and=A0

integrity=A0check while RFC 5766 only supports long-= term credential.

My question is how to integrate the long-term creden= tial with SSO,=A0

for example, SAML=A0mechanism?

=A0

2 typical user cases in my mind are:

1. Deploy TURN in enterprise just like HTTP proxy, i= n such a case,=A0

it would be better to authenticate with enterprise A= ctive Directory;

2. Deploy TURN as a cloud service, the service provi= ders would=A0

always have their own unified authentication server.=

Are these 2 user cases typical for TURN?

=A0

Thanks,

Wilson Chen

=A0


--f46d0444ece54747f704ce98f2fa-- From internet-drafts@ietf.org Mon Nov 26 22:41:07 2012 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 A0AAB21F867E; Mon, 26 Nov 2012 22:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG83mpm2Yuyr; Mon, 26 Nov 2012 22:41:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632B821F8434; Mon, 26 Nov 2012 22:41:06 -0800 (PST) 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.36 Message-ID: <20121127064106.31268.35576.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 22:41:06 -0800 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-13.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, 27 Nov 2012 06:41:07 -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-13.txt Pages : 18 Date : 2012-11-26 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 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat64-discovery-heuris= tic-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alper.yegin@yegin.org Tue Nov 27 11:01:50 2012 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 BF78921F878A for ; Tue, 27 Nov 2012 11:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI5S6505UDvt for ; Tue, 27 Nov 2012 11:01:50 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id C331921F8731 for ; Tue, 27 Nov 2012 11:01:49 -0800 (PST) Received: from [192.168.2.9] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MA9IX-1TWZre2gy9-00BCU5; Tue, 27 Nov 2012 14:01:46 -0500 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_518A19A3-F038-4FC9-AE57-C915EB0660A1" Date: Tue, 27 Nov 2012 21:01:24 +0200 Message-Id: To: behave@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:ZgFhr3XzS27e8jkaaMJfDAha6J85Zzrsg6qNzww+rYp 15X1jtmjx8NUAZPjrS47/qqb8yreUyIAvqxFPal7wsUxZe60M1 xO6DGyFy3fP/e4C8qchOowup3D3IyjfsDCdZC+42FYvw84FDKF 4+WDhZ/d3v7W/26LdebqWtHv7mdp2s+8TAClSm8V6Jl60ddrUB TkPZfUDfqY7lEsQ+Poz3RKB9zmvdKpcx9/qD/mBi62GXEO3wCO did3r4SZy5VEHlZ37vXLm1Xif5NdnAqiVc2gNW0EtNx6YGcuI0 mToth/PMFPaCkNndV97r4+kjdkBsjTDI0xjSgwiWP9GP5/3L5v 1NBDxv8hGLII10Eb19Oxn60IniW8qvtD3lL7bh9fbldKD2SL/e E49zi+rP0JzDQ== Cc: oeichenwei@gmail.com, tireddy@cisco.com Subject: Re: [BEHAVE] Some questions regarding RFC5766(TURN) authentication 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, 27 Nov 2012 19:01:50 -0000 --Apple-Mail=_518A19A3-F038-4FC9-AE57-C915EB0660A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, I may not be understanding the problem well. Nevertheless, let me share = the following points based on some understanding, and let's see if they = are useful. As I see, TURN is relying on a username/password based credential for = message integrity protection. Username/password is agreed between the end-points using an out-of band = mechanism. (Actually, if the protocol were relying on PSK-based credentials = [ID/PSK] that'd be more secure and modular=85 If it is not too late, = please consider that as well. Probably that's a side improvement.) PANA can be the out-of band mechanism to populate the credential = (whether it's username/password, or PSK-based) to be used with TURN.=20 Input to the PANA authentication is a set of credentials. The output is another set of credentials (e.g., session credentials). = Such as ID/PSK, or username/password. The output credentials can be used with TURN to secure the TURN = signaling. PANA end-points are same as TURN end-points. But, if the server-side = end-point is not in a position to authenticate the client (because it = does not have access to the user DB), then it can utilize another = protocol (RADIUS or Diameter) to reach another the server that has = access to such DB. PANA and RADIUS run in conjunction to perform = authentication and generate session credentials. So, we are talking about the TURN server also implementing the PANA = Authentication Server functionality. In that case, TURN server does not = have to know or learn the "windows credential". It'll talk to the a = RADIUS/Diameter server that knows the windows credential to authenticate = the client, and receive a session credential (a temporary-use = credential), which gets used for securing TURN. Alper Thanks Tiru,=20 I take a look at the PANA, it didn't clear my confusion. My real headache is TURN needs to generate long-term credential = attribute, it requires a username and password, how to choose the = username? In enterprise, I have a domain account with realm -- that is my windows = credential. I would like user to use that credential, but the TURN = server is most likely to be deployed in DMZ, AD-DS is always in internal = network, so how can TURN get the username and password to verify my TURN = authentication attribute? Thanks, Wilson Chen=20 On Tue, Nov 13, 2012 at 12:51 PM, Tirumaleswar Reddy (tireddy) wrote: Hi Wilson, =20 In enterprise deployments for webrtc calls TURN server is required to = audit all media sessions from inside the company premises to any = external peer = (http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-0= 9). Hence this will be a important scenario to consider for Enterprise = deployments. PANA (RFC 5191) can be used to solve the problem for both = STUN/TURN servers deployed in Enterprise premises. Using PANA for other = protocols like PCP is already being discussed in PCP WG.=20 =20 --Tiru. From: chen wilson [mailto:oeichenwei at gmail.com]=20 Sent: Wednesday, October 31, 2012 3:07 AM To: behave at ietf.org Subject: [BEHAVE] Some questions regarding RFC5766(TURN) authentication =20 RFC5389(STUN) section 10 provides 2 ways to do authentication and=20 integrity check while RFC 5766 only supports long-term credential. My question is how to integrate the long-term credential with SSO,=20 for example, SAML mechanism? =20 2 typical user cases in my mind are: 1. Deploy TURN in enterprise just like HTTP proxy, in such a case,=20 it would be better to authenticate with enterprise Active Directory; 2. Deploy TURN as a cloud service, the service providers would=20 always have their own unified authentication server. Are these 2 user cases typical for TURN? =20 Thanks, Wilson Chen =20= --Apple-Mail=_518A19A3-F038-4FC9-AE57-C915EB0660A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello,

I may not be = understanding the problem well. Nevertheless, let me share the following = points based on some understanding, and let's see if they are = useful.


As I see, TURN is = relying on a username/password based credential for message integrity = protection.
Username/password is agreed between the = end-points using an out-of band mechanism.

(Actually, if the protocol were relying on = PSK-based credentials [ID/PSK] that'd be more secure and modular=85 If = it is not too late, please consider that as well. Probably that's a side = improvement.)

PANA can be the out-of = band mechanism to populate the credential (whether it's = username/password, or PSK-based) to be used with = TURN. 

Input to the PANA = authentication is a set of credentials.
The output is another = set of credentials (e.g., session credentials). Such as ID/PSK, or = username/password.
The output credentials can be used with TURN to = secure the TURN signaling.

PANA end-points are same as TURN end-points. But, = if the server-side end-point is not in a position to authenticate the = client (because it does not have access to the user DB), then it can = utilize another protocol (RADIUS or Diameter) to reach another the = server that has access to such DB. PANA and RADIUS run in conjunction to = perform authentication and generate session = credentials.

So, we are talking = about the TURN server also implementing the PANA Authentication Server = functionality. In that case, TURN server does not have to know or learn = the "windows credential". It'll talk to the a RADIUS/Diameter server = that knows the windows credential to authenticate the client, and = receive a session credential (a temporary-use credential), which gets = used for securing TURN.

Alper













Thanks = Tiru, 

I take a look at the PANA, it didn't = clear my confusion.
My real = headache is TURN needs to generate long-term credential attribute, it = requires a username and password, how to choose the username?
In enterprise, I have a domain account = with realm -- that is my windows credential. I would like user to use = that credential, but the TURN server is most likely to be deployed in = DMZ, AD-DS is always in internal network, so how can TURN get the = username and password to verify my TURN authentication = attribute?


Thanks,
Wilson = Chen 
On Tue, Nov 13, 2012 at 12:51 PM, = Tirumaleswar Reddy (tireddy) <tireddy at = cisco.com> wrote:
Hi =
Wilson,
In =
enterprise deployments for webrtc calls TURN server is required to audit =
all media sessions from inside the company premises to any external peer =
(http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-a=
nd-requirements-09). Hence this will be a important scenario to =
consider for Enterprise deployments. PANA (RFC 5191) can be used to =
solve the problem for both STUN/TURN servers deployed in Enterprise =
premises. Using PANA for other protocols like PCP is already being =
discussed in PCP WG. 
 

From: chen = wilson [mailto:oeichenwei = at gmail.com] 
Sent: Wednesday, October 31, 2012 = 3:07 AM
To: behave at = ietf.org
Subject: [BEHAVE] Some questions regarding = RFC5766(TURN) = authentication

 

RFC5389(STUN) section 10 provides 2 ways to do = authentication and 

integrity check while RFC 5766 only supports = long-term credential.

My question is how to integrate the long-term = credential with SSO, 

for example, = SAML mechanism?

 

2 typical user cases in my mind = are:

1. Deploy TURN = in enterprise just like HTTP proxy, in such a = case, 

it would = be better to authenticate with enterprise Active = Directory;

2. Deploy = TURN as a cloud service, the service providers = would 

always = have their own unified authentication = server.

Are these 2 = user cases typical for TURN?

 

Thanks,

Wilson Chen

 

<= /blockquote>
= --Apple-Mail=_518A19A3-F038-4FC9-AE57-C915EB0660A1-- From oeichenwei@gmail.com Wed Nov 28 02:04:46 2012 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 B81A321F8763 for ; Wed, 28 Nov 2012 02:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNzWc+Ybo09e for ; Wed, 28 Nov 2012 02:04:46 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2567E21F8760 for ; Wed, 28 Nov 2012 02:04:46 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so1319542obq.31 for ; Wed, 28 Nov 2012 02:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+P6zM+UzIFMBxDgzRslh58nQLh9J0tFuxz7RS/DlEAI=; b=ZW+kABkdpzSsNxQpX6GW92Vyq30yv4Y/uhYcpwpyFcsLqrdmMqoOzk/cpUurhBsC7C U+4fYjG6ZOYREadjxmXLFvZwEAuUOEb7LVTKZDlz7aa1JBw+XFTAa/GTciIu8cFCj4GE 0bCM3i7s8syyN1JO2DOd3gAbKj99Vw0xGHd86fVioarPYvSTTkkxD8mzfgfSsfPstQSi EwCWdi1igDfJhMMrHSW1+Srh9nhr9srRiOSyng4g+BkuDjVK8QwTWSu5XTrY3mnS5RxE qBG/lcsS/7YuLXWA7DseUs6VJPhqcJKhrRHramfDrDXTSbv7gtZmA6DB2Ds3GuEuIRZJ bNgQ== MIME-Version: 1.0 Received: by 10.182.157.45 with SMTP id wj13mr2471091obb.58.1354097085641; Wed, 28 Nov 2012 02:04:45 -0800 (PST) Received: by 10.182.73.161 with HTTP; Wed, 28 Nov 2012 02:04:45 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Nov 2012 18:04:45 +0800 Message-ID: From: chen wilson To: Alper Yegin Content-Type: multipart/alternative; boundary=f46d044269dcc7f1ea04cf8b4b6f Cc: "behave@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [BEHAVE] Some questions regarding RFC5766(TURN) authentication 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, 28 Nov 2012 10:04:46 -0000 --f46d044269dcc7f1ea04cf8b4b6f Content-Type: text/plain; charset=ISO-8859-1 Alper, Thank you, that is useful for me! PANA is an option for out-of-band mechanism to negotiate a temporary username/password (ID/PSK) between client and server, and ID/PSK is really a good practice which I will take! - Wilson On Wed, Nov 28, 2012 at 3:01 AM, Alper Yegin wrote: > RFC 5191 --f46d044269dcc7f1ea04cf8b4b6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Alper, =A0
<= br>
Thank you, that is useful for me!
=
PANA is an option for out-of-band mechanism to n= egotiate a temporary username/password (ID/PSK) between client and server,= =A0and ID/PSK is really a good practice which I will take!

- Wilson

On Wed, Nov 28= , 2012 at 3:01 AM, Alper Yegin <alper.yegin@yegin.org> w= rote:
RFC 5191

--f46d044269dcc7f1ea04cf8b4b6f--